WO2017119802A1 - 무선 통신 시스템에서 nidd(non-ip data delivery) 구성 설정 방법 및 이를 위한 장치 - Google Patents

무선 통신 시스템에서 nidd(non-ip data delivery) 구성 설정 방법 및 이를 위한 장치 Download PDF

Info

Publication number
WO2017119802A1
WO2017119802A1 PCT/KR2017/000294 KR2017000294W WO2017119802A1 WO 2017119802 A1 WO2017119802 A1 WO 2017119802A1 KR 2017000294 W KR2017000294 W KR 2017000294W WO 2017119802 A1 WO2017119802 A1 WO 2017119802A1
Authority
WO
WIPO (PCT)
Prior art keywords
scef
nidd
terminal
scs
mme
Prior art date
Application number
PCT/KR2017/000294
Other languages
English (en)
French (fr)
Inventor
류진숙
김래영
Original Assignee
엘지전자(주)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자(주) filed Critical 엘지전자(주)
Priority to US16/068,598 priority Critical patent/US10652085B2/en
Publication of WO2017119802A1 publication Critical patent/WO2017119802A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/04—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration using triggered events

Definitions

  • the present invention relates to a wireless communication system, and more particularly, to a method and apparatus for supporting a non-IP data delivery (NIDD) configuration of a network node.
  • NIDD non-IP data delivery
  • Mobile communication systems have been developed to provide voice services while ensuring user activity.
  • the mobile communication system has expanded not only voice but also data service.As a result of the explosive increase in traffic, a shortage of resources and users are demanding higher speed services, a more advanced mobile communication system is required. have.
  • Small data transmission and reception using the SCEF includes a mobile originated call, and according to the current standard, when the NIDD configuration is not set / established, the core network node processes this even if the terminal transmits the origination signal. I can't. However, since the terminal does not know whether the current NIDD can be performed, even though the current NIDD configuration is not set / established, small data (ie, an outgoing signal) is transmitted. As a result, if the MME that receives it does not buffer the small data received from the terminal until the NIDD configuration is set, inefficiency / problem that the small data is discarded is generated.
  • an object of the present invention is to propose an NIDD configuration setting method for smoothly transmitting / receiving transmission of small data (eg, non-IP data) of a terminal by checking / setting the NIDD configuration in a network node.
  • small data eg, non-IP data
  • An aspect of the present invention provides a method for setting a non-IP data delivery (NIDD) configuration by a service capability exposure function (SCEF) in a wireless communication system, the non-IP of a terminal from a network node.
  • SCEF service capability exposure function
  • the first SCEF connection setup request includes an external identifier of the terminal and an SCS / AS identifier of a services capability server (SCS) / application server (AS) serving the terminal.
  • SCS services capability server
  • AS application server
  • Determining whether the NIDD configuration with is established If the NIDD configuration is not established, sending a second SCEF connection setup request to the SCS / AS to establish the NIDD configuration; Wherein the second SCEF connection setup request includes the external identifier of the terminal, and setting the NIDD configuration for the SCS / AS and the terminal; It may include.
  • the external identifier of the terminal may correspond to the International Mobile Subscriber Identity (IMSI) of the terminal, and the SCS / AS ID may be stored in the HSS as subscription information of the terminal.
  • IMSI International Mobile Subscriber Identity
  • the network node may correspond to a home subscriber server (HSS) or a mobility management entity (MME).
  • HSS home subscriber server
  • MME mobility management entity
  • a first SCEF connection setup request may be received from the MME.
  • the network node corresponds to the HSS and the HSS determines that the NIDD configuration for the non-IP data transmission is necessary through an update location request (ULR) message
  • the first SCEF connection setup request This may be received from the HSS.
  • the setting of the NIDD configuration may include: receiving a first NIDD configuration request message requesting the NIDD configuration setting with the terminal from the SCS / AS; And transmitting a second NIDD configuration request message for setting the NIDD configuration to an HSS based on the received first NIDD configuration request message.
  • the first and second NIDD configuration request messages may include an SCS / AS identifier and an SCS / AS reference identifier for the SCS / AS, a maximum number of NIDDs, an NIDD duration, and / or an NIDD destination. ) May include an address.
  • the NIDD configuration setting method may further include: receiving a first MO NIDD indication message indicating transmission of Mobile Originated (MO) data as the non-IP data after the NIDD configuration is set; And transmitting a second MO NIDD indication message to the SCS / AS.
  • the first and second MO NIDD indication messages may further include the SCEF reference identifier and the call signal data.
  • the NIDD configuration setting method may further include receiving a first MO NIDD Acck message in response to the second MO NIDD indication message; And sending a second MO NIDD Acck (ACK) message in response to the first MO NIDD indication message; It may further include.
  • the NIDD configuration setting method may further include: receiving, from the SCS / AS, a first MT NIDD request message notifying transmission of mobile terminated (MT) data as the non-IP data after the NIDD configuration is set; And sending a second MO NIDD request message;
  • the first and second MO NIDD request messages may further include the SCEF reference identifier and the incoming call data.
  • the NIDD configuration setting method may further include receiving a second MT NIDD response message as a response to the second MT NIDD request message; And sending a first MT NIDD response message as a response to the first MT NIDD request message.
  • the second MT NIDD response message may further include a cause value indicating a reason why transmission is impossible when it is determined by the MME that the incoming call data cannot be transmitted.
  • SCEF Service Capability Exposure Function
  • Communication module for transmitting and receiving signals (communication module);
  • a processor controlling the communication module.
  • the processor receives a first SCEF connection setup request for non-IP data transmission of the terminal from a network node, wherein the first SCEF connection setup request is an external identifier of the terminal.
  • an SCS / AS identifier of a Services Capability Server (SCS) / Application Server (AS) serving the terminal determines whether the NIDD configuration with the SCS / AS is established, and the NIDD configuration is not established.
  • SCS Services Capability Server
  • AS Application Server
  • a second SCEF connection setup request for establishing the NIDD configuration is transmitted to the SCS / AS, wherein the second SCEF connection setup request includes the external identifier of the terminal, to the SCS / AS and the terminal.
  • the external identifier of the terminal may correspond to the International Mobile Subscriber Identity (IMSI) of the terminal, and the SCS / AS ID may be stored in the HSS as subscription information of the terminal.
  • IMSI International Mobile Subscriber Identity
  • the network node may correspond to a home subscriber server (HSS) or a mobility management entity (MME).
  • HSS home subscriber server
  • MME mobility management entity
  • a first SCEF connection setup request may be received from the MME.
  • the network node corresponds to the HSS and the HSS determines that the NIDD configuration for the non-IP data transmission is necessary through an update location request (ULR) message
  • the first SCEF connection setup request This may be received from the HSS.
  • the terminal recognizes whether the current configuration of the NIDD configuration, the small data can be transmitted when the NIDD configuration is set, the effect that the problem that the small data is discarded (discard) is reduced Occurs.
  • the SCS / AS when the terminal performs data transmission and reception through the SCEF at the time of attachment, the SCS / AS is not waiting for the establishment / execution of the NIDD configuration triggered by the SCS / AS at the network end directly. Since the AS can actively request the NIDD configuration, the small data transmission and reception of the UE can be performed smoothly.
  • FIG. 1 is a view briefly illustrating an EPS (Evolved Packet System) to which the present invention can be applied.
  • EPS Evolved Packet System
  • E-UTRAN evolved universal terrestrial radio access network
  • FIG. 3 illustrates the structure of an E-UTRAN and an EPC in a wireless communication system to which the present invention can be applied.
  • FIG. 4 shows a structure of a radio interface protocol between a terminal and an E-UTRAN in a wireless communication system to which the present invention can be applied.
  • FIG. 5 is a diagram exemplarily illustrating a structure of a physical channel in a wireless communication system to which the present invention can be applied.
  • FIG. 6 is a diagram for explaining a contention based random access procedure in a wireless communication system to which the present invention can be applied.
  • FIG. 7 is a flowchart illustrating an access procedure according to an embodiment of the present invention.
  • FIG. 8 is a diagram exemplarily illustrating a PDN connection procedure in a wireless communication system to which the present invention can be applied.
  • FIG. 9 is a diagram illustrating a Machine-Type Communication (MTC) architecture in a wireless communication system to which the present invention may be applied.
  • MTC Machine-Type Communication
  • FIG. 10 illustrates an architecture for Service Capability Exposure in a wireless communication system to which the present invention can be applied.
  • FIG. 11 is a diagram illustrating an end-to-end small data flow in a wireless communication system to which the present invention can be applied.
  • FIG. 12 illustrates a cellular IoT network architecture proposed for efficient non-IP small data transmission via SCEF in a wireless communication system to which the present invention can be applied.
  • FIG. 13 illustrates a procedure for setting and deleting a monitoring event through an HSS in a wireless communication system to which the present invention can be applied.
  • FIG. 14 illustrates an MO small data transmission procedure in a wireless communication system to which the present invention can be applied.
  • 15 illustrates an MT small data transmission procedure in a wireless communication system to which the present invention can be applied.
  • 16 illustrates a link setup process for transmitting UL / DL data (ie, non-IP data) through MME and SCEF in a wireless communication system to which the present invention can be applied.
  • UL / DL data ie, non-IP data
  • FIG. 17 illustrates an NIDD configuration procedure in a wireless communication system to which the present invention can be applied.
  • FIG. 18 illustrates a MO NIDD procedure in a wireless communication system to which the present invention can be applied.
  • FIG. 19 illustrates an MT NIDD procedure in a wireless communication system to which the present invention can be applied.
  • 20 is a flowchart illustrating an access procedure for SCEF connection according to a first embodiment of the present invention.
  • 21 is a flowchart illustrating an access procedure for SCEF connection according to a second embodiment of the present invention.
  • FIG. 22 is a flowchart illustrating an NIDD configuration setting procedure according to an embodiment of the present invention.
  • FIG. 23 illustrates a block diagram of a communication device according to an embodiment of the present invention.
  • 24 is a block diagram of a communication device according to one embodiment of the present invention.
  • a base station has a meaning as a terminal node of a network that directly communicates with a terminal.
  • the specific operation described as performed by the base station in this document may be performed by an upper node of the base station in some cases. That is, it is obvious that various operations performed for communication with a terminal in a network composed of a plurality of network nodes including a base station may be performed by the base station or other network nodes other than the base station.
  • a 'base station (BS)' may be replaced by terms such as a fixed station, a Node B, an evolved-NodeB (eNB), a base transceiver system (BTS), an access point (AP), and the like. .
  • a 'terminal' may be fixed or mobile, and may include a user equipment (UE), a mobile station (MS), a user terminal (UT), a mobile subscriber station (MSS), a subscriber station (SS), and an AMS ( Advanced Mobile Station (WT), Wireless Terminal (WT), Machine-Type Communication (MTC) Device, Machine-to-Machine (M2M) Device, Device-to-Device (D2D) Device, etc.
  • UE user equipment
  • MS mobile station
  • UT user terminal
  • MSS mobile subscriber station
  • SS subscriber station
  • AMS Advanced Mobile Station
  • WT Wireless Terminal
  • MTC Machine-Type Communication
  • M2M Machine-to-Machine
  • D2D Device-to-Device
  • downlink means communication from a base station to a terminal
  • uplink means communication from a terminal to a base station.
  • a transmitter may be part of a base station, and a receiver may be part of a terminal.
  • a transmitter may be part of a terminal and a receiver may be part of a base station.
  • CDMA code division multiple access
  • FDMA frequency division multiple access
  • TDMA time division multiple access
  • OFDMA orthogonal frequency division multiple access
  • SC-FDMA single carrier frequency division multiple access
  • GSM global system for mobile communications
  • GPRS general packet radio service
  • EDGE enhanced data rates for GSM evolution
  • OFDMA may be implemented in a wireless technology such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, evolved UTRA (E-UTRA).
  • UTRA is part of a universal mobile telecommunications system (UMTS).
  • 3rd generation partnership project (3GPP) long term evolution (LTE) is a part of evolved UMTS (E-UMTS) using E-UTRA, and employs OFDMA in downlink and SC-FDMA in uplink.
  • LTE-A (advanced) is the evolution of 3GPP LTE.
  • Embodiments of the present invention may be supported by standard documents disclosed in at least one of the wireless access systems IEEE 802, 3GPP and 3GPP2. That is, steps or parts which are not described to clearly reveal the technical spirit of the present invention among the embodiments of the present invention may be supported by the above documents. In addition, all terms disclosed in the present document can be described by the above standard document.
  • UMTS Universal Mobile Telecommunications System
  • GSM Global System for Mobile Communication
  • Evolved Packet System A network system consisting of an Evolved Packet Core (EPC), which is a packet switched core network based on Internet Protocol (IP), and an access network such as LTE and UTRAN.
  • EPC Evolved Packet Core
  • IP Internet Protocol
  • UMTS is an evolutionary network.
  • NodeB base station of UMTS network. It is installed outdoors and its coverage is macro cell size.
  • eNodeB base station of EPS network. It is installed outdoors and its coverage is macro cell size.
  • a terminal may be referred to in terms of terminal, mobile equipment (ME), mobile station (MS), and the like.
  • the terminal may be a portable device such as a laptop, a mobile phone, a personal digital assistant (PDA), a smartphone, a multimedia device, or the like, or may be a non-portable device such as a personal computer (PC) or a vehicle-mounted device.
  • the term "terminal” or “terminal” in the MTC related content may refer to an MTC terminal.
  • IMS IP Multimedia Subsystem
  • IMSI International Mobile Subscriber Identity
  • Machine Type Communication Communication performed by a machine without human intervention. It may also be referred to as M2M (Machine to Machine) communication.
  • MTC terminal MTC UE or MTC device or MTC device: a terminal (eg, vending machine, etc.) having a function of communicating via a mobile communication network (for example, communicating with an MTC server via a PLMN) and performing an MTC function; Meter reading, etc.).
  • MTC UE or MTC device or MTC device a terminal having a function of communicating via a mobile communication network (for example, communicating with an MTC server via a PLMN) and performing an MTC function; Meter reading, etc.).
  • MTC server A server on a network that manages an MTC terminal. It may exist inside or outside the mobile communication network. It may have an interface that an MTC user can access. In addition, the MTC server may provide MTC related services to other servers (Services Capability Server (SCS)), or the MTC server may be an MTC application server.
  • SCS Services Capability Server
  • MTC mobile broadband
  • services e.g., remote meter reading, volume movement tracking, weather sensors, etc.
  • (MTC) application server a server on a network where (MTC) applications run
  • MTC feature A function of a network to support an MTC application.
  • MTC monitoring is a feature for preparing for loss of equipment in an MTC application such as a remote meter reading
  • low mobility is a feature for an MTC application for an MTC terminal such as a vending machine.
  • the MTC user uses a service provided by the MTC server.
  • MTC subscriber An entity having a connection relationship with a network operator and providing a service to one or more MTC terminals.
  • MTC group A group of MTC terminals that share at least one MTC feature and belongs to an MTC subscriber.
  • SCS Services Capability Server
  • MTC-IWF MTC InterWorking Function
  • HPLMN Home PLMN
  • SCS provides the capability for use by one or more MTC applications.
  • External Identifier An identifier used by an external entity (e.g., an SCS or application server) of a 3GPP network to point to (or identify) an MTC terminal (or a subscriber to which the MTC terminal belongs). Globally unique.
  • the external identifier is composed of a domain identifier and a local identifier as follows.
  • Domain Identifier An identifier for identifying a domain in a control term of a mobile communication network operator.
  • One provider may use a domain identifier for each service to provide access to different services.
  • Local Identifier An identifier used to infer or obtain an International Mobile Subscriber Identity (IMSI). Local identifiers must be unique within the application domain and are managed by the mobile telecommunications network operator.
  • IMSI International Mobile Subscriber Identity
  • RAN Radio Access Network: a unit including a Node B, a Radio Network Controller (RNC), and an eNodeB controlling the Node B in a 3GPP network. It exists at the terminal end and provides connection to the core network.
  • RNC Radio Network Controller
  • HLR Home Location Register
  • HSS Home Subscriber Server
  • RANAP RAN Application Part: between the RAN and the node in charge of controlling the core network (ie, Mobility Management Entity (MME) / Serving General Packet Radio Service (GPRS) Supporting Node) / MSC (Mobile Switching Center) Interface.
  • MME Mobility Management Entity
  • GPRS General Packet Radio Service
  • MSC Mobile Switching Center
  • PLMN Public Land Mobile Network
  • Non-Access Stratum A functional layer for transmitting and receiving signaling and traffic messages between a terminal and a core network in a UMTS and EPS protocol stack. The main function is to support the mobility of the terminal and to support the session management procedure for establishing and maintaining an IP connection between the terminal and the PDN GW.
  • SEF Service Capability Exposure Function
  • FIG. 1 is a diagram briefly illustrating an EPS (Evolved Packet System) to which the present invention may be applied.
  • EPS Evolved Packet System
  • the network structure diagram of FIG. 1 briefly reconstructs a structure of an EPS (Evolved Packet System) including an Evolved Packet Core (EPC).
  • EPS Evolved Packet System
  • EPC Evolved Packet Core
  • EPC Evolved Packet Core
  • SAE System Architecture Evolution
  • SAE is a research project to determine network structure supporting mobility between various kinds of networks.
  • SAE aims to provide an optimized packet-based system, for example, supporting various radio access technologies on an IP basis and providing improved data transfer capability.
  • the EPC is a core network of an IP mobile communication system for a 3GPP LTE system and may support packet-based real-time and non-real-time services.
  • a conventional mobile communication system i.e., a second generation or third generation mobile communication system
  • the core network is divided into two distinct sub-domains of circuit-switched (CS) for voice and packet-switched (PS) for data.
  • CS circuit-switched
  • PS packet-switched
  • the function has been implemented.
  • the sub-domains of CS and PS have been unified into one IP domain.
  • the EPC may include various components, and in FIG. 1, some of them correspond to a Serving Gateway (SGW) (or S-GW), PDN GW (Packet Data Network Gateway) (or PGW or P-GW), A mobility management entity (MME), a Serving General Packet Radio Service (GPRS) Supporting Node (SGSN), and an enhanced Packet Data Gateway (ePDG) are shown.
  • SGW Serving Gateway
  • PDN GW Packet Data Network Gateway
  • MME mobility management entity
  • GPRS General Packet Radio Service
  • SGSN Serving General Packet Radio Service
  • ePDG enhanced Packet Data Gateway
  • the SGW acts as a boundary point between the radio access network (RAN) and the core network, and is an element that functions to maintain a data path between the eNodeB and the PDN GW.
  • the SGW serves as a local mobility anchor point. That is, packets may be routed through the SGW for mobility in the E-UTRAN (Universal Mobile Telecommunications System (Evolved-UMTS) Terrestrial Radio Access Network defined in 3GPP Release-8 or later).
  • E-UTRAN Universal Mobile Telecommunications System (Evolved-UMTS) Terrestrial Radio Access Network defined in 3GPP Release-8 or later.
  • SGW also provides mobility with other 3GPP networks (RANs defined before 3GPP Release-8, such as UTRAN or GERAN (Global System for Mobile Communication (GSM) / Enhanced Data rates for Global Evolution (EDGE) Radio Access Network). It can also function as an anchor point.
  • GSM Global System for Mobile Communication
  • EDGE Enhanced Data rates for Global Evolution
  • the PDN GW corresponds to the termination point of the data interface towards the packet data network.
  • the PDN GW may support policy enforcement features, packet filtering, charging support, and the like.
  • untrusted networks such as 3GPP networks and non-3GPP networks (e.g., Interworking Wireless Local Area Networks (I-WLANs), trusted divisions such as Code Division Multiple Access (CDMA) networks or Wimax). It can serve as an anchor point for mobility management with the network.
  • I-WLANs Interworking Wireless Local Area Networks
  • CDMA Code Division Multiple Access
  • FIG. 1 shows that the SGW and the PDN GW are configured as separate gateways, two gateways may be implemented according to a single gateway configuration option.
  • the MME is an element that performs signaling and control functions for supporting access to a network connection, allocation of network resources, tracking, paging, roaming, handover, and the like.
  • the MME controls the control plane functions related to subscriber and session management.
  • the MME manages a number of eNodeBs and performs signaling for the selection of a conventional gateway for handover to other 2G / 3G networks.
  • the MME also performs functions such as security procedures, terminal-to-network session handling, and idle terminal location management.
  • SGSN handles all packet data, such as user's mobility management and authentication to other 3GPP networks (eg GPRS networks).
  • 3GPP networks eg GPRS networks.
  • the ePDG acts as a secure node for untrusted non-3GPP networks (eg, I-WLAN, WiFi hotspots, etc.).
  • untrusted non-3GPP networks eg, I-WLAN, WiFi hotspots, etc.
  • a terminal having IP capability includes an IP service network provided by an operator (ie, an operator) via various elements in the EPC, based on 3GPP access as well as non-3GPP access.
  • an operator ie, an operator
  • 3GPP access based on 3GPP access as well as non-3GPP access.
  • IMS IMS
  • FIG. 1 illustrates various reference points (eg, S1-U, S1-MME, etc.).
  • a conceptual link defining two functions existing in different functional entities of E-UTRAN and EPC is defined as a reference point.
  • Table 1 below summarizes the reference points shown in FIG. 1.
  • various reference points may exist according to the network structure.
  • S2a and S2b correspond to non-3GPP interfaces.
  • S2a is a reference point that provides the user plane with relevant control and mobility resources between trusted non-3GPP access and PDN GW.
  • S2b is a reference point that provides the user plane with relevant control and mobility support between the ePDG and the PDN GW.
  • E-UTRAN evolved universal terrestrial radio access network
  • the E-UTRAN system is an evolution from the existing UTRAN system and may be, for example, a 3GPP LTE / LTE-A system.
  • Communication networks are widely deployed to provide various communication services, such as voice (eg, Voice over Internet Protocol (VoIP)) over IMS and packet data.
  • voice eg, Voice over Internet Protocol (VoIP)
  • VoIP Voice over Internet Protocol
  • an E-UMTS network includes an E-UTRAN, an EPC, and one or more UEs.
  • the E-UTRAN consists of eNBs providing a control plane and a user plane protocol to the UE, and the eNBs are connected through an X2 interface.
  • X2 user plane interface (X2-U) is defined between eNBs.
  • the X2-U interface provides non guaranteed delivery of user plane packet data units (PDUs).
  • An X2 control plane interface (X2-CP) is defined between two neighboring eNBs.
  • X2-CP performs functions such as context transfer between eNBs, control of user plane tunnel between source eNB and target eNB, delivery of handover related messages, and uplink load management.
  • the eNB is connected to the terminal through a wireless interface and is connected to an evolved packet core (EPC) through the S1 interface.
  • EPC evolved packet core
  • the S1 user plane interface (S1-U) is defined between the eNB and the serving gateway (S-GW).
  • the S1 control plane interface (S1-MME) is defined between the eNB and the mobility management entity (MME).
  • the S1 interface performs an evolved packet system (EPS) bearer service management function, a non-access stratum (NAS) signaling transport function, network sharing, and MME load balancing function.
  • EPS evolved packet system
  • NAS non-access stratum
  • the S1 interface supports a many-to-many-relation between eNB and MME / S-GW.
  • MME provides NAS signaling security, access stratum (AS) security control, inter-CN inter-CN signaling to support mobility between 3GPP access networks, and performing and controlling paging retransmission.
  • EWS Earthquake and Tsunami Warning System
  • CMAS Commercial Mobile Alert System
  • FIG. 3 illustrates the structure of an E-UTRAN and an EPC in a wireless communication system to which the present invention can be applied.
  • an eNB may select a gateway (eg, MME), route to the gateway during radio resource control (RRC) activation, scheduling of a broadcast channel (BCH), and the like. Dynamic resource allocation to the UE in transmission, uplink and downlink, and may perform the function of mobility control connection in the LTE_ACTIVE state.
  • the gateway is responsible for paging initiation, LTE_IDLE state management, ciphering of the user plane, System Architecture Evolution (SAE) bearer control, and NAS signaling encryption. It can perform the functions of ciphering and integrity protection.
  • FIG. 4 shows a structure of a radio interface protocol between a terminal and an E-UTRAN in a wireless communication system to which the present invention can be applied.
  • FIG. 4 (a) shows the radio protocol structure for the control plane and FIG. 4 (b) shows the radio protocol structure for the user plane.
  • the layers of the air interface protocol between the terminal and the E-UTRAN are based on the lower three layers of the open system interconnection (OSI) standard model known in the art of communication systems. It may be divided into a first layer L1, a second layer L2, and a third layer L3.
  • the air interface protocol between the UE and the E-UTRAN consists of a physical layer, a data link layer, and a network layer horizontally, and vertically stacks a protocol stack for transmitting data information. (protocol stack) It is divided into a user plane and a control plane, which is a protocol stack for transmitting control signals.
  • the control plane refers to a path through which control messages used by the terminal and the network to manage a call are transmitted.
  • the user plane refers to a path through which data generated at an application layer, for example, voice data or Internet packet data, is transmitted.
  • an application layer for example, voice data or Internet packet data
  • a physical layer which is a first layer (L1), provides an information transfer service to a higher layer by using a physical channel.
  • the physical layer is connected to a medium access control (MAC) layer located at a higher level through a transport channel, and data is transmitted between the MAC layer and the physical layer through the transport channel.
  • Transport channels are classified according to how and with what characteristics data is transmitted over the air interface.
  • data is transmitted between different physical layers through a physical channel between a physical layer of a transmitter and a physical layer of a receiver.
  • the physical layer is modulated by an orthogonal frequency division multiplexing (OFDM) scheme and utilizes time and frequency as radio resources.
  • OFDM orthogonal frequency division multiplexing
  • a physical downlink control channel is a resource allocation of a paging channel (PCH) and a downlink shared channel (DL-SCH) and uplink shared channel (UL-SCH) to the UE.
  • PCH paging channel
  • DL-SCH downlink shared channel
  • UL-SCH uplink shared channel
  • the PDCCH may carry an UL grant that informs the UE of resource allocation of uplink transmission.
  • PDFICH physical control format indicator channel informs the UE of the number of OFDM symbols used for PDCCHs and is transmitted every subframe.
  • a physical HARQ indicator channel (PHICH) carries a HARQ acknowledgment (ACK) / non-acknowledge (NACK) signal in response to uplink transmission.
  • the physical uplink control channel (PUCCH) carries uplink control information such as HARQ ACK / NACK, downlink request and channel quality indicator (CQI) for downlink transmission.
  • a physical uplink shared channel (PUSCH) carries a UL-SCH.
  • the MAC layer of the second layer provides a service to a radio link control (RLC) layer, which is a higher layer, through a logical channel.
  • RLC radio link control
  • the MAC layer multiplexes / demultiplexes into a transport block provided as a physical channel on a transport channel of a MAC service data unit (SDU) belonging to the logical channel and mapping between the logical channel and the transport channel.
  • SDU MAC service data unit
  • the RLC layer of the second layer supports reliable data transmission. Functions of the RLC layer include concatenation, segmentation, and reassembly of RLC SDUs.
  • the RLC layer In order to guarantee the various quality of service (QoS) required by the radio bearer (RB), the RLC layer has a transparent mode (TM), an unacknowledged mode (UM) and an acknowledgment mode (AM). There are three modes of operation: acknowledge mode.
  • AM RLC provides error correction through an automatic repeat request (ARQ). Meanwhile, when the MAC layer performs an RLC function, the RLC layer may be included as a functional block of the MAC layer.
  • the packet data convergence protocol (PDCP) layer of the second layer (L2) performs user data transmission, header compression, and ciphering functions in the user plane.
  • Header compression is relatively large and large in order to allow efficient transmission of Internet protocol (IP) packets, such as IPv4 (internet protocol version 4) or IPv6 (internet protocol version 6), over a small bandwidth wireless interface. It means the function to reduce the IP packet header size that contains unnecessary control information.
  • IP Internet protocol
  • IPv4 Internet protocol version 4
  • IPv6 Internet protocol version 6
  • a radio resource control (RRC) layer located at the lowest part of the third layer L3 is defined only in the control plane.
  • the RRC layer serves to control radio resources between the terminal and the network.
  • the UE and the network exchange RRC messages with each other through the RRC layer.
  • the RRC layer controls the logical channel, transport channel and physical channel with respect to configuration, re-configuration and release of radio bearers.
  • the radio bearer means a logical path provided by the second layer (L2) for data transmission between the terminal and the network.
  • Establishing a radio bearer means defining characteristics of a radio protocol layer and a channel to provide a specific service, and setting each specific parameter and operation method.
  • the radio bearer may be further divided into two signaling radio bearers (SRBs) and data radio bearers (DRBs).
  • SRB is used as a path for transmitting RRC messages in the control plane
  • DRB is used as a path for transmitting user data in the user plane.
  • a non-access stratum (NAS) layer located above the RRC layer performs functions such as session management and mobility management.
  • NAS non-access stratum
  • One cell constituting the base station is set to one of the bandwidth, such as 1.25, 2.5, 5, 10, 20Mhz to provide a downlink or uplink transmission service to multiple terminals.
  • Different cells may be configured to provide different bandwidths.
  • a downlink transport channel for transmitting data from a network to a terminal includes a broadcast channel (BCH) for transmitting system information, a PCH for transmitting a paging message, and a DL-SCH for transmitting user traffic or control messages.
  • BCH broadcast channel
  • PCH for transmitting a paging message
  • DL-SCH for transmitting user traffic or control messages.
  • Traffic or control messages of the downlink multicast or broadcast service may be transmitted through the DL-SCH or may be transmitted through a separate downlink multicast channel (MCH).
  • an uplink transport channel for transmitting data from a terminal to a network includes a random access channel (RACH) for transmitting an initial control message, and an UL-SCH (uplink shared) for transmitting user traffic or a control message. channel).
  • RACH random access channel
  • UL-SCH uplink shared
  • the logical channel is on top of the transport channel and is mapped to the transport channel.
  • the logical channel may be divided into a control channel for transmitting control region information and a traffic channel for delivering user region information.
  • the control channel includes a broadcast control channel (BCCH), a paging control channel (PCCH), a common control channel (CCCH), a dedicated control channel (DCCH), multicast And a control channel (MCCH: multicast control channel).
  • Traffic channels include a dedicated traffic channel (DTCH) and a multicast traffic channel (MTCH).
  • PCCH is a downlink channel that carries paging information and is used when the network does not know the cell to which the UE belongs.
  • CCCH is used by a UE that does not have an RRC connection with the network.
  • the DCCH is a point-to-point bi-directional channel used by a terminal having an RRC connection for transferring dedicated control information between the UE and the network.
  • DTCH is a point-to-point channel dedicated to one terminal for transmitting user information that may exist in uplink and downlink.
  • MTCH is a point-to-multipoint downlink channel for carrying traffic data from the network to the UE.
  • the DCCH may be mapped to the UL-SCH
  • the DTCH may be mapped to the UL-SCH
  • the CCCH may be mapped to the UL-SCH.
  • the BCCH may be mapped with the BCH or DL-SCH
  • the PCCH may be mapped with the PCH
  • the DCCH may be mapped with the DL-SCH.
  • the DTCH may be mapped with the DL-SCH
  • the MCCH may be mapped with the MCH
  • the MTCH may be mapped with the MCH.
  • FIG. 5 is a diagram exemplarily illustrating a structure of a physical channel in a wireless communication system to which the present invention can be applied.
  • a physical channel transmits signaling and data through a radio resource including one or more subcarriers in a frequency domain and one or more symbols in a time domain.
  • One subframe having a length of 1.0 ms is composed of a plurality of symbols.
  • the specific symbol (s) of the subframe eg, the first symbol of the subframe
  • the PDCCH carries information about dynamically allocated resources (eg, a resource block, a modulation and coding scheme (MCS), etc.).
  • MCS modulation and coding scheme
  • the UE performs an RRC connection re-establishment procedure. Cases are performed.
  • a contention-based random access procedure in which the UE randomly selects and uses one preamble within a specific set And a non-contention based random access procedure using a random access preamble allocated by a base station only to a specific terminal.
  • FIG. 6 is a diagram for explaining a contention based random access procedure in a wireless communication system to which the present invention can be applied.
  • the UE randomly selects one random access preamble (RACH preamble) from a set of random access preambles indicated through system information or a handover command, and A physical RACH (PRACH) resource capable of transmitting a random access preamble is selected and transmitted.
  • RACH preamble random access preamble
  • PRACH physical RACH
  • the base station receiving the random access preamble from the terminal decodes the preamble and obtains an RA-RNTI.
  • the RA-RNTI associated with the PRACH in which the random access preamble is transmitted is determined according to the time-frequency resource of the random access preamble transmitted by the corresponding UE.
  • the base station transmits a random access response addressed to the RA-RNTI obtained through the preamble on the first message to the terminal.
  • the random access response includes a random access preamble identifier (RA preamble index / identifier), an uplink grant (UL grant) indicating an uplink radio resource, a temporary cell identifier (TC-RNTI), and a time synchronization value ( TAC: time alignment commands) may be included.
  • the TAC is information indicating a time synchronization value that the base station sends to the terminal to maintain uplink time alignment.
  • the terminal updates the uplink transmission timing by using the time synchronization value. When the terminal updates the time synchronization, a time alignment timer is started or restarted.
  • the UL grant includes an uplink resource allocation and a transmit power command (TPC) used for transmission of a scheduling message (third message), which will be described later. TPC is used to determine the transmit power for the scheduled PUSCH.
  • TPC transmit power command
  • the base station After the UE transmits the random access preamble, the base station attempts to receive its random access response within the random access response window indicated by the system information or the handover command, and PRACH
  • the PDCCH masked by the RA-RNTI corresponding to the PDCCH is detected, and the PDSCH indicated by the detected PDCCH is received.
  • the random access response information may be transmitted in the form of a MAC packet data unit (MAC PDU), and the MAC PDU may be transmitted through a PDSCH.
  • MAC PDU MAC packet data unit
  • the monitoring stops the random access response.
  • the random access response message is not received until the random access response window ends, or if a valid random access response having the same random access preamble identifier as the random access preamble transmitted to the base station is not received, the random access response is received. Is considered to have failed, and then the UE may perform preamble retransmission.
  • the terminal When the terminal receives a valid random access response to the terminal, it processes each of the information included in the random access response. That is, the terminal applies the TAC, and stores the TC-RNTI. In addition, by using the UL grant, the data stored in the buffer of the terminal or newly generated data is transmitted to the base station.
  • an RRC connection request generated in the RRC layer and delivered through the CCCH may be included in the third message and transmitted.
  • the RRC layer is generated in the RRC layer and CCCH.
  • the RRC connection reestablishment request delivered through the RRC connection reestablishment request may be included in the third message and transmitted. It may also include a NAS connection request message.
  • the third message should include the identifier of the terminal.
  • C-RNTI valid cell identifier allocated in the corresponding cell before the random access procedure
  • the UE If the UE transmits data corresponding to the UL grant, it starts a timer for contention resolution (contention resolution timer).
  • the base station When the base station receives the C-RNTI of the terminal through the third message from the terminal, the base station transmits a fourth message to the terminal using the received C-RNTI.
  • the unique identifier ie, S-TMSI or random number
  • the fourth message is transmitted using the TC-RNTI allocated to the terminal in the random access response.
  • the fourth message may include an RRC connection setup message.
  • the terminal After transmitting the data including its identifier through the UL grant included in the random access response, the terminal waits for an instruction of the base station to resolve the collision. That is, it attempts to receive a PDCCH to receive a specific message.
  • the third message transmitted in response to the UL grant is its C-RNTI
  • the identifier is a unique identifier (that is, In the case of S-TMSI or a random number, it attempts to receive the PDCCH using the TC-RNTI included in the random access response.
  • the terminal determines that the random access procedure has been normally performed, and terminates the random access procedure.
  • the terminal determines that the random access procedure has been normally performed, and terminates the random access procedure.
  • the terminal determines that the random access procedure is normally performed, and terminates the random access procedure.
  • the terminal acquires the C-RNTI through the fourth message, and then the terminal and the network transmit and receive a terminal-specific message using the C-RNTI.
  • the random access procedure is terminated by only transmitting the first message and transmitting the second message.
  • the terminal before the terminal transmits the random access preamble to the base station as the first message, the terminal is allocated a random access preamble from the base station, and transmits the allocated random access preamble to the base station as a first message, and sends a random access response from the base station.
  • the random access procedure is terminated by receiving.
  • the terminal needs to be registered in the network to receive a service requiring registration. Such registration may be referred to as a network connection.
  • a service requiring registration may be referred to as a network connection.
  • an initial access procedure in the E-UTRAN will be described.
  • FIG. 7 is a flowchart illustrating an access procedure according to an embodiment of the present invention.
  • a UE camped in an E-UTRAN cell may initiate an access procedure with a new MME by transmitting an access request message to a base station.
  • the Attach Request message includes an International Mobile Subscriber Identity (IMSI) of the terminal, a PDN type requested by the terminal, and the like.
  • IMSI International Mobile Subscriber Identity
  • PDN type indicates an IP version (ie, IPv4, IPv4v6, IPv6) requested by the terminal.
  • the Attach Request message is included in the RRC Connection Setup Complete message in the RRC connection and delivered, and is included in the Initial UE message in the S1 signaling connection.
  • the terminal may transmit an Attach Request message together with a PDN Connectivity Request message in order to request PDN connectivity.
  • the new MME determines the type of the old node (eg, MME or SGSN), old MME / SGSN
  • the GUTI received from the terminal can be used to derive the address.
  • the new MME may transmit an identification request (including an old GUTI and a complete Attach Request message) to the old MME / SGSN to request IMSI.
  • the old MME may first check a connection request message by the NAS MAC, and may perform an identification response (including IMSI and MM context) as a response to the identification request.
  • the new MME may send an identification request to the terminal to request IMSI.
  • the terminal may respond to the identification request as an identification response including the IMSI.
  • NAS security setup can be performed essentially. If the NAS security algorithm is changed, NAS security setup can be performed at this step.
  • the new MME may retrieve / retrieve an IMEISV (ME Identity) from the terminal.
  • the IMEISV ME Identity
  • the IMEISV ME Identity
  • the new MME is a Ciphered Options (eg, Protocol Configuration Options (PCO) and / or name of PDN (APN)). Can be retrieved / searched from the terminal.
  • PCO Protocol Configuration Options
  • API name of PDN
  • the new MME deletes the bearer context by transmitting an LBI (Delete Session Request) message to the GW.
  • GWs respond with a Delete Session Response (Cause) message.
  • the MME After Detach, the MME has changed, there is no valid UE context in the MME, the UE provides IMSI, the UE provides an invalid old GUTI in the MME, or the PLMN-ID of the TAI by the eNB If the GUTI of the UE context is different in a scenario shared in some networks (eg, GWCN), the MME may transmit an Update Location request message to the HSS.
  • the MME may transmit an Update Location request message to the HSS.
  • the HSS sends Cancel Location (including IMSI, Cancellation Type) to the olde MME.
  • Cancel Location Ack including IMSI
  • MM Mobility Management
  • the old MME / SGSN may remove the bearer context by transmitting a Delete Session Request (LBI) to the GW.
  • the GW may send a Delete Session Response (Cause) to the old MME / SGSN.
  • the HSS may send an Update Location Ack (including IMSI, Subscription data) message to the new MME in response to the Update Location Request message.
  • Update Location Ack including IMSI, Subscription data
  • the MME may apply parameters from the MME emergency configuration data for establishing an emergency bearer performed in this step, and potentially ignore the stored IMSI associated subscription information.
  • the Serving GW creates a new entry in the EPS Bearer Table and sends a Create Session Request message to the PDN GW (or P-GW) indicated by the PDN GW address received in the previous step.
  • the PDN GW performs the IP-CAN Session establishment procedure defined in TS 23.203 [6], whereby the PDN GW obtains the default PCC rules for the UE. do.
  • Steps 12 to 16 described above may be omitted when the ESM (EPS Session Management) container is not included in the access request.
  • ESM EPS Session Management
  • the P-GW creates a new item in the EPS bearer context table and generates a billing ID for the default bearer.
  • the new item allows the P-GW to initiate user plane PDU paths and charging between the S-GW and packet data networks.
  • the P-GW also sends a Create Session Response message to the Serving GW.
  • the Serving GW sends a Create Session Response message to the new MME.
  • the new MME may transmit a downlink NAS transport to the base station along with an initial context setup request or an attach accept.
  • the base station transmits to the terminal including the RRC Connection Reconfiguration message including the EPS Radio Bearer Identity, in which the Attach Accept message is also sent to the terminal.
  • the terminal transmits an RRC Connection Reconfiguration Complete message to the base station.
  • the base station transmits an Initial Context Response message to the new MME.
  • the Initial Context Response message includes the base station's TEID and the address of the base station used for DL traffic of the S1-U reference point.
  • the terminal sends a Direct Transfer message including an Attach Complete message (including the EPS Bearer Identity, NAS sequence number, NAS-MAC) to the base station.
  • an Attach Complete message including the EPS Bearer Identity, NAS sequence number, NAS-MAC
  • the base station sends an Attach Complete message to the new MME.
  • the new MME sends a Modify Bearer Request message to the Serving GW.
  • the Serving GW sends a Modify Bearer Request message (including the handover indication) to the PDN GW.
  • the PDN GW may respond to the Modify Bearer Request message by sending a Modify Bearer Response to the Serving GW.
  • the Serving GW may send a Modify Bearer Response message (including the EPS Bearer Identity) to the new MME.
  • the Serving GW may send buffer DL packets of the Serving GW.
  • the MME sends a Notify Request including the APN and PDN GW identity to the HSS for non-3GPP access.
  • the message includes information identifying the PLMN where the PDN GW is located.
  • the HSS stores the APN and PDN GW identity pair and sends a Notify Response to the MME.
  • the UE requested PDN connectivity procedure is used for the UE to request connection (including assignment of a default bearer) to an additional PDN through the E-UTRAN.
  • FIG. 8 is a diagram exemplarily illustrating a PDN connection procedure in a wireless communication system to which the present invention can be applied.
  • the UE initiates a UE Requested PDN procedure by sending a PDN Connectivity Request message to the MME.
  • the PDN Connectivity Request message includes an APN, a PDN type (ie, an IP version) requested by the UE, and the like.
  • the PDN type indicates the IP version (ie, IPv4, IPv4v6, IPv6) requested by the terminal.
  • the MME verifies whether the APN provided by the terminal is allowed by the subscription information. If the terminal does not provide the APN in the PDN Connectivity Request message, the MME uses the APN from the default PDN subscription context.
  • the MME assigns an EPS bearer ID and sends a Create Session Request message to the S-GW.
  • the Create Session Request message includes the IMSI of the UE, the EPS bearer ID, the P-GW ID selected by the MME for creating the EPS bearer (ie, the P-GW address), the subscription QoS profile received from the APN, and the HSS, and the PDN. Type, IP address (ie, PDN address) of the terminal, and the like.
  • the PDN type includes the same PDN type information received from the terminal.
  • the IP address of the terminal may be set to 0.
  • the static IP address information allocated to the terminal may be Inclusively).
  • the S-GW allocates an S5 S-GW Tunnel Endpoint Identifier (TEID) to create an S5 bearer with the P-GW included in the Create Session Request message received from the MME, and the corresponding P-GW. Send a Create Session Request message to the user.
  • TEID S5 S-GW Tunnel Endpoint Identifier
  • the Create Session Request message includes the IMSI, EPS bearer ID, S5 S-GW TEID, APN, subscription QoS profile, PDN type (i.e., IP version), IP address (i.e., PDN address) of the terminal, and the like. It includes.
  • the P-GW allocates an Internet Protocol (IP) address to be used by the terminal and performs a PCRF and IP connectivity access network (IP-CAN) session establishment / modification procedure.
  • IP Internet Protocol
  • IP-CAN IP connectivity access network
  • the P-GW may allocate an IP address selected from the IP address pool owned by the P-GW to the terminal in the case of dynamic IP address allocation, and a static IP address allocation. ),
  • the fixed IP address information (included in the subscription information) allocated to the terminal may be identically allocated.
  • the P-GW allocates a P-GW Tunnel Endpoint Identifier (TEID) to create an S5 bearer with the S-GW, and responds to the S-GW with a session creation response (in response to a Create Session Request message). Create Session Response) message.
  • TEID P-GW Tunnel Endpoint Identifier
  • the Create Session Response message includes an IMSI of the terminal, an EPS bearer ID, an S5 P-GW TEID, a subscription QoS profile, a PDN type, an IP address assigned to the terminal (ie, a PDN address), and the like.
  • the P-GW indicates to the UE why the PDN type is modified along with the PDN type.
  • the generation of the S5 bearer between the S-GW and the P-GW is completed, and the S-GW may transmit uplink traffic to the P-GW or receive downlink traffic from the P-GW.
  • the S-GW allocates the S1 S-GW TEID to create the S1 bearer, and sends a Create Session Response message to the MME in response to the Create Session Request message.
  • the Create Session Response message includes an IMSI of the terminal, an EPS bearer ID, an S1 S-GW TEID, a PDN type, an IP address assigned to the terminal (ie, a PDN address), and the like.
  • the MME transmits a PDN Connectivity Accept message to the UE in response to the PDN Connectivity Request message.
  • the PDN Connectivity Accept message includes an EPS bearer ID, an APN, an IP address (ie, a PDN address), a PDN type, etc. of a UE allocated by the P-GW.
  • the PDN Connectivity Accept message is included in the bearer setup request message in the S1 signaling connection and delivered to the base station.
  • the base station After completing this procedure, the generation of the uplink S1 bearer between the base station and the S-GW is completed, the base station can transmit the uplink traffic to the S-GW.
  • the PDN Connectivity Accept message is included in the RRC Connection Reconfiguration message in the RRC connection and transmitted from the base station to the terminal.
  • the terminal may transmit the uplink traffic to the base station or receive downlink traffic from the base station.
  • the terminal transmits an RRC connection reconfiguration complete message to the base station.
  • the base station sends a bearer setup response message to the MME.
  • the bearer setup response message includes an S1 eNB TEID.
  • the terminal transmits a PDN Connectivity Complete message including the EPS bearer ID to the MME.
  • the terminal may transmit the uplink data to the P-GW.
  • the MME forwards the S1 eNB TEID received from the base station to the S-GW through a Modify Bearer Request message.
  • the base station can receive the downlink traffic from the S-GW.
  • the S-GW sends a Modify Bearer Response message to the MME in response to the Modify Bearer Request message.
  • the P-GW may transmit the downlink data to the terminal. That is, the terminal may establish a connection with the PDN and receive the PDN service using the assigned IP address.
  • the MME sends a Notify Request message to the HSS that includes the P-GW ID (ie, P-GW address) and APN as needed.
  • P-GW ID ie, P-GW address
  • APN APN
  • the HSS stores the P-GW ID (ie, P-GW address) and associated APN and sends a Notify Response message to the MME.
  • FIG. 9 is a diagram illustrating a Machine-Type Communication (MTC) architecture in a wireless communication system to which the present invention may be applied.
  • MTC Machine-Type Communication
  • An end-to-end application between a terminal (or MTC terminal) used for MTC and an MTC application may use services provided by the 3GPP system and optional services provided to the MTC server.
  • the 3GPP system may provide transport and communication services (including 3GPP bearer services, IMS and SMS) including various optimizations to facilitate MTC.
  • FIG. 9 shows that a terminal used for MTC is connected to a 3GPP network (UTRAN, E-UTRAN, GERAN, I-WLAN, etc.) through a Um / Uu / LTE-Uu interface.
  • the architecture of FIG. 9 includes various MTC models (Direct model, Indirect model, Hybrid model).
  • the application server is a server on a network where an MTC application is executed.
  • the MTC application server the above-described technology for implementing various MTC applications may be applied, and a detailed description thereof will be omitted.
  • the MTC application server may access the MTC server through a reference point API, and a detailed description thereof will be omitted.
  • the MTC Application Server may be collocated with the MTC Server.
  • An MTC server (eg, the SCS server of FIG. 9) is a server on a network managing an MTC terminal and may be connected to a 3GPP network to communicate with terminals and PLMN nodes used for MTC.
  • the MTC-Interworking Function manages the interworking between the MTC server and the operator core network and may serve as a proxy for the MTC operation.
  • the MTC-IWF can relay or interpret the signaling protocol on the reference point Tsp to activate certain functions in the PLMN.
  • the MTC-IWF performs the functions of authenticating the MTC server before the MTC server establishes communication with the 3GPP network, authenticating the control plane request from the MTC server, and various functions related to trigger instructions described below. can do.
  • SMS-SC Short Message Service-Service Center
  • IP-SM-GW Internet Protocol Short Message GateWay
  • SME Short Message Entity
  • IP-SM-GW Internet Protocol Short Message GateWay
  • the charging data function (CDF) / charging gateway function (CGF) may perform an operation related to charging.
  • the HLR / HSS may function to store subscriber information (IMSI, etc.), routing information, configuration information, and the like and provide the MTC-IWF.
  • IMSI subscriber information
  • HSS may function to store subscriber information (IMSI, etc.), routing information, configuration information, and the like and provide the MTC-IWF.
  • the MSC / SGSN / MME may perform a control function such as mobility management, authentication, resource allocation, etc. for the UE's network connection.
  • a function of receiving a trigger instruction from the MTC-IWF and processing the message in the form of a message provided to the MTC terminal may be performed.
  • the Gateway GPRS Support Node (GGSN) / Serving-Gateway (S-GW) + Packet Date Network-Gateway (P-GW) may function as a gateway that manages the connection between the core network and the external network.
  • T5a one or more reference points of T5a, T5b, and T5c are referred to as T5.
  • user plane communication with the MTC server in the case of indirect and hybrid models, and communication with the MTC application server in the case of direct and hybrid models may be performed using existing protocols through reference points Gi and SGi. .
  • FIG. 10 illustrates an architecture for Service Capability Exposure in a wireless communication system to which the present invention can be applied.
  • the architecture for Service Capability Exposure illustrated in FIG. 10 allows the 3GPP network to securely expose its services and capabilities provided by the 3GPP network interface to external 3rd party service provider applications. Makes it possible to do
  • SCEF Service Capability Exposure Function
  • SCEF is a key entity within the 3GPP architecture for service capability exposure that provides a means to securely expose the services and capabilities provided by the 3GPP network interface. )to be.
  • the SCEF is a key entity for providing a service function belonging to a trust domain operated by a mobile communication operator.
  • SCEF provides an API interface to third party service providers and provides 3GPP service functions to third party service providers through connection with various entities of 3GPP.
  • SCEF functionality may be provided by the SCS.
  • the MTC-IWF may be co-located with the SCEF.
  • a protocol eg DIAMETER, RESTful APIs, XML over HTTP, etc.
  • DIAMETER e.g. DIAMETER, RESTful APIs, XML over HTTP, etc.
  • the SCEF is an entity belonging to a trust domain, and may be operated by a cellular operator or may be operated by a third party operator that has a trusted relationship.
  • a node for service architecture exposing under work items such as Monitoring Enhancement (MONTE) and Architecture Enhancements for Service Capability Exposure (AESE) of 3GPP Release 13, the service is provided as shown in FIG. It is connected with 3GPP entities to provide various monitoring and billing functions to external third parties, and manages third party operators' communication patterns in EPS.
  • MONTE Monitoring Enhancement
  • AESE Architecture Enhancements for Service Capability Exposure
  • the Cellular Internet of Things defines a new wireless connection for IoT services, and two types of CIoT are under discussion in the 3GPP Release-13.
  • One is GERAN's solution in CIoT form, while the other is in Narrow Band Radio Access Technology (RAT) (e.g., NB-IOT) called Clean Slate.
  • RAT Narrow Band Radio Access Technology
  • FIG. 11 is a diagram illustrating an end-to-end small data flow in a wireless communication system to which the present invention can be applied.
  • non-IP data may be transmitted and received in a point-to-point tunnel manner between an AS and a CI Serving Gateway Node (C-SGN).
  • C-SGN is a node added to Rel-13 to support the CIoT terminal.
  • the SCEF framework can be used for sending and receiving Non-IP packets.
  • transmission and reception of Non-IP data may be performed between the AS / SCS and the C-SGN via the SCEF.
  • non-IP data may be transmitted and received between the C-SGN and the UE through the S1-MME reference point. That is, small data (eg, non-IP data) encrypted at the NAS layer may be transmitted and received between the UE and the C-SGN.
  • small data eg, non-IP data
  • C-SGN is a new logical entity and can be implemented to support only the essential functionality required for CIoT use cases as follows:
  • SMS Short Message Service
  • FIG. 12 illustrates a cellular IoT network architecture proposed for efficient non-IP small data transmission via SCEF in a wireless communication system to which the present invention can be applied.
  • T6a is a reference point used between the SCEF and the serving MME
  • T6b is a reference point used between the SCEF and the serving SGSN.
  • T6a / T6b meets the following requirements:
  • T6a connects the SCEF to the serving MME
  • T6b connects the SCEF to the serving SGSN
  • -Supports functions such as monitoring event setting in the serving MME / SGSN by the SCEF and monitoring event reporting to the SCEF by the serving MME / SGSN.
  • Non-IP Data Delivery to / from Serving MME / SGSN
  • S6t is a reference point used between SCEF and HSS and satisfies the following requirements.
  • the SCEF is connected to an HSS including subscription and UE related information.
  • the monitoring event of small data transmission may be set as follows.
  • the Monitoring Event Configuration procedure Prior to Mobile Originated (MO) and Mobile Terminated (MT) small data transmission, the Monitoring Event Configuration procedure allows the MME / C-SGN and SCEF to send MO and MT small data, respectively. Obtain necessary information (SCEF ID and MME / C-SGN routing information).
  • FIG. 13 illustrates a procedure for setting and deleting a monitoring event through an HSS in a wireless communication system to which the present invention can be applied.
  • SCS / AS is a Monitoring Request message (External Identifier (s)) or Mobile Station Integrated System Digital Network (MSRSDN) (SCS) / AS Identifier (SCS / AS Identifier).
  • SCS / AS Reference ID Monitoring Type, Maximum Number of Reports, Monitoring Duration, Monitoring Destination Address, Delete SCS / AS Reference ID for Deletion
  • MSRSDN Mobile Station Integrated System Digital Network
  • the SCS / AS may set the monitoring type to “SDT”.
  • the SCEF stores the SCS / AS Reference ID, SCS / AS Identifier, Monitoring Destination Address, Monitoring Duration, and Maximum Number of Reports. SCEF assigns an SCEF Reference ID. Based on operator policy, the SCS / AS is not authorized to carry out this request, or the Monitoring Request is malformed, or the SCS / AS submits a limit or rate of submission of the monitoring request. If SCEF is exceeded, the SCEF performs step 9 and provides an appropriate Cause value indicating an error. If the SCEF receives the SCS / AS Reference ID for Deletion, the SCEF derives an SCEF Reference ID for Deletion.
  • the SCEF uses a Monitoring Request message (External Identifier or MSISDN, SCEF ID, SCEF Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, SCEF Reference ID for Deletion, etc.) to configure the monitoring events given to the HSS and MME / SGSN.
  • the paid party identifier (Chargeable Party Identifier) is transmitted to the HSS.
  • the HSS examines the Monitoring Request message. For example, with respect to the presence of an External Identifier or MSISDN, whether the parameters included in the message are within acceptable range to the operator, whether the monitoring event (s) are supported by the serving MME / SGSN, or the monitoring to be deleted. Check whether the event is valid. The HSS optionally authorizes a chargeable party identified by the Chargeable Party Identifier. If the above check fails, the HSS follows step 8 and provides a cause value indicating to the SCEF the reason for the failure condition.
  • MSISDN External Identifier
  • the HSS stores the SCEF Reference ID, SCEF ID, Maximum Number of Reports, Monitoring Duration, and SCEF Reference ID for Deletion provided by the SCEF.
  • the HSS When required by a particular Monitoring Type and the monitoring event (s) is supported by the serving MME / SGSN, the HSS will send an Insert Subscriber Data Request message (Monitoring Type, SCEF ID, SCEF Reference ID, Maximum Number of Reports, Monitoring Duration, SCEF Reference ID for Deletion, Chargeable Party Identifier) is transmitted to MME / SGSN.
  • an Insert Subscriber Data Request message (Monitoring Type, SCEF ID, SCEF Reference ID, Maximum Number of Reports, Monitoring Duration, SCEF Reference ID for Deletion, Chargeable Party Identifier) is transmitted to MME / SGSN.
  • the MME / SGSN verifies the request. For example, if the Monitoring Type is covered by a roaming agreement when the request is sent from another PLMN, or if it can service and delete the SCEF Reference ID for Deletion. If this check fails, the MME / SGSN follows step 7 and provides a cause value indicating to the SCEF the reason for the failure status. Based on operator policy, the MME / SGSN may also reject the request for other reasons (eg, overload or if the HSS has exceeded the quota or rate of the monitoring request). .
  • the MME / SGSN stores the received parameters, sends the indicated monitoring event if the monitoring event is not available at the MME / SGSN at the time of a one-time request and sends an Insert Subscriber Data Answer. Begin to observe.
  • the MME / SGSN deletes the monitoring setup identified by the SCEF Reference ID for Deletion.
  • the MME / SGSN sends an Insert Subscriber Data Answer (cause) message to the HSS. If the requested monitoring event is available in the MME / SGSN at the time the Insert Subscriber Data Answer is sent, the MME / SGSN includes a Monitoring Event Report in the Insert Subscriber Data Answer message.
  • the HSS sends a Monitoring Response message (SCEF Reference ID, Cause) to the SCEF to acknowledge the approval of the Monitoring Request and the deletion of the identified monitoring event configuration.
  • the HSS deletes the monitoring event configuration identified by the SCEF Reference ID. If the requested monitoring event is available to the HSS at the time of sending the Monitoring Response message or if the requested monitoring event is received from the MME / SGSN in step 7, the HSS includes a Monitoring Event Report in the Monitoring Response message.
  • the HSS deletes the associated monitoring event configuration.
  • the HSS determines whether the new MME / SGSN supports the requested monitoring event (s).
  • the HSS may include routing information of the MME / C-SGN in the monitoring response message.
  • the SCEF sends a Monitoring Response message (SCS / AS Reference ID, Cause) to the SCS / AS in order to confirm the approval of the Monitoring Request and the deletion of the identified monitoring event configuration. If the SCEF receives the Monitoring Event Report, the SCEF includes the Monitoring Event Report in the Monitoring Response message. If it is a one-time request and the Monitoring Response includes a Monitoring Event Report, the SCEF deletes the associated monitoring event configuration.
  • the SCS / AS Reference ID is a parameter generated by the SCS / AS and represents a specific transaction initiated by the SCS / AS toward the SCEF.
  • the SCS / AS Reference ID is stored in the SCEF.
  • the SCEF Reference ID is generated by the SCEF in order to associate a monitoring event report or deletion of the monitoring event with context information associated with a particular monitoring request in the SCEF.
  • the SCEF Reference ID is stored in the HSS, MME or SGSN.
  • the SCEF ID indicates the SCEF to which a Monitoring Indication message should be transmitted by HSS, MME or SGSN.
  • the SCEF ID is stored in the HSS, MME or SGSN.
  • the Monitoring Type identifies the specific monitoring event that is requested.
  • Maximum Number of Reports is an optional parameter and indicates the maximum number of event reports generated by the HSS, MME or SGSN until the associated monitoring event is considered expired.
  • Monitoring Duration is an optional parameter and indicates the absolute time when the associated monitoring event request is considered to have expired.
  • Including the Maximum Number of Reports (which has a value greater than 1) or Monitoring Duration indicates that the monitoring request is a Continuous Monitoring Request.
  • a Continuous Monitoring Request a single monitoring request may generate multiple Monitoring Indication messages. Can be generated.
  • the absence of both Maximum Number of Reports and Monitoring Duration indicates that the monitoring request is a one-time monitoring request.
  • a single monitoring request generates one monitoring report.
  • the monitoring request is considered to expire when one condition is met.
  • the Monitoring Destination Address is an optional parameter included by the SCS / AS to indicate that the Monitoring Indication (s) is to be delivered to an address different from the address of the requesting SCS / AS. The absence of this parameter indicates that the Monitoring Indication (s) is forwarded to the SCS / AS from which the monitoring request was issued.
  • the SCS / AS Reference ID for Deletion identifies the monitoring event configuration that must be deleted before applying the requested monitoring event configuration.
  • the SCEF Reference ID for Deletion identifies the monitoring event configuration that must be deleted before applying the requested monitoring event configuration.
  • Chargeable Party Identifier is an optional parameter included by the SCEF. This parameter identifies the entity on which the accounting / billing function is performed by the involved 3GPP network element.
  • MO small data ie, IP, non-IP, SMS
  • FIG. 14 illustrates an MO small data transmission procedure in a wireless communication system to which the present invention can be applied.
  • the monitoring event is detected by the node where the monitoring event is set (ie, MME / C-SGN).
  • the MME / C-SGN may detect the monitoring event by receiving the MO small data.
  • the UE may request the AS of the UE to establish an RRC connection.
  • a new NAS message format for carrying small data packets within an encrypted Information Element (IE) may be used.
  • the unencrypted portion of this new NAS PDU may carry an "eKSI and Sequence Number" IE.
  • the MME / C-SGN may use an "eKSI and Sequence Number” IE and a SAE-Temporary Mobile Subscriber Identity (S-TMSI) to identify a security context for decrypting small data packets.
  • the RAN may deliver the NAS PDU to the MME / C-SGN.
  • the MME / C-SGN may decrypt the NAS message and obtain a small data packet.
  • the node ie, MME / C-SGN
  • MME / C-SGN sends a Monitoring Indication message (SCEF Reference ID and Monitoring Event Report) to the SCEF. If the monitoring event configuration was triggered by the One-time Monitoring Request, the monitoring event configuration is deleted by the MME / SGSN when this step is completed. If the MME / SGSN has a Maximum Number of Reports stored for this monitoring task, the MME / SGSN decrements it by one.
  • the monitoring event report may include MO small data.
  • the SCEF may respond to the MME / C-SGN with an acknowledgment message.
  • the SCEF retrieves the SCS / AS Reference ID associated with the Monitoring Destination Address or the address of the SCS / AS as a destination for the transmission of the Monitoring Indication message.
  • the SCEF transmits a Monitoring Indication message (SCS / AS Reference ID, External ID or MSISDN, Monitoring Information) to the identified destination.
  • the SCEF When the maximum number of reports is reached for a Continuous Monitoring Request, the SCEF sends an HSS (for monitoring events set up through HSS) or MME (s) / SGSN (s) (for monitoring events set directly in MME / SGSN). Request to delete the monitoring event setting according to steps 3-8 in the procedure of FIG. 13 associated with the related monitoring event setting above.
  • the SCEF sets the monitoring event according to steps 3-8 in the procedure of FIG. Request to delete.
  • the SCEF may transmit the MO small data to the monitoring destination node through a monitoring report procedure.
  • the MT small data (ie, IP, non-IP, SMS) transmission procedure will be described.
  • 15 illustrates an MT small data transmission procedure in a wireless communication system to which the present invention can be applied.
  • the SCS / AS transmits a small data transmission request (SDT Request) message (SCS / AS Reference ID for MTD, MT small data) to the SCEF.
  • SDT Request small data transmission request
  • the SCEF If the SCEF does not have valid routing information for the MME / C-SGN corresponding to the SCS / AS Reference ID for the SDT, the SCEF queries the HSS.
  • the SCEF sends an SDT Request message (SCEF Reference ID, MT Small Data) to the MME / C-SGN.
  • the MME / C-SGN may transmit MT small data to the UE.
  • the MME / C-SGN may receive a small data packet from the SCEF. If there is no signaling connection with the UE, the MME / C-SGN may buffer the received small data packet and transmit paging to the UE. The UE may transmit a service request message to the MME / C-SGN in response to the paging. Next, the C-SGN may transmit the small data packet in the encrypted IE in the NAS PDU in the downlink NAS message, and the RAN may transmit the NAS PDU to the UE.
  • the MME / C-SGN sends an SDT Response message (SCEF Reference ID, Cause for SDT) to the SCEF.
  • the MME / C-SGN If a valid context related to the SCEF Reference ID for the SDT does not exist in the MME / C-SGN, the MME / C-SGN notifies the SCEF of the MT small data transmission failure by setting the Cause to an appropriate value. In this case, the SCEF may be performed again from step 2 above.
  • the SCEF sends an SDT Response message (SCS / AS Reference ID, Cause for SDT) to the SCS / AS.
  • Non-IP Data Delivery (NIDD : Non-IP Data Delivery)
  • NIDD network terminated communication
  • MT mobile terminated
  • UE packets used for communication
  • EPS standpoints May be regarded as not. That is, it may refer to a non-IP packet and may be understood as a concept equivalent to small data herein. Support for non-IP data is part of the CIoT EPS optimization.
  • SCS / AS may require configuration of information required for delivery of non-IP data, that is, configuration of SCS / AS triggers for NIDD procedures. In this case, the following may be allowed.
  • An MME for obtaining uplink path information (SCEF ID) and downlink path information (IMSI) associated with the SCEF reference ID;
  • SCEF (where IWK-SCEF is roaming) to obtain uplink path information (SCS / AS identifier) and downlink path information (serving MME address or IWK-SCEF ID) associated with the SCEF and SCS / AS reference ID. Corresponds to the node used).
  • MO / MT non-IP data may be conveyed via an uplink / downlink path associated with a reference ID.
  • NIDD MO and MT
  • NIDD may be allowed only between the 3GPP network and a single SCEF.
  • Data between the UE and the MME is carried through a control plane optimized for CIoT.
  • 16 illustrates a link setup process for transmitting UL / DL data (ie, non-IP data) through MME and SCEF in a wireless communication system to which the present invention can be applied.
  • UL / DL data ie, non-IP data
  • Non-IP data Since the transmission and reception of non-IP data does not use the IP protocol, data can be transmitted and received in a P2P manner, and the link between the UE and the PDN (i.e., APN) in advance via MME and SCEF is applied to the network. For example, a PDN connection for transmitting and receiving Non-IP data may be set up.
  • APN PDN
  • connection setup between SCS / AS and SCEF may be referred to as NIDD configuration. This can be considered to be in advance of the T6a connection setup. That is, before a third party operator contracts an IoT business with an operator and IoT terminals are deployed and registered in the network, the NIDD setting procedure may be performed in advance.
  • a setup request is made to the SCEF for a corresponding terminal by using an MSISDN or an external identity of a terminal that wants to establish a connection setup. Therefore, the SCEF requests the HSS to authorize handling of the terminal and the SCS / AS and ID resolution of the terminal. That is, the IMSI is a UE identifier that cannot be exposed to the external network (ie, SCS / AS). As described above, the external network can generally identify the terminal using an MSISDN (ie, a terminal number) or an external identifier. This ID and IMSI mapping information is stored in the HSS. If the NIDD configuration procedure is successfully completed, the NIDD configuration is completed and the context for the terminal is created in the SCEF.
  • the NIDD configuration procedures are performed with an API interface.
  • the terminal transmits a PDN connection request message to the MME.
  • the UE transmits the APN information together with the Non-ip type indication to the MME while requesting a preset PDN connection setup (ie, transmitting a PDN Connection request message).
  • the MME checks the subscription information corresponding to the APN through the HSS and determines whether the PDN connection setup using the SCEF.
  • the MME initiates the setup of a T6a connection to the SCEF.
  • the destination SCEF used at this time may also use the subscription information of the terminal stored in the HSS.
  • the UE when the UE wants to attach or service, the UE requests the MME for a PDN connection.
  • the MME reports the subscription information of the UE corresponding to the requested PDN connection is Non-IP type (that is, the PDN type is 'Non-IP') and the received APN (default APN is available if the APN is not included). It is determined whether a connection is established.
  • Table 3 illustrates HSS storage information for SCEF connection.
  • FIG. 17 illustrates an NIDD configuration procedure in a wireless communication system to which the present invention can be applied.
  • the flowchart of FIG. 17 shows the procedure for configuring the necessary information in IWK-SCEF for SCEF, HSS, MME and optionally NIDD. This procedure can also be used to change or delete configuration information.
  • NIDD Configuration Request NIDD Configuration Request
  • MSSISDN Mobile Subscriber International Subscriber Directory Number
  • SCS / AS identifier SCS / AS reference ID
  • maximum number of NIDD NIDD Duration
  • SCS / AS reference ID maximum number of NIDD Destination Address and / or SCS / AS reference ID for deletion
  • Relative priority scheme for processing multiple SCS / AS NIDD configuration requests, i.e., to determine which requests to handle under overload conditions. This priority scheme is used locally by the SCEF and is not used or translated in procedures for other functions.
  • MT non-IP data in SCS / AS may trigger an NIDD configuration request message.
  • SCEF can transmit MT non-IP data after the NIDD configuration is established / established.
  • the SCEF stores the SCS / AS Reference ID, SCS / AS Identifier, NIDD Destination Address, NIDD Duration, and / or NIDD Maximum Number. SCEF assigns an SCEF reference ID. If the SCS / AS does not have the authority to perform this request (for example, the SLA does not allow it) or the NIDD configuration request is malformed according to operator policy, or the SCS / AS submits the NIDD configuration request Or if the rate is exceeded, the SCEF performs step 12 and provides a cause value that adequately indicates the error. If the SCEF receives the SCS / AS reference ID for deletion, the SCEF derives the relevant SCEF reference ID for deletion.
  • the SCEF may request NIDD configuration requests (external identifier or SCID reference ID, SCID reference ID, maximum number of NIDDs, NIDD duration, delete) to configure necessary information for NIDD for HSS and MME, if necessary. SCEF reference ID, and / or pay party identifier) message.
  • the HSS examines the NIDD configuration request message (eg, with respect to the presence of an external identifier or MSISDN, whether the included parameters are within acceptable range of the operator or whether the NIDD configuration to be deleted is valid). .
  • the HSS optionally authenticates the paying party specified by the billing party indicated by the billing identifier. If this check fails, the HSS performs step 11 and provides a cause value indicating the cause of the failure condition for the SCEF.
  • the HSS stores the SCEF reference ID, the SCEF ID, the maximum number of NIDDs, the NIDD duration, and / or the SCEF reference ID for deletion provided by the SCEF.
  • the HSS sends an Insert Subscriber Data Request (SCEF ID, SCEF Reference ID, Maximum Number of NIDDs, NIDD Duration, SCEF Reference ID for Deletion, and / or Paid Party Identifier) messages to the MME. (E.g. during the attach / connect procedure).
  • SCEF ID SCEF Reference ID
  • Maximum Number of NIDDs SCEF Reference ID
  • SCEF Reference ID for Deletion SCEF Reference ID for Deletion
  • / or Paid Party Identifier Paid Party Identifier
  • the MME shall accept Inform IWK-SCEF (SCEF ID, SCEF Reference ID, Maximum NIDD Number, NIDD Duration, SCEF Reference ID for Deletion and / or Paid Party Identifier) message to the IWK-SCEF.
  • the new / target MME is expected to inform the IWK-SCEF of UE mobility. More details are performed in step 3, otherwise the MME performs step 9.
  • the IWK-SCEF may approve the request. NIDD is subject to roaming agreements and if possible records the SCEF reference ID for deletion. If this authentication fails, the IWK-SCEF performs step 9 and provides a cause value indicating the cause of the failure condition for the MME. Depending on the operator's policy, the IWK-SCEF may reject the request for other reasons (for example, overload or exceeding the quota defined by the SLA).
  • the IWK-SCEF performs the necessary final actions (eg, create final billing information, delete stored parameters) and send a confirmation response to the MME in step 9.
  • the IWK-SCEF approves the request, if successful, saves the received parameters, sends an acknowledgment to the MME and initiates monitoring of non-IP data in step 9. do.
  • the IWK-SCEF sends an acknowledgment to the MME / SGSN in the IWK-SCEF (Cause) message.
  • the MME may verify the request, for example, to determine whether the NIDD is a request from another PLMN or provides an SCEF reference ID through a roaming agreement. If this check fails, the MME performs step 10 and provides the SCEF with a cause value indicating the cause of the failure condition. Depending on the operator's policy, the MME may reject the request for other reasons (eg, when the overload or the HSS exceeds the quota or rate of submission of the NIDD configuration request defined by the SLA).
  • the MME stores the parameters received in step 5 and the (if possible) IWK-SCEF ID in the MM context, which is a one-time request and the MME is already non-IP before the time of the Insert Subscriber Data Answer. If not receiving data, it starts to monitor the indicated NIDD from the UE. The MME deletes the NIDD configuration identified by the SCEF Reference ID for deletion.
  • the MME sends parameters as part of the context information stored for all NIDD events while the MME is changing. If the UE is disconnected from the network, the HSS receives the remaining number of reports in the maximum number of NIDD parameters.
  • the MME sends a subscriber data response (cause) message to the HSS. If the MME is configured to use IWK-SCEF for the PLMN, the MME includes the IWK-SCEF ID in the insert subscriber data response message.
  • the HSS sends the SCEF an NIDD Configuration Response (SCEF Reference ID, Search MME Address, IWK-SCEF ID, Cause) message to the SCEF to confirm the approval of the NIDD configuration request and the deletion of the identified NIDD configuration. send.
  • HSS deletes the NIDD configuration identified by the SCEF reference ID (if requested).
  • the HSS includes serving MME address information for the SCEF that transmits non-IP data for MT NIDD to the UE to the MME.
  • the HDD includes the IWK-SCEF ID instead of the serving MME address in the NIDD configuration response message.
  • the SCEF sends an NIDD Configuration Response (SCS / AS Reference ID, Cause) message to the SCS / AS, confirming the approval of the NIDD configuration request and the deletion of the identified NIDD configuration, if requested.
  • SCS / AS Reference ID, Cause NIDD Configuration Response
  • FIG. 18 illustrates a MO NIDD procedure in a wireless communication system to which the present invention can be applied.
  • the SCS / AS may receive non-IP data from the UE via the SCEF.
  • SCS / AS In order to receive non-IP data via SCEF, SCS / AS must request NIDD configuration. Reference IDs of SCS / AS and SCEF used in this procedure are obtained through the above-described NIDD configuration procedure.
  • MO non-IP data is received from the UE by the MME in which the NIDD configuration is set.
  • the MME decides to send non-IP data via SCEF.
  • the MME If the MME is not configured to use IWK-SCEF, the MME sends a MO NIDD indication (SCEF reference ID, non-IP data) message to the SCEF.
  • MO NIDD indication SCEF reference ID, non-IP data
  • the MME If the MME is configured to use IWK-SCEF, the MME sends a MO NIDD indication message to the IWK-SCEF, and the IWK-SCEF sends a MO NIDD indication (SCEF reference ID, non-IP data) message to the SCEF.
  • a MO NIDD indication SCEF reference ID, non-IP data
  • the SCEF retrieves the address of the SCS / AS as the destination for the MO NIDD indication message if it cannot retrieve or use the SCS / AS reference ID associated with the NIDD destination address.
  • the SCEF sends a MO NIDD indication (SCS / AS reference ID, external ID or MSISDN, non-IP data) message to the identified destination.
  • the SCS / AS acknowledges the MO NIDD indication to the SCEF.
  • the SCEF acknowledges the MO NIDD indication to the MME (via IWK-SCEF if IWK-SCEF is used).
  • FIG. 19 illustrates an MT NIDD procedure in a wireless communication system to which the present invention can be applied.
  • SCS / AS may send non-IP data to the UE via SCEF.
  • SCS / AS In order to transmit non-IP data through SCEF, SCS / AS must request NIDD configuration. Reference IDs of SCS / AS and SCEF used in this procedure are obtained through the above-described NIDD configuration procedure.
  • SCS / AS transmits MT non-IP data for the UE.
  • the originating node sends an MT NIDD Request (SCS / AS Reference ID, Non-IP Data) message to the SCEF.
  • the SCEF uses the SCS / AS reference ID to retrieve the SCEF reference ID associated with the serving MME address (step 3a) or the IWK-SCEF ID (step 3b).
  • the SCEF sends an MT NIDD Request (SCEF Reference ID, Non-IP Data) message to the serving MME (step 3a). If the IWK-SCEF ID is available, the SCEF sends an MT NIDD request (SCEF reference ID, non-IP data) message to the IWK-SCEF (step 3b). The IWK-SCEF sends an MT NIDD Request (SCEF Reference ID, Non-IP Data) message to the serving MME.
  • the MME delivers non-IP data to the UE.
  • the MME responds to the MT NIDD request for the SCEF. If the MME cannot carry MT non-IP data, the MT NIDD request shall be rejected with the appropriate cause value for the SCEF.
  • the SCEF sends a subscriber information request (external identifier or MSISDN) message to the HSS to retrieve the serving MME address stored in the relevant HSS, and the HSS sends a subscriber information response (external identifier or MSISDN, serving MME address, cause) message. .
  • the SCEF performs three steps with the new serving MME address.
  • MME responds to MT NIDD request for IWK-SCEF
  • IWK-SCEF responds to MT NIDD request for SCEF.
  • the SCEF responds to MT NIDD requests for SCS / AS.
  • Non-ip data transmission through the SCEF is a transparent operation (that is, the terminal unknown operation) to the terminal using the existing SCEF framework.
  • the existing monitoring and service exposure capability is an operation between the network, the server and the SCEF node without affecting the terminal. For example, when the SCS / AS is required, in the case of setting the monitoring and reporting the monitored event by the MME / HSS, the SCEF setting operation does not affect the terminal.
  • SCEF can be used for group message transmission.
  • the SCEF can be used through a broadcast multicast-service center (BM-SC).
  • BM-SC broadcast multicast-service center
  • a message is sent to group terminals with MBMS content.
  • the small data transmission / reception using the SCEF includes a mobile originated call, and according to the current standard, when the NIDD configuration according to the procedure described above with reference to FIG. 17 is not set / established, the terminal Even when this outgoing signal data is transmitted, the core network node of the MME / C-GSN cannot process this.
  • the NIDD configuration of the SCEF is a transparent operation from the terminal's point of view, the terminal does not know whether the NIDD transmission is possible (that is, whether or not to perform / establish the NIDD configuration of the SCS / AS terminal), and thus the terminal does not have the NIDD configuration / established.
  • the NIDD configuration is not directly waited for establishment / execution of the NIDD configuration triggered by the SCS / AS in the network node, but directly by the SCS / AS. Suggest a procedure for making an active request.
  • FIGS. 7 and 17 are a flowchart illustrating an access procedure for SCEF connection according to a first embodiment of the present invention.
  • the descriptions of FIGS. 7 and 17 described above with respect to the flowchart may be applied in the same or similar manner, and redundant descriptions are omitted.
  • the UE When the UE requests a connection, the UE includes indication information for transmitting non-IP type data, CIoT UP (user plane) capability information, or CIoT CP (control plane) capability information in the access request message to the network. send.
  • the CIoT UP capability information indicates whether the UE applies the UP mode
  • the CIoT CP capability information indicates whether the UE applies the CP mode.
  • CP mode refers to a mode in which packet data is encapsulated and transmitted / received in a NAS PDU through an SRB (that is, a data transmission / reception mode through a control plane), and an UP mode is a mode in which packet data is transmitted and received to a DRB through a DRB setup (that is, Data transmission / reception mode through the user plane).
  • steps 2 to 11 of FIG. 7 may be performed in the present steps 2 to 11.
  • the MME may select either SCEF delivery (ie, data transmission via SCEF) and SGi delivery (data transmission via SGi) for non-ip data transmission based on configuration information and MM context information. .
  • SCEF delivery ie, data transmission via SCEF
  • SGi delivery data transmission via SGi
  • the MME may select SGi delivery if the terminal requesting access does not support CP CIoT optimization, or select SCEF delivery if CP CIoT optimization is supported.
  • the MME may select SCEF delivery or SGi delivery according to network configuration and network policy.
  • the MME may check whether there is an SCEF connection (or NIDD configuration) based on subscription information (or HSS storage information for SCEF connection) received from the UE.
  • subscription information or HSS storage information for SCEF connection
  • the HSS updates the establishment / configuration information thereof as subscription information for the terminal and then updates the MME. You can send subscription information.
  • the MME may determine whether the SCEF connection (or NIDD configuration) for the terminal is currently established / set by checking the subscription information for the terminal. .
  • the SCS / AS address the address of the SCS / AS to be connected to the SCEF
  • the external identifier of the terminal in addition to the information in Table 3 above.
  • Information may be added as to whether ID is included in triggering SCEF connection (or NIDD configuration) from SCEF to SCS / AS and / or whether to establish / set current SCEF connection (or NIDD configuration).
  • the MME selects SCEF delivery and determines that there is no SCEF connection (or NIDD configuration) for the UE requesting access, the MME is configured to SCEF connection (or NIDD configuration) for non-ip data transmission of the UE to the HSS. You can ask the HSS to establish / set). More specifically, if the MME determines that no SCEF connection (or NIDD configuration) exists, it can request a T6a connection setup to the SCEF (via HSS). The SCEF connection (or T6a) setup request may be transmitted through a Notify Request (NOR) message or a newly defined message.
  • NOR Notify Request
  • the HSS transmits an SCEF connection setup request to a destination SCEF supporting the SCS / AS of the terminal after determining whether the SCEF can be connected to the terminal.
  • the destination SCEF may be stored in subscription information or may be an SCEF serving an SCS / AS id of the terminal.
  • the destination SCEF to which the HSS requests the SCEF connection setup may be derived by using the destination SCS / AS id by the HSS, or by using the SCEF id previously stored in the subscription information.
  • the HSS may transmit a SCEF connection setup request including the SCS / AS id (id of the SCS / AS serving the terminal) and the external id corresponding to the IMSI of the terminal to the SCEF.
  • the SCEF may determine whether the SCEF connection (or NIDD configuration) with the destination SCS / AS corresponding to the SCS / AS id received from the HSS is currently established / established. If it is determined that the SCEF connection (or NIDD configuration) with the destination SCS / AS is currently established / established, the SCEF may terminate the procedure without performing steps 15 to 18 described below. In this case, the SCEF may inform the MME that the current SCEF connection (or NIDD configuration) is already established / established.
  • the SCEF sends an SCEF connection request message containing the external id received from the HSS to the destination SCS / AS, and 16 You can enter the steps.
  • the SCS / AS may perform the NIDD configuration procedure described above with reference to FIG. 17 and may store parameters such as an SCEF ID and an SCEF reference ID to be used by the MME when transmitting an outgoing signal of the UE.
  • the MME When the MME recognizes that the SCEF connection (or NIDD configuration) is created through the NIDD configuration procedure, the MME sends an access grant message to the eNB.
  • the access authorization message transmitted may include an indication indicating availability of SCEF connection (or NIDD configuration) or validity of non-ip data transmission.
  • the eNB transmits an RRC direct transfer message to the UE.
  • the RRC direct delivery message may include a connection acknowledgment message including an indication indicating valid or non-ip data transmission of the SCEF connection (or NIDD configuration). Accordingly, the UE recognizes that non-ip data transmission is possible, and when data to be transmitted is generated in a higher layer, the UE can transmit non-ip data through a newly established / established SCEF connection (or NIDD configuration) to a network.
  • connection acknowledgment message does not include an indication indicating the validity of the SCEF connection (or the NIDD configuration) or the validity of the non-ip data transmission
  • the terminal waits until the next incoming call is received. Only then can the call be sent. The reason is that the incoming call means that there is currently a valid SCEF connection (or NIDD configuration).
  • step 15 if there is no valid SCEF connection (or NIDD configuration), it will be determined according to various embodiments to determine which SCS / AS and SCEF connection (or NIDD configuration) to establish. Can be.
  • the terminal inquires about the SCEF connection related information to the HSS upon access ( query).
  • the HSS may transmit the SCS / AS id and the external id stored as additional information to the SCEF when the SCEF connection setup request is made to the SCEF.
  • the SCEF establishes the SCEF connection (or NIDD configuration) using the external id received toward the SCS / AS corresponding to the SCS / AS id received from the MME.
  • the MME may request the HSS separately or the information may be previously stored / set in the SCEF.
  • the MME may inform the HSS of the need for the SCEF connection. Accordingly, the HSS may check the SCS / AS ID of the corresponding UE, derive an external identifier corresponding to the IMSI value of the UE, and request to set up the SCEF connection to the target SCEF.
  • the HSS may inform the SCEF of the SCS / AS ID and the external ID together.
  • the SCEF determines whether a currently valid SCEF connection (or NIDD configuration) is established / established based on this, and establishes / establishes or presets / establishes a new SCEF connection (or NIDD configuration) according to the determination result. It can signal that a connection (or NIDD configuration) exists.
  • FIGS. 7, 17, and 20 are flowchart illustrating an access procedure for SCEF connection according to a second embodiment of the present invention. Descriptions of FIGS. 7, 17, and 20 described above with respect to the flowchart may be applied in the same or similar manner, and redundant descriptions are omitted.
  • the UE When the UE requests a connection, the UE includes indication information for transmitting non-IP type data, CIoT UP (user plane) capability information, or CIoT CP (control plane) capability information in the access request message to the network. send.
  • CIoT UP user plane
  • CIoT CP control plane
  • steps 2 to 7 of FIG. 7 may be performed in the present steps 2 to 7.
  • the MME transmits an Update Location Request (ULR) message to the HSS when a valid MM context of the terminal on the network does not exist or accesses a new PLMN.
  • the MME may send the ULR message including an indication that setup for a non-ip data path is required.
  • the HSS determines that a non-ip data setup (or SCEF connection / NIDD configuration) is required by receiving a ULR message, the HSS infers a serving SCEF node by checking / using the stored SCS / AS id for the terminal and then infers the corresponding terminal. It can check whether the service of SCS / AS is possible. In this case, the HSS may determine whether a non-ip data setup (or SCEF connection / NIDD configuration) is necessary based on whether there is a valid SCEF connection (or NIDD configuration) and whether there are remaining number of NIDD transmissions.
  • the SCEF connection is performed through step 8b.
  • Setup Sends a request to the SCEF.
  • the SCEF through which the HSS transmits an SCEF connection (setup) request corresponds to an SCEF node that can serve the UE inferred previously.
  • the HSS sends a SCEF connection (setup) request to the destination SCEF.
  • the transmitted SCEF connection (setup) request may include the external id and the SCS / AS id of the terminal.
  • the SCEF transmits an SCEF connection (setup) request including an external id of the terminal to a destination SCS / AS corresponding to the received SCS / AS id.
  • the SCS / AS may perform the NIDD configuration procedure described with reference to FIG. 17.
  • steps 9 and 10 of the legacy connection procedure described above with reference to FIG. 7 may be performed.
  • the HSS sends the SCEF connection information (or NIDD configuration information) to the MME via an update location response message instead of the existing Insert subscription Data Request message.
  • the SCEF connection information is information on the performed / completed SCEF connection (or NIDD configuration), for example, an indication indicating the SCEF connection (or NIDD configuration) / available of non-ip data transmission, SCEF ID It may include an SCEF reference ID, a maximum number of NIDDs, an NIDD duration, an SCEF reference ID for deletion, and / or a chargeable party identifier. In this case, steps 10 to 12 may be omitted in the NIDD configuration procedure applicable to the flowchart.
  • the MME determines that non-ip data transmission is possible for the UE by receiving the SCEF connection information (or NIDD configuration information), the SCEF connection (or NIDD configuration) / available for non-ip data transmission is available.
  • the ULR message transmitted to the HSS to register the serving node of the terminal in the access procedure of the terminal indicates that the SCEF connection (or NIDD configuration) of the terminal is required May be included.
  • An indication that this SCEF connection (or NIDD configuration) is required may be interpreted as an indication that non-ip data transmission is required.
  • the HSS determines whether the UE needs the SCEF connection (for example, based on the existence of a valid SCEF connection (or NIDD configuration), the remaining number of NIDD transmissions, etc.), and if necessary, the SCEF connection to the UE by the SCEF. (Or NIDD configuration) tell them you need it.
  • the terminal may transmit a ULR message to the HSS even if the registration of the serving node is not necessary to inform the necessity of SCEF connection setup.
  • SCS / AS can directly request the monitoring of the terminal.
  • the SCS / AS since the SCS / AS does not know whether the terminal is connected in advance, when the HSS receives a monitoring request from the SCS / AS, the HSS stores configuration information regarding the terminal monitoring requested by the SCS / AS. When the terminal accesses, the configuration information may be transmitted to the MME.
  • the SCS / AS may not be able to perform the necessary SCEF connection (or NIDD configuration) for the terminal because it is not associated with the SCS / AS providing the service. This may require a function to inform the SCS / AS whether the terminal is connected, that is, whether the terminal can be connected to the SCEF (or NIDD configuration). Therefore, if the MME determines that it is necessary to indicate to the SCS / AS whether or not the terminal is connected when the terminal is connected (for example, when a new terminal that is not associated with the SCS / AS requested to access) ), The ULR message of the access procedure described above with reference to FIG.
  • the HSS 7 may include the indication information (eg, SCEF id, SCS / AS id, and external id) for transmission to the HSS.
  • the HSS may transmit, together with the serving node information, an indication on whether the UE is connected / validated to the SCS / AS through the SCEF.
  • the SCS / AS receiving the indication may recognize whether the corresponding UE is connected without performing a separate query for the HSS, and perform setting such as monitoring of the SCEF connection (or NIDD configuration) for the corresponding UE.
  • FIG. 22 is a flowchart illustrating an NIDD configuration setting procedure of an SCEF according to an embodiment of the present invention.
  • the above descriptions and embodiments described above may be applied in the same or similar manners with respect to the flowchart, and redundant descriptions will be omitted.
  • the SCEF may receive a first SCEF connection setup request for non-IP data transmission of a terminal from a network node (S2210).
  • the first SCEF connection setup request may include an external identifier of the terminal requesting the connection and an SCS / AS identifier for the SCS / AS serving the terminal.
  • the external identifier of the terminal corresponds to the IMSI of the terminal, and the SCS / AS ID may be stored in the HSS as subscription information of the terminal.
  • the SCEF may determine whether an NIDD configuration with the SCS / AS is established (S2220). If it is determined in step S2220 that the NIDD configuration is not established, the SCEF may transmit a second SCEF connection setup request to the SCS / AS to establish the NIDD configuration (S2230). In this case, the second SCEF connection setup request may include an external identifier of the terminal.
  • the SCEF may configure the NIDD configuration for the SCS / AS and the UE. More specifically, the SCEF receives a first NIDD configuration request message requesting NIDD configuration setting with the terminal from the SCS / AS, and a second for configuring the NIDD configuration with the HSS based on the received first NIDD configuration request message.
  • the NIDD configuration request message can be sent.
  • the first and second NIDD configuration request messages include an SCS / AS identifier and an SCS / AS reference identifier for the SCS / AS, a maximum number of NIDDs, an NIDD duration, and / or an NIDD destination address. can do.
  • the SCEF may receive a first MO NIDD indication message informing transmission of call signal data as non-IP data, and transmit a second MO NIDD indication message to SCS / AS.
  • the first and second MO NIDD indication messages may include an SCEF reference identifier and call signal data.
  • the SCEF may receive a first MO NIDD Acck message in response to the second MO NIDD indication message and transmit a second MO NIDD Acck message in response to the first MO NIDD indication message. .
  • the SCEF may receive a first MT NIDD request message indicating the transmission of the incoming call data as non-IP data from the SCS / AS and transmit a second MO NIDD request message.
  • the first and second MO NIDD request messages may include an SCEF reference identifier and incoming call data.
  • the SCEF may receive the second MT NIDD response message as a response to the second MT NIDD request message and transmit the first MT NIDD response message as a response to the first MT NIDD request message.
  • the second MT NIDD response message may include a cause value indicating the reason for transmission impossible when it is determined by the MME that the incoming call data cannot be transmitted.
  • the NIDD configuration procedure described above with reference to FIG. 17 may be applied to various procedures for configuring the NIDD.
  • the network node of step S2210 may correspond to the HSS or MME.
  • the first SCEF connection setup request is generated. May be received from the MME.
  • a first SCEF connection setup request may be received from the HSS.
  • FIG. 23 illustrates a block diagram of a communication device according to an embodiment of the present invention.
  • a wireless communication system includes a network node 2310 and a plurality of terminals (UEs) 2320.
  • UEs terminals
  • the network node 2310 includes a processor 2311, a memory 2312, and a communication module 2313.
  • the processor 2311 implements the functions, processes, and / or methods proposed in FIGS. 1 to 22. Layers of the wired / wireless interface protocol may be implemented by the processor 2311.
  • the memory 2312 is connected to the processor 2311 and stores various information for driving the processor 2311.
  • the communication module 2313 is connected to the processor 2311 and transmits and / or receives a wired / wireless signal.
  • a base station, an MME, an HSS, an SGW, a PGW, an SCEF, an SCS / AS, and the like may correspond thereto.
  • the communication module 2313 may include a radio frequency unit (RF) unit for transmitting / receiving a radio signal.
  • RF radio frequency unit
  • the terminal 2320 includes a processor 2321, a memory 2232, and a communication module (or RF unit) 2323.
  • the processor 2321 implements the functions, processes, and / or methods proposed in FIGS. 1 to 22. Layers of the air interface protocol may be implemented by the processor 2321.
  • the memory 2232 is connected to the processor 2321 and stores various information for driving the processor 2321.
  • the communication module 2323 is connected to the processor 2321 to transmit and / or receive a radio signal.
  • the memories 2312 and 2322 may be inside or outside the processors 2311 and 2321, and may be connected to the processors 2311 and 2321 by various well-known means.
  • the network node 2310 in the case of a base station
  • the terminal 2320 may have a single antenna or multiple antennas.
  • 24 is a block diagram of a communication device according to one embodiment of the present invention.
  • FIG. 24 is a diagram illustrating the terminal of FIG. 23 in more detail.
  • the terminal may include a processor (or a digital signal processor (DSP) 2410, an RF module (or RF unit) 2435, and a power management module 2405). ), Antenna 2440, battery 2455, display 2415, keypad 2420, memory 2430, SIM card Subscriber Identification Module card) 2425 (this configuration is optional), a speaker 2445 and a microphone 2450.
  • the terminal may also include a single antenna or multiple antennas. Can be.
  • the processor 2410 implements the functions, processes, and / or methods proposed in FIGS. 1 to 23.
  • the layer of the air interface protocol may be implemented by the processor 2410.
  • the memory 2430 is connected to the processor 2410 and stores information related to the operation of the processor 2410.
  • the memory 2430 may be inside or outside the processor 2410 and may be connected to the processor 2410 by various well-known means.
  • the user enters command information, such as a telephone number, for example by pressing (or touching) a button on keypad 2420 or by voice activation using microphone 2450.
  • the processor 2410 receives the command information, processes the telephone number, and performs a proper function. Operational data may be extracted from the SIM card 2425 or the memory 2430. In addition, the processor 2410 may display command information or driving information on the display 2415 for the user to recognize and for convenience.
  • the RF module 2435 is coupled to the processor 2410 to transmit and / or receive RF signals.
  • the processor 2410 communicates command information to the RF module 2435 to, for example, transmit a radio signal constituting voice communication data to initiate communication.
  • the RF module 2435 is composed of a receiver and a transmitter for receiving and transmitting a radio signal.
  • Antenna 2440 functions to transmit and receive wireless signals. Upon receiving a wireless signal, the RF module 2435 may forward the signal and convert the signal to baseband for processing by the processor 2410. The processed signal may be converted into audible or readable information output through the speaker 2445.
  • each component or feature is to be considered optional unless stated otherwise.
  • Each component or feature may be embodied in a form that is not combined with other components or features. It is also possible to combine some of the components and / or features to form an embodiment of the invention.
  • the order of the operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is obvious that the claims may be combined to form an embodiment by combining claims that do not have an explicit citation relationship in the claims or as new claims by post-application correction.
  • Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof.
  • an embodiment of the present invention may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, and the like.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • processors controllers, microcontrollers, microprocessors, and the like.
  • an embodiment of the present invention may be implemented in the form of a module, procedure, function, etc. that performs the functions or operations described above.
  • the software code may be stored in memory and driven by the processor.
  • the memory may be located inside or outside the processor, and may exchange data with the processor by various known means.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 발명의 일 양상은, 무선 통신 시스템에서 SCEF가 NIDD 구성을 설정하기 위한 방법에 있어서, 네트워크 노드로부터 단말의 비-IP 데이터 송신을 위한 제1 SCEF 연결 셋업 요청을 수신하는 단계; 로서, 상기 제1 SCEF 연결 셋업 요청은 상기 단말의 외부 식별자 및 상기 단말을 서비스하는 SCS/AS의 SCS/AS 식별자를 포함함, 상기 SCS/AS와의 상기 NIDD 구성이 확립되어 있는지 판단하는 단계; 상기 NIDD 구성이 확립되어 있지 않은 경우, 상기 NIDD 구성을 확립하기 위한 제2 SCEF 연결 셋업 요청을 상기 SCS/AS로 전송하는 단계; 로서, 상기 제2 SCEF 연결 셋업 요청은 상기 단말의 상기 외부 식별자를 포함함, 및 상기 SCS/AS와 상기 단말에 대한 상기 NIDD 구성을 설정하는 단계; 를 포함할 수 있다.

Description

무선 통신 시스템에서 NIDD(NON-IP DATA DELIVERY) 구성 설정 방법 및 이를 위한 장치
본 발명은 무선 통신 시스템에 관한 것으로서, 보다 상세하게 네트워크 노드의 NIDD(Non-IP Data Delivery) 구성을 설정하기 위한 방법 및 이를 지원하는 장치에 관한 것이다.
이동 통신 시스템은 사용자의 활동성을 보장하면서 음성 서비스를 제공하기 위해 개발되었다. 그러나 이동통신 시스템은 음성뿐 아니라 데이터 서비스까지 영역을 확장하였으며, 현재에는 폭발적인 트래픽의 증가로 인하여 자원의 부족 현상이 야기되고 사용자들이 보다 고속의 서비스에 대한 요구하므로, 보다 발전된 이동 통신 시스템이 요구되고 있다.
차세대 이동 통신 시스템의 요구 조건은 크게 폭발적인 데이터 트래픽의 수용, 사용자 당 전송률의 획기적인 증가, 대폭 증가된 연결 디바이스 개수의 수용, 매우 낮은 단대단 지연(End-to-End Latency), 고에너지 효율을 지원할 수 있어야 한다. 이를 위하여 이중 연결성(Dual Connectivity), 대규모 다중 입출력(Massive MIMO: Massive Multiple Input Multiple Output), 전이중(In-band Full Duplex), 비직교 다중접속(NOMA: Non-Orthogonal Multiple Access), 초광대역(Super wideband) 지원, 단말 네트워킹(Device Networking) 등 다양한 기술들이 연구되고 있다.
SCEF를 이용한 스몰 데이터 송수신은 단말의 발신호(mobile originated call)를 포함하는 것으로, 현재 표준에 따르면 NIDD 구성이 설정/확립되어 있지 않은 경우에는, 단말이 발신호를 송신하더라도 core 네트워크 노드에서는 이를 처리할 수가 없다. 하지만, 단말 입장에서는 현재 NIDD 수행 가능 여부를 알지 못하므로, 현재 NIDD 구성이 설정/확립되어 있지 않음에도 스몰 데이터(즉, 발신호)를 전송하게 된다. 그 결과, 이를 수신한 MME가 NIDD 구성이 설정되기 전까지 단말로부터 수신한 스몰 데이터를 버퍼링하지 못한다면, 상기 스몰 데이터는 폐기(discard)된다는 비효율성/문제점이 발생하게 된다.
따라서, 본 발명의 목적은, 네트워크 노드에서 NIDD 구성의 확인/설정하여 단말의 스몰 데이터(예를 들어, Non-IP 데이터) 전송이 원활히 송수신되기 위한 NIDD 구성 설정 방법을 제안한다.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명의 일 양상은, 무선 통신 시스템에서 SCEF(Service Capability Exposure Function)가 NIDD(Non-IP Data Delivery) 구성(configuration)을 설정하기 위한 방법에 있어서, 네트워크 노드로부터 단말의 비(non)-IP 데이터 송신을 위한 제1 SCEF 연결 셋업 요청을 수신하는 단계; 로서, 상기 제1 SCEF 연결 셋업 요청은 상기 단말의 외부 식별자(external identifier) 및 상기 단말을 서비스하는 SCS(Services Capability Server)/AS(Application Server)의 SCS/AS 식별자를 포함함, 상기 SCS/AS와의 상기 NIDD 구성이 확립되어 있는지 판단하는 단계; 상기 NIDD 구성이 확립되어 있지 않은 경우, 상기 NIDD 구성을 확립하기 위한 제2 SCEF 연결 셋업 요청을 상기 SCS/AS로 전송하는 단계; 로서, 상기 제2 SCEF 연결 셋업 요청은 상기 단말의 상기 외부 식별자를 포함함, 및 상기 SCS/AS와 상기 단말에 대한 상기 NIDD 구성을 설정하는 단계; 를 포함할 수 있다.
또한, 상기 단말의 외부 식별자는 상기 단말의 IMSI(International Mobile Subscriber Identity)에 대응되며, 상기 SCS/AS ID는 상기 단말의 가입 정보로서 상기 HSS에 저장되어 있을 수 있다.
또한, 상기 네트워크 노드는 HSS(Home Subscriber Server) 또는 MME(Mobility Management Entity)에 해당할 수 있다.
또한, 상기 네트워크 노드가 상기 MME에 해당하며, 상기 MME에 의해 상기 단말의 제어 평면을 통한 상기 비-IP 데이터 송신 지원이 판단됨에 따라 상기 비-IP 데이터 송신을 위한 SCEF 전달 방식이 선택된 경우, 상기 제1 SCEF 연결 셋업 요청이 상기 MME로부터 수신될 수 있다.
또한, 상기 네트워크 노드가 상기 HSS에 해당하며, 상기 HSS에 의해 상기 비-IP 데이터 송신을 위한 상기 NIDD 구성이 ULR(Update Location Request) 메시지를 통해 필요하다고 판단되는 경우, 상기 제1 SCEF 연결 셋업 요청이 상기 HSS로부터 수신될 수 있다.
또한, 상기 NIDD 구성을 설정하는 단계는, 상기 SCS/AS로부터 상기 단말과의 상기 NIDD 구성 설정을 요청하는 제1 NIDD 구성 요청 메시지를 수신하는 단계; 및 상기 수신한 제1 NIDD 구성 요청 메시지에 기초하여 HSS로 상기 NIDD 구성 설정을 위한 제2 NIDD 구성 요청 메시지를 전송하는 단계; 를 포함하되, 상기 제1 및 제2 NIDD 구성 요청 메시지는, 상기 SCS/AS에 대한 SCS/AS 식별자와 SCS/AS 참조 식별자, NIDD 최대 횟수, NIDD 지속 기간(Duration) 및/또는 NIDD 목적지(Destination) 주소를 포함할 수 있다.
또한, 상기 NIDD 구성 설정 방법은 상기 NIDD 구성이 설정된 후, 상기 비-IP 데이터로서 발신호(Mobile Originated; MO) 데이터의 전송을 알리는 제1 MO NIDD 지시 메시지를 수신하는 단계; 및 상기 SCS/AS로 제2 MO NIDD 지시 메시지를 전송하는 단계; 를 더 포함하되, 상기 제1 및 제2 MO NIDD 지시 메시지는 상기 SCEF 참조 식별자 및 상기 발신호 데이터를 포함할 수 있다.
또한, 상기 NIDD 구성 설정 방법은 상기 제2 MO NIDD 지시 메시지에 대한 응답으로서 제1 MO NIDD Ack(Acknowledge) 메시지를 수신하는 단계; 및 제1 MO NIDD 지시 메시지에 대한 응답으로서 제2 MO NIDD Ack(Acknowledge) 메시지를 전송하는 단계; 를 더 포함할 수 있다.
또한, 상기 NIDD 구성 설정 방법은 상기 NIDD 구성이 설정된 후, 상기 비-IP 데이터로서 착신호(Mobile Terminated; MT) 데이터의 전송을 알리는 제1 MT NIDD 요청 메시지를 상기 SCS/AS로부터 수신하는 단계; 및 제2 MO NIDD 요청 메시지를 전송하는 단계; 를 더 포함하되, 상기 제1 및 제2 MO NIDD 요청 메시지는 상기 SCEF 참조 식별자 및 상기 착신호 데이터를 포함할 수 있다.
또한, 또한, 상기 NIDD 구성 설정 방법은 상기 제2 MT NIDD 요청 메시지에 대한 응답으로서 제2 MT NIDD 응답 메시지를 수신하는 단계; 및 제1 MT NIDD 요청 메시지에 대한 응답으로서 제1 MT NIDD 응답 메시지를 전송하는 단계; 를 더 포함하되, 상기 제2 MT NIDD 응답 메시지는, MME에 의해 상기 착신호 데이터가 전송 불가라고 판단된 경우, 전송 불가 이유를 지시하는 원인 값을 포함할 수 있다.
또한, 본 발명의 다른 양상은, 무선 통신 시스템에서 NIDD(Non-IP Data Delivery) 구성(configuration)을 설정하는 SCEF(Service Capability Exposure Function)에 있어서, 신호를 송수신하기 위한 통신 모듈(communication module); 및 상기 통신 모듈을 제어하는 프로세서; 를 포함하고, 상기 프로세서는, 네트워크 노드로부터 단말의 비(non)-IP 데이터 송신을 위한 제1 SCEF 연결 셋업 요청을 수신하되, 상기 제1 SCEF 연결 셋업 요청은 상기 단말의 외부 식별자(external identifier) 및 상기 단말을 서비스하는 SCS(Services Capability Server)/AS(Application Server)의 SCS/AS 식별자를 포함함, 상기 SCS/AS와의 상기 NIDD 구성이 확립되어 있는지 판단하고, 상기 NIDD 구성이 확립되어 있지 않은 경우, 상기 NIDD 구성을 확립하기 위한 제2 SCEF 연결 셋업 요청을 상기 SCS/AS로 전송하되, 상기 제2 SCEF 연결 셋업 요청은 상기 단말의 상기 외부 식별자를 포함함, 상기 SCS/AS와 상기 단말에 대한 상기 NIDD 구성을 설정할 수 있다.
또한, 상기 단말의 외부 식별자는 상기 단말의 IMSI(International Mobile Subscriber Identity)에 대응되며, 상기 SCS/AS ID는 상기 단말의 가입 정보로서 상기 HSS에 저장되어 있을 수 있다.
또한, 상기 네트워크 노드는 HSS(Home Subscriber Server) 또는 MME(Mobility Management Entity)에 해당할 수 있다.
또한, 상기 네트워크 노드가 상기 MME에 해당하며, 상기 MME에 의해 상기 단말의 제어 평면을 통한 상기 비-IP 데이터 송신 지원이 판단됨에 따라 상기 비-IP 데이터 송신을 위한 SCEF 전달 방식이 선택된 경우, 상기 제1 SCEF 연결 셋업 요청이 상기 MME로부터 수신될 수 있다.
또한, 상기 네트워크 노드가 상기 HSS에 해당하며, 상기 HSS에 의해 상기 비-IP 데이터 송신을 위한 상기 NIDD 구성이 ULR(Update Location Request) 메시지를 통해 필요하다고 판단되는 경우, 상기 제1 SCEF 연결 셋업 요청이 상기 HSS로부터 수신될 수 있다.
본 발명의 실시예에 따르면, 단말이 현재 NIDD 구성의 설정 여부를 인지하고, NIDD 구성이 설정되어 있는 경우에 스몰 데이터를 전송할 수 있게 되어, 스몰 데이터가 폐기(discard)된다는 문제점이 줄어든다는 효과가 발생한다.
또한, 본 발명의 다른 실시예에 따르면, 단말이 접속(Attach) 시 SCEF를 통한 데이터 송수신을 수행하는 경우, 네트워크 단에서 SCS/AS가 트리거링하는 NIDD 구성의 확립/수행되기를 기다리는 것이 아니라 직접 SCS/AS로 NIDD 구성을 적극적으로 요청할 수 있어 단말의 스몰 데이터 송수신이 원활하게 수행될 수 있다는 효과가 발생한다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 특징을 설명한다.
도 1은 본 발명이 적용될 수 있는 EPS(Evolved Packet System)을 간략히 예시하는 도면이다.
도 2는 본 발명이 적용될 수 있는 E-UTRAN(evolved universal terrestrial radio access network)의 네트워크 구조의 일 예를 나타낸다.
도 3은 본 발명이 적용될 수 있는 무선 통신 시스템에서 E-UTRAN 및 EPC의 구조를 예시한다.
도 4는 본 발명이 적용될 수 있는 무선 통신 시스템에서 단말과 E-UTRAN 사이의 무선 인터페이스 프로토콜(radio interface protocol) 구조를 나타낸다.
도 5는 본 발명이 적용될 수 있는 무선 통신 시스템에서 물리 채널의 구조를 간략히 예시하는 도면이다.
도 6은 본 발명이 적용될 수 있는 무선 통신 시스템에서 경쟁 기반 랜덤 액세스 절차를 설명하기 위한 도면이다.
도 7은 본 발명의 일 실시예에 따른 접속 절차를 예시한 순서도이다.
도 8은 본 발명이 적용될 수 있는 무선 통신 시스템에서 PDN 연결 절차를 간략히 예시하는 도면이다.
도 9는 본 발명이 적용될 수 있는 무선 통신 시스템에서 MTC(Machine-Type Communication) 아키텍처(architecture)를 예시하는 도면이다.
도 10은 본 발명이 적용될 수 있는 무선 통신 시스템에서 서비스 능력 노출(Service Capability Exposure)을 위한 아키텍쳐를 예시한다.
도 11은 본 발명이 적용될 수 있는 무선 통신 시스템에서 단대단(End to End) 스몰 데이터 플로우를 예시하는 도면이다.
도 12는 본 발명이 적용될 수 있는 무선 통신 시스템에서 SCEF를 경유한 효율적인 non-IP 스몰 데이터 전송을 위해 제안되는 셀룰러 IoT 네트워크 아키텍쳐를 예시한다.
도 13은 본 발명이 적용될 수 있는 무선 통신 시스템에서 HSS를 통한 모니터링 이벤트 설정 및 삭제 절차를 예시한다.
도 14는 본 발명이 적용될 수 있는 무선 통신 시스템에서 MO 스몰 데이터 전송 절차를 예시한다.
도 15는 본 발명이 적용될 수 있는 무선 통신 시스템에서 MT 스몰 데이터 전송 절차를 예시한다.
도 16은 본 발명이 적용될 수 있는 무선 통신 시스템에서 MME와 SCEF를 통해 UL/DL 데이터(즉, non-IP 데이터) 전송을 위한 링크 셋업 과정을 예시한다.
도 17은 본 발명이 적용될 수 있는 무선 통신 시스템에서 NIDD 구성 절차를 예시한다.
도 18은 본 발명이 적용될 수 있는 무선 통신 시스템에서 MO NIDD 절차를 예시한다.
도 19는 본 발명이 적용될 수 있는 무선 통신 시스템에서 MT NIDD 절차를 예시한다.
도 20은 본 발명의 제1 실시예에 따른 SCEF 연결을 위한 접속 절차를 예시한 순서도이다.
도 21은 본 발명의 제2 실시예에 따른 SCEF 연결을 위한 접속 절차를 예시한 순서도이다.
도 22는 본 발명의 일 실시예에 따른 NIDD 구성 설정 절차를 예시한 순서도이다.
도 23는 본 발명의 일 실시예에 따른 통신 장치의 블록 구성도를 예시한다.
도 24는 본 발명의 일 실시예에 따른 통신 장치의 블록 구성도를 예시한다.
이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.
몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다.
본 명세서에서 기지국은 단말과 직접적으로 통신을 수행하는 네트워크의 종단 노드(terminal node)로서의 의미를 갖는다. 본 문서에서 기지국에 의해 수행되는 것으로 설명된 특정 동작은 경우에 따라서는 기지국의 상위 노드(upper node)에 의해 수행될 수도 있다. 즉, 기지국을 포함하는 다수의 네트워크 노드들(network nodes)로 이루어지는 네트워크에서 단말과의 통신을 위해 수행되는 다양한 동작들은 기지국 또는 기지국 이외의 다른 네트워크 노드들에 의해 수행될 수 있음은 자명하다. '기지국(BS: Base Station)'은 고정국(fixed station), Node B, eNB(evolved-NodeB), BTS(base transceiver system), 액세스 포인트(AP: Access Point) 등의 용어에 의해 대체될 수 있다. 또한, '단말(Terminal)'은 고정되거나 이동성을 가질 수 있으며, UE(User Equipment), MS(Mobile Station), UT(user terminal), MSS(Mobile Subscriber Station), SS(Subscriber Station), AMS(Advanced Mobile Station), WT(Wireless terminal), MTC(Machine-Type Communication) 장치, M2M(Machine-to-Machine) 장치, D2D(Device-to-Device) 장치 등의 용어로 대체될 수 있다.
이하에서, 하향링크(DL: downlink)는 기지국에서 단말로의 통신을 의미하며, 상향링크(UL: uplink)는 단말에서 기지국으로의 통신을 의미한다. 하향링크에서 송신기는 기지국의 일부이고, 수신기는 단말의 일부일 수 있다. 상향링크에서 송신기는 단말의 일부이고, 수신기는 기지국의 일부일 수 있다.
이하의 설명에서 사용되는 특정 용어들은 본 발명의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 발명의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
이하의 기술은 CDMA(code division multiple access), FDMA(frequency division multiple access), TDMA(time division multiple access), OFDMA(orthogonal frequency division multiple access), SC-FDMA(single carrier frequency division multiple access), NOMA(non-orthogonal multiple access) 등과 같은 다양한 무선 접속 시스템에 이용될 수 있다. CDMA는 UTRA(universal terrestrial radio access)나 CDMA2000과 같은 무선 기술(radio technology)로 구현될 수 있다. TDMA는 GSM(global system for mobile communications)/GPRS(general packet radio service)/EDGE(enhanced data rates for GSM evolution)와 같은 무선 기술로 구현될 수 있다. OFDMA는 IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, E-UTRA(evolved UTRA) 등과 같은 무선 기술로 구현될 수 있다. UTRA는 UMTS(universal mobile telecommunications system)의 일부이다. 3GPP(3rd generation partnership project) LTE(long term evolution)은 E-UTRA를 사용하는 E-UMTS(evolved UMTS)의 일부로써, 하향링크에서 OFDMA를 채용하고 상향링크에서 SC-FDMA를 채용한다. LTE-A(advanced)는 3GPP LTE의 진화이다.
본 발명의 실시예들은 무선 접속 시스템들인 IEEE 802, 3GPP 및 3GPP2 중 적어도 하나에 개시된 표준 문서들에 의해 뒷받침될 수 있다. 즉, 본 발명의 실시예들 중 본 발명의 기술적 사상을 명확히 드러내기 위해 설명하지 않은 단계들 또는 부분들은 상기 문서들에 의해 뒷받침될 수 있다. 또한, 본 문서에서 개시하고 있는 모든 용어들은 상기 표준 문서에 의해 설명될 수 있다.
설명을 명확하게 하기 위해, 3GPP LTE/LTE-A를 위주로 기술하지만 본 발명의 기술적 특징이 이에 제한되는 것은 아니다.
본 문서에서 사용될 수 있는 용어들은 다음과 같이 정의된다.
- UMTS(Universal Mobile Telecommunications System): 3GPP에 의해서 개발된, GSM(Global System for Mobile Communication) 기반의 3 세대(Generation) 이동 통신 기술
- EPS(Evolved Packet System): IP(Internet Protocol) 기반의 패킷 교환(packet switched) 코어 네트워크인 EPC(Evolved Packet Core)와 LTE, UTRAN 등의 액세스 네트워크로 구성된 네트워크 시스템. UMTS가 진화된 형태의 네트워크이다.
- NodeB: UMTS 네트워크의 기지국. 옥외에 설치하며 커버리지는 매크로 셀(macro cell) 규모이다.
- eNodeB: EPS 네트워크의 기지국. 옥외에 설치하며 커버리지는 매크로 셀(macro cell) 규모이다.
- 단말(User Equipment): 사용자 기기. 단말은 단말(terminal), ME(Mobile Equipment), MS(Mobile Station) 등의 용어로 언급될 수 있다. 또한, 단말은 노트북, 휴대폰, PDA(Personal Digital Assistant), 스마트폰, 멀티미디어 기기 등과 같이 휴대 가능한 기기일 수 있고, 또는 PC(Personal Computer), 차량 탑재 장치와 같이 휴대 불가능한 기기일 수도 있다. MTC 관련 내용에서 단말 또는 단말이라는 용어는 MTC 단말을 지칭할 수 있다.
- IMS(IP Multimedia Subsystem): 멀티미디어 서비스를 IP 기반으로 제공하는 서브시스템.
- IMSI(International Mobile Subscriber Identity): 이동 통신 네트워크에서 국제적으로 고유하게 할당되는 사용자 식별자.
- MTC(Machine Type Communication): 사람의 개입 없이 머신에 의해 수행되는 통신. M2M(Machine to Machine) 통신이라고 지칭할 수도 있다.
- MTC 단말(MTC UE 또는 MTC device 또는 MTC 장치): 이동 통신 네트워크를 통한 통신(예를 들어, PLMN을 통해 MTC 서버와 통신) 기능을 가지고, MTC 기능을 수행하는 단말(예를 들어, 자판기, 검침기 등).
- MTC 서버(MTC server): MTC 단말을 관리하는 네트워크 상의 서버. 이동 통신 네트워크의 내부 또는 외부에 존재할 수 있다. MTC 사용자가 접근(access)할 수 있는 인터페이스를 가질 수 있다. 또한, MTC 서버는 다른 서버들에게 MTC 관련 서비스를 제공할 수도 있고(SCS(Services Capability Server) 형태), 자신이 MTC 어플리케이션 서버일 수도 있다.
- (MTC) 어플리케이션(application): (MTC가 적용되는) 서비스(예를 들어, 원격 검침, 물량 이동 추적, 기상 관측 센서 등)
- (MTC) 어플리케이션 서버: (MTC) 어플리케이션이 실행되는 네트워크 상의 서버
- MTC 특징(MTC feature): MTC 어플리케이션을 지원하기 위한 네트워크의 기능. 예를 들어, MTC 모니터링(monitoring)은 원격 검침 등의 MTC 어플리케이션에서 장비 분실 등을 대비하기 위한 특징이고, 낮은 이동성(low mobility)은 자판기와 같은 MTC 단말에 대한 MTC 어플리케이션을 위한 특징이다.
- MTC 사용자(MTC User): MTC 사용자는 MTC 서버에 의해 제공되는 서비스를 사용한다.
- MTC 가입자(MTC subscriber): 네트워크 오퍼레이터와 접속 관계를 가지고 있으며, 하나 이상의 MTC 단말에게 서비스를 제공하는 엔티티(entity)이다.
- MTC 그룹(MTC group): 적어도 하나 이상의 MTC 특징을 공유하며, MTC 가입자에 속한 MTC 단말의 그룹을 의미한다.
- 서비스 역량 서버(SCS: Services Capability Server): HPLMN(Home PLMN) 상의 MTC-IWF(MTC InterWorking Function) 및 MTC 단말과 통신하기 위한 엔티티로서, 3GPP 네트워크와 접속되어 있다. SCS는 하나 이상의 MTC 어플리케이션에 의한 사용을 위한 능력(capability)를 제공한다.
- 외부 식별자(External Identifier): 3GPP 네트워크의 외부 엔티티(예를 들어, SCS 또는 어플리케이션 서버)가 MTC 단말(또는 MTC 단말이 속한 가입자)을 가리키기(또는 식별하기) 위해 사용하는 식별자(identifier)로서 전세계적으로 고유(globally unique)하다. 외부 식별자는 다음과 같이 도메인 식별자(Domain Identifier)와 로컬 식별자(Local Identifier)로 구성된다.
- 도메인 식별자(Domain Identifier): 이동 통신 네트워크 사업자의 제어 항에 있는 도메인을 식별하기 위한 식별자. 하나의 사업자는 서로 다른 서비스로의 접속을 제공하기 위해 서비스 별로 도메인 식별자를 사용할 수 있다.
- 로컬 식별자(Local Identifier): IMSI(International Mobile Subscriber Identity)를 유추하거나 획득하는데 사용되는 식별자. 로컬 식별자는 어플리케이션 도메인 내에서는 고유(unique)해야 하며, 이동 통신 네트워크 사업자에 의해 관리된다.
- RAN(Radio Access Network): 3GPP 네트워크에서 Node B 및 이를 제어하는 RNC(Radio Network Controller), eNodeB를 포함하는 단위. 단말 단에 존재하며 코어 네트워크로의 연결을 제공한다.
- HLR(Home Location Register)/HSS(Home Subscriber Server): 3GPP 네트워크 내의 가입자 정보를 가지고 있는 데이터베이스. HSS는 설정 저장(configuration storage), 식별자 관리(identity management), 사용자 상태 저장 등의 기능을 수행할 수 있다.
- RANAP(RAN Application Part): RAN과 코어 네트워크의 제어를 담당하는 노드(즉, MME(Mobility Management Entity)/SGSN(Serving GPRS(General Packet Radio Service) Supporting Node)/MSC(Mobile Switching Center)) 사이의 인터페이스.
- PLMN(Public Land Mobile Network): 개인들에게 이동 통신 서비스를 제공할 목적으로 구성된 네트워크. 오퍼레이터 별로 구분되어 구성될 수 있다.
- NAS(Non-Access Stratum): UMTS, EPS 프로토콜 스택에서 단말과 코어 네트워크 간의 시그널링, 트래픽 메시지를 주고 받기 위한 기능적인 계층. 단말의 이동성을 지원하고, 단말과 PDN GW 간의 IP 연결을 수립 및 유지하는 세션 관리 절차를 지원하는 것을 주된 기능으로 한다.
- SCEF(Service Capability Exposure Function): 3GPP 네트워크 인터페이스에 의해 제공되는 서비스 및 능력(capability)을 안전하게 노출하기 위한 수단을 제공하는 서비스 능력 노출(service capability exposure)을 위한 3GPP 아키텍쳐 내 엔티티.
이하, 위와 같이 정의된 용어를 바탕으로 본 발명에 대하여 기술한다.
본 발명이 적용될 수 있는 시스템 일반
도 1은 본 발명이 적용될 수 있는 EPS (Evolved Packet System)을 간략히 예시하는 도면이다.
도 1의 네트워크 구조도는 EPC(Evolved Packet Core)를 포함하는 EPS(Evolved Packet System)의 구조를 이를 간략하게 재구성 한 것이다.
EPC(Evolved Packet Core)는 3GPP 기술들의 성능을 향상하기 위한 SAE(System Architecture Evolution)의 핵심적인 요소이다. SAE는 다양한 종류의 네트워크 간의 이동성을 지원하는 네트워크 구조를 결정하는 연구 과제에 해당한다. SAE는, 예를 들어, IP 기반으로 다양한 무선 접속 기술들을 지원하고 보다 향상된 데이터 전송 능력을 제공하는 등의 최적화된 패킷-기반 시스템을 제공하는 것을 목표로 한다.
구체적으로, EPC는 3GPP LTE 시스템을 위한 IP 이동 통신 시스템의 코어 네트워크(Core Network)이며, 패킷-기반 실시간 및 비실시간 서비스를 지원할 수 있다. 기존의 이동 통신 시스템(즉, 2 세대 또는 3 세대 이동 통신 시스템)에서는 음성을 위한 CS(Circuit-Switched) 및 데이터를 위한 PS(Packet-Switched)의 2 개의 구별되는 서브-도메인을 통해서 코어 네트워크의 기능이 구현되었다. 그러나, 3 세대 이동 통신 시스템의 진화인 3GPP LTE 시스템에서는, CS 및 PS의 서브-도메인들이 하나의 IP 도메인으로 단일화되었다. 즉, 3GPP LTE 시스템에서는, IP 능력(capability)을 가지는 단말과 단말 간의 연결이, IP 기반의 기지국(예를 들어, eNodeB(evolved Node B)), EPC, 애플리케이션 도메인(예를 들어, IMS)을 통하여 구성될 수 있다. 즉, EPC는 단-대-단(end-to-end) IP 서비스 구현에 필수적인 구조이다.
EPC는 다양한 구성요소들을 포함할 수 있으며, 도 1에서는 그 중에서 일부에 해당하는, SGW(Serving Gateway)(또는 S-GW), PDN GW(Packet Data Network Gateway)(또는 PGW 또는 P-GW), MME(Mobility Management Entity), SGSN(Serving GPRS(General Packet Radio Service) Supporting Node), ePDG(enhanced Packet Data Gateway)를 도시한다.
SGW는 무선 접속 네트워크(RAN)와 코어 네트워크 사이의 경계점으로서 동작하고, eNodeB와 PDN GW 사이의 데이터 경로를 유지하는 기능을 하는 요소이다. 또한, 단말이 eNodeB에 의해서 서빙(serving)되는 영역에 걸쳐 이동하는 경우, SGW는 로컬 이동성 앵커 포인트(anchor point)의 역할을 한다. 즉, E-UTRAN (3GPP 릴리즈-8 이후에서 정의되는 Evolved-UMTS(Universal Mobile Telecommunications System) Terrestrial Radio Access Network) 내에서의 이동성을 위해서 SGW를 통해서 패킷들이 라우팅될 수 있다. 또한, SGW는 다른 3GPP 네트워크(3GPP 릴리즈-8 전에 정의되는 RAN, 예를 들어, UTRAN 또는 GERAN(GSM(Global System for Mobile Communication)/EDGE(Enhanced Data rates for Global Evolution) Radio Access Network)와의 이동성을 위한 앵커 포인트로서 기능할 수도 있다.
PDN GW는 패킷 데이터 네트워크를 향한 데이터 인터페이스의 종단점(termination point)에 해당한다. PDN GW는 정책 집행 특징(policy enforcement features), 패킷 필터링(packet filtering), 과금 지원(charging support) 등을 지원할 수 있다. 또한, 3GPP 네트워크와 비-3GPP(non-3GPP) 네트워크 (예를 들어, I-WLAN(Interworking Wireless Local Area Network)과 같은 신뢰되지 않는 네트워크, CDMA(Code Division Multiple Access) 네트워크나 Wimax와 같은 신뢰되는 네트워크)와의 이동성 관리를 위한 앵커 포인트 역할을 할 수 있다.
도 1의 네트워크 구조의 예시에서는 SGW와 PDN GW가 별도의 게이트웨이로 구성되는 것을 나타내지만, 두 개의 게이트웨이가 단일 게이트웨이 구성 옵션(Single Gateway Configuration Option)에 따라 구현될 수도 있다.
MME는, 단말의 네트워크 연결에 대한 액세스, 네트워크 자원의 할당, 트래킹(tracking), 페이징(paging), 로밍(roaming) 및 핸드오버 등을 지원하기 위한 시그널링 및 제어 기능들을 수행하는 요소이다. MME는 가입자 및 세션 관리에 관련된 제어 평면 기능들을 제어한다. MME는 수많은 eNodeB들을 관리하고, 다른 2G/3G 네트워크에 대한 핸드오버를 위한 종래의 게이트웨이의 선택을 위한 시그널링을 수행한다. 또한, MME는 보안 과정(Security Procedures), 단말-대-네트워크 세션 핸들링(Terminal-to-network Session Handling), 유휴 단말 위치결정 관리(Idle Terminal Location Management) 등의 기능을 수행한다.
SGSN은 다른 3GPP 네트워크(예를 들어, GPRS 네트워크)에 대한 사용자의 이동성 관리 및 인증(authentication)과 같은 모든 패킷 데이터를 핸들링한다.
ePDG는 신뢰되지 않는 비-3GPP 네트워크(예를 들어, I-WLAN, WiFi 핫스팟(hotspot) 등)에 대한 보안 노드로서의 역할을 한다.
도 1을 참조하여 설명한 바와 같이, IP 능력을 가지는 단말은, 3GPP 액세스는 물론 비-3GPP 액세스 기반으로도 EPC 내의 다양한 요소들을 경유하여 사업자(즉, 오퍼레이터(operator))가 제공하는 IP 서비스 네트워크(예를 들어, IMS)에 액세스할 수 있다.
또한, 도 1에서는 다양한 레퍼런스 포인트들(예를 들어, S1-U, S1-MME 등)을 도시한다. 3GPP 시스템에서는 E-UTRAN 및 EPC의 상이한 기능 개체(functional entity)들에 존재하는 2 개의 기능을 연결하는 개념적인 링크를 레퍼런스 포인트(reference point)라고 정의한다. 다음의 표 1은 도 1에 도시된 레퍼런스 포인트를 정리한 것이다. 표 1의 예시들 외에도 네트워크 구조에 따라 다양한 레퍼런스 포인트(reference point)들이 존재할 수 있다.
Figure PCTKR2017000294-appb-T000001
도 1에 도시된 레퍼런스 포인트 중에서 S2a 및 S2b는 비-3GPP 인터페이스에 해당한다. S2a는 신뢰되는 비-3GPP 액세스 및 PDN GW 간의 관련 제어 및 이동성 자원을 사용자 플레인에 제공하는 레퍼런스 포인트이다. S2b는 ePDG 및 PDN GW 간의 관련 제어 및 이동성 지원을 사용자 플레인에 제공하는 레퍼런스 포인트이다.
도 2는 본 발명이 적용될 수 있는 E-UTRAN(evolved universal terrestrial radio access network)의 네트워크 구조의 일 예를 나타낸다.
E-UTRAN 시스템은 기존 UTRAN 시스템에서 진화한 시스템으로, 예를 들어, 3GPP LTE/LTE-A 시스템일 수 있다. 통신 네트워크는 IMS 및 패킷 데이터를 통해 음성(voice)(예를 들어, VoIP(Voice over Internet Protocol))과 같은 다양한 통신 서비스를 제공하기 위하여 광범위하게 배치된다.
도 2를 참조하면, E-UMTS 네트워크는 E-UTRAN, EPC 및 하나 이상의 UE를 포함한다. E-UTRAN은 단말에게 제어 평면(control plane)과 사용자 평면(user plane) 프로토콜을 제공하는 eNB들로 구성되고, eNB들은 X2 인터페이스를 통해 연결된다.
X2 사용자 평면 인터페이스(X2-U)는 eNB들 사이에 정의된다. X2-U 인터페이스는 사용자 평면 PDU(packet data unit)의 보장되지 않은 전달(non guaranteed delivery)을 제공한다. X2 제어 평면 인터페이스(X2-CP)는 두 개의 이웃 eNB 사이에 정의된다. X2-CP는 eNB 간의 컨텍스트(context) 전달, 소스 eNB와 타겟 eNB 사이의 사용자 평면 터널의 제어, 핸드오버 관련 메시지의 전달, 상향링크 부하 관리 등의 기능을 수행한다.
eNB은 무선인터페이스를 통해 단말과 연결되고 S1 인터페이스를 통해 EPC(evolved packet core)에 연결된다.
S1 사용자 평면 인터페이스(S1-U)는 eNB와 서빙 게이트웨이(S-GW: serving gateway) 사이에 정의된다. S1 제어 평면 인터페이스(S1-MME)는 eNB와 이동성 관리 개체(MME: mobility management entity) 사이에 정의된다. S1 인터페이스는 EPS(evolved packet system) 베어러 서비스 관리 기능, NAS(non-access stratum) 시그널링 트랜스포트 기능, 네트워크 쉐어링, MME 부하 밸런싱 기능 등을 수행한다. S1 인터페이스는 eNB와 MME/S-GW 간에 다수-대-다수 관계(many-to-many-relation)를 지원한다.
MME는 NAS 시그널링 보안(security), AS(Access Stratum) 보안(security) 제어, 3GPP 액세스 네트워크 간 이동성을 지원하기 위한 CN(Core Network) 노드 간(Inter-CN) 시그널링, (페이징 재전송의 수행 및 제어 포함하여) 아이들(IDLE) 모드 UE 접근성(reachability), (아이들 및 액티브 모드 단말을 위한) 트래킹 영역 식별자(TAI: Tracking Area Identity) 관리, PDN GW 및 SGW 선택, MME가 변경되는 핸드오버를 위한 MME 선택, 2G 또는 3G 3GPP 액세스 네트워크로의 핸드오버를 위한 SGSN 선택, 로밍(roaming), 인증(authentication), 전용 베어러 확립(dedicated bearer establishment)를 포함하는 베어러 관리 기능, 공공 경고 시스템(PWS: Public Warning System)(지진 및 쓰나미 경고 시스템(ETWS: Earthquake and Tsunami Warning System) 및 상용 모바일 경고 시스템(CMAS: Commercial Mobile Alert System) 포함) 메시지 전송의 지원 등의 다양한 기능을 수행할 수 있다.
도 3은 본 발명이 적용될 수 있는 무선 통신 시스템에서 E-UTRAN 및 EPC의 구조를 예시한다.
도 3을 참조하면, eNB는 게이트웨이(예를 들어, MME)의 선택, 무선 자원 제어(RRC: radio resource control) 활성(activation) 동안 게이트웨이로의 라우팅, 방송 채널(BCH: broadcast channel)의 스케줄링 및 전송, 상향링크 및 하향링크에서 UE로 동적 자원 할당, 그리고 LTE_ACTIVE 상태에서 이동성 제어 연결의 기능을 수행할 수 있다. 상술한 바와 같이, EPC 내에서 게이트웨이는 페이징 개시(orgination), LTE_IDLE 상태 관리, 사용자 평면(user plane)의 암호화(ciphering), 시스템 구조 진화(SAE: System Architecture Evolution) 베어러 제어, 그리고 NAS 시그널링의 암호화(ciphering) 및 무결성(intergrity) 보호의 기능을 수행할 수 있다.
도 4는 본 발명이 적용될 수 있는 무선 통신 시스템에서 단말과 E-UTRAN 사이의 무선 인터페이스 프로토콜(radio interface protocol) 구조를 나타낸다.
도 4(a)는 제어 평면(control plane)에 대한 무선 프로토콜 구조를 나타내고, 도 4(b)는 사용자 평면(user plane)에 대한 무선 프로토콜 구조를 나타낸다.
도 4를 참조하면, 단말과 E-UTRAN 사이의 무선 인터페이스 프로토콜의 계층들은 통신 시스템의 기술분야에 공지된 널리 알려진 개방형 시스템 간 상호접속(OSI: open system interconnection) 표준 모델의 하위 3 계층에 기초하여 제1 계층(L1), 제2 계층 (L2) 및 제3 계층 (L3)으로 분할될 수 있다. 단말과 E-UTRAN 사이의 무선 인터페이스 프로토콜은 수평적으로 물리계층(physical layer), 데이터링크 계층(data link layer) 및 네트워크 계층(network layer)으로 이루어지며, 수직적으로는 데이터 정보 전송을 위한 프로토콜 스택(protocol stack) 사용자 평면(user plane)과 제어신호(signaling) 전달을 위한 프로토콜 스택인 제어 평면(control plane)으로 구분된다.
제어평면은 단말과 네트워크가 호를 관리하기 위해서 이용하는 제어 메시지들이 전송되는 통로를 의미한다. 사용자 평면은 애플리케이션 계층에서 생성된 데이터, 예를 들어, 음성 데이터 또는 인터넷 패킷 데이터 등이 전송되는 통로를 의미한다. 이하, 무선 프로토콜의 제어평면과 사용자평면의 각 계층을 설명한다.
제1 계층(L1)인 물리 계층(PHY: physical layer)은 물리 채널(physical channel)을 사용함으로써 상위 계층으로의 정보 송신 서비스(information transfer service)를 제공한다. 물리 계층은 상위 레벨에 위치한 매체 접속 제어(MAC: medium access control) 계층으로 전송 채널(transport channel)을 통하여 연결되고, 전송 채널을 통하여 MAC 계층과 물리 계층 사이에서 데이터가 전송된다. 전송 채널은 무선 인터페이스를 통해 데이터가 어떻게 어떤 특징으로 전송되는가에 따라 분류된다. 그리고, 서로 다른 물리 계층 사이, 송신단의 물리 계층과 수신단의 물리 계층 간에는 물리 채널(physical channel)을 통해 데이터가 전송된다. 물리 계층은 OFDM(orthogonal frequency division multiplexing) 방식으로 변조되며, 시간과 주파수를 무선 자원으로 활용한다.
물리 계층에서 사용되는 몇몇 물리 제어 채널들이 있다. 물리 하향링크 제어 채널(PDCCH: physical downlink control channel)는 단말에게 페이징 채널(PCH: paging channel)와 하향링크 공유 채널(DL-SCH: downlink shared channel)의 자원 할당 및 상향링크 공유 채널(UL-SCH: uplink shared channel)과 관련된 HARQ(hybrid automatic repeat request) 정보를 알려준다. 또한, PDCCH는 단말에게 상향링크 전송의 자원 할당을 알려주는 상향링크 승인(UL grant)를 나를 수 있다. 물리 제어 포맷 지시자 채널(PDFICH: physical control format indicator channel)는 단말에게 PDCCH들에 사용되는 OFDM 심볼의 수를 알려주고, 매 서브프레임마다 전송된다. 물리 HARQ 지시자 채널(PHICH: physical HARQ indicator channel)는 상향링크 전송의 응답으로 HARQ ACK(acknowledge)/NACK(non-acknowledge) 신호를 나른다. 물리 상향링크 제어 채널(PUCCH: physical uplink control channel)은 하향링크 전송에 대한 HARQ ACK/NACK, 스케줄링 요청 및 채널 품질 지시자(CQI: channel quality indicator) 등과 같은 상향링크 제어 정보를 나른다. 물리 상향링크 공유 채널(PUSCH: physical uplink shared channel)은 UL-SCH을 나른다.
제2 계층(L2)의 MAC 계층은 논리 채널(logical channel)을 통하여 상위 계층인 무선 링크 제어(RLC: radio link control) 계층에게 서비스를 제공한다. 또한, MAC 계층은 논리 채널과 전송 채널 간의 맵핑 및 논리 채널에 속하는 MAC 서비스 데이터 유닛(SDU: service data unit)의 전송 채널 상에 물리 채널로 제공되는 전송 블록(transport block)으로의 다중화/역다중화 기능을 포함한다.
제2 계층(L2)의 RLC 계층은 신뢰성 있는 데이터 전송을 지원한다. RLC 계층의 기능은 RLC SDU의 연결(concatenation), 분할(segmentation) 및 재결합(reassembly)을 포함한다. 무선 베어러(RB: radio bearer)가 요구하는 다양한 QoS(quality of service)를 보장하기 위해, RLC 계층은 투명 모드(TM: transparent mode), 비확인 모드(UM: unacknowledged mode) 및 확인 모드(AM: acknowledge mode)의 세 가지의 동작 모드를 제공한다. AM RLC는 ARQ(automatic repeat request)를 통해 오류 정정을 제공한다. 한편, MAC 계층이 RLC 기능을 수행하는 경우에 RLC 계층은 MAC 계층의 기능 블록으로 포함될 수 있다.
제2 계층(L2)의 패킷 데이터 컨버전스 프로토콜(PDCP: packet data convergence protocol) 계층은 사용자 평면에서 사용자 데이터의 전달, 헤더 압축(header compression) 및 암호화(ciphering) 기능을 수행한다. 헤더 압축 기능은 작은 대역폭을 가지는 무선 인터페이스를 통하여 IPv4(internet protocol version 4) 또는 IPv6(internet protocol version 6)와 같은 인터넷 프로토콜(IP: internet protocol) 패킷을 효율적으로 전송되게 하기 위하여 상대적으로 크기가 크고 불필요한 제어 정보를 담고 있는 IP 패킷 헤더 사이즈를 줄이는 기능을 의미한다. 제어 평면에서의 PDCP 계층의 기능은 제어 평면 데이터의 전달 및 암호화/무결정 보호(integrity protection)을 포함한다.
제3 계층(L3)의 최하위 부분에 위치한 무선 자원 제어(RRC: radio resource control) 계층은 제어 평면에만 정의된다. RRC 계층은 단말과 네트워크 간의 무선 자원을 제어하는 역할을 수행한다. 이를 위해 단말과 네트워크는 RRC 계층을 통해 RRC 메시지를 서로 교환한다. RRC 계층은 무선 베어러들의 설정(configuration), 재설정(re-configuration) 및 해제(release)와 관련하여 논리 채널, 전송 채널 및 물리 채널을 제어한다. 무선 베어러는 단말과 네트워크 사이의 데이터 전송을 위하여 제2 계층(L2)에 의하여 제공되는 논리적인 경로를 의미한다. 무선 베어러가 설정된다는 것은 특정 서비스를 제공하기 위해 무선 프로토콜 계층 및 채널의 특성을 규정하고, 각각의 구체적인 파라미터 및 동작 방법을 설정하는 것을 의미한다. 무선 베어러는 다시 시그널링 무선 베어러(SRB: signaling RB)와 데이터 무선 베어러(DRB: data RB) 두 가지로 나눠 질 수 있다. SRB는 제어 평면에서 RRC 메시지를 전송하는 통로로 사용되며, DRB는 사용자 평면에서 사용자 데이터를 전송하는 통로로 사용된다.
RRC 계층 상위에 위치하는 NAS(non-access stratum) 계층은 세션 관리(session management)와 이동성 관리(mobility management) 등의 기능을 수행한다.
기지국을 구성하는 하나의 셀은 1.25, 2.5, 5, 10, 20Mhz 등의 대역폭 중 하나로 설정되어 여러 단말에게 하향 또는 상향 전송 서비스를 제공한다. 서로 다른 셀은 서로 다른 대역폭을 제공하도록 설정될 수 있다.
네트워크에서 단말로 데이터를 전송하는 하향 전송채널(downlink transport channel)은 시스템 정보를 전송하는 방송 채널(BCH: broadcast channel), 페이징 메시지를 전송하는 PCH, 사용자 트래픽이나 제어메시지를 전송하는 DL-SCH 등이 있다. 하향 멀티캐스트 또는 방송 서비스의 트래픽 또는 제어메시지의 경우 DL-SCH를 통해 전송될 수도 있고, 또는 별도의 하향 멀티캐스트 채널(MCH: multicast channel)을 통해 전송될 수도 있다. 한편, 단말에서 네트워크로 데이터를 전송하는 상향 전송채널(uplink transport channel)로는 초기 제어메시지를 전송하는 랜덤 액세스 채널(RACH: random access channel), 사용자 트래픽이나 제어메시지를 전송하는 UL-SCH(uplink shared channel)가 있다.
논리 채널(logical channel)은 전송 채널의 상위에 있으며, 전송 채널에 맵핑된다. 논리 채널은 제어 영역 정보의 전달을 위한 제어 채널과 사용자 영역 정보의 전달을 위한 트래픽 채널로 구분될 수 있다. 제어 채널로는 방송 제어 채널(BCCH: broadcast control channel), 페이징 제어 채널(PCCH: paging control channel), 공통 제어 채널(CCCH: common control channel), 전용 제어 채널(DCCH: dedicated control channel), 멀티캐스트 제어 채널(MCCH: multicast control channel) 등이 있다. 트래픽 채널로는 전용 트래픽 채널(DTCH: dedicated traffic channel), 멀티캐스트 트래픽 채널(MTCH: multicast traffic channel) 등이 있다. PCCH는 페이징 정보를 전달하는 하향링크 채널이고, 네트워크가 UE가 속한 셀을 모를 때 사용된다. CCCH는 네트워크와의 RRC 연결을 가지지 않는 UE에 의해 사용된다. MCCH 네트워크로부터 UE로의 MBMS(Multimedia Broadcast and Multicast Service) 제어 정보를 전달하기 위하여 사용되는 점-대-다점(point-to-multipoint) 하향링크 채널이다. DCCH는 UE와 네트워크 간에 전용 제어 정보를 전달하는 RRC 연결을 가지는 단말에 의해 사용되는 일-대-일(point-to-point) 양방향(bi-directional) 채널이다. DTCH는 상향링크 및 하향링크에서 존재할 수 있는 사용자 정보를 전달하기 위하여 하나의 단말에 전용되는 일-대-일(point-to-point) 채널이다. MTCH는 네트워크로부터 UE로의 트래픽 데이터를 전달하기 위하여 일-대-다(point-to-multipoint) 하향링크 채널이다.
논리 채널(logical channel)과 전송 채널(transport channel) 간 상향링크 연결의 경우, DCCH는 UL-SCH과 매핑될 수 있고, DTCH는 UL-SCH와 매핑될 수 있으며, CCCH는 UL-SCH와 매핑될 수 있다. 논리 채널(logical channel)과 전송 채널(transport channel) 간 하향링크 연결의 경우, BCCH는 BCH 또는 DL-SCH와 매핑될 수 있고, PCCH는 PCH와 매핑될 수 있으며, DCCH는 DL-SCH와 매핑될 수 있으며, DTCH는 DL-SCH와 매핑될 수 있으며, MCCH는 MCH와 매핑될 수 있으며, MTCH는 MCH와 매핑될 수 있다.
도 5는 본 발명이 적용될 수 있는 무선 통신 시스템에서 물리 채널의 구조를 간략히 예시하는 도면이다.
도 5를 참조하면, 물리 채널은 주파수 영역(frequency domain)에서 하나 이상의 서브캐리어와 시간 영역(time domain)에서 하나 이상의 심볼로 구성되는 무선 자원을 통해 시그널링 및 데이터를 전달한다.
1.0ms 길이를 가지는 하나의 서브프레임은 복수의 심볼로 구성된다. 서브프레임의 특정 심볼(들)(예를 들어, 서브프레임의 첫번째 심볼)은 PDCCH를 위해 사용될 수 있다. PDCCH는 동적으로 할당되는 자원에 대한 정보(예를 들어, 자원 블록(Resource Block), 변조 및 코딩 방식(MCS: Modulation and Coding Scheme) 등)를 나른다.
랜덤 액세스 절차(Random Access Procedure)
이하에서는 LTE/LTE-A 시스템에서 제공하는 랜덤 액세스 절차(random access procedure)에 대해 살펴본다.
랜덤 액세스 절차는 단말이 기지국과의 RRC 연결(RRC Connection)이 없어, RRC 아이들 상태에서 초기 접속 (initial access)을 수행하는 경우, RRC 연결 재-확립 절차(RRC connection re-establishment procedure)를 수행하는 경우 등에 수행된다.
LTE/LTE-A 시스템에서는 랜덤 액세스 프리앰블(random access preamble, RACH preamble)을 선택하는 과정에서, 특정한 집합 안에서 단말이 임의로 하나의 프리앰블을 선택하여 사용하는 경쟁 기반 랜덤 액세스 절차(contention based random access procedure)과 기지국이 특정 단말에게만 할당해준 랜덤 액세스 프리앰블을 사용하는 비 경쟁 기반 랜덤 액세스 절차(non-contention based random access procedure)을 모두 제공한다.
도 6은 본 발명이 적용될 수 있는 무선 통신 시스템에서 경쟁 기반 랜덤 액세스 절차를 설명하기 위한 도면이다.
(1) 제1 메시지(Msg 1, message 1)
먼저, 단말은 시스템 정보(system information) 또는 핸드오버 명령(handover command)을 통해 지시된 랜덤 액세스 프리앰블의 집합에서 임의로(randomly) 하나의 랜덤 액세스 프리앰블(random access preamble, RACH preamble)을 선택하고, 상기 랜덤 액세스 프리앰블을 전송할 수 있는 PRACH(physical RACH) 자원을 선택하여 전송한다.
단말로부터 랜덤 액세스 프리앰블을 수신한 기지국은 프리앰블을 디코딩하고, RA-RNTI를 획득한다. 랜덤 액세스 프리앰블이 전송된 PRACH와 관련된 RA-RNTI는 해당 단말이 전송한 랜덤 액세스 프리앰블의 시간-주파수 자원에 따라 결정된다.
(2) 제2 메시지(Msg 2, message 2)
기지국은 제1 메시지 상의 프리앰블을 통해서 획득한 RA-RNTI로 지시(address)되는 랜덤 액세스 응답(random access response)을 단말로 전송한다. 랜덤 액세스 응답에는 랜덤 액세스 프리앰블 구분자/식별자(RA preamble index/identifier), 상향링크 무선자원을 알려주는 상향링크 승인(UL grant), 임시 셀 식별자(TC-RNTI: Temporary Cell RNTI) 그리고 시간 동기 값(TAC: time alignment command)들이 포함될 수 있다. TAC는 기지국이 단말에게 상향링크 시간 정렬(time alignment)을 유지하기 위해 보내는 시간 동기 값을 지시하는 정보이다. 단말은 상기 시간 동기 값을 이용하여, 상향링크 전송 타이밍을 갱신한다. 단말이 시간 동기를 갱신하면, 시간 동기 타이머(time alignment timer)를 개시 또는 재시작한다. UL grant는 후술하는 스케줄링 메시지(제3 메시지)의 전송에 사용되는 상향링크 자원 할당 및 TPC(transmit power command)를 포함한다. TPC는 스케줄링된 PUSCH를 위한 전송 파워의 결정에 사용된다.
단말은 랜덤 액세스 프리앰블을 전송 후에, 기지국이 시스템 정보 또는 핸드오버 명령을 통해 지시된 랜덤 액세스 응답 윈도우(random access response window) 내에서 자신의 랜덤 액세스 응답(random access response)의 수신을 시도하며, PRACH에 대응되는 RA-RNTI로 마스킹된 PDCCH를 검출하고, 검출된 PDCCH에 의해 지시되는 PDSCH를 수신하게 된다. 랜덤 액세스 응답 정보는 MAC PDU(MAC packet data unit)의 형식으로 전송될 수 있으며, 상기 MAC PDU는 PDSCH을 통해 전달될 수 있다.
단말은 기지국에 전송하였던 랜덤 액세스 프리앰블과 동일한 랜덤 액세스 프리앰블 구분자/식별자를 가지는 랜덤 액세스 응답을 성공적으로 수신하면, 랜덤 액세스 응답의 모니터링을 중지한다. 반면, 랜덤 액세스 응답 윈도우가 종료될 때까지 랜덤 액세스 응답 메시지를 수신하지 못하거나, 기지국에 전송하였던 랜덤 액세스 프리앰블과 동일한 랜덤 액세스 프리앰블 구분자를 가지는 유효한 랜덤 액세스 응답을 수신하지 못한 경우 랜덤 액세스 응답의 수신은 실패하였다고 간주되고, 이후 단말은 프리앰블 재전송을 수행할 수 있다.
(3) 제3 메시지(Msg 3, message 3)
단말이 자신에게 유효한 랜덤 액세스 응답을 수신한 경우에는, 상기 랜덤 액세스 응답에 포함된 정보들을 각각 처리한다. 즉, 단말은 TAC을 적용시키고, TC-RNTI를 저장한다. 또한, UL grant를 이용하여, 단말의 버퍼에 저장된 데이터 또는 새롭게 생성된 데이터를 기지국으로 전송한다.
단말의 최초 접속의 경우, RRC 계층에서 생성되어 CCCH를 통해 전달된 RRC 연결 요청(RRC Connection Request)이 제3 메시지에 포함되어 전송될 수 있으며, RRC 연결 재확립 절차의 경우 RRC 계층에서 생성되어 CCCH를 통해 전달된 RRC 연결 재확립 요청(RRC Connection Re-establishment Request)이 제3 메시지에 포함되어 전송될 수 있다. 또한, NAS 접속 요청 메시지를 포함할 수도 있다.
제3 메시지는 단말의 식별자가 포함되어야 한다. 단말의 식별자를 포함시키는 방법으로는 두 가지 방법이 존재한다. 첫 번째 방법은 단말이 상기 랜덤 액세스 절차 이전에 이미 해당 셀에서 할당 받은 유효한 셀 식별자(C-RNTI)를 가지고 있었다면, 단말은 상기 UL grant에 대응하는 상향링크 전송 신호를 통해 자신의 셀 식별자를 전송한다. 반면에, 만약 랜덤 액세스 절차 이전에 유효한 셀 식별자를 할당 받지 못하였다면, 단말은 자신의 고유 식별자(예를 들면, S-TMSI 또는 임의 값(random number))를 포함하여 전송한다. 일반적으로 상기의 고유 식별자는 C-RNTI보다 길다.
단말은 상기 UL grant에 대응하는 데이터를 전송하였다면, 충돌 해결을 위한 타이머(contention resolution timer)를 개시한다.
(4) 제4 메시지(Msg 4, message 4)
기지국은 단말로부터 제3 메시지를 통해 해당 단말의 C-RNTI를 수신한 경우 수신한 C-RNTI를 이용하여 단말에게 제4 메시지를 전송한다. 반면, 단말로부터 제3 메시지를 통해 상기 고유 식별자(즉, S-TMSI 또는 임의 값(random number))를 수신한 경우, 랜덤 액세스 응답에서 해당 단말에게 할당한 TC-RNTI를 이용하여 제4 메시지를 단말에게 전송한다. 일례로, 제4 메시지는 RRC 연결 설정 메시지(RRC Connection Setup)가 포함할 수 있다.
단말은 랜덤 액세스 응답에 포함된 UL grant를 통해 자신의 식별자를 포함한 데이터를 전송한 이후, 충돌 해결을 위해 기지국의 지시를 기다린다. 즉, 특정 메시지를 수신하기 위해 PDCCH의 수신을 시도한다. 상기 PDCCH를 수신하는 방법에 있어서도 두 가지 방법이 존재한다. 앞에서 언급한 바와 같이 상기 UL grant에 대응하여 전송된 제3 메시지가 자신의 식별자가 C-RNTI인 경우, 자신의 C-RNTI를 이용하여 PDCCH의 수신을 시도하고, 상기 식별자가 고유 식별자(즉, S-TMSI 또는 임의 값(random number))인 경우에는, 랜덤 액세스 응답에 포함된 TC-RNTI를 이용하여 PDCCH의 수신을 시도한다. 그 후, 전자의 경우, 만약 상기 충돌 해결 타이머가 만료되기 전에 자신의 C-RNTI를 통해 PDCCH를 수신한 경우에, 단말은 정상적으로 랜덤 액세스 절차가 수행되었다고 판단하고, 랜덤 액세스 절차를 종료한다. 후자의 경우에는 상기 충돌 해결 타이머가 만료되기 전에 TC-RNTI를 통해 PDCCH를 수신하였다면, 상기 PDCCH가 지시하는 PDSCH이 전달하는 데이터를 확인한다. 만약 상기 데이터의 내용에 자신의 고유 식별자가 포함되어 있다면, 단말은 정상적으로 랜덤 액세스 절차가 수행되었다고 판단하고, 랜덤 액세스 절차를 종료한다. 제4 메시지를 통해 단말은 C-RNTI를 획득하고, 이후 단말과 네트워크는 C-RNTI를 이용하여 단말 특정 메시지(dedicated message)를 송수신하게 된다.
한편, 비경쟁 기반 임의접속 과정에서의 동작은 도 6에 도시된 경쟁 기반 임의접속 과정과 달리 제1 메시지 전송 및 제2 메시지 전송만으로 임의접속 절차가 종료되게 된다. 다만, 제1 메시지로서 단말이 기지국에 임의접속 프리앰블을 전송하기 전에 단말은 기지국으로부터 임의접속 프리앰블을 할당받게 되며, 이 할당받은 임의접속 프리앰블을 기지국에 제1 메시지로서 전송하고, 기지국으로부터 임의접속 응답을 수신함으로써 임의접속 절차가 종료되게 된다.
어태치 절차(Attach procedure)
단말은 등록이 필요한 서비스를 받기 위해 네트워크에 등록될 필요가 있다. 이러한 등록을 네트워크 접속이라고 지칭할 수 있다. 이하에서는 E-UTRAN에서의 초기 접속 절차에 대해 살펴본다.
도 7은 본 발명의 일 실시예에 따른 접속 절차를 예시한 순서도이다.
1-2. 우선, E-UTRAN 셀에 캠핑된 단말은 접속 요청 메시지를 기지국으로 전송함으로써 new MME와의 접속 절차를 개시할 수 있다.
접속 요청(Attach Request) 메시지는 단말의 IMSI(International Mobile Subscriber Identity), 단말이 요청하는 PDN 타입 등을 포함한다. 여기서, PDN 타입은 단말에 의해 요청되는 IP 버전(즉, IPv4, IPv4v6, IPv6)을 지시한다.
접속 요청(Attach Request) 메시지는 RRC 연결에서 RRC 연결 셋업 완료(RRC Connection Setup Complete) 메시지에 포함되어 전달되고, S1 시그널링 연결에서 초기 UE 메시지(Initial UE message)에 포함되어 전달된다.
단말은 PDN 연결(connectivity)을 요청하기 위하여 PDN 연결 요청(PDN Connectivity Request) 메시지와 함께 접속 요청(Attach Request) 메시지를 전송할 수도 있다.
3. 만일, 단말이 GUTI를 이용하여 스스로를 식별하고, MME가 해지(detach) 이후로 변경된 경우, new MME는 old node(예를 들어, MME 또는 SGSN)의 타입을 결정하고, old MME/SGSN 주소를 도출하기 위해 단말로부터 수신한 GUTI를 이용할 수 있다. 또한, new MME는 IMSI를 요청하기 위해 식별 요청(Identification Request)(old GUTI 및 complete Attach Request message 포함)을 old MME/SGSN으로 전송할 수 있다. old MME는 우선 NAS MAC에 의한 접속 요청 메시지를 확인하고, 식별 요청에 대한 응답으로써 식별 응답(Identification Response)(IMSI, MM 컨텍스트 포함)할 수 있다.
4. 만일 UE가 old MME/SGSN 및 new MME 모두에 알려지지 않은 경우, new MME는 IMSI를 요청하기 위해 식별 요청을 단말로 전송할 수 있다. 단말은 IMSI가 포함된 식별 응답으로써 해당 식별 요청에 응답할 수 있다.
5a. 만일 단말을 위한 단말 컨텍스트가 네트워크에 존재하지 않고, 접속 절차가 온전히 보호되지 않거나(integrity protected), 보호 온전함(integrity)의 확인에 실패한 경우, 온전한 보호 및 NAS 연산(NAS ciphering)을 활성화하기 위한 인증(Authentication) 및 NAS 시큐리티 셋업은 필수적으로 수행될 수 있다. 만일 NAS 시큐리티 알고리즘이 변경되면, NAS 시큐리티 셋업은 본 단계에서 수행될 수 있다.
5b. new MME는 IMEISV(ME Identity)는 단말로부터 회수/검색할 수 있다. 이때, IMEISV(ME Identity)는 단말이 비상 접속을 수행하거나 인증할 수 없는 경우를 제외하곤 암호화되어 전송될 수 있다.
6. 만일 단말이 접속 요청 메시지에서 암호화 옵션 전송 플래그(Ciphered Options Transfer Flag)를 설정한 경우, new MME는 Ciphered Options(예를 들어, PCO(Protocol Configuration Options) 및/또는 APN(name of PDN))을 단말로부터 회수/검색할 수 있다.
7. 특정 UE에 대한 new MME에서 활성화된 bearer context가 존재하는 경우, new MME는 LBI(Delete Session Request) 메시지를 GW로 전송함으로써 bearer context를 삭제한다. GW들은 Delete Session Response(Cause) 메시지로 응답한다.
8. 해지(Detach) 이후, MME가 변경되었거나, MME에 유효한 UE context 없거나, UE가 IMSI를 제공하거나, UE가 MME에서 유효하지 않은 old GUTI를 제공하거나, 또는 eNB에 의한 TAI의 PLMN-ID가 일부 네트워크에서 공유(예. GWCN)되는 시나리오에서 UE context의 GUTI가 상이한 경우에는, MME는 업데이트 위치 요청(Update Location request) 메시지를 HSS로 전송할 수 있다.
9. HSS는 olde MME에게 Cancel Location(IMSI, Cancellation Type 포함)을 전송한다. old MME는 Cancel Location Ack(IMSI 포함)을 통해 응답하고 MM(Mobility Management) context 및 bearer context를 제거한다.
10. 특정 단말에 대해 old MME/SGSN에서 활성화된 bearer context가 있다면, old MME/SGSN은 GW로 Delete Session Request(LBI)를 전송함으로써 해당 bearer context를 제거할 수 있다. GW는 Delete Session Response(Cause)를 old MME/SGSN로 전송할 수 있다.
11. HSS는 업데이트 위치 요청 메시지에 대한 응답으로써 new MME로 업데이트 위치 응답(Update Location Ack)(IMSI, Subscription data 포함) 메시지를 전송할 수 있다.
12. 긴급 Attach의 경우, MME는 이 단계에서 수행되는 긴급 bearer 확립을 위한 MME 긴급 구성 데이터로부터의 파라미터들을 적용하고, 잠재적으로 저장된 IMSI 연관된 가입 정보를 무시할 수 있다.
13. Serving GW는 EPS Bearer 표에 새 항목을 생성하고 이전 단계에서 수신된 PDN GW 주소에 의해 지시된 PDN GW(또는 P-GW)로 Create Session Request 메시지를 보낸다.
14. 동적 PCC가 수행되고 핸드오버 지시가 존재하지 않을 경우, PDN GW는 TS 23.203 [6]에 정의된 IP-CAN Session 확립 절차를 수행하며, 이로써, PDN GW는 단말에 대한 default PCC 규칙을 획득한다.
상술한 12 내지 16 단계는 ESM(EPS Session Management) 컨테이너가 접속 요청에 포함되어 있지 않은 경우, 생략될 수 있다.
15. P-GW는 EPS bearer context 테이블에 새 항목을 생성하고 default bearer에 대한 과금 ID를 생성한다. 새 항목은 P-GW로 하여금 S-GW 및 패킷 데이터 네트워크 사이의 사용자 평면 PDU 경로 및 과금 시작을 허용한다. 또한, P-GW는 Create Session 응답 메시지를 Serving GW로 전송한다.
16. Serving GW는 Create Session 응답 메시지를 new MME로 전송한다.
17. new MME는 initial context setup request 또는 접속 허용(Attach Accept)과 함께 downlink NAS transport를 기지국으로 전송할 수 있다.
18. 기지국은 EPS Radio Bearer Identity를 포함하는 RRC Connection Reconfiguration message를 포함하는 단말로 전송하며, 이때 Attach Accept message도 단말로 함께 전송된다.
19. 단말은 RRC Connection Reconfiguration Complete 메시지를 기지국으로 전송한다.
20. 기지국은 Initial Context Response 메시지를 new MME로 전송한다. Initial Context Response 메시지는 기지국의 TEID와 S1-U 참조 포인트의 DL traffic을 위해 사용되는 기지국의 주소를 포함한다.
21. 단말은 Attach Complete 메시지(EPS Bearer Identity, NAS sequence number, NAS-MAC 포함)를 포함하는 Direct Transfer 메시지를 기지국으로 보낸다.
22. 기지국은 Attach Complete 메시지를 new MME로 전달한다.
23. 단계 20의 Initial Context Response 메시지와 단계 22의 Attach Complete 메시지가 모두 수신된 경우, new MME는 Modify Bearer Request 메시지를 Serving GW로 전송한다.
23a. 핸드오버 지시가 단계 23에 포함되어 있는 경우, Serving GW는 Modify Bearer Request 메시지(핸드오버 지시 포함)를 PDN GW로 보낸다.
23b. PDN GW는 Serving GW로 Modify Bearer Response를 전송함으로써 Modify Bearer Request 메시지에 대해 응답할 수 있다.
24. Serving GW는 Modify Bearer Response 메시지(EPS Bearer Identity 포함)를 new MME로 전송할 수 있다. 다음으로, Serving GW는 Serving GW의 버퍼 DL packet들을 보낼 수 있다.
25. MME는 비 3GPP 접속을 위해 APN과 PDN GW identity를 포함한 Notify Request 를 HSS로 보낸다. 해당 메시지는 PDN GW가 위치하는 PLMN를 식별하는 정보를 포함한다.
26. HSS는 APN과 PDN GW identity pair를 저장하고 Notify Response를 MME로 전송한다.
PDN 연결 절차( PDN connectivity precedure )
단말 요청 PDN 연결 절차(UE requested PDN connectivity procedure)는 단말이 E-UTRAN을 통해 추가적인 PDN으로의 연결(디폴트 베어러의 할당 포함)을 요청하기 위하여 이용된다.
도 8은 본 발명이 적용될 수 있는 무선 통신 시스템에서 PDN 연결 절차를 간략히 예시하는 도면이다.
1. 단말은 PDN 연결 요청(PDN Connectivity Request) 메시지를 MME에게 전송함으로써 단말 요청 PDN 절차(UE Requested PDN procedure)를 개시한다.
PDN 연결 요청(PDN Connectivity Request) 메시지는 APN, 단말이 요청하는 PDN 타입(즉, IP 버전) 등을 포함한다. 상술한 바와 같이, PDN 타입은 단말에 의해 요청되는 IP 버전(즉, IPv4, IPv4v6, IPv6)을 지시한다.
MME는 단말에 의해 제공된 APN이 가입 정보에 의해 허용되는지 검증(verify)한다. 만약, 단말이 PDN 연결 요청(PDN Connectivity Request) 메시지에 APN을 제공하지 않은 경우, MME는 디폴트 PDN 가입 컨텍스트(default PDN subscription context)로부터 APN을 사용한다.
2. MME는 EPS 베어러 ID를 할당하고, S-GW에게 세션 생성 요청(Create Session Request) 메시지를 전송한다.
세션 생성 요청(Create Session Request) 메시지는 단말의 IMSI, EPS 베어러 ID, MME가 EPS 베어러 생성을 위해 선택한 P-GW ID(즉, P-GW 주소), APN, HSS로부터 수신한 가입 QoS 프로파일, PDN 타입, 단말의 IP 주소(즉, PDN 주소) 등을 포함한다.
여기서, PDN 타입은 단말로부터 수신된 PDN 타입 정보가 동일하게 포함된다. 유동 IP 주소 할당(dynamic IP address allocation)의 경우 단말의 IP 주소는 0 값으로 셋팅될 수 있으며, 고정 IP 주소 할당(static IP address allocation)의 경우 해당 단말에게 할당된 고정 IP 주소 정보(가입 정보에 포함)로 셋팅될 수 있다.
3. S-GW는 MME로부터 수신한 세션 생성 요청(Create Session Request) 메시지에 포함된 P-GW로 S5 베어러를 생성하기 위하여 S5 S-GW TEID(Tunnel Endpoint Identifier)를 할당하고, 해당 P-GW에게 세션 생성 요청(Create Session Request) 메시지를 전송한다.
세션 생성 요청(Create Session Request) 메시지는 단말의 IMSI, EPS 베어러 ID, S5 S-GW TEID, APN, 가입 QoS 프로파일, PDN 타입(즉, IP 버전), 단말의 IP 주소(즉, PDN 주소) 등을 포함한다.
4. P-GW는 단말이 사용할 IP(Internet Protocol) 주소를 할당하고, PCRF와 IP-CAN(IP connectivity access network) 세션 확립(establishment)/수정(modification) 절차를 수행한다.
이때, P-GW는 유동 IP 주소 할당(dynamic IP address allocation)의 경우 P-GW가 보유한 IP 주소 풀(pool)에서 선택된 IP 주소를 단말에 할당할 수 있으며, 고정 IP 주소 할당(static IP address allocation)의 경우 해당 단말에게 할당된 고정 IP 주소 정보(가입 정보에 포함)가 동일하게 할당될 수 있다.
5. P-GW는 S-GW로 S5 베어러를 생성하기 위하여 P-GW TEID(Tunnel Endpoint Identifier)를 할당하고, 세션 생성 요청(Create Session Request) 메시지에 대한 응답으로 S-GW에게 세션 생성 응답(Create Session Response) 메시지 전송한다.
세션 생성 응답(Create Session Response) 메시지는 단말의 IMSI, EPS 베어러 ID, S5 P-GW TEID, 가입 QoS 프로파일, PDN 타입, 단말에 할당된 IP 주소(즉, PDN 주소) 등을 포함한다.
만약, P-GW가 요청된 PDN 타입과 상이한 PDN 타입을 선택하였으면, P-GW는 PDN 타입과 함께 왜 PDN 타입이 수정되었는지 원인을 단말에게 지시한다.
이 절차를 마치면 S-GW와 P-GW 간에 S5 베어러의 생성이 완료되어, S-GW는 P-GW로 상향링크 트래픽을 전송하거나 P-GW로부터 하향링크 트래픽을 수신할 수 있다.
6. S-GW는 S1 베어러를 생성하기 위하여 S1 S-GW TEID를 할당하고, 세션 생성 요청(Create Session Request) 메시지에 대한 응답으로 세션 생성 응답(Create Session Response) 메시지를 MME에게 전송한다.
세션 생성 응답(Create Session Response) 메시지는 단말의 IMSI, EPS 베어러 ID, S1 S-GW TEID, PDN 타입, 단말에 할당된 IP 주소(즉, PDN 주소) 등을 포함한다.
7. MME는 PDN 연결 요청(PDN Connectivity Request) 메시지에 대한 응답으로 PDN 연결 승인(PDN Connectivity Accept) 메시지를 단말에게 전송한다.
PDN 연결 승인(PDN Connectivity Accept) 메시지는 EPS 베어러 ID, APN, P-GW에서 할당한 단말의 IP 주소(즉, PDN 주소), PDN 타입 등을 포함한다.
PDN 연결 승인(PDN Connectivity Accept) 메시지는 S1 시그널링 연결에서 베어러 셋업 요청(Bearer Setup Request) 메시지에 포함되어 기지국에 전달된다.
이 절차를 마치면, 기지국과 S-GW 간에 상향링크 S1 베어러의 생성이 완료되고, 기지국은 S-GW에게 상향링크 트래픽을 전송할 수 있다.
8. PDN 연결 승인(PDN Connectivity Accept) 메시지는 RRC 연결에서 RRC 연결 재설정(RRC Connection Reconfiguration) 메시지에 포함되어 기지국으로부터 단말에게 전달된다.
이 절차를 마치면, 단말과 기지국 간에 DRB의 생성이 완료되어, 단말은 기지국으로 상향링크 트래픽을 전송하거나 기지국으로부터 하향링크 트래픽을 수신할 수 있다.
9. 단말은 기지국에게 RRC 연결 재설정 완료(RRC Connection Reconfiguration Complete) 메시지를 전송한다.
10. 기지국은 베어러 셋업 응답(Bearer Setup Response) 메시지를 MME에게 전송한다.
베어러 셋업 응답(Bearer Setup Response) 메시지는 S1 eNB TEID 등을 포함한다.
11-12. 단말은 EPS 베어러 ID를 포함하는 PDN 연결 완료(PDN Connectivity Complete) 메시지를 MME에게 전송한다.
이 절차를 마치면, 단말과 P-GW 간 상향링크 디폴트 EPS 베어러의 생성이 완료되어 단말은 P-GW로 상향링크 데이터를 전송할 수 있다.
13. MME는 기지국으로부터 수신한 S1 eNB TEID를 수정 베어러 요청(Modify Bearer Request) 메시지를 통해 S-GW에게 전달한다.
이 절차를 마치면, 기지국과 S-GW 간에 하향링크 S1 베어러의 생성이 완료되고, 기지국은 S-GW로부터 하향링크 트래픽을 수신할 수 있다.
13a-13b. 필요에 따라 S-GW와 P-GW 간에 베어러가 갱신(update) 된다.
14. S-GW는 수정 베어러 요청(Modify Bearer Request) 메시지에 대한 응답으로 수정 베어러 응답(Modify Bearer Response) 메시지를 MME에게 전송한다.
이 절차를 마치면, 단말과 P-GW 간 하향링크 디폴트 EPS 베어러의 생성이 완료되어 P-GW는 단말로 하향링크 데이터를 전송할 수 있다. 즉, 단말은 PDN과 연결이 확립되고, 할당 받은 IP 주소를 이용하여 PDN 서비스를 제공 받을 수 있다.
15. MME는 필요에 따라 P-GW ID(즉, P-GW 주소), APN을 포함하는 통지 요청(Notify Request) 메시지를 HSS에게 전송한다.
16. HSS는 P-GW ID(즉, P-GW 주소) 및 연관된 APN을 저장하고, MME에게 통지 응답(Notify Response) 메시지를 전송한다.
MTC (Machine-Type Communication)
도 9는 본 발명이 적용될 수 있는 무선 통신 시스템에서 MTC(Machine-Type Communication) 아키텍처(architecture)를 예시하는 도면이다.
MTC를 위해서 사용되는 단말(또는, MTC 단말)과 MTC 어플리케이션 간의 단-대-단(end-to-end) 어플리케이션은 3GPP 시스템에서 제공되는 서비스들과 MTC 서버에게 제공되는 선택적인 서비스들을 이용할 수 있다. 3GPP 시스템은 MTC를 용이하게 하는 다양한 최적화를 포함하는 수송 및 통신 서비스들(3GPP 베어러 서비스, IMS 및 SMS 포함)을 제공할 수 있다.
도 9에서는 MTC를 위해 사용되는 단말이 Um/Uu/LTE-Uu 인터페이스를 통하여 3GPP 네트워크(UTRAN, E-UTRAN, GERAN, I-WLAN 등)으로 연결되는 것을 도시한다. 도 9의 아키텍처는 다양한 MTC 모델(Direct 모델, Indirect 모델, Hybrid 모델)들을 포함한다.
먼저, 도 9에서 도시하는 개체(entity)들에 대하여 설명한다.
도 9에서 어플리케이션 서버는 MTC 어플리케이션이 실행되는 네트워크 상의 서버이다. MTC 어플리케이션 서버에 대해서는 전술한 다양한 MTC 어플리케이션의 구현을 위한 기술이 적용될 수 있으며, 이에 대한 구체적인 설명은 생략한다. 또한, 도 9에서 MTC 어플리케이션 서버는 레퍼런스 포인트 API를 통하여 MTC 서버에 액세스할 수 있으며, 이에 대한 구체적인 설명은 생략한다. 또는, MTC 어플리케이션 서버는 MTC 서버와 함께 위치될(collocated) 수도 있다.
MTC 서버(예를 들어, 도 9의 SCS 서버)는 MTC 단말을 관리하는 네트워크 상의 서버이며, 3GPP 네트워크에 연결되어 MTC를 위하여 사용되는 단말 및 PLMN 노드들과 통신할 수 있다.
MTC-IWF(MTC-InterWorking Function)는 MTC 서버와 오퍼레이터 코어 네트워크 간의 상호 동작(interworking)을 관장하고, MTC 동작의 프록시 역할을 할 수 있다. MTC 간접 또는 하이브리드 모델을 지원하기 위해서, MTC-IWF는 레퍼런스 포인트 Tsp 상의 시그널링 프로토콜을 중계하거나 해석하여 PLMN에 특정 기능을 작동시킬 수 있다. MTC-IWF는, MTC 서버가 3GPP 네트워크와의 통신을 수립하기 전에 MTC 서버를 인증(authenticate)하는 기능, MTC 서버로부터의 제어 플레인 요청을 인증하는 기능, 후술하는 트리거 지시와 관련된 다양한 기능 등을 수행할 수 있다.
SMS-SC(Short Message Service-Service Center)/IP-SM-GW(Internet Protocol Short Message GateWay)는 단문서비스(SMS)의 송수신을 관리할 수 있다. SMS-SC는 SME(Short Message Entity)(단문을 송신 또는 수신하는 개체)와 단말 간의 단문을 중계하고, 저장 및 전달하는 기능을 담당할 수 있다. IP-SM-GW는 IP 기반의 단말과 SMS-SC 간의 프로토콜 상호 동작을 담당할 수 있다.
CDF(Charging Data Function)/CGF(Charging Gateway Function)는 과금에 관련된 동작을 할 수 있다.
HLR/HSS는 가입자 정보(IMSI 등), 라우팅 정보, 설정 정보 등을 저장하고 MTC-IWF에게 제공하는 기능을 할 수 있다.
MSC/SGSN/MME는 단말의 네트워크 연결을 위한 이동성 관리, 인증, 자원 할당 등의 제어 기능을 수행할 수 있다. 후술하는 트리거링과 관련하여 MTC-IWF로부터 트리거 지시를 수신하여 MTC 단말에게 제공하는 메시지의 형태로 가공하는 기능을 수행할 수 있다.
GGSN(Gateway GPRS Support Node)/S-GW(Serving-Gateway)+P-GW(Packet Date Network-Gateway)는 코어 네트워크와 외부 네트워크의 연결을 담당하는 게이트웨이 기능을 할 수 있다.
표 2는 도 9에서의 주요 레퍼런스 포인트를 정리한 것이다.
Figure PCTKR2017000294-appb-T000002
표 2에서 T5a, T5b, T5c 중 하나 이상의 레퍼런스 포인트를 T5라고 지칭한다.
한편, 간접 및 하이브리드 모델의 경우에 MTC 서버와의 사용자 플레인 통신, 및 직접 및 하이브리드 모델의 경우에 MTC 어플리케이션 서버와의 통신은, 레퍼런스 포인트 Gi 및 SGi를 통해서 기존의 프로토콜을 사용하여 수행될 수 있다.
도 9에서 설명한 내용과 관련된 구체적인 사항은 3GPP TS 23.682 문서를 참조함으로써 본 문서에 병합될 수 있다(incorporated by reference).
도 10은 본 발명이 적용될 수 있는 무선 통신 시스템에서 서비스 능력 노출(Service Capability Exposure)을 위한 아키텍쳐를 예시한다.
도 10에서 예시하고 있는 서비스 능력 노출(Service Capability Exposure)을 위한 아키텍쳐는 3GPP 네트워크가 3GPP 네트워크 인터페이스에 의해 제공되는 자신의 서비스 및 능력을 외부의 서드 파티 서비스 제공자(3rd party Service Provider) 어플리케이션에게 안전하게 노출하는 것을 가능하게 한다.
서비스 능력 노출 기능(SCEF: Service Capability Exposure Function)는 3GPP 네트워크 인터페이스에 의해 제공되는 서비스 및 능력을 안전하게 노출하기 위한 수단을 제공하는 서비스 능력 노출(service capability exposure)을 위한 3GPP 아키텍쳐 내 핵심적인 엔티티(entity)이다. 다시 말해, SCEF는 이동통신 사업자가 운용하는 트러스트 도메인(Trust Domain)에 속하는 서비스 기능 제공을 위한 핵심 엔티티이다. SCEF는 서드 파티 서비스 제공자에게 API 인터페이스를 제공하고, 3GPP의 각종 엔티티와 연결을 통해 서드 파티 서비스 제공자에게 3GPP의 서비스 기능들을 제공한다. SCEF 기능은 SCS에 의해 제공될 수도 있다.
Tsp 기능이 어플리케이션 프로그램 인터페이스(API: application program interface)를 통해 노출될 수 있는 경우, MTC-IWF는 SCEF와 동일하게 위치(co-located)할 수 있다. 다중의 인자에 의존하여 새로운 3GPP 인터페이스를 특정하기 위한 프로토콜(예를 들어, DIAMETER, RESTful APIs, XML over HTTP, 등)이 선택되며, 여기서 다중의 인자는 요청된 정보의 노출의 용이함 또는 특정 인터페이스의 필요를 포함하나 이에 한정되는 것은 아니다.
SCEF는 트러스트 도메인(Trust Domain)에 속하는 엔티티로서, 셀룰러 운영자(Cellular operator)에 의해 운용될 수도 있고, 트러스트(trusted) 관계를 맺은 서드 파티(3rd party) 사업자에 의해 운용될 수 있다. 3GPP 릴리즈(Release) 13의 MONTE(Monitoring Enhancement), AESE(Architecture Enhancements for Service Capability Exposure) 등의 워크 아이템 아래 진행 된 서비스 아키텍쳐 노출(Service architecture exposing)을 위한 노드로서, 앞서 도 10과 같이 서비스를 제공할 3GPP 엔티티들과 연결되어 여러 모니터링 및 과금과 관련된 기능들을 외부 서드 파티에 제공하고, 서드 파티 사업자의 통신 패턴 등을 EPS 내부로 설정해 주는 등의 중간에서 관리하는 역할을 한다.
협대역 IOT(Internet of Things)를 위한 효율적인 스몰 데이터 전송
셀룰러 IoT(CIoT: Cellular Internet of Things)는 IoT 서비스에 적합한 새로운 무선 접속을 정의한 것으로 현재 3GPP 릴리즈(Release)-13에서 두 가지 방식의 CIoT가 논의 중이다. 하나는 GERAN을 CIoT 형태로 발전한 솔루션이면, 하나는 클린 스테이트(Clean Slate)라고 지칭되는 협대역(NB: Narrow Band) 무선 접속 기술(RAT: Radio Access Technology)(예를 들어, NB-IOT)에 적합한 새로운 무선 접속 네트워크 형태이다.
3GPP에서는 협대역 IOT 지원을 위한 효율적인 스몰 데이터(small data) 송신을 위한 새로운 코어 네트워크에 대한 아키텍쳐가 논의되고 있다.
도 11은 본 발명이 적용될 수 있는 무선 통신 시스템에서 단대단(End to End) 스몰 데이터 플로우를 예시하는 도면이다.
도 11의 예시와 같이, AS와 C-SGN(CIoT Serving Gateway Node) 간에 점대점 터널(point-to-point tunnel) 방식으로 non-IP 데이터의 송수신이 수행될 수 있다. C-SGN은 CIoT 단말을 지원하기 위해 Rel-13에 추가된 노드이다.
또는, Non-IP 패킷의 송수신을 위해 SCEF 프레임워크를 사용할 수 있다. 다시 말해, AS/SCS와 C-SGN 간에 SCEF를 경유하여 Non-IP 데이터의 송수신이 수행될 수도 있다.
그리고, C-SGN과 UE 간에는 S1-MME 레퍼런스 포인트를 통해 Non-IP 데이터의 송수신이 수행될 수 있다. 즉, NAS 계층에서 암호화된 스몰 데이터(예를 들어, Non-IP 데이터)가 UE와 C-SGN 간에 송수신될 수 있다.
C-SGN는 새로운 논리적 엔티티이며, 다음과 같이 CIoT 활용 케이스를 위해 요구되는 필수적인 기능만을 지원하기 위해 구현될 수 있다.
- 이동성 관리(MM: Mobility Management) 절차 내 필요한 일부 절차;
- 효율적인 스몰 데이터 절차;
- 효율적인 스몰 데이터를 위해 요구되는 보안 절차;
- SMS(Short Message Service) 지원이 필요하면, 결합되지 않은(non-combined) GPRS 어태치 절차를 이용한 PS 도메인 상의 SMS;
- 커버리지 향상을 위한 페이징 최적화;
- 로밍되지 않은(non-roaming) 케이스를 위한 SGi 인터페이스의 종단(termination);
- 로밍 케이스를 위한 S8 인터페이스 지원;
- SMS 만을 위한 어태치(즉 IP(또는 non-IP) 데이터를 위한 PDN 연결 없이 SMS 송수신만을 위한 어태치) 절차 지원;
- non-IP 데이터를 위한 SGi 상에서 터널링(tunneling) 지원.
또한, SCEF를 이용한 스몰 데이터(예를 들어, Non-IP 데이터) 전송을 위한 다음과 같은 솔루션이 논의되고 있다.
솔루션) HSS로의 로드가 최소화되는 SCEF를 경유한 Non-IP 스몰 데이터 전송
도 12는 본 발명이 적용될 수 있는 무선 통신 시스템에서 SCEF를 경유한 효율적인 non-IP 스몰 데이터 전송을 위해 제안되는 셀룰러 IoT 네트워크 아키텍쳐를 예시한다.
T6a은 SCEF와 서빙 MME 간에 사용되는 레퍼런스 포인트이고, T6b는 SCEF와 서빙 SGSN 간에 사용되는 레퍼런스 포인트이다. T6a/T6b는 다음과 같은 요구사항을 만족한다.
- T6a는 SCEF를 서빙 MME에 연결시킨다;
- T6b는 SCEF를 서빙 SGSN에 연결시킨다;
- SCEF에 의한 서빙 MME/SGSN에서의 모니터링 이벤트 설정, 서빙 MME/SGSN에 의한 SCEF로의 모니터링 이벤트 보고와 같은 기능을 지원한다.
- 서빙 MME/SGSN으로/으로부터 Non-IP 데이터 전달(NIDD: Non-IP Data Delivery)
S6t는 SCEF와 HSS 간에 사용되는 레퍼런스 포인트이고, 다음과 같은 요구사항을 만족한다.
- SCEF를 가입(subscription)과 UE 관련 정보를 포함하는 HSS에 연결시킨다.
- SCEF에 의한 HSS에서의 모니터링 이벤트 설정/삭제
- HSS에 의한 SCEF로의 모니터링 이벤트 보고
- SCEF에 의한 HSS로의 통신 패턴 파라미터의 설정/삭제
먼저, 모니터링 이벤트의 설정 절차를 살펴본다.
스몰 데이터 전송(SDT: Small Data Transmission)의 모니터링 이벤트는 다음과 같이 설정될 수 있다.
발신(MO: Mobile Originated) 및 착신(MT: Mobile Terminated) 스몰 데이터 전송 이전에, 모니터링 이벤트 설정 절차(Monitoring Event Configuration procedure)를 통해 MME/C-SGN과 SCEF는 MO 및 MT 스몰 데이터 전송을 위해 각각 필요한 정보(SCEF ID 및 MME/C-SGN 라우팅 정보)를 획득한다.
도 13은 본 발명이 적용될 수 있는 무선 통신 시스템에서 HSS를 통한 모니터링 이벤트 설정 및 삭제 절차를 예시한다.
1. SCS/AS는 모니터링 요청(Monitoring Request) 메시지(외부 식별자(들)(External Identifier(s)) 또는 MSISDN(Mobile Station Integrated System Digital Network)(들), SCS/AS 식별자(SCS/AS Identifier), SCS/AS 참조 ID(SCS/AS Reference ID), 모니터링 타입(Monitoring Type), 보고의 최대 개수(Maximum Number of Reports), 모니터링 기간(Monitoring Duration), 모니터링 목적지 주소(Monitoring Destination Address), 삭제를 위한 SCS/AS 참조 ID(SCS/AS Reference ID for Deletion))를 SCEF에게 전송한다.
이때, SCS/AS는 Monitoring Type을 "SDT"로 셋팅할 수 있다.
2. SCEF는 SCS/AS Reference ID, SCS/AS Identifier, Monitoring Destination Address, Monitoring Duration, 및 Maximum Number of Reports를 저장한다. SCEF는 SCEF 참조 ID(SCEF Reference ID)를 할당한다. 운영자 정책에 기반하여, SCS/AS가 이 요청을 수행하는데 권한을 부여받지 않았거나, 또는 Monitoring Request이 잘 못되거나(malformed) 또는 SCS/AS가 모니터링 요청의 제출의 한도(quita) 또는 비율(rate)을 초과하였다면, SCEF는 9 단계를 수행하고, 에러를 지시하는 적절한 원인 값(Cause value)를 제공한다. SCEF가 SCS/AS Reference ID for Deletion를 수신하였다면, SCEF는 관련된 삭제를 위한 SCEF 참조 ID(SCEF Reference ID for Deletion)를 도출한다.
3. SCEF는 HSS와 MME/SGSN에 주어진 모니터링 이벤트를 설정하기 위하여 Monitoring Request 메시지(External Identifier 또는 MSISDN, SCEF ID, SCEF Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, SCEF Reference ID for Deletion, 유료의 파티 식별자(Chargeable Party Identifier))를 HSS에게 전송한다.
4. HSS는 Monitoring Request 메시지를 검사한다. 예를 들어, External Identifier 또는 MSISDN의 존재와 관련하여, 메시지 내 포함된 파라미터들이 운영자에게 수락될 수 있는 범위인지 여부, 모니터링 이벤트(들)이 서빙 MME/SGSN에 의해 지원되는지 여부, 또는 삭제될 모니터링 이벤트가 유효한지 여부를 검사한다. HSS는 선택적으로 Chargeable Party Identifier에 의해 식별된 유료의 파티(chargeable party)에게 권한을 부여한다. 만약, 위의 체크가 실패하면, HSS는 단계 8을 따르고, SCEF에게 실패 상태의 이유를 지시하는 원인 값을 제공한다.
HSS는 SCEF에 의해 제공된 SCEF Reference ID, SCEF ID, Maximum Number of Reports, Monitoring Duration, SCEF Reference ID for Deletion을 저장한다.
5. 특정한 Monitoring Type에 의해 요구되고, 모니터링 이벤트(들)이 서빙 MME/SGSN에 의해 지원될 때, HSS는 가입 데이터 삽입 요청(Insert Subscriber Data Request) 메시지(Monitoring Type, SCEF ID, SCEF Reference ID, Maximum Number of Reports, Monitoring Duration, SCEF Reference ID for Deletion, Chargeable Party Identifier)를 MME/SGSN에게 전송한다.
6. MME/SGSN은 요청을 확인(verify)한다. 예를 들어, 요청이 또 다른 PLMN으로부터 전송될 때 Monitoring Type이 로밍 합의(roaming agreement)에 의해 커버된다면, 또는 SCEF Reference ID for Deletion를 서비스하고, 삭제할 수 있는지 여부를 확인한다. 이 체크가 실패하면, MME/SGSN은 7 단계에 따르며, SCEF에게 실패 상태를 위한 이유를 지시하는 원인 값을 제공한다. 운영자 정책에 기반하여, MME/SGSN은 또한 다른 이유(예를 들어, 오버로드(overload) 또는 HSS가 모니터링 요청의 제출 한도(quota) 또는 레이트(rate)가 초과하였는지)로 요청을 거절할 수 있다.
MME/SGSN은 수신한 파라미터를 저장하고, 일회의(One-time) 요청이며 고객 데이터 삽입 응답(Insert Subscriber Data Answer)을 전송하는 시점에서 MME/SGSN에서 모니터링 이벤트가 가용하지 않다면 지시된 모니터링 이벤트를 관찰하기 시작한다. MME/SGSN는 the SCEF Reference ID for Deletion에 의해 식별된 모니터링 설정을 삭제한다.
7. 모니터링 설정이 성공적이면, MME/SGSN이 Insert Subscriber Data Answer (원인) 메시지를 HSS에게 전송한다. 요청된 모니터링 이벤트가 Insert Subscriber Data Answer를 전송하는 시점에서 MME/SGSN에서 가용하다면, MME/SGSN은 모니터링 이벤트 보고(Monitoring Event Report)를 Insert Subscriber Data Answer 메시지에 포함시킨다.
8. HSS는 Monitoring Request의 승인 그리고 식별된 모니터링 이벤트 설정의 삭제를 확인(acknowledge)하기 위해, 모니터링 응답(Monitoring Response) 메시지(SCEF Reference ID, 원인(Cause))를 SCEF에게 전송한다. HSS는 SCEF Reference ID에 의해 식별되는 모니터링 이벤트 설정을 삭제한다. 요청된 모니터링 이벤트가 Monitoring Response 메시지를 전송하는 시점에서 HSS에게 가용하거나 요청된 모니터링 이벤트가 7 단계에서 MME/SGSN으로부터 수신되었다면, HSS는 Monitoring Response 메시지에 모니터링 이벤트 보고(Monitoring Event Report)를 포함시킨다.
일회의(One-time) 요청이고, Insert Subscriber Data Answer이 Monitoring Event Report를 포함하면, HSS는 관련된 모니터링 이벤트 설정을 삭제한다.
UE 이동성의 경우, HSS는 새로운 MME/SGSN이 요청된 모니터링 이벤트(들)을 지원하는지 여부를 결정한다.
이때, 만약 앞서 3 단계에서 수신한 Monitoring Type이 "SDT"로 셋팅되었다면, HSS는 MME/C-SGN의 라우팅 정보를 Monitoring Response 메시지에 포함시킬 수 있다.
9. SCEF는 Monitoring Request의 승인 그리고, 식별된 모니터링 이벤트 설정의 삭제를 확인(acknowledge)하기 위하여 모니터링 응답(Monitoring Response) 메시지(SCS/AS Reference ID, Cause)를 SCS/AS에게 전송한다. SCEF는 모니터링 이벤트 보고(Monitoring Event Report)를 수신하였다면, Monitoring Event Report를 Monitoring Response 메시지에 포함시킨다. 일회의 요청이고, Monitoring Response이 Monitoring Event Report를 포함하면, SCEF는 관련된 모니터링 이벤트 설정을 삭제한다.
도 13에서 예시된 모니터링 이벤트 설정 절차와 관련된 공통된 파라미터는 다음과 같다.
SCS/AS Reference ID는 SCS/AS에 의해 생성되는 파라미터이며, SCEF를 향하여 SCS/AS에 의해 개시된 특정한 처리(transaction)를 나타낸다. SCS/AS Reference ID는 SCEF 내 저장된다.
SCEF Reference ID는 모니터링 이벤트 보고 또는 모니터링 이벤트의 삭제를 특정한 모니터링 요청과 SCEF 내 연관된 컨텍스트 정보에 연관시키기 위하여 SCEF에 의해 생성된다. SCEF Reference ID는 HSS, MME 또는 SGSN 내 저장된다.
SCEF ID는 HSS, MME 또는 SGSN에 의해 모니터링 지시(Monitoring Indication) 메시지가 전송되어야 하는 SCEF를 지시한다. SCEF ID는 HSS, MME 또는 SGSN 내 저장된다.
Monitoring Type은 요청되는 특정 모니터링 이벤트를 식별한다.
Maximum Number of Reports는 선택적인 파라미터이며, 연관된 모니터링 이벤트가 만료되었다고 간주될 때까지 HSS, MME 또는 SGSN에 의해 생성되는 이벤트 보고의 최대 횟수를 지시한다.
Monitoring Duration는 선택적인 파라미터이며, 연관된 모니터링 이벤트 요청이 만료되었다고 간주될 때의 절대 시간을 지시한다.
Maximum Number of Reports (1 보다 큰 값을 가지는) 또는 Monitoring Duration를 포함하는 것은 모니터링 요청이 계속적인 모니터링 요청(Continuous Monitoring Request)임을 나타낸다 Continuous Monitoring Request에 있어서, 단일의 모니터링 요청은 복수의 Monitoring Indication 메시지를 생성할 수 있다.
Maximum Number of Reports 및 Monitoring Duration 모두 존재하지 않는 것은 모니터링 요청이 일회의 모니터링 요청(One-time Monitoring Request)임을 나타낸다. One-time Monitoring Request에 있어서, 단일의 모니터링 요청은 하나의 모니터링 보고를 생성한다.
주어진 모니터링 이벤트에 대하여 Maximum Number of Reports 및 Monitoring Duration이 모두 포함되면, 모니터링 요청은 하나의 조건이 만족될 때 만료된다고 간주된다.
Monitoring Destination Address는 요청하는 SCS/AS의 주소와 상이한 주소로 Monitoring Indication(들)이 전달되도록 지시하기 위하여 SCS/AS에 의해 포함되는 선택적인 파라미터이다. 이 파라미터가 존재하지 않는다는 것은 Monitoring Indication(들)이 모니터링 요청이 발생된 SCS/AS에게 전달되는 것을 나타낸다.
SCS/AS Reference ID for Deletion는 요청된 모니터링 이벤트 설정을 적용하기 이전에 삭제되어야 하는 모니터링 이벤트 설정을 식별한다.
SCEF Reference ID for Deletion는 요청된 모니터링 이벤트 설정을 적용하기 이전에 삭제되어야 하는 모니터링 이벤트 설정을 식별한다.
Chargeable Party Identifier는 SCEF에 의해 포함되는 선택적인 파라미터이다. 이 파라미터는 관여된 3GPP 네트워크 요소에 의해 회계/과금 기능이 수행되는 엔티티를 식별한다.
이하, MO 스몰 데이터(즉, IP, non-IP, SMS) 전송 절차를 살펴본다.
도 14는 본 발명이 적용될 수 있는 무선 통신 시스템에서 MO 스몰 데이터 전송 절차를 예시한다.
1a. 모니터링 이벤트가 설정된 노드(즉, MME/C-SGN)에 의해 모니터링 이벤트가 감지(detect)된다.
즉, MME/C-SGN은 MO 스몰 데이터를 수신함으로써 모니터링 이벤트를 감지할 수 있다.
보다 구체적으로 살펴보면, UE는 UE의 AS에게 RRC 연결을 확립하도록 요청할 수 있다. 암호화된 정보 요소(IE: Information Element) 내에서 스몰 데이터 패킷을 나르는 새로운 NAS 메시지 포맷이 이용될 수 있다. 이때, 이 새로운 NAS PDU의 암호화되지 않은(unencrypted) 부분은 "eKSI and Sequence Number" IE를 나를 수 있다. MME/C-SGN는 스몰 데이터 패킷을 해독(decrypt)하기 위한 보안 컨텍스트(security context)를 식별하기 위하여 "eKSI and Sequence Number" IE와 S-TMSI(SAE-Temporary Mobile Subscriber Identity)를 이용할 수 있다. RAN은 NAS PDU를 MME/C-SGN에게 전달할 수 있다. MME/C-SGN는 NAS 메시지를 해독(decrypt)하고, 스몰 데이터 패킷을 획득할 수 있다.
2a. 노드(즉, MME/C-SGN)는 모니터링 지시(Monitoring Indication) 메시지(SCEF Reference ID 및 모니터링 이벤트 보고(Monitoring Event Report))를 SCEF에게 전송한다. 모니터링 이벤트 설정이 One-time Monitoring Request에 의해 트리거되었다면, 모니터링 이벤트 설정은 이 단계가 완료될 때 MME/SGSN에 의해 삭제된다. MME/SGSN이 이 모니터링 태스트(task)를 위해 저장된 Maximum Number of Reports를 가지고 있다면, MME/SGSN은 그 값을 1 감소시킨다.
이때, Monitoring Event Report는 MO 스몰 데이터를 포함할 수 있다. SCEF는 MME/C-SGN에게 확인(acknowledgement)메시지로 응답할 수 있다.
3. SCEF Reference ID를 사용하여, SCEF는 Monitoring Indication 메시지의 전송을 위한 목적지로서 Monitoring Destination Address 또는 SCS/AS의 주소와 함께 관련된 SCS/AS Reference ID를 획득(retrieve)한다. SCEF는 Monitoring Indication 메시지(SCS/AS Reference ID, External ID 또는 MSISDN, 모니터링 정보(Monitoring Information))를 식별된 목적지로 전송한다.
Continuous Monitoring Request에 대하여 보고의 최대 횟수가 도달될 때, SCEF는 HSS (HSS를 통해 설정된 모니터링 이벤트의 경우) 또는 MME(들)/SGSN(들) (MME/SGSN에서 직접 설정된 모니터링 이벤트의 경우) 에게 관련된 모니터링 이벤트 설정과 또한 연관된 앞서 도 13의 절차에서 3-8 단계에 따른 모니터링 이벤트 설정을 삭제하도록 요청한다.
HSS를 통해 설정된 One time Monitoring Request에 대한 보고가 MME/SGSN으로부터 수신된 경우 (2a 단계), SCEF는 HSS에게 관련된 모니터링 이벤트 설정과 또한 연관된 앞서 도 13의 절차에서 3-8 단계에 따른 모니터링 이벤트 설정을 삭제하도록 요청한다.
이때, SCEF는 MO 스몰 데이터를 모니터링 보고 절차를 통해 모니터링 목적지 노드에게 전송할 수 있다.
이하, MT 스몰 데이터(즉, IP, non-IP, SMS) 전송 절차를 살펴본다.
도 15는 본 발명이 적용될 수 있는 무선 통신 시스템에서 MT 스몰 데이터 전송 절차를 예시한다.
1. SCS/AS는 스몰 데이터 전송 요청(SDT Request) 메시지(SDT를 위한 SCS/AS Reference ID, MT 스몰 데이터)를 SCEF에게 전송한다.
2. SCEF가 SDT를 위한 SCS/AS Reference ID에 상응하는 MME/C-SGN을 위한 유효한 라우팅 정보를 가지고 있지 않으면, SCEF는 HSS에게 문의(query)한다.
3. SCEF는 SDT Request 메시지(SDT를 위한 SCEF Reference ID, MT 스몰 데이터)를 MME/C-SGN에게 전송한다.
그리고, MME/C-SGN는 MT 스몰 데이터를 UE에게 전송할 수 있다.
보다 구체적으로 살펴보면, MME/C-SGN는 스몰 데이터 패킷을 SCEF로부터 수신할 수 있다. 만약, UE와 시그널링 연결이 존재하지 않으면, MME/C-SGN는 수신한 스몰 데이터 패킷을 버퍼하고, UE에게 페이징을 전송할 수 있다. UE는 페이징에 대한 응답으로 MME/C-SGN에게 서비스 요청(Service Request) 메시지를 전송할 수 있다. 다음으로, C-SGN은 하향링크 NAS 메시지 내 NAS PDU 내 암호화된 IE 내 스몰 데이터 패킷을 전송할 수 있으며, RAN은 NAS PDU는 UE에게 전송할 수 있다.
4. MME/C-SGN는 SDT 응답(SDT Response) 메시지(SDT를 위한 SCEF Reference ID, Cause)를 SCEF에게 전송한다.
만약, SDT를 위한 SCEF Reference ID와 관련된 유효한 컨텍스트가 MME/C-SGN 내 존재하지 않으면, MME/C-SGN는 원인(Cause)를 적절한 값으로 셋팅함으로써 SCEF에게 MT 스몰 데이터 전송 실패를 알린다. 이 경우, SCEF는 앞서 2 단계부터 다시 수행할 수 있다.
5. SCEF는 SDT Response 메시지(SDT를 위한 SCS/AS Reference ID, Cause)를 SCS/AS에게 전송한다.
넌-IP 데이터 전달( NIDD : Non-IP Data Delivery)
NIDD를 위한 기능은 단말들과 단말 발신(MO: mobile originated) 및 단말 착신(MT: mobile terminated) 통신을 처리하기 위하여 사용될 수 있으며, 여기서 통신을 위해 사용되는 패킷은 EPS 관점(standpoint)으로부터 구조화되지 않은 것으로 간주될 수 있다. 즉, 이는 비-IP(Non-IP) 패킷을 지칭할 수 있으며, 본 명세서에서 스몰 데이터와 동등한 개념으로 이해될 수 있다. 비-IP 데이터의 지원은 CIoT EPS 최적화의 일부이다.
SCS/AS는 비-IP 데이터의 전달에 필요한 정보의 구성, 즉 NIDD 절차를 위한 SCS/AS 트리거 구성을 요구할 수 있다. 이 경우, 아래와 같은 사항들이 허용될 수 있다.
- SCEF 레퍼런스 ID와 연관된 상향 링크 경로 정보(SCEF ID) 및 하향 링크 경로 정보(IMSI)를 획득하기 위한 MME; 및
- SCEF 및 SCS/AS 참조 ID와 연관된 상향 링크 경로 정보(SCS / AS 식별자) 및 하향 링크 경로 정보(서빙 MME 주소 또는 IWK-SCEF ID)를 획득하기 위한 SCEF(여기서, IWK-SCEF는 로밍(roaming) 시 사용되는 노드에 해당함).
MO/MT 비-IP 데이터는 참조 ID와 연관된 상향 링크/하향 링크 경로를 통해 전달될 수 있다. 주어진 UE에 대해, NIDD(MO 및 MT)는 3GPP 네트워크와 단일 SCEF 사이에서만 허용될 수 있다. UE와 MME 사이의 데이터는 CIoT에 대해 최적화된 제어 평면을 통해 전달된다.
이하, MME/SGSN와 SCEF를 통해 UL/DL 데이터(즉, non-IP 데이터) 전송을 위한 링크 셋업 과정을 살펴본다.
도 16은 본 발명이 적용될 수 있는 무선 통신 시스템에서 MME와 SCEF를 통해 UL/DL 데이터(즉, non-IP 데이터) 전송을 위한 링크 셋업 과정을 예시한다.
non-IP 데이터의 송수신은 IP 프로토콜을 사용하지 않기 때문에, P2P 방식으로 데이터가 송수신될 수 있으며, 이를 네트워크에 적용하기 위하여 MME 및 SCEF를 경유하여 UE와 PDN(즉, APN) 간에 미리 링크(즉, Non-IP 데이터 송수신을 위한 PDN connection)가 셋업될 수 있다.
1) 먼저, NIDD 설정(NIDD Configuration) 절차가 수행된다.
SCS/AS와 SCEF사이의 연결 셋업(connection setup)을 NIDD 설정이라고 지칭할 수 있다. 이는 T6a 연결 셋업(connection setup)보다 미리 되어 있다라고 간주될 수 있다. 즉, 서드 파티(3'rd party) 사업자가 운영자와 IoT 사업을 계약하고 이에 IoT 단말들이 배포(deploy)하여 네트워크에 등록되기 전에, NIDD 설정 절차가 미리 수행될 수 있다.
SCS/AS에서 연결 셋업(connection setup)을 원하는 단말의 MSISDN 혹은 External Identity를 이용해서 해당 단말을 위한 SCEF에게 셋업을 요청한다. 이에, SCEF는 HSS에 단말과 SCS/AS의 승인 처리(authorization handling) 및 단말의 식별자 레졸루션(ID resolution)을 요청한다. 즉, IMSI는 외부 망(즉, SCS/AS)으로 노출될 수 없는 UE 식별자로서, 상술한 바와 같이 외부망에서는 보통 MSISDN(즉, 단말 번호) 혹은 External Identifier를 이용하여 단말을 식별할 수 있다. 이러한 ID와 IMSI의 매핑 정보는 HSS에 저장되어 있다. NIDD Configuration procedure가 성공적으로 완료되면, NIDD configuration이 완료되고 SCEF에 해당 단말에 대한 컨텍스트가 생성된다.
이때, NIDD 설정 절차들은 API 인터페이스로 수행된다.
NIDD 설정 절차에 대한 보다 상세한 설명은 아래 도 17을 참조한다.
2a) 단말은 MME에게 PDN 연결 요청(PDN Connection request) 메시지를 전송한다.
단말은 미리 설정되어 있는 PDN 연결 셋업(PDN connection setup)을 요청하면서(즉, PDN Connection request 메시지 전송), Non-ip 타입 지시(Type indication)와 함께 APN 정보를 함께 MME에게 전송한다. 이에 MME는 해당 APN에 대응되는 가입 정보를 HSS를 통해 확인하고 SCEF를 이용한 PDN 연결 셋업(PDN connection setup) 여부를 판단한다.
2b) T6a 연결 확립(T6a Connection Establishment) 절차가 수행된다.
아래 표 3과 같이 SCEF 선택 호출(Invoke SCEF selection)이 활성화 되어 있다면, MME는 SCEF로의 T6a 연결 셋업을 개시한다. 이때 사용되는 목적지 SCEF 역시 HSS에 저장되어 있는 단말의 가입 정보를 이용할 수 있다.
상술한 바와 같이, 단말은 Attach 혹은 서비스를 원하는 경우 PDN 연결을 MME에게 요청한다. MME는 요청되는 PDN 연결이 Non-IP type(즉, PDN 타입이 'Non-IP')이고 수신한 APN (APN은 포함되지 않은 경우 디폴트 APN이 가능함)에 대응하는 단말의 가입 정보를 보고, T6a 연결 확립 여부를 판단하게 된다.
T6a 연결 확립 절차에 대한 보다 상세한 설명은 아래 도 18을 참조한다.
표 3은 SCEF 연결을 위한 HSS 저장 정보를 예시한다.
Figure PCTKR2017000294-appb-T000003
도 17은 본 발명이 적용될 수 있는 무선 통신 시스템에서 NIDD 구성 절차를 예시한다.
도 17의 순서도는 SCEF, HSS, MME 및 선택적으로는 NIDD를 위한 IWK-SCEF에서 필요한 정보를 구성하는 절차를 나타낸다. 이 절차는 구성 정보를 바꾸거나 삭제할 때도 사용될 수 있다.
1. SCS/AS는 NIDD 구성 요청(NIDD Configuration Request) 메시지(외부 식별자, MSISDN(Mobile Subscriber International Subscriber Directory Number), SCS/AS 식별자, SCS/AS 참조 ID, NIDD 최대 수, NIDD 기간(NIDD Duration), NIDD 목적지 주소(NIDD Destination Address) 및/또는 삭제를 위한 SCS/AS 참조 ID)를 SCEF에게 전송한다.
다중 SCS/AS NIDD 구성 요청 처리를 위한 상대적 우선 순위 스킴, 즉, 과부하 조건에서 어떤 요청을 처리할 것인지를 결정하기 위해 적용될 수 있다. 이 우선 순위 체계는 SCEF에 의해 국부적으로 사용되며, 다른 기능에 대한 절차에서는 사용되거나 번역되지 않는다.
SCS/AS 내의 MT 비-IP 데이터는 NIDD 구성 요청 메시지를 트리거할 수 있다. SCEF는 NIDD 구성이 설정/확립된 후에 MT non-IP 데이터를 전송할 수 있다.
2. SCEF는 SCS/AS 참조 ID, SCS/AS 식별자, NIDD 대상 주소, NIDD 지속 시간 및/또는 NIDD 최대 수를 저장한다. SCEF는 SCEF 참조 ID를 할당한다. 운영자 정책에 따라 SCS/AS가 이 요청을 수행할 권한이 없는 경우(예를 들어, SLA가 허용하지 않는 경우) 또는 NIDD 구성 요청이 잘못되었거나(malformed), SCS/AS가 NIDD 구성 요청의 제출량 또는 비율을 초과한 경우, SCEF는 12 단계를 수행하고 에러를 적절하게 나타내는 원인 값을 제공한다. SCEF가 삭제를 위한 SCS/AS 참조 ID를 수신한 경우, SCEF는 삭제를 위한 관련 SCEF 참조 ID를 도출한다.
3. SCEF는 필요한 경우, HSS 및 MME에 대한 NIDD를 위한 필요한 정보를 구성하기 위해, HSS에 NIDD 구성 요청(외부 식별자 또는 SCID 참조 ID, SCID 참조 ID, NIDD 최대 수, NIDD 지속 시간, 삭제를 위한 SCEF 참조 ID, 및/또는 유료 파티 식별자) 메시지를 전송한다.
4. HSS는 NIDD 구성 요청 메시지를 검사한다(예를 들어, 외부 식별자 또는 MSISDN의 존재와 관련하여, 포함된 매개 변수가 운영자가 수용할 수 있는 범위에 있는지 또는 삭제될 NIDD 구성이 유효한 지 여부). HSS는 선택적으로 과금 대상 식별자에 의해 지시되는 과금 대상 당사자가 지정한 유상 당사자를 인증한다. 이 검사가 실패하면 HSS는 11 단계를 수행하고 SCEF에 대한 실패 조건의 원인을 나타내는 원인 값을 제공한다. HSS는 SCEF 참조 ID, SCEF ID, 최대 NIDD 수, NIDD 지속 시간 및/또는 SCEF에 의해 제공된 삭제를 위한 SCEF 참조 ID를 저장한다.
5. HSS는 MME에 삽입 가입자 데이터 요청(Insert Subscriber Data Request)(SCEF ID, SCEF 참조 ID, NIDD의 최대 개수, NIDD 지속 시간, 삭제를 위한 SCEF 참조 ID, 및/또는 유료 파티 식별자) 메시지를 전송한다(예를 들어, 어태치/접속 절차 중).
6. MME가 SCEF의 PLMN에 IWK-SCEF를 사용하도록 구성된 경우, MME는 Inform IWK-SCEF(SCEF ID, SCEF 참조 ID, 최대 NIDD 수, NIDD 지속 시간, 삭제를 위한 SCEF 참조 ID 및/또는 유료 파티 식별자) 메시지를 IWK-SCEF에 전송한다.
서빙 MME가 변경된 경우, new/target MME는 IWK-SCEF에게 UE 이동성을 알릴 것으로 예상된다. 보다 상세한 내용은 3 단계에서 수행되며, 그렇지 않으면, MME는 9 단계를 수행한다.
7. IWK-SCEF는 요청을 승인할 수 있다. NIDD가 로밍 협약(agreement)의 적용을 받으며 가능한 경우 삭제를 위해 SCEF 참조 ID를 기록한다. 이 인증이 실패하면 IWK-SCEF는 9 단계를 수행하고 MME에 대한 실패 조건의 원인을 나타내는 원인 값을 제공한다. 운영자 정책에 따라 IWK-SCEF는 다른 이유로 인해 요청을 거부할 수도 있다(예를 들어, 과부하 또는 SLA가 정의한 할당량 초과).
상기 요청에 NIDD 구성 삭제가 표시되면 IWK-SCEF는 필요한 최종 작업(예를 들어, 최종 청구 정보 생성, 저장된 매개 변수 삭제)을 수행하고 9 단계에서 MME에 확인 응답을 보낸다.
상기 요청이 지속적인 보고(신규 또는 수정)를 나타내면 IWK-SCEF는 요청을 승인하고, 승인이 성공하면 수신된 매개 변수를 저장하고, 9 단계에서 MME에 승인을 보내고 수신을 비 IP 데이터의 감시를 시작한다.
8. 인증에 성공하면 IWK-SCEF는 IWK-SCEF (원인) 메시지에 MME/SGSN으로 승인을 보냅니다.
9. MME는 요청을 검증할 수 있는데, 예를 들어, NIDD가 다른 PLMN으로부터의 요청이거나 로밍 협약(agreement)을 통해 SCEF 참조 ID를 제공하는지 여부를 결정할 수 있다. 이 검사가 실패하면 MME는 10 단계를 수행하고 SCEF에 실패 조건의 원인을 나타내는 원인 값을 제공한다. 운영자 정책에 따라 MME는 다른 이유로 인해 요청을 거부할 수도 있다(예를 들어, 과부하 또는 HSS가 SLA에 의해 정의된 NIDD 구성 요청 제출의 할당량 또는 비율을 초과한 경우).
MME는 5 단계에서 수신된 파라미터들 및 (가능하다면) IWK-SCEF ID를 MM 컨텍스트에 저장하고, 이것이 1회 요청이고 MME가 삽입 가입자 데이터 응답(Insert Subscriber Data Answer)의 전송 시간 전까지 이미 비-IP 데이터를 수신하지 않으면, UE로부터 지시된 NIDD를 감시하기 시작한다. MME는 삭제를 위해 SCEF Reference ID에 의해 식별된 NIDD 구성을 삭제한다.
MME는 MME가 변경되는 동안 모든 NIDD 이벤트에 대해 저장된 컨텍스트 정보의 일부로 매개 변수를 전송한다. UE가 네트워크로부터 분리되면, HSS는 최대 수의 NIDD 파라미터에서 나머지 수의 리포트를 수신한다.
10. NIDD 구성이 성공하면, MME는 가입자 데이터 응답 (원인) 메시지를 HSS에 전송한다. MME가 PLMN에 IWK-SCEF를 사용하도록 구성된 경우, MME는 삽입 가입자 데이터 응답 메시지에 IWK-SCEF ID를 포함시킨다.
11. HSS는 요청받은 경우, NIDD 구성 요청의 승인과 식별된 NIDD 구성의 삭제를 확인하기 위해 SCEF에 NIDD 구성 응답(SCEF 참조 ID, 검색 MME 주소 제공, IWK-SCEF ID, 원인) 메시지를 SCEF에 전송한다. HSS는 (요청받은 경우) SCEF 참조 ID 로 식별된 NIDD 구성을 삭제한다. HSS는 UE로의 MT NIDD에 대한 비-IP 데이터를 MME에 송신하는 SCEF를 위한 서빙 MME 어드레스 정보를 포함한다. HSS가 10 단계에서 IWK-SCEF ID를 수신한 경우, NIDD 구성 응답 메시지에 서빙 MME 주소 대신 IWK-SCEF ID를 포함한다.
12. SCEF는 NIDD 구성 응답(SCS/AS 참조 ID, 원인) 메시지를 SCS/AS에 전송하여, 요청된 경우 NIDD 구성 요청의 승인과 식별된 NIDD 구성의 삭제를 확인한다.
도 18은 본 발명이 적용될 수 있는 무선 통신 시스템에서 MO NIDD 절차를 예시한다.
SCS/AS는 SCEF를 통해 비-IP 데이터를 UE로부터 수신할 수 있다. SCEF를 통한 비-IP 데이터의 수신을 위해 SCS/AS는 NIDD 구성을 요청해야 한다. 본 절차에서 사용되는 SCS/AS 및 SCEF의 참조 ID는 앞서 상술한 NIDD 구성 절차를 통해 획득된다.
1. MO 비-IP 데이터는 NIDD 구성이 설정된 MME에 의해 UE로부터 수신된다. MME는 SCEF를 통해 비-IP 데이터를 전송할 것을 결정한다.
2a. MME가 IWK-SCEF를 사용하도록 구성되지 않은 경우, MME는 MO NIDD 지시(SCEF 참조 ID, 비 IP 데이터) 메시지를 SCEF로 전송한다.
2b. MME가 IWK-SCEF를 사용하도록 구성된 경우, MME는 MO NIDD 지시 메시지를 IWK-SCEF로 보내고, IWK-SCEF는 MO NIDD 지시(SCEF 참조 ID, 비 IP 데이터) 메시지를 SCEF로 전송한다.
3. SCEF 참조 ID를 사용하여, SCEF는 NIDD 목적지 주소와 연관된 SCS/AS 참조 ID를 검색하거나 사용할 수 없다면, MO NIDD 지시 메시지에 대한 목적지로서 SCS/AS의 주소를 검색한다. SCEF는 식별된 목적지에 MO NIDD 지시(SCS/AS 참조 ID, 외부 ID 또는 MSISDN, 비-IP 데이터) 메시지를 전송한다.
4. SCS / AS는 MO NIDD 지시를 SCEF에 확인(acknowledge)한다.
5. SCEF는 MO NIDD 지시를 (IWK-SCEF가 사용되는 경우 IWK-SCEF를 통해) MME에 확인(acknowledge)한다.
도 19는 본 발명이 적용될 수 있는 무선 통신 시스템에서 MT NIDD 절차를 예시한다.
SCS/AS는 비-IP 데이터를 SCEF를 통해 UE로 전송할 수 있다. SCEF를 통해 비-IP 데이터를 전송하기 위해서는 SCS/AS가 NIDD 구성을 요청해야 한다. 본 절차에 사용되는 SCS/AS 및 SCEF의 참조 ID는 앞서 상술한 NIDD 구성 절차를 통해 획득된다.
1. SCS/AS는 UE에 대한 MT 비-IP 데이터를 전송한다.
2. 발신 노드는 MT NIDD 요청(SCS/AS 참조 ID, 비-IP 데이터) 메시지를 SCEF로 전송한다.
3. SCEF는 SCS/AS 참조 ID를 사용하여 서빙 MME 주소(단계 3a) 또는 IWK-SCEF ID(단계 3b)와 함께 연관된 SCEF 참조 ID를 검색한다.
서빙 MME 주소가 이용 가능한 경우, SCEF는 서빙 MME에 MT NIDD 요청(SCEF 참조 ID, 비-IP 데이터) 메시지를 전송한다(단계 3a). IWK-SCEF ID가 사용 가능하면 SCEF는 MT NIDD 요청(SCEF 참조 ID, 비-IP 데이터) 메시지를 IWK-SCEF로 전송한다(3b 단계). IWK-SCEF는 서빙 MME에 MT NIDD 요청(SCEF 참조 ID, 비-IP 데이터) 메시지를 전송한다.
4. MME는 비-IP 데이터를 UE에 전달한다.
5a. MME는 SCEF에 대한 MT NIDD 요청에 대해 응답한다. MME가 MT 비-IP 데이터를 전달할 수 없는 경우, MT NIDD 요청은 SCEF에 대해 적절한 원인 값으로 거절되어야한다. SCEF는 관련 HSS에 저장된 서빙 MME 주소를 검색하기 위해 가입자 정보 요청(외부 식별자 또는 MSISDN) 메시지를 HSS로 전송하고, HSS는 가입자 정보 응답(외부 식별자 또는 MSISDN, 서빙 MME 주소, 원인) 메시지를 전송한다. SCEF는 새로운 서빙 MME 주소로 3 단계를 수행한다.
5b. MME는 IWK-SCEF에 대한 MT NIDD 요청에 응답하고, IWK-SCEF는 SCEF에 대한 MT NIDD 요청에 응답한다.
6. SCEF는 SCS/AS에 대한 MT NIDD 요청에 응답한다.
NIDD를 위한 SCEF 연결 절차
SCEF를 통한 비-ip 데이터 전달은 기존 SCEF framework를 이용한 것으로 단말에는 transparent한 동작(즉, 단말은 알 수 없는 동작)이다. 또한, 기존의 모니터링 및 service exposure capability는 단말에 영향 없는 네트워크, 서버 그리고 SCEF 노드 간의 동작이다. 예를 들어, SCS/AS가 필요한 경우 모니터링을 설정하여 MME/HSS가 모니터링된 이벤트를 보고하는 방식의 경우, SCEF 설정 동작이 단말에게 주는 영향이 없게 된다.
또한, SCEF는 그룹 메시지 송신의 경우에도 사용될 수 있는데, 예를 들어, SCS/AS가 그룹 메시지를 보내고자 하는 그룹 ID와 컨텐츠를 SCEF에 설정해 주면, BM-SC(Broadcast Multicast-Service Centre)를 통해 MBMS 컨텐츠로 그룹 단말들에게 메시지가 송신된다.
이러한 SCEF를 이용한 스몰 데이터 송수신은 단말의 발신호(mobile originated call)를 포함하는 것으로, 현재 표준에 따르면 앞서 도 17과 관련하여 상술한 절차에 따른 NIDD 구성이 설정/확립되어 있지 않은 경우에는, 단말이 발신호 데이터를 송신하더라도 MME/C-GSN의 core 네트워크 노드에서는 이를 처리할 수가 없다. 하지만, 단말 입장에서 SCEF의 NIDD 구성은 transparent한 동작으로 단말은 NIDD 전송 가능 여부(즉, SCS/AS단의 NIDD 구성 수행/확립 여부)를 알지 못하므로, 단말은 NIDD 구성이 설정/확립되어 있지 않음에도 상향 링크 데이터/비-IP 데이터/스몰 데이터(예를 들어, 발신호)를 전송하는 상황이 발생하게 된다. 그 결과, 이를 수신한 MME가 NIDD 구성이 설정되기 전까지 단말로부터 수신한 데이터를 버퍼링하지 못한다면, 해당 데이터는 MME 단에서 폐기(discard)된다는 비효율성/문제점이 발생하게 된다.
이에 본 명세서에서는, 단말이 접속(Attach) 시 SCEF를 통한 데이터 송수신을 수행하는 경우, 네트워크 노드에서 SCS/AS가 트리거링하는 NIDD 구성의 확립/수행되기를 기다리는 것이 아니라, 직접 SCS/AS로 NIDD 구성을 적극적으로 요청할 수 있도록 하는 절차에 관해 제안하기로 한다.
도 20은 본 발명의 제1 실시예에 따른 SCEF 연결을 위한 접속 절차를 예시한 순서도이다. 본 순서도와 관련하여 앞서 상술한 도 7 및 17의 설명이 동일/유사하게 적용될 수 있으며, 중복되는 설명은 생략한다.
1. 단말은 접속 요청 시, 비-IP 타입의 데이터를 송신한다는 지시 정보와 CIoT UP(user plane) 능력(capability) 정보 또는 CIoT CP(control plane) 능력 정보 등을 접속 요청 메시지에 포함하여 네트워크로 전송한다. 여기서, CIoT UP 능력 정보는 단말의 UP 모드 적용 여부를 지시하며, CIoT CP 능력 정보는 단말의 CP 모드 적용 여부를 지시한다. CP 모드는 SRB를 통해 NAS PDU 안에 패킷 데이터가 encapsulation되어 송수신되는 모드(즉, 제어 평면을 통한 데이터 송수신 모드)를 지칭하며, UP 모드는 DRB 셋업을 통해 DRB로 패킷 데이터가 송수신되는 모드(즉, 사용자 평면을 통한 데이터 송수신 모드)를 지칭한다.
2 내지 11. 다음으로, 도 7과 관련하여 상술한 레가시 접속 절차가 수행될 수 있다. 즉, 본 2 내지 11 단계에서 도 7의 2 내지 11 단계가 수행될 수 있다.
12. MME는 구성(configuration) 정보 및 MM 컨텍스트 정보에 의해 비-ip 데이터 송신을 위한 SCEF delivery(즉, SCEF를 통한 데이터 송신) 및 SGi delivery(SGi를 통한 데이터 송신) 중 어느 하나를 선택할 수 있다. 예를 들어, MME는 접속 요청한 단말이 CP CIoT 최적화를 지원하지 않는 경우에는 SGi delivery를 선택하거나, CP CIoT 최적화를 지원하는 경우에는 SCEF delivery를 선택할 수 있다. 이외에 MME는 네트워크 구성 및 네트워크 정책 등에 따라 SCEF delivery 또는 SGi delivery를 선택할 수 있다.
MME가 SCEF delivery를 선택한 경우에는 미리 확립/설정되어 있는 SCEF 연결(또는 NIDD 구성)이 존재하는지 여부를 확인할 수 있다. 이때, MME는 HSS로부터 수신한 단말의 가입 정보(또는 SCEF 연결을 위한 HSS 저장 정보)를 기초로 SCEF 연결(또는 NIDD 구성)이 존재하는지 여부를 확인할 수 있다. 보다 상세하게는, HSS는 특정 SCEF 및 SCS/AS 사이의 SCEF 연결(또는 NIDD 구성)이 확립/설정되는 경우, 이에 대한 확립/설정 정보를 단말에 대한 가입 정보로서 업데이트한 뒤, MME로 업데이트한 가입 정보를 전송해줄 수 있다. 그 결과, MME는 단말의 접속 요청에 따라 SCEF delivery를 선택한 경우, 해당 단말에 대한 가입 정보를 확인하여 해당 단말에 대한 SCEF 연결(또는 NIDD 구성)이 현재 확립/설정되어 있는지 여부를 판단할 수 있다. 이때, SCEF 연결(또는 NIDD 구성)에 대해 업데이트되는 가입 정보로는 앞서 상술한 표 3의 정보 외에, SCS/AS 주소(SCEF와 연결을 맺을 SCS/AS의 주소), 단말의 외부 식별자(단말의 ID로 SCEF에서 SCS/AS로 SCEF 연결(또는 NIDD 구성)을 트리거링하는 경우에 포함됨) 및/또는 현재 SCEF 연결(또는 NIDD 구성)의 확립/설정 여부에 관한 정보가 추가될 수 있다.
13. MME가 SCEF delivery를 선택했고 접속 요청한 단말에 대한 SCEF 연결(또는 NIDD 구성)이 존재하지 않는 것으로 확인된 경우, MME는 HSS로 단말의 비-ip 데이터 송신을 위한 SCEF 연결(또는, NIDD 구성)을 확립/설정해 줄 것을 HSS로 요청할 수 있다. 보다 상세하게는, MME는 SCEF 연결(또는 NIDD 구성)이 존재하지 않는 것으로 판단한 경우, (HSS를 통해) SCEF로 T6a 연결 셋업을 요청할 수 있다. 이러한 SCEF 연결(또는 T6a)의 설정 요청은 NOR(Notify Request) 메시지 또는 새롭게 정의된 메시지를 통해 전송될 수 있다.
14. HSS는 단말에 대한 SCEF 연결 가능 여부 등을 판단 후, 단말의 SCS/AS를 지원하는 destination SCEF로 SCEF 연결 셋업 요청(SCEF connection setup request)을 송신한다. 여기서, destination SCEF는 가입자(subscription) 정보에 저장되어 있거나 단말의 SCS/AS id를 서비스하는 SCEF일 수 있다. HSS가 SCEF 연결 셋업을 요청할 destination SCEF는 HSS에 의해 목적(destination) SCS/AS id를 이용하여, 또는 가입자 정보(subscription information)에 미리 저장되어 있는 SCEF id를 이용하여 도출될 수 있다. HSS는 단말의 가입자 정보에 저장되어 있는 SCS/AS id(단말을 서비스하는 SCS/AS의 id) 및 단말의 IMSI에 해당하는 외부 id가 포함된 SCEF 연결 셋업 요청을 SCEF로 전송할 수 있다.
15. SCEF는 HSS로부터 수신한 SCS/AS id와 대응되는 destination SCS/AS와의 SCEF 연결(또는 NIDD 구성)이 현재 확립/설정되어 있는지를 판단할 수 있다. 만일, 현재 destination SCS/AS와의 SCEF 연결(또는 NIDD 구성)이 확립/설정되어 있다고 판단한 경우, SCEF는 이하에서 후술하는 15 내지 18 단계를 수행하지 않고, 절차를 종료할 수 있다. 이 경우, SCEF는 MME에게 현재 SCEF 연결(또는, NIDD 구성)이 이미 확립/설정되어 있음을 알릴 수 있다. 반대로, destination SCS/AS와의 SCEF 연결(또는 NIDD 구성)이 현재 확립/설정되어 있지 않다고 판단한 경우, SCEF는 HSS로부터 수신한 외부 id가 포함된 SCEF 연결 요청 메시지를 destination SCS/AS로 송신하고, 16 단계로 진입할 수 있다.
16. SCS/AS는 앞서 도 17에서 상술한 NIDD 구성 절차를 수행하여, 이후 단말의 발신호 전송 시 MME가 사용할 수 있도록 SCEF ID, SCEF 참조 ID 등의 파라미터를 저장할 수 있다.
17. MME는 NIDD 구성 절차를 통해 SCEF 연결(또는 NIDD 구성)이 생성된 것을 인지하면 접속 승인 메시지를 eNB로 보낸다. 이때 전송되는 접속 승인 메시지에는 SCEF 연결(또는 NIDD 구성)의 유효(available) 또는 비-ip 데이터 전송의 유효 등을 나타내는 지시가 포함되어 있을 수 있다.
18. eNB는 단말에 RRC 직접 전달(direct transfer) 메시지를 송신한다. RRC 직접 전달 메시지에는 SCEF 연결(또는 NIDD 구성)의 유효 또는 비-ip 데이터 전송의 유효 등을 나타내는 지시가 포함되어 있는 접속 승인 메시지가 포함되어 있을 수 있다. 이로써 단말은 비-ip 데이터 송신이 가능함을 인지하고 상위 계층에서 전송할 데이터가 발생하는 경우, 네트워크로 새롭게 확립/설정된 SCEF 연결(또는 NIDD 구성)을 통해 비-ip 데이터를 전송할 수 있게 된다.
다만, 접속 승인 메시지에 SCEF 연결(또는 NIDD 구성)의 유효 또는 비-ip 데이터 전송의 유효 등을 나타내는 지시가 포함되어 있지 않는 경우에 단말은 다음 착신호가 수신될때가지 대기했다가, 착신호가 수신되면 그때서야 발신호를 전송할 수 있다. 그 이유는, 착신호가 수신됨은 현재 유효한 SCEF 연결(또는 NIDD 구성)이 존재함을 의미하기 때문이다.
한편, 15 단계와 관련하여 추가적으로 기술하면, 유효한 SCEF 연결(또는 NIDD 구성)이 존재하지 않는 경우, SCEF가 어떤 SCS/AS와 SCEF 연결(또는 NIDD 구성)을 확립/설정할지는 다양한 실시예에 따라 결정될 수 있다.
일 실시예로서, 단말과 대응되는 SCS/AS id(또는 주소) 및 이와 대응되는 외부 id 정보가 가입자 정보로서 HSS에 저장되어 있는 경우, 단말은 접속 시 자신의 SCEF 연결 관련 정보를 HSS로 문의(query)할 수 있다. 이 경우, 단말 또는 MME가 SCEF 연결 관련 정보를 HSS로 문의(query)하게 되면, HSS는 SCEF로의 SCEF 연결 셋업 요청 시 추가 정보로서 저장되어 있는 SCS/AS id 및 외부 id를 SCEF에 전송할 수 있다. 이때 만일, 현재 유효한 SCEF 연결(또는 NIDD 구성)이 존재하지 않다면, SCEF는 MME로부터 수신한 SCS/AS id와 대응되는 SCS/AS를 향해 수신한 외부 id를 이용하여 SCEF 연결(또는 NIDD 구성)을 요청할 수 있다.
만약, 이와 달리, MME가 접속 시 별도로 SCEF 연결 관련 정보를 HSS에 문의(query)하지 않는 경우에는, 별도로 이를 HSS에 요청하거나, SCEF에 해당 정보가 미리 저장/설정되어 있을 수 있다.
즉, 도 20에 도시한 순서도를 요약하면, 접속 절차에서 MME는 단말로부터 전송된 접속 요청 메시지에 포함된 데이터 송신 타입이 비-IP 타입인 경우, SCEF 연결 필요 여부 및/또는 SCEF 연결(즉, NIDD 구성)의 확립/설정 여부를 판단할 수 있다. 만일, SCEF 연결이 확립/설정될 필요가 있다고 판단하거나 및/또는 SCEF 연결이 확립/설정되어 있지 않은 경우, MME는 HSS로 SCEF 연결의 필요성을 알릴 수 있다. 이에 HSS는 해당 단말의 SCS/AS ID를 확인하고, 단말의 IMSI 값에 부합하는 외부 식별자를 도출해서 타겟 SCEF로 SCEF 연결을 셋업할 것을 요청할 수 있다. 이때, HSS는 SCS/AS ID와 외부 ID를 함께 SCEF에 알려줄 수 있다. 다음으로, SCEF는 이를 기초로 현재 유효한 SCEF 연결(또는 NIDD 구성)이 확립/설정되어 있는지를 판단하고 판단 결과에 따라 새로운 SCEF 연결(또는 NIDD 구성)을 설정/확립하거나 미리 설정/확립되어있는 SCEF 연결(또는 NIDD 구성)이 존재함을 알릴 수 있다.
도 21은 본 발명의 제2 실시예에 따른 SCEF 연결을 위한 접속 절차를 예시한 순서도이다. 본 순서도와 관련하여 앞서 상술한 도 7, 도 17 및 도 20의 설명이 동일/유사하게 적용될 수 있으며, 중복되는 설명은 생략한다.
1. 단말은 접속 요청 시, 비-IP 타입의 데이터를 송신한다는 지시 정보와 CIoT UP(user plane) 능력(capability) 정보 또는 CIoT CP(control plane) 능력 정보 등을 접속 요청 메시지에 포함하여 네트워크로 전송한다.
2 내지 7. 다음으로, 도 7과 관련하여 상술한 레가시 접속 절차가 수행될 수 있다. 즉, 본 2 내지 7 단계에서 도 7의 2 내지 7 단계가 수행될 수 있다.
8. MME는 네트워크 상의 단말의 유효한 MM 컨텍스트가 존재하지 않거나 새로운 PLMN에 접속하는 경우, HSS에 업데이트 위치 요청(Update Location Request; ULR)(단말의 서빙 노드 등록) 메시지를 송신한다. 이 경우, MME는 ULR 메시지에 비-ip 데이터 경로를 위한 셋업이 필요하다는 지시를 포함시켜 전송할 수 있다.
8a. HSS는 ULR 메시지를 수신하여 비-ip 데이터 셋업(또는 SCEF 연결/NIDD 구성)이 필요하다고 판단하는 경우, 단말에 대해 저장된 SCS/AS id를 확인/이용하여 서빙 가능한 SCEF 노드를 유추하고, 해당 단말에 대해 SCS/AS의 서비스가 가능한지를 확인할 수 있다. 이때, HSS는 유효한 SCEF 연결(또는 NIDD 구성)의 존재 여부, 남은 NIDD 송신 횟수 여부 등에 기초하여 비-ip 데이터 셋업(또는 SCEF 연결/NIDD 구성)의 필요 여부를 판단할 수 있다.
만일, HSS가 해당 단말에 대한 SCS/AS 서비스가 현재 불가능하다고 판단한 경우(즉, 현재 유효한 SCEF 연결(또는 NIDD 구성)이 존재하지 않아 SCEF 연결 셋업이 필요하다고 판단한 경우) 8b 단계를 통해 SCEF 연결 (셋업) 요청을 SCEF로 전송한다. 이때, HSS가 SCEF 연결 (셋업) 요청을 전송하는 SCEF는 앞서 유추했던 단말에 대해 서빙 가능한 SCEF 노드에 해당한다.
8b. HSS가 destination SCEF로 SCEF 연결 (셋업) 요청을 송신한다. 이때 전송되는 SCEF 연결 (셋업) 요청에는 단말의 외부 id와 SCS/AS id가 포함되어 있을 수 있다.
8c. SCEF는 수신한 SCS/AS id와 대응되는 destination SCS/AS로 단말의 외부 id가 포함된 SCEF 연결 (셋업) 요청을 송신한다.
A. SCS/AS는 8c 단계의 SCEF 연결 (셋업) 요청을 수신하면, 도 17에서 상술한 NIDD 구성 절차를 수행할 수 있다.
9 내지 10. 다음으로, 도 7과 관련하여 상술한 레가시 접속 절차의 9 및 10 단계가 수행될 수 있다.
11. SCEF 연결(또는 NIDD 구성)이 성공적으로 수행/완료된 경우, HSS는 SCEF 연결 정보(또는 NIDD 구성 정보)를 기존의 데이터 삽입 요청(Insert subscription Data Request) 메시지 대신 업데이트 위치 응답 메시지를 통해 MME로 전송할 수 있다. 여기서, SCEF 연결 정보는 수행/완료된 SCEF 연결(또는 NIDD 구성)에 관한 정보로서, 예를 들어, SCEF 연결(또는 NIDD 구성)/비-ip 데이터 전송의 유효(available) 등을 나타내는 지시, SCEF ID, SCEF 참조 ID, NIDD 최대 수, NIDD 지속 시간, 삭제를 위한 SCEF 참조 ID 및/또는 유료의 파티 식별자(Chargeable Party Identifier)를 포함할 수 있다. 이 경우, 본 순서도에 적용될 수 있는 NIDD 구성 절차에서 10 내지 12 단계는 생략되어 적용될 수 있다.
12 및 13. MME는 SCEF 연결 정보(또는 NIDD 구성 정보)를 수신하여 단말에 대한 비-ip 데이터 송신이 가능하다고 판단하면, SCEF 연결(또는 NIDD 구성)/비-ip 데이터 전송의 유효(available) 등을 나타내는 지시가 포함된 접속 승인 메시지를 eNB를 통해 단말로 전송할 수 있다.
즉, 도 21에 도시한 순서도를 요약하면, 단말의 접속 절차에서 해당 단말의 서빙 노드 등을 등록하기 위해 HSS로 전송되는 ULR 메시지에는 해당 단말의 SCEF 연결(또는 NIDD 구성)이 필요함에 대한 지시가 포함될 수 있다. 이러한 SCEF 연결(또는 NIDD 구성)이 필요함에 대한 지시는 비-ip 데이터 송신이 필요하다는 지시로 해석될 수 있다. HSS는 해당 단말의 SCEF 연결 필요 여부를 판단(예를 들어, 유효한 SCEF 연결(또는 NIDD 구성)의 존재 여부, 남은 NIDD 송신 횟수 여부 등에 기초하여 판단)하여 필요한 경우, SCEF로 해당 단말에 대한 SCEF 연결(또는 NIDD 구성)이 필요하다고 알린다. 본 실시예의 경우, 단말은 SCEF 연결 셋업의 필요성을 알리기 위해, 서빙 노드의 등록이 필요 없는 경우에도 HSS로 ULR 메시지를 송신할 수 있다.
한편, 순서도에는 도시하지 않았으나, 도 20 및 21의 실시예에서와 달리, SCS/AS에서 직접 능동적으로 단말에 대한 모니터링을 요청할 수 있다. 단, SCS/AS는 단말의 접속 여부를 사전에 알고 있지 않기 때문에, HSS가 SCS/AS로부터 모니터링 요청을 수신한 경우, HSS는 SCS/AS가 요청하는 단말 모니터링에 관한 구성 정보를 저장하고 있다가 단말이 접속하면 해당 구성 정보를 MME로 전송할 수 있다.
다만, 추가적으로 배치(deploy)되는 단말이 있을 경우, 서비스를 제공하는 SCS/AS와 연계되지 않아서 SCS/AS가 해당 단말에 대해 필요한 SCEF 연결(또는 NIDD 구성)을 수행하지 못하는 경우가 발생할 수 있다. 이에 단말의 접속 여부, 즉 단말의 SCEF 연결(또는 NIDD 구성) 가능 여부를 SCS/AS로 알려주는 기능이 필요할 수 있다. 이에, 만일 MME가 단말의 접속 시 해당 단말의 접속 여부(또는 존재 여부)를 SCS/AS로 지시할 필요가 있다고 판단하는 경우(예를 들어, SCS/AS와 연계되지 않은 새로운 단말이 접속 요청한 경우), 도 7과 관련하여 상술한 접속 절차의 ULR 메시지에 이에 대한 지시 정보(예를 들어, SCEF id, SCS/AS id 및 외부 id)를 포함시켜 HSS로 전송할 수 있다. 이 경우, HSS는 서빙 노드 정보와 함께 SCEF를 통해 SCS/AS로 단말의 접속/유효 여부에 관한 지시 등을 함께 전송할 수 있다. 해당 지시를 수신한 SCS/AS는 별도의 HSS에 대한 문의(query)없이 해당 단말의 접속 여부를 인지하고 해당 단말을 위한 SCEF 연결(또는 NIDD 구성)의 모니터링 등의 설정을 수행할 수 있다.
도 22는 본 발명의 일 실시예에 따른 SCEF의 NIDD 구성 설정 절차를 예시한 순서도이다. 본 순서도와 관련하여 앞서 상술한 설명 및 실시예들이 동일/유사하게 적용될 수 있으며, 중복되는 설명은 생략한다.
우선, SCEF는 네트워크 노드로부터 단말의 비-IP 데이터 송신을 위한 제1 SCEF 연결 셋업 요청을 수신할 수 있다(S2210). 여기서, 제1 SCEF 연결 셋업 요청은 접속을 요청한 단말의 외부 식별자 및 단말을 서비스하는 SCS/AS에 대한 SCS/AS 식별자를 포함할 수 있다. 단말의 외부 식별자는 단말의 IMSI에 대응되며, SCS/AS ID는 단말의 가입 정보로서 HSS에 저장되어 있을 수 있다.
다음으로, SCEF는 SCS/AS와의 NIDD 구성이 확립되어 있는지 판단할 수 있다(S2220). S2220 단계에서 NIDD 구성이 확립되어 있지 않은 것으로 판단된 경우, SCEF는 NIDD 구성을 확립하기 위한 제2 SCEF 연결 셋업 요청을 SCS/AS로 전송할 수 있다(S2230). 이때, 제2 SCEF 연결 셋업 요청은 단말의 외부 식별자를 포함할 수 있다.
마지막으로, SCEF는 SCS/AS와 단말에 대한 NIDD 구성을 설정할 수 있다. 보다 상세하게는, SCEF는 SCS/AS로부터 단말과의 NIDD 구성 설정을 요청하는 제1 NIDD 구성 요청 메시지를 수신하고, 수신한 제1 NIDD 구성 요청 메시지에 기초하여 HSS로 NIDD 구성 설정을 위한 제2 NIDD 구성 요청 메시지를 전송할 수 있다. 여기서, 제1 및 제2 NIDD 구성 요청 메시지는, SCS/AS에 대한 SCS/AS 식별자와 SCS/AS 참조 식별자, NIDD 최대 횟수, NIDD 지속 기간(Duration) 및/또는 NIDD 목적지(Destination) 주소를 포함할 수 있다.
NIDD 구성이 설정된 후, SCEF는 비-IP 데이터로서 발신호 데이터의 전송을 알리는 제1 MO NIDD 지시 메시지를 수신하고, SCS/AS로 제2 MO NIDD 지시 메시지를 전송할 수 있다. 이때, 제1 및 제2 MO NIDD 지시 메시지는 SCEF 참조 식별자 및 발신호 데이터를 포함할 수 있다. 나아가, SCEF는 제2 MO NIDD 지시 메시지에 대한 응답으로서 제1 MO NIDD Ack(Acknowledge) 메시지를 수신하고, 제1 MO NIDD 지시 메시지에 대한 응답으로서 제2 MO NIDD Ack(Acknowledge) 메시지를 전송할 수 있다.
또는, NIDD 구성이 설정된 후, SCEF는 비-IP 데이터로서 착신호 데이터의 전송을 알리는 제1 MT NIDD 요청 메시지를 상기 SCS/AS로부터 수신하고, 제2 MO NIDD 요청 메시지를 전송할 수 있다. 이때, 제1 및 제2 MO NIDD 요청 메시지는 SCEF 참조 식별자 및 착신호 데이터를 포함할 수 있다. 나아가, SCEF는 제2 MT NIDD 요청 메시지에 대한 응답으로서 제2 MT NIDD 응답 메시지를 수신하고, 제1 MT NIDD 요청 메시지에 대한 응답으로서 제1 MT NIDD 응답 메시지를 전송할 수 있다. 이때, 제2 MT NIDD 응답 메시지는, MME에 의해 착신호 데이터가 전송 불가라고 판단된 경우, 전송 불가 이유를 지시하는 원인 값을 포함할 수 있다.
이외에, NIDD 구성을 위한 제반 절차에는 앞서 도 17과 관련하여 상술한 NIDD 구성 절차가 적용될 수 있다.
한편, S2210 단계의 네트워크 노드는 HSS 또는 MME에 해당할 수 있다.
만일, 네트워크 노드가 MME에 해당하며, MME에 의해 단말의 제어 평면을 통한 비-IP 데이터 송신 지원이 판단됨에 따라 비-IP 데이터 송신을 위한 SCEF 전달 방식이 선택된 경우, 제1 SCEF 연결 셋업 요청이 MME로부터 수신될 수 있다.
또한, 만일, 네트워크 노드가 HSS에 해당하며, HSS에 의해 비-IP 데이터 송신을 위한 NIDD 구성이 ULR 메시지를 통해 필요하다고 판단되는 경우, 제1 SCEF 연결 셋업 요청이 상기 HSS로부터 수신될 수 있다.
본 발명이 적용될 수 있는 장치 일반
도 23는 본 발명의 일 실시예에 따른 통신 장치의 블록 구성도를 예시한다.
도 23를 참조하면, 무선 통신 시스템은 네트워크 노드(2310)와 다수의 단말(UE)(2320)을 포함한다.
네트워크 노드(2310)는 프로세서(processor, 2311), 메모리(memory, 2312) 및 통신 모듈(communication module, 2313)을 포함한다. 프로세서(2311)는 앞서 도 1 내지 도 22에서 제안된 기능, 과정 및/또는 방법을 구현한다. 유/무선 인터페이스 프로토콜의 계층들은 프로세서(2311)에 의해 구현될 수 있다. 메모리(2312)는 프로세서(2311)와 연결되어, 프로세서(2311)를 구동하기 위한 다양한 정보를 저장한다. 통신 모듈(2313)은 프로세서(2311)와 연결되어, 유/무선 신호를 송신 및/또는 수신한다. 네트워크 노드(2310)의 일례로, 기지국, MME, HSS, SGW, PGW, SCEF, SCS/AS 등이 이에 해당될 수 있다. 특히, 네트워크 노드(2310)가 기지국인 경우, 통신 모듈(2313)은 무선 신호를 송/수신하기 위한 RF부(radio frequency unit)을 포함할 수 있다.
단말(2320)은 프로세서(2321), 메모리(2322) 및 통신 모듈(또는 RF부)(2323)을 포함한다. 프로세서(2321)는 앞서 도 1 내지 도 22에서 제안된 기능, 과정 및/또는 방법을 구현한다. 무선 인터페이스 프로토콜의 계층들은 프로세서(2321)에 의해 구현될 수 있다. 메모리(2322)는 프로세서(2321)와 연결되어, 프로세서(2321)를 구동하기 위한 다양한 정보를 저장한다. 통신 모듈(2323)는 프로세서(2321)와 연결되어, 무선 신호를 송신 및/또는 수신한다.
메모리(2312, 2322)는 프로세서(2311, 2321) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(2311, 2321)와 연결될 수 있다. 또한, 네트워크 노드(2310)(기지국인 경우) 및/또는 단말(2320)은 한 개의 안테나(single antenna) 또는 다중 안테나(multiple antenna)를 가질 수 있다.
도 24는 본 발명의 일 실시예에 따른 통신 장치의 블록 구성도를 예시한다.
특히, 도 24에서는 앞서 도 23의 단말을 보다 상세히 예시하는 도면이다.
도 24를 참조하면, 단말은 프로세서(또는 디지털 신호 프로세서(DSP: digital signal processor)(2410), RF 모듈(RF module)(또는 RF 유닛)(2435), 파워 관리 모듈(power management module)(2405), 안테나(antenna)(2440), 배터리(battery)(2455), 디스플레이(display)(2415), 키패드(keypad)(2420), 메모리(memory)(2430), 심카드(SIM(Subscriber Identification Module) card)(2425)(이 구성은 선택적임), 스피커(speaker)(2445) 및 마이크로폰(microphone)(2450)을 포함하여 구성될 수 있다. 단말은 또한 단일의 안테나 또는 다중의 안테나를 포함할 수 있다.
프로세서(2410)는 앞서 도 1 내지 도 23에서 제안된 기능, 과정 및/또는 방법을 구현한다. 무선 인터페이스 프로토콜의 계층은 프로세서(2410)에 의해 구현될 수 있다.
메모리(2430)는 프로세서(2410)와 연결되고, 프로세서(2410)의 동작과 관련된 정보를 저장한다. 메모리(2430)는 프로세서(2410) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(2410)와 연결될 수 있다.
사용자는 예를 들어, 키패드(2420)의 버튼을 누르거나(혹은 터치하거나) 또는 마이크로폰(2450)를 이용한 음성 구동(voice activation)에 의해 전화 번호 등과 같은 명령 정보를 입력한다. 프로세서(2410)는 이러한 명령 정보를 수신하고, 전화 번호로 전화를 거는 등 적절한 기능을 수행하도록 처리한다. 구동 상의 데이터(operational data)는 심카드(2425) 또는 메모리(2430)로부터 추출할 수 있다. 또한, 프로세서(2410)는 사용자가 인지하고 또한 편의를 위해 명령 정보 또는 구동 정보를 디스플레이(2415) 상에 디스플레이할 수 있다.
RF 모듈(2435)는 프로세서(2410)에 연결되어, RF 신호를 송신 및/또는 수신한다. 프로세서(2410)는 통신을 개시하기 위하여 예를 들어, 음성 통신 데이터를 구성하는 무선 신호를 전송하도록 명령 정보를 RF 모듈(2435)에 전달한다. RF 모듈(2435)은 무선 신호를 수신 및 송신하기 위하여 수신기(receiver) 및 전송기(transmitter)로 구성된다. 안테나(2440)는 무선 신호를 송신 및 수신하는 기능을 한다. 무선 신호를 수신할 때, RF 모듈(2435)은 프로세서(2410)에 의해 처리하기 위하여 신호를 전달하고 기저 대역으로 신호를 변환할 수 있다. 처리된 신호는 스피커(2445)를 통해 출력되는 가청 또는 가독 정보로 변환될 수 있다.
이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.
본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 발명의 일 실시예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.
펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명의 일 실시예는 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태로 구현될 수 있다. 소프트웨어 코드는 메모리에 저장되어 프로세서에 의해 구동될 수 있다. 상기 메모리는 상기 프로세서 내부 또는 외부에 위치하여, 이미 공지된 다양한 수단에 의해 상기 프로세서와 데이터를 주고 받을 수 있다.
본 발명은 본 발명의 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상술한 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
본 발명은 3GPP LTE/LTE-A 시스템에 적용되는 예를 중심으로 설명하였으나, 3GPP LTE/LTE-A 시스템 이외에도 다양한 무선 통신 시스템에 적용하는 것이 가능하다.

Claims (15)

  1. 무선 통신 시스템에서 SCEF(Service Capability Exposure Function)가 NIDD(Non-IP Data Delivery) 구성(configuration)을 설정하기 위한 방법에 있어서,
    네트워크 노드로부터 단말의 비(non)-IP 데이터 송신을 위한 제1 SCEF 연결 셋업 요청을 수신하는 단계; 로서, 상기 제1 SCEF 연결 셋업 요청은 상기 단말의 외부 식별자(external identifier) 및 상기 단말을 서비스하는 SCS(Services Capability Server)/AS(Application Server)의 SCS/AS 식별자를 포함함,
    상기 SCS/AS와의 상기 NIDD 구성이 확립되어 있는지 판단하는 단계;
    상기 NIDD 구성이 확립되어 있지 않은 경우, 상기 NIDD 구성을 확립하기 위한 제2 SCEF 연결 셋업 요청을 상기 SCS/AS로 전송하는 단계; 로서, 상기 제2 SCEF 연결 셋업 요청은 상기 단말의 상기 외부 식별자를 포함함, 및
    상기 SCS/AS와 상기 단말에 대한 상기 NIDD 구성을 설정하는 단계; 를 포함하는, NIDD 구성을 설정하기 위한 방법.
  2. 제 1 항에 있어서,
    상기 단말의 외부 식별자는 상기 단말의 IMSI(International Mobile Subscriber Identity)에 대응되며,
    상기 SCS/AS ID는 상기 단말의 가입 정보로서 상기 HSS에 저장되어 있는, NIDD 구성을 설정하기 위한 방법.
  3. 제 1 항에 있어서,
    상기 네트워크 노드는 HSS(Home Subscriber Server) 또는 MME(Mobility Management Entity)에 해당하는, NIDD 구성을 설정하기 위한 방법.
  4. 제 3 항에 있어서,
    상기 네트워크 노드가 상기 MME에 해당하며, 상기 MME에 의해 상기 단말의 제어 평면을 통한 상기 비-IP 데이터 송신 지원이 판단됨에 따라 상기 비-IP 데이터 송신을 위한 SCEF 전달 방식이 선택된 경우, 상기 제1 SCEF 연결 셋업 요청이 상기 MME로부터 수신되는, NIDD 구성을 설정하기 위한 방법.
  5. 제 3 항에 있어서,
    상기 네트워크 노드가 상기 HSS에 해당하며, 상기 HSS에 의해 상기 비-IP 데이터 송신을 위한 상기 NIDD 구성이 ULR(Update Location Request) 메시지를 통해 필요하다고 판단되는 경우, 상기 제1 SCEF 연결 셋업 요청이 상기 HSS로부터 수신되는, NIDD 구성을 설정하기 위한 방법.
  6. 제 1 항에 있어서,
    상기 NIDD 구성을 설정하는 단계는,
    상기 SCS/AS로부터 상기 단말과의 상기 NIDD 구성 설정을 요청하는 제1 NIDD 구성 요청 메시지를 수신하는 단계; 및
    상기 수신한 제1 NIDD 구성 요청 메시지에 기초하여 HSS로 상기 NIDD 구성 설정을 위한 제2 NIDD 구성 요청 메시지를 전송하는 단계; 를 포함하되,
    상기 제1 및 제2 NIDD 구성 요청 메시지는, 상기 SCS/AS에 대한 SCS/AS 식별자와 SCS/AS 참조 식별자, NIDD 최대 횟수, NIDD 지속 기간(Duration) 및/또는 NIDD 목적지(Destination) 주소를 포함하는, NIDD 구성을 설정하기 위한 방법.
  7. 제 6 항에 있어서,
    상기 NIDD 구성이 설정된 후, 상기 비-IP 데이터로서 발신호(Mobile Originated; MO) 데이터의 전송을 알리는 제1 MO NIDD 지시 메시지를 수신하는 단계; 및
    상기 SCS/AS로 제2 MO NIDD 지시 메시지를 전송하는 단계; 를 더 포함하되,
    상기 제1 및 제2 MO NIDD 지시 메시지는 상기 SCEF 참조 식별자 및 상기 발신호 데이터를 포함하는, NIDD 구성을 설정하기 위한 방법.
  8. 제 7 항에 있어서,
    상기 제2 MO NIDD 지시 메시지에 대한 응답으로서 제1 MO NIDD Ack(Acknowledge) 메시지를 수신하는 단계; 및
    제1 MO NIDD 지시 메시지에 대한 응답으로서 제2 MO NIDD Ack(Acknowledge) 메시지를 전송하는 단계; 를 더 포함하는, NIDD 구성을 설정하기 위한 방법.
  9. 제 1 항에 있어서,
    상기 NIDD 구성이 설정된 후, 상기 비-IP 데이터로서 착신호(Mobile Terminated; MT) 데이터의 전송을 알리는 제1 MT NIDD 요청 메시지를 상기 SCS/AS로부터 수신하는 단계; 및
    제2 MO NIDD 요청 메시지를 전송하는 단계; 를 더 포함하되,
    상기 제1 및 제2 MO NIDD 요청 메시지는 상기 SCEF 참조 식별자 및 상기 착신호 데이터를 포함하는, NIDD 구성을 설정하기 위한 방법.
  10. 제 9 항에 있어서,
    상기 제2 MT NIDD 요청 메시지에 대한 응답으로서 제2 MT NIDD 응답 메시지를 수신하는 단계; 및
    제1 MT NIDD 요청 메시지에 대한 응답으로서 제1 MT NIDD 응답 메시지를 전송하는 단계; 를 더 포함하되,
    상기 제2 MT NIDD 응답 메시지는, MME에 의해 상기 착신호 데이터가 전송 불가라고 판단된 경우, 전송 불가 이유를 지시하는 원인 값을 포함하는, NIDD 구성을 설정하기 위한 방법.
  11. 무선 통신 시스템에서 NIDD(Non-IP Data Delivery) 구성(configuration)을 설정하는 SCEF(Service Capability Exposure Function)에 있어서,
    신호를 송수신하기 위한 통신 모듈(communication module); 및
    상기 통신 모듈을 제어하는 프로세서; 를 포함하고,
    상기 프로세서는,
    네트워크 노드로부터 단말의 비(non)-IP 데이터 송신을 위한 제1 SCEF 연결 셋업 요청을 수신하되, 상기 제1 SCEF 연결 셋업 요청은 상기 단말의 외부 식별자(external identifier) 및 상기 단말을 서비스하는 SCS(Services Capability Server)/AS(Application Server)의 SCS/AS 식별자를 포함함,
    상기 SCS/AS와의 상기 NIDD 구성이 확립되어 있는지 판단하고,
    상기 NIDD 구성이 확립되어 있지 않은 경우, 상기 NIDD 구성을 확립하기 위한 제2 SCEF 연결 셋업 요청을 상기 SCS/AS로 전송하되, 상기 제2 SCEF 연결 셋업 요청은 상기 단말의 상기 외부 식별자를 포함함,
    상기 SCS/AS와 상기 단말에 대한 상기 NIDD 구성을 설정하는, SCEF.
  12. 제 11 항에 있어서,
    상기 단말의 외부 식별자는 상기 단말의 IMSI(International Mobile Subscriber Identity)에 대응되며,
    상기 SCS/AS ID는 상기 단말의 가입 정보로서 상기 HSS에 저장되어 있는, SCEF.
  13. 제 11 항에 있어서,
    상기 네트워크 노드는 HSS(Home Subscriber Server) 또는 MME(Mobility Management Entity)에 해당하는, SCEF.
  14. 제 13 항에 있어서,
    상기 네트워크 노드가 상기 MME에 해당하며, 상기 MME에 의해 상기 단말의 제어 평면을 통한 상기 비-IP 데이터 송신 지원이 판단됨에 따라 상기 비-IP 데이터 송신을 위한 SCEF 전달 방식이 선택된 경우, 상기 제1 SCEF 연결 셋업 요청이 상기 MME로부터 수신되는, SCEF.
  15. 제 13 항에 있어서,
    상기 네트워크 노드가 상기 HSS에 해당하며, 상기 HSS에 의해 상기 비-IP 데이터 송신을 위한 상기 NIDD 구성이 ULR(Update Location Request) 메시지를 통해 필요하다고 판단되는 경우, 상기 제1 SCEF 연결 셋업 요청이 상기 HSS로부터 수신되는, SCEF.
PCT/KR2017/000294 2016-01-07 2017-01-09 무선 통신 시스템에서 nidd(non-ip data delivery) 구성 설정 방법 및 이를 위한 장치 WO2017119802A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/068,598 US10652085B2 (en) 2016-01-07 2017-01-09 Method for setting configuration of non-IP data delivery (NDID) in wireless communication system and device for same

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662275790P 2016-01-07 2016-01-07
US62/275,790 2016-01-07

Publications (1)

Publication Number Publication Date
WO2017119802A1 true WO2017119802A1 (ko) 2017-07-13

Family

ID=59273823

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/000294 WO2017119802A1 (ko) 2016-01-07 2017-01-09 무선 통신 시스템에서 nidd(non-ip data delivery) 구성 설정 방법 및 이를 위한 장치

Country Status (2)

Country Link
US (1) US10652085B2 (ko)
WO (1) WO2017119802A1 (ko)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019232795A1 (en) * 2018-06-08 2019-12-12 Telefonaktiebolaget Lm Ericsson (Publ) Methods and nodes for facilitating non-ip ue-to-ue communications
WO2020060871A1 (en) * 2018-09-19 2020-03-26 Intel Corporation Protection of initial non-access stratum protocol message in 5g systems
WO2020071805A1 (en) * 2018-10-05 2020-04-09 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data in wireless communication system
JP2020088738A (ja) * 2018-11-29 2020-06-04 ソフトバンク株式会社 管理装置、通信システム、プログラム及び制御方法
US11252652B2 (en) 2019-04-02 2022-02-15 Electronics And Telecommunications Research Institute Non-IP data delivery authorization update method and connection release method for non-IP data delivery, and device for performing the method
WO2023068699A1 (en) * 2021-10-20 2023-04-27 Lg Electronics Inc. Method and apparatus for managing time alignment timer for small data transmission in wireless communication system
US11785435B2 (en) 2018-05-11 2023-10-10 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for capability exposure

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019050437A (ja) 2016-01-19 2019-03-28 シャープ株式会社 端末装置、ｃ−ｓｇｎおよび通信制御方法
CN106982473B (zh) * 2016-01-19 2021-09-07 中兴通讯股份有限公司 传输通道的建立方法和无线通信装置
JP2019050435A (ja) * 2016-01-19 2019-03-28 シャープ株式会社 端末装置、ｃ−ｓｇｎおよび通信制御方法
CN107046714B (zh) * 2016-02-05 2020-08-11 中兴通讯股份有限公司 一种数据传输方法、装置和系统
WO2017141749A1 (en) * 2016-02-17 2017-08-24 Nec Corporation Selection of control plane and user plane for the data transmission
WO2017156706A1 (zh) * 2016-03-15 2017-09-21 华为技术有限公司 用于处理数据包的方法及设备
TR201911124T4 (tr) * 2016-03-31 2019-08-21 Ericsson Telefon Ab L M SCEF vasıtasıyla yüksek gecikmeli iletişim.
CN109417728B (zh) * 2016-06-30 2023-02-28 苹果公司 用于授权和启用/禁用增强覆盖功能的装置
CN109937588B (zh) * 2016-11-07 2022-03-04 日本电气株式会社 Scef实体、控制设备、通信方法和非暂时性计算机可读介质
US11349938B2 (en) * 2017-03-24 2022-05-31 Qualcomm Incorporated Exhanging service capability exposure function (SCEF)-related information of a user equipment
EP3639612B1 (en) * 2017-06-16 2023-09-20 IPLA Holdings Inc. Small data transfer, data buffering, and data management as a service in a communications network
CN112911583A (zh) * 2017-07-11 2021-06-04 华为技术有限公司 设备接入方法、设备及系统
EP3668185B1 (en) 2017-08-08 2024-07-31 Nec Corporation Control device, communication terminal, control method, non-transitory computer readable medium, mme, and base station
TWI669019B (zh) * 2017-08-14 2019-08-11 宏達國際電子股份有限公司 處理互通程序的裝置及方法
US10805178B2 (en) 2017-11-27 2020-10-13 Cisco Technology, Inc. Subscription-based event notification techniques for reducing data buffering in mobile networks
WO2020103662A1 (en) * 2018-11-19 2020-05-28 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for event monitoring
EP3841831B1 (en) * 2018-12-12 2024-09-25 Telefonaktiebolaget LM Ericsson (publ) A method implemented at a network exposure node for ip and non-ip data communication
EP3903511A4 (en) * 2018-12-29 2022-07-13 Telefonaktiebolaget LM Ericsson (publ) METHOD AND DEVICE FOR LOCATION-BASED GROUP MESSAGING
WO2020156460A1 (en) * 2019-02-02 2020-08-06 Telefonaktiebolaget Lm Ericsson (Publ) Methods and nodes for ue-to-ue event monitoring
EP3923650A4 (en) * 2019-02-08 2022-08-03 Ntt Docomo, Inc. WIRELESS NODE, AND WIRELESS COMMUNICATION CONTROL METHOD
US10945120B2 (en) 2019-02-27 2021-03-09 Oracle International Corporation Methods, systems, and computer readable media for dynamically provisioning and using public land mobile network (PLMN) location mappings in service capability exposure function (SCEF) or network exposure function (NEF)
US11516263B2 (en) * 2019-03-14 2022-11-29 T-Mobile Usa, Inc. Secure and transparent transport of application level protocols to non-IP data delivery communication channels
WO2020200104A1 (en) * 2019-03-29 2020-10-08 Telefonaktiebolaget Lm Ericsson (Publ) Network node, server and methods for facilitating non-ip data delivery
US11044605B2 (en) * 2019-05-10 2021-06-22 Verizon Patent And Licensing Inc. Network based non-IP data delivery service authorization for wireless networks
JP7326860B2 (ja) * 2019-05-17 2023-08-16 富士フイルムビジネスイノベーション株式会社 システム、プログラム
US10972368B2 (en) * 2019-05-17 2021-04-06 Oracle International Corporation Methods, systems, and computer readable media for providing reduced signaling internet of things (IoT) device monitoring
AU2020354228B2 (en) * 2019-09-27 2023-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and entity for checking port consistency of NIDD message
US12069045B2 (en) * 2019-09-30 2024-08-20 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for enabling remote management of a profile in an identity module
WO2022007896A1 (en) * 2020-07-09 2022-01-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for group message delivery
US11381955B2 (en) * 2020-07-17 2022-07-05 Oracle International Corporation Methods, systems, and computer readable media for monitoring machine type communications (MTC) device related information
FI3968666T3 (fi) 2020-09-10 2024-08-26 Telia Co Ab Päätelaitteen valmistelu matkaviestinverkkoa varten
US11503659B2 (en) * 2021-01-15 2022-11-15 T-Mobile Usa, Inc. Routing optimization for service capability exposure
US11700510B2 (en) 2021-02-12 2023-07-11 Oracle International Corporation Methods, systems, and computer readable media for short message delivery status report validation
US11895080B2 (en) 2021-06-23 2024-02-06 Oracle International Corporation Methods, systems, and computer readable media for resolution of inter-network domain names
WO2023115350A1 (en) * 2021-12-21 2023-06-29 Lenovo (Beijing) Limited Enhanced mechanism on uu interface for mt sdt
CN118715804A (zh) * 2022-02-18 2024-09-27 上海诺基亚贝尔股份有限公司 用于小数据传输的接入资源选择

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150264512A1 (en) * 2014-03-14 2015-09-17 Puneet K. Jain Conveyance of application communication patterns from an external application server to a 3rd generation partnership project system
US20150365789A1 (en) * 2014-06-11 2015-12-17 Cisco Technology, Inc. Location reporting of user equipment in a cellular network environment

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016054588A1 (en) * 2014-10-02 2016-04-07 Zte Corporation Group communication with a logical group of wireless devices operating in different networks
WO2016073533A1 (en) * 2014-11-03 2016-05-12 Zte Corporation Group communication function for delivering group communication messages in communication netwoks
WO2017025152A1 (en) * 2015-08-07 2017-02-16 Nec Europe Ltd. Network management method and system for a shared radio access network, ran, infrastructure
EP3346753B1 (en) * 2015-11-06 2020-04-29 Samsung Electronics Co., Ltd. Method for transmitting data in ciot system and device therefor
US20180352501A1 (en) * 2015-12-29 2018-12-06 Telefonaktiebolaget Lm Ericsson (Publ) Method And Apparatus For Virtualized Network Service Provision

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150264512A1 (en) * 2014-03-14 2015-09-17 Puneet K. Jain Conveyance of application communication patterns from an external application server to a 3rd generation partnership project system
US20150365789A1 (en) * 2014-06-11 2015-12-17 Cisco Technology, Inc. Location reporting of user equipment in a cellular network environment

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ERICSSON ET AL.: "Introducing Support for Non-IP Data for CIoT", 3GPP TSG-SA WG2 MEETING #112 S2-153871, 12 November 2015 (2015-11-12), pages 2 - 15387, XP051035460 *
NEUL: "Asynchronous Message Transport for Non-IP Devices", S2-154092, 3GPP TSG-SA WG2 MEETING #112, 12 November 2015 (2015-11-12), XP051035621 *
SAMSUNG ET AL.: "Introduction of Non-IP Data Delivery via the SCEF for Cellular IoT", 3GPP TSG-SA WG2 MEETING #112 S2- 154024, 12 November 2015 (2015-11-12), pages 2 - 1 54024, XP051035557 *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11785435B2 (en) 2018-05-11 2023-10-10 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for capability exposure
EP3791620B1 (en) * 2018-05-11 2024-08-07 Telefonaktiebolaget LM Ericsson (publ.) Methods and apparatuses for capability exposure
WO2019232795A1 (en) * 2018-06-08 2019-12-12 Telefonaktiebolaget Lm Ericsson (Publ) Methods and nodes for facilitating non-ip ue-to-ue communications
US11277873B2 (en) 2018-06-08 2022-03-15 Telefonaktiebolaget Lm Ericsson (Publ) Methods and nodes for facilitating non-IP UE-to-UE communications
WO2020060871A1 (en) * 2018-09-19 2020-03-26 Intel Corporation Protection of initial non-access stratum protocol message in 5g systems
CN112703754A (zh) * 2018-09-19 2021-04-23 苹果公司 5g系统中的初始非接入层协议消息的保护
US11877149B2 (en) 2018-09-19 2024-01-16 Apple Inc. Protection of initial non-access stratum protocol message in 5G systems
WO2020071805A1 (en) * 2018-10-05 2020-04-09 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data in wireless communication system
US11153785B2 (en) 2018-10-05 2021-10-19 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data in wireless communication system
US11729671B2 (en) 2018-10-05 2023-08-15 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data in wireless communication system
JP2020088738A (ja) * 2018-11-29 2020-06-04 ソフトバンク株式会社 管理装置、通信システム、プログラム及び制御方法
US11792727B2 (en) 2019-04-02 2023-10-17 Electronics And Telecommunications Research Institute Non-IP data delivery authorization update method and connection release method for non-IP data delivery, and device for performing the method
US11252652B2 (en) 2019-04-02 2022-02-15 Electronics And Telecommunications Research Institute Non-IP data delivery authorization update method and connection release method for non-IP data delivery, and device for performing the method
WO2023068699A1 (en) * 2021-10-20 2023-04-27 Lg Electronics Inc. Method and apparatus for managing time alignment timer for small data transmission in wireless communication system

Also Published As

Publication number Publication date
US20190028337A1 (en) 2019-01-24
US10652085B2 (en) 2020-05-12

Similar Documents

Publication Publication Date Title
WO2017119802A1 (ko) 무선 통신 시스템에서 nidd(non-ip data delivery) 구성 설정 방법 및 이를 위한 장치
WO2017078485A1 (ko) 무선 통신 시스템에서 서빙 노드 이전 방법 및 이를 위한 장치
WO2017164679A1 (ko) 무선 통신 시스템에서 트래킹 영역 업데이트 방법 및 이를 위한 장치
WO2017200269A1 (ko) 무선 통신 시스템에서 착신 데이터 제어 방법 및 이를 위한 장치
WO2018131984A1 (ko) 무선 통신 시스템에서 ue 설정 업데이트 방법 및 이를 위한 장치
WO2018128528A1 (ko) 무선 통신 시스템에서 pdu 세션 관리 방법 및 이를 위한 장치
WO2017126922A1 (ko) 무선 통신 시스템에서 연결 재개 방법 및 이를 위한 장치
WO2018174525A1 (ko) 무선 통신 시스템에서 계층간 상호작용 방법 및 이를 위한 장치
WO2018155908A1 (ko) 무선 통신 시스템에서 릴레이를 통한 데이터 송수신 방법 및 이를 위한 장치
WO2017126884A1 (ko) 무선 통신 시스템에서 혼잡 제어 방법 및 이를 위한 장치
WO2018231028A1 (ko) 무선 통신 시스템에서 단말의 등록 방법 및 이를 위한 장치
WO2017188758A1 (ko) 무선 통신 시스템에서 nas 시그널링 유보/재개를 수행하기 위한 방법 및 이를 위한 장치
WO2017048042A1 (ko) 무선 통신 시스템에서의 페이징 절차를 수행하는 방법 및 이를 위한 장치
WO2018008980A1 (ko) 무선 통신 시스템에서 사용자가 선호하는 자원 운용 선택 방법 및 이를 위한 장치
WO2018066876A1 (ko) 무선 통신 시스템에서 v2x 통신 지원 방법
WO2019098745A1 (ko) 무선 통신 시스템에서의 핸드오버 방법 및 이를 위한 장치
WO2018147698A1 (ko) 무선 통신 시스템에서 nas 메시지 송수신 방법 및 이를 위한 장치
WO2018174516A1 (ko) 무선 통신 시스템에서 nas 메시지 처리 방법 및 이를 위한 장치
WO2017082682A1 (ko) 무선 통신 시스템에서의 데이터 전송 모드 선택 방법 및 이를 위한 장치
WO2018110939A1 (ko) 무선 통신 시스템에서의 트래킹 영역 할당 방법 및 이를 위한 장치
WO2018093168A1 (ko) 무선 통신 시스템에서의 네트워크 노드 선택 방법 및 이를 위한 장치
WO2018097601A1 (ko) 무선 통신 시스템에서의 등록 해제 방법 및 이를 위한 장치
WO2018169244A1 (ko) 무선 통신 시스템에서 이동성 이벤트 통지 방법 및 이를 위한 장치
WO2018164552A1 (ko) 무선 통신 시스템에서 릴레이를 통한 데이터 송수신 방법 및 이를 위한 장치
WO2017003235A1 (ko) 무선 통신 시스템에서 그룹 메시지를 전송하기 위한 방법 및 이를 위한 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17736174

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17736174

Country of ref document: EP

Kind code of ref document: A1