[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2013070051A1 - 무선 통신 시스템에서 mtc 트리거(trigger) 방법 및 장치 - Google Patents

무선 통신 시스템에서 mtc 트리거(trigger) 방법 및 장치 Download PDF

Info

Publication number
WO2013070051A1
WO2013070051A1 PCT/KR2012/009545 KR2012009545W WO2013070051A1 WO 2013070051 A1 WO2013070051 A1 WO 2013070051A1 KR 2012009545 W KR2012009545 W KR 2012009545W WO 2013070051 A1 WO2013070051 A1 WO 2013070051A1
Authority
WO
WIPO (PCT)
Prior art keywords
mtc
trigger
trigger request
retry
iwf
Prior art date
Application number
PCT/KR2012/009545
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 US14/357,991 priority Critical patent/US9392396B2/en
Publication of WO2013070051A1 publication Critical patent/WO2013070051A1/ko

Links

Classifications

    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems

Definitions

  • a method and apparatus for performing or supporting Machine Type Communications (MTC) triggering is disclosed.
  • Machine Type Communications refers to a communication method including one or more machines, and may also be referred to as machine-to-machine communication or thing communication.
  • a machine is an entity that does not require human intervention or intervention.
  • devices such as meters or vending machines equipped with mobile communication modules, as well as user devices such as smartphones that can automatically connect and communicate with a network without user intervention / intervention, This may be the case.
  • Various examples of such machines are referred to herein as MTC devices or terminals. That is, MTC means communication performed by one or more machines (ie, MTC terminals) without human intervention / intervention.
  • the MTC may include communication between MTC terminals (eg, device-to-device (D2D) communication) and communication between an MTC terminal and an MTC application server.
  • MTC terminals eg, device-to-device (D2D) communication
  • D2D device-to-device
  • Point of Sale (POS) devices and servers, electricity, gas or water meters Can be mentioned.
  • applications based on MTC may include security transportation, health care, and the like.
  • a first technical aspect of the present invention is a method in which a MTC-IWF (Machine Type Communication) trigger request is performed in a wireless communication system, wherein the trigger request and the trigger request are made to a first serving node. And transmitting information related to retrying of the information, wherein the information related to retrying the trigger request includes information on whether to retry when the trigger request transmission fails.
  • the trigger request retry is a method of performing a trigger request that is delegated to the first serving node when instructing to perform retry.
  • An MTC-IWF (InterWorking Function) device for performing a communication trigger request, comprising: transmission and reception modules; And a processor, wherein the processor is connected to a first serving node. Transmits information related to the trigger request and retry of the trigger request, and the information related to the trigger request retry includes information on whether retry is performed when the trigger request transmission fails, and whether or not the retry is performed.
  • the trigger request retry is an MTC-IWF device that is delegated to the first serving node when the information indicates that the retry is performed.
  • the first to second technical aspects of the present invention may include the following.
  • the information related to the trigger request retry may be determined in consideration of at least one of the number of available serving nodes, a network congestion situation, the preference of the MTC terminal, and whether the MTC terminal roams.
  • the delegation of the trigger request retry may mean that the first serving node is instructed to deliver the trigger request to the second serving node when the trigger request delivery fails.
  • the first serving node fails to deliver the trigger request to the terminal, and the information on whether to perform the retry instructs to perform the retry, the first serving node sends the trigger request to the second serving node.
  • the second serving node may transmit a trigger request to the terminal.
  • the information related to the trigger request retries may further include at least one of a retry count or a retry allowance time. There may be two or more available serving nodes capable of transmitting the trigger request. Also, the above .
  • the first serving node and the second serving node may be any one of a Serving General Packet Radio Service (GPRS) Supporting Node (SGSN), a Mobility Management Entity (MME), and a Mobile Switching Center (MSC).
  • GPRS General Packet Radio Service
  • SGSN Serving General Packet Radio Service
  • MME Mobility Management Entity
  • MSC Mobile Switching Center
  • the MCT-IWF transmits a subscriber notification message for subscribing to the terminal related information notification service to a home subscriber server (HSS) / home location register (HLR); And receiving a notification subscriber information message indicating that trigger delivery from the HSS / HLR to the terminal is enabled, wherein the notification subscriber information message includes one or more servings capable of transmitting a trigger to the terminal. May contain information about the node.
  • the method may further include determining a second serving node among the one or more serving nodes by using the notification subscriber information message, and transmitting information related to a trigger request and a trigger request retry to the second serving node. .
  • the information on the one or more serving nodes may include an identifier of the one or more serving nodes.
  • the method includes receiving the trigger request from a service capability server (SCS); And verifying that the trigger request is valid.
  • SCS service capability server
  • a method for accurately and efficiently performing triggering on an MTC terminal may be provided.
  • EPC Evolved Packet Core
  • 3 is a view for explaining the MTC terminal trigger delivery procedure.
  • FIG. 4 is a diagram for explaining a trigger delivery procedure using T5.
  • FIG. 5 is a diagram for explaining a trigger delivery procedure using T4.
  • 6 to 7 are diagrams for explaining a trigger delivery procedure according to an embodiment of the present invention.
  • FIG. 8 is a diagram illustrating a device configuration according to an embodiment of the present invention.
  • each component or feature may be considered to be optional unless otherwise stated.
  • Each component or feature may be embodied in a form that is not combined with other components or features.
  • some components and / or features may be combined to form an embodiment of the present invention.
  • the order of the operations described in the embodiments of the present invention may be changed. Some configurations or features of one embodiment may be included in another embodiment, or may be replaced with other configurations or features of another embodiment. Specific terms used in the following description are provided to help the understanding of the present invention, and the use of such specific terms may be changed to other forms without departing from the technical spirit of the present invention.
  • Embodiments of the present invention may be supported by standard documents disclosed in relation to at least one of the Institute of Electrical and Electronics Engineers (IEEE) 802 series system, 3GPP system, 3GPP LTE and LTE-A system, and 3GPP2 system. 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.
  • all terms disclosed in this document can be described by the above standard document.
  • the following techniques can be used in various wireless communication systems. For clarity, the following description focuses on 3GPP LTE and 3GPP LTE-A systems, but the technical spirit of the present invention is not limited thereto.
  • UMTS Universal Mobile Telecommunications System
  • GSM Global System for Mobile Communication
  • EPS Evolved Packet System
  • EPC Evolved packet core
  • LTE Long Term Evolution
  • UTRAN UTRAN
  • 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 smart phone, 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.
  • IP Multimedia Subsystem Subsystem that provides multimedia service based on IP
  • IMSl International Mobile Subscriber Identity
  • Machine Type Communications A message performed by a machine without human intervention.
  • MTC terminal (MTC UE (or MTC device): A terminal capable of communicating via a mobile communication network and performing a specific purpose (for example, a vending machine, a meter reader, etc.).
  • MTC server A server on a network that manages an MTC terminal. It can be inside or outside the mobile communication network. It may have an interface that an MTC user can access. MTC server is also different It may provide MTC related services to servers (in the form of SCS), or it may be an MTC application server.
  • MTC application Services to which MTC applies (eg, remote meter reading, volume movement tracking, etc.)
  • MTC Application Server A server on the network on which the MTC application runs.
  • MTC feature The ability of a network to support MTC applications.
  • MTC monitoring is a feature to prepare for loss of equipment in MTC applications such as remote meter reading
  • low mobility is a feature for MTC applications for MTC terminals such as vending machines.
  • MTC subscriber An entity that has a connection with a network operator and provides services to one or more MTC terminals.
  • MTC Group A group of MTC terminals sharing at least one MTC feature and belonging to an MTC subscriber.
  • External Identifier An identifier used by an external entity (eg, SCS or Application Server) of a 3 GPP network to indicate (or identify) an MTC terminal (or a subscriber to which the MTC terminal belongs). Is globally unique. External identifiers consist of a Domain Identifier and a Local Identifier as follows: Domain Identifier: An identifier for identifying a domain under the control of the mobile 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 child network provider.
  • IMSI International Mobile Subscriber Identity
  • RAN Radio Access Network: a unit including a NodeB, an eNodeB and a Radio Network Controller (RNC) controlling them in a 3 GPP network. It exists between terminals and provides a connection to the core network.
  • RNC Radio Network Controller
  • HLR Home Location Register
  • HSS Home Subscriber Server
  • -RANAP Node in charge of controlling the RAN and the core network (MME (Mobility Management Entity) / SGSN (Serving GPRS (General Packet Radio)
  • MME Mobility Management Entity
  • SGSN Serving GPRS (General Packet Radio)
  • 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 protocol stack.
  • the main function is to support mobility of the terminal and to support a session management procedure for establishing and maintaining an IP connection between the terminal and the PDN GW.
  • NAS Non-Access Stratum
  • 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, such as supporting various radio access technologies and providing improved data transfer capability, for example on an IP basis.
  • EPC is a core network (Core Network) of an IP mobile communication system for a 3GPP LTE system
  • a packet-based support can be a real-time and non-real-time service.
  • 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 connection between the terminal having the IP capability (capability) is connected to the IP-based base station (for example, evolved Node B (eNodeB)), EPC, application domain (for example, IMS) It can be configured through.
  • EPC is an essential structure for implementing end-to-end IP service.
  • the EPC may include various components, and in FIG. 1, a part of the EPC may include a Serving Gateway (SGW), a PDN GW (Packet Data Network Gateway),
  • SGW Serving Gateway
  • PDN GW Packet Data Network Gateway
  • MME Mobility Management Entity
  • SGRS Serving General Packet Radio Service
  • the SGW is an element that acts as a boundary point between a radio access network (RAN) and a core network and maintains a data path between an eNodeB and a PDN GW.
  • RAN radio access network
  • PDN GW packet data gateway
  • SGW also provides mobility with other 3GPP networks (RANs defined before 3GPP Release-8, such as UTRAN or GE AN (Global System for Mobile Communication (GSM) / Enhanced Data rates for Global Evolution (EDGE) Radio Access Network). It may also serve as an anchor point for.
  • RANs defined before 3GPP Release-8 such as UTRAN or GE AN (Global System for Mobile Communication (GSM) / Enhanced Data rates for Global Evolution (EDGE) Radio Access Network). It may also serve as an anchor point for.
  • 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.
  • mobility management between 3GPP networks and non-3GPP networks for example, untrusted networks such as Interworking Wireless Local Area Networks (I-WLANs), trusted networks such as Code Division Multiple Access (CDMA) networks or WiMax) Can serve as an anchor point for.
  • untrusted networks such as Interworking Wireless Local Area Networks (I-WLANs)
  • trusted networks such as Code Division Multiple Access (CDMA) networks or WiMax
  • 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 access to the network connection of the terminal, allocation of network resources, It is an element that performs signaling and control functions to support 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 another 2G / 3G network.
  • 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 for other 3GPP networks (e.g., GPRS networks).
  • 3GPP networks e.g., GPRS networks.
  • ePDG serves as a secure node for untrusted non-3GPP networks (eg, I-WLAN, WiFi hotspots, etc.).
  • 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 an 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 also shows various reference points (eg, Sl-U, S1-MME, etc.).
  • reference points eg, Sl-U, S1-MME, etc.
  • Table 1 summarizes the reference points shown in FIG. 1.
  • S2a and S2b correspond to non-3GPP interfaces.
  • S2a is a reference point that provides the user plane with associated control and mobility support between trusted non-3GPP access and PDNGW.
  • S2b is a reference point that provides the user plane with relevant control and mobility support between the ePDG and the PDN GW.
  • _ 2 is a diagram illustrating an exemplary model of an MTC structure.
  • the end-to-end application between the terminal (or MTC terminal) used for the MTC and the MTC application may use services provided by the 3GPP system and optional services provided by the MTC server.
  • the 3GPP system may provide transport and communication services (including 3GPP bearer services, IMS and SMS), including various optimizations that facilitate MTC.
  • FIG. 2 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. 2 includes various MTC models (Direct model, Indirect model, Hybrid model).
  • the application server is a server on a network on which 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.
  • the MTC server (for example, the SCS server shown) is a server on a network that manages an MTC terminal, and is connected to a 3GPP network and used for MTC. Communicate with nodes of the PLMN.
  • the MTC-Interworking Function manages the interworking between the MTC server and the operator core network, and can act as a proxy for MTC operations . have.
  • MTC-IWF MTC-Interworking Function
  • HPLMN home PLMN
  • 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 the trigger instruction described below. can do.
  • the Short Message Service-Service Center (SMS-SC) / Internet Protocol Short Message Gate Way (IP-SM-GW) may manage transmission and reception of a Short Message Service (SMS).
  • SMS-SC may be responsible for relaying, storing-and-forwarding the unit between the Short Message Entity (SME) (an entity that sends or receives a short message) and the mobile station.
  • SME Short Message Entity
  • IP-SM-GW may be in charge of protocol interaction between the IP-based terminal and the SMS-SC.
  • 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 control functions such as mobility management, authentication, and resource allocation for the network connection of the terminal.
  • control functions such as mobility management, authentication, and resource allocation for the network connection of the terminal.
  • a message provided to the MTC terminal receiving a trigger instruction from the MTC-IWF in connection with the triggering described later Machining function can be performed.
  • the Gateway GPRS Support Node (GGSN) / Serving-Gateway (S-GW) + Packet Data Network-Gateway (P-GW) may function as a gateway for connecting the core network and the external network.
  • T5a One or more reference points of the foregoing 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 can be performed using existing protocols via reference points Gi and SGi. .
  • MTC terminal In the case of MTC, it is expected that more MTC terminals exist on the network than general user equipment. Therefore, minimum network resource usage, minimum signaling usage, minimum power usage, etc. are required for MTC. In addition, the MTC terminal may not normally establish an IP connection with the MTC application server to minimize the use of system resources. If the MTC terminal fails to transmit data to the MTC terminal because the MTC terminal does not establish an IP connection, the MTC terminal may request or instruct the MTC terminal to establish an IP connection, which is called a trigger indication. In other words, MTC terminal triggering is required if the IP address for the MTC terminal is not available or reachable by the MTC application server (that no entity or address of that entity is reachable).
  • the MTC terminal may receive a trigger instruction from the network, and when receiving the trigger instruction, the MTC terminal is required to perform and / or perform an operation of the MTC application in the terminal or establish communication with the MTC application server.
  • the MTC terminal receives the trigger indication, a) when the MTC terminal is offline (not attached to the network), b) the MTC terminal is online but is not established (although attached to the network). Or c) the MTC terminal is online (attached to the network) and a data connection is established.
  • triggering on an MTC terminal may be performed when an IP connection (or PDN connection) is established in which the MTC terminal may receive data from the MTC application server (or the MTC terminal may receive a basic control signal). But user data is not available), use the triggering message
  • the MTC terminal performs the operation of / MTC application in the terminal and / or MTC This operation can be called to perform an IP connection request to an application server.
  • the triggering message may be expressed as a message including information (hereinafter referred to as triggering information) for causing the network to route the message to the appropriate MTC terminal and for the MTC terminal to route the message to an application in the appropriate MTC terminal.
  • the SCS 380 may determine to trigger the MTC terminal (S301). If there is no information on the MTC-IWF to which the SCS connects to make a trigger request, DNS query the DNS 370 using an external identifier of the MTC terminal to be triggered or an identifier of the MTC-IWF set in the SCS. By performing the operation, the IP address and port number of the MTC-IWF can be determined. The SCS 380 then sends a device trigger request message to the MTC-IWF 360 (S302). The device trigger request message may include information as shown in Table 3 below.
  • the MTC-IWF 360 Upon receiving the device trigger request message from the SCS 380, the MTC-IWF 360 performs authority verification on whether the SCS is allowed to send a trigger request to the 3GPP network (S303). If the authorization verification fails, the MTC-IWF 360 sends a device trigger confirmation message to the SCS 380 indicating that the device trigger request has failed. Alternatively, if the authority verification is successful, the next step may be performed.
  • the MTC-IWF 360 sends a Subscriber Information Request message to the HSS / HLR 350 (S304). It checks whether the SCS is an SCS that is allowed to trigger the MTC terminal, obtains IMSI using an identifier (external identifier or MSISDN) of the MTC terminal received in step S302, and serves the serving node serving the MTC terminal. This is to obtain routing information including the identifier of the (serving node).
  • the HSS / HLR 350 checks whether the SCS that sent the device trigger request message is an SCS that is allowed to trigger the MTC terminal (S305). Thereafter, the HSS / HLR 350 transmits a subscriber information response message to the MTC-IWF 360. It serves IMSI and MTC terminal Contains the identifier of the serving node. If the test result does not allow the SCS to trigger the MTC terminal or if there is no valid subscription information related to the MTC terminal in the HSSHLR 350, the HSS / HLR 350 is the MTC-IWF 360. Send a subscriber information answer message including information informing the subscriber. In this case, the MTC-IWF 360 sends a device trigger acknowledgment message indicating that the device trigger request has failed to the SCS 380, and subsequent steps are not performed.
  • the MTC-IWF 360 selects a trigger delivery procedure based on information received from the HSS / HLR 350 and a local policy. (S306a)
  • MTC-IWF 360 performs the T5 trigger forwarding procedure (S306b). A detailed T5 trigger forwarding procedure will be described later with reference to FIG. 4. If the delivery procedure using T4 is selected in step S306a, or if T5 delivery fails as a result of step S306b, MTC-IWF 360 performs a T4 trigger delivery procedure (S306c to 306d). Details of the T4 trigger delivery procedure will be described later with reference to FIG. 5.
  • the MTC-IWF 360 transmits a device trigger report message, which is a response to the device trigger request message of step S302, to the SCS 380 (S307).
  • Device triggers report message indicates whether the requested SCS device triggers the delivery of the results to the MTC terminal or failed the success of the trigger.
  • the UE-1 310 performs an operation based on the contents of the trigger payload (S308). This behavior is typically SCS or
  • Initiate communication with an AS application server.
  • 4 is a diagram for explaining a T5 trigger delivery procedure.
  • the MTC-IWF receives the device trigger request from the SCS in step S302 of FIG. 3, the MTC-IWF selects an appropriate trigger delivery procedure based on the information received from the HSS / HLR and the local policy (steps S304 to FIG. 3 of FIG. 3). S306a).
  • the MTC-IWF goes to SGSN through the T5a interface, to the MME through the T5b interface, and to T5c.
  • the MTC-IWF 440 selects an appropriate serving node.
  • the MTC-IWF 440 transmits a submit request message to the selected serving node 420 (S401).
  • the selected serving node is SGSN, T5a, MME, T5b: or MSC, the submission request message is transmitted.
  • the serving node 420 receiving the submission request message is a UE- which is a target terminal of a device trigger.
  • the trigger message is transmitted to the first 410 (S402).
  • the serving node 420 performing the triggering operation sends a delivery report message to the MTC-IWF 460.
  • the delivery report message indicates whether the trigger delivery to the MTC terminal succeeded or failed as a result of the device trigger requested by the MTC-IWF.
  • 5 is a diagram for explaining a T4 trigger delivery procedure. 5
  • the MTC-IWF 560 includes the device trigger request message received from the SCS 580.
  • a submit trigger message is transmitted to the SMS-SC 540 based on the information and the information included in the subscriber information response message received from the HSS / HLR 550 (S501).
  • the SMS-SC 540 transmits a submission trigger confirmation message to the MTC-IWF 560 acknowledging that it has received the submission trigger message (S502).
  • the short message containing the device trigger message sent by the SMS-SC 540 is delivered to the serving node 520 (S504).
  • the SMS-SC 540 needs to perform an interrogation with the HSS / HLR 550 to obtain the received device trigger message including routing information (information on the serving node). none.
  • the SMS-SC 540 stores necessary information excluding routing information among the information received from the MTC-IWF 560 in case the short message transmission fails.
  • the serving node 520 transmits a short message to the UE-1 510 (S505).
  • the UE- 1 510 may answer the serving node 520.
  • the serving node 520 sends a delivery report message to the SMS-SC 540 (S506).
  • the delivery report message may indicate whether the short message delivery to the MTC terminal succeeded or failed as a result of the short message delivery requested by the SMS-SC. If the short message delivery fails, the SMS-SC 540 acquires routing information for delivering the short message to the UE-1 510 through interrogation with the HSS / HLR 550, and then Retransmission may be performed using the information stored in S504.
  • the SMS-SC 540 sends the MTC-IWF 560 an MTC- A message delivery report message is sent to inform whether the trigger delivery to the MTC terminal is successful or failed as a result of the device trigger requested by the IWF (S507). If the device trigger request operation fails in the above-described MTC trigger procedure, MTC-
  • the IWF can perform a trigger retry. Specifically, if T5 trigger delivery fails, the MTC-IWF may retry the device trigger via the T4 trigger. In addition, even when the T4 trigger procedure is used, the SMS-SC may perform retransmission when the transmission of the short message including the trigger message fails. In addition, the device trigger request is received from the MTC-IWF through the T5 interface. Serving nodes (SGSN, MME, MSC) may also retry when the device trigger operation fails.
  • SGSN, MME, MSC Serving nodes
  • the MTC-IWF transmits a trigger request to a serving node (SGSN, MME, MSC) or SMS-SC
  • a serving node SGSN, MME, MSC
  • SMS-SC SMS-SC
  • the information related to the retry of the trigger request includes information on whether or not to perform the retry when the trigger request delivery fails. If the information indicates to perform the retry, the trigger request retry is performed. Can be delegated to the next node
  • delegation of the trigger request retry means to instruct the next node to deliver the trigger request when the trigger request delivery fails.
  • the next node is a serving node when the MTC-IWF sends a trigger request to the serving nodes (SGSN, MME, MSC), and an SMS-SC when the MTC-IWF sends a trigger request to the SMS-SC.
  • the aforementioned 'retry,' means that the node receiving the device trigger request from the MTC-IWF performs one or more of the following after the trigger operation to the terminal fails. i) A device trigger request that has failed to be transmitted is stored (self-stored or stored in a third node), and the user repeats the trigger operation to the terminal.
  • trigger delivery to the terminal is known to be possible (i.e., when the triggered terminal is available (available or reachable) or when it is possible to perform a device trigger delivery operation) For example, a node may be too busy to perform a device trigger forwarding operation, but the congestion situation may be cleared to allow device trigger forwarding operations.
  • the other node of the network i.e., have another node or a third node perform a trigger retry.
  • the trigger method in the present invention is a device used by MTC-IWF
  • the trigger request can be applied to various cases, such as SMS-based, NAS-based, or user plane-based.
  • the domain to which the MTC terminal belongs may be at least one of a PS domain, a CS domain, and an IMS domain
  • the access network to which the MTC terminal is connected may be at least one of GERAN, UTRAN, E-UTRAN, WLAN, and 3GPP2.
  • MTC-IWF may also be located with the SCS or application server ( C0 -l 0Ca t e ) or a separate node. It may be. Or it may be co-located with other existing network nodes.
  • the role of the MTC-IWF node described below may be performed by another node (eg, an SCS or an application server).
  • Information related to retrying a trigger request may be applied to various cases, such as SMS-based, NAS-based, or user plane-based.
  • the trigger request may be classified into MTC-IWF sending a trigger request to a serving node through the T5 interface or sending an SMS-based trigger request to the SMS-SC through the T4 interface. It may be included in information related to retries. First, it may include information indicating not to perform the retry (or information indicating to perform only one attempt). Information indicating not to perform retries may be included, either explicitly or implicitly. It may also be instructed not to perform the retry by not including the above information. Multiple pieces of information may also indicate not to retry in combination.
  • it may include information indicating to perform a retry (or information indicating to perform a plurality of retries, or information indicating delegation of a retry to a next node).
  • Information indicating that retry is to be performed may be included explicitly or implicitly. You can also instruct that retry be performed by not including this information. Also, a plurality of pieces of information may indicate to perform a retry in combination.
  • MTC-IWF does not include the information indicating to perform the retry (or the information indicating to perform a number of attempts), but only triggers the device by including the number of retries set to greater than 0 or the number of attempts set to greater than 1 You can also send a request to the next node.
  • This number of retries (or number of attempts) implies that retries should be performed.
  • the MTC-IWF does not include information indicating that it will not perform a retry (or information indicating that one attempt will be performed), but includes only the number of retries set to 0 or the number of attempts set to 1 to request a device trigger request. You can also send it to the next node. This number of retries (or number of attempts) has a meaning indicating that no retries will be performed.
  • the retry allow / valid time value is determined by MTC-IWF. It may be based on a Validity time or Validity period value received from the SCS. At this time, the retry allowance time may be set equal to the allowable time value received from the SCS, or the retry allowance time may be set to a value smaller than the valid time value received from the SCS.
  • the MTC-IWF will determine the configured values (based on operator policy, values previously obtained from the SCS, etc.) and / or network conditions (eg congestion).
  • the retry allowance time may be set based on the above.
  • MTC-IWF does not include information indicating not to perform retries (or information indicating to perform one attempt), but only includes a retry allowance time (or attempt allow time) set to 0 to follow a device trigger request. You can also send it to a node. A retry allowance time (or attempt allowance time) set to 0 indicates that no retry should be performed. In addition, the MTC-IWF does not include information indicating to perform the retry (or information indicating to perform a plurality of attempts), and includes only a retry allowance time (or an attempt allowance time) set to a non-zero value. You can also send a device trigger request to the next node.
  • the SMS-SC When the MTC-IWF sends an SMS-based trigger request to the SMS-SC via the T4 interface, use a field in the SMS message to define the above information, define a new field, or use a device trigger request. You can use the newly defined fields for new messages defined for this purpose (such as messages that encapsulate SMS messages).
  • the retry allowance time is not a retry attempt, the SMS—SC triggers a device triggered action for reasons such as network congestion. Even in the case of a defer (i.e., postponing the device triggering action until network congestion is eliminated), it is applicable.
  • the MTC-IWF sends the device trigger operation. Inform failure.
  • the MTC-IWF may have received a trigger request from the MTC server.
  • the information related to the retry of the trigger request may further include the following information.
  • the SGSN may include information indicating that retry is performed by sending a device trigger request to the MME and to the SGSN for the MME.
  • the information may mean or include address information of the partner node.
  • SGSN and MSC e.g. Gs or Sv
  • partner node i.e. to MSC for SGSN and SGSN for MSC.
  • the partner node i.e. to the MSC for the MME and to the MME for the MSC.
  • the above information i.e., information indicating to perform a retry with another serving node, is either explicit or It may be implicitly included. Also, by not including the above information, it may be instructed to perform retry to another serving node. In addition, a plurality of pieces of information may instruct to perform a retry to another serving node in combination.
  • the information related to the retry includes both the retry count and the retry allowance time information, and the device trigger request for which the retry failed to be transmitted is stored (self-stored or stored in a third node). If it means that the trigger operation is performed again, if one of the retry count and the retry allowance time is exceeded, the node receiving the device trigger request from the MTC-IWF no longer performs the trigger operation to the terminal. The device trigger request stored with this can be deleted.
  • the information related to the retry includes both the retry count and the retry allowance time information, and indicates that there is a trigger to be transmitted to the terminal due to the failure of the retry attempt (or the information that a trigger is in progress).
  • the node receiving the device trigger request from MTC-IWF deletes the information that there is a trigger to be delivered to the stored terminal. .
  • a message informing that the stored request is to be deleted when another node or a third node has previously performed to store it can be sent.
  • the MSC, SGSN or MME has delayed the device trigger action (i.e., defer the device trigger action until the network congestion is resolved). That is, in this case, if it is possible to perform the device trigger operation before the retry allow time expires, if the device retrieval time has expired and it is still impossible to perform the device trigger action, the device triggers the MTC-IWF. Notify of failure.
  • the above-described information related to the retry may be applied to the case of performing the retry as well as the case of performing the trigger request for the first time.
  • the MTC-IWF triggered request is transmitted together with the retry information as described above. If the device trigger operation is not successful, the device trigger retry may be applied. This will be described below.
  • the retry may be performed through the same node as the node that sent the previous trigger request or may be performed through another node.
  • the retry may be referred to as fallback mode. Can be.
  • MTC-IWF to SGSN, MME or MSC via T5a, T5b or T5c interface If a device trigger request was sent and the transmission failed, then the MTC-IWF pointed to the next node to perform the retry, then the next node sends another failed device trigger request to another node in the network. You can let 's node save it. Alternatively, if it is known that trigger transmission to the terminal is enabled, an operation of notifying the other node of the network may be performed (this operation may cause the other node or a third node to perform the trigger retry). .
  • the trigger storage request to another node or to a third node may include three cases of SMS-SC, MTC-IWF, and HSS / HLR, each of which describes the operation.
  • a device trigger request for which transmission failed at the SMS-SC or a third storage node managed by the SMS-SC.
  • Serving node that failed device trigger transmission ie, SGSN / MME / MSC
  • Additional information for example, the address of the serving node, the number of attempts to transmit itself, and whether the device trigger request message is in the form of SMS may be transmitted to the SMS-SC.
  • the SMS-SC may send a response to the device trigger storage request message received from the serving node.
  • the exchange of messages between the serving node and the SMS-SC may be performed directly in the form of 'serving node vs. SMS-SC' if there is a direct interface with each other, or in the form of 'Training node vs. MTC-IWF vs SMS-SC'. It may be done through the T5b / T5c and the T4 interface, or may be in the form of 'serving node vs. SMS-GMSC (or SMS-IWMSC) vs. SMS-SC.
  • the serving node In addition to the above cases, the serving node,
  • SMS-SC or intermediate node goes to terminal because trigger action fails on HSS / HLR
  • a request may be made to set the information that there is a trigger to be delivered.
  • SMS-SC is for a device that requested the storage trigger, the trigger being transmitted to the mobile station becomes possible to i) the serving node is sending a message to the SMS-SC indicating becomes possible to trigger transmission of the terminal (the serving node and the SMS Message exchange between the SCs), and ii) the HSS / HLR sends a message informing the SMS-SC that the trigger delivery to the UE is enabled.
  • SMS-SC can subscribe to the terminal-related information notification service provided by HSS / HLR.
  • the MTC-IWF which finds that trigger transmission to the terminal is enabled, sends a message informing the SMS-SC (message exchange between the MTC-IWF and the SMS-SC). It can be known through at least one of.
  • the SMS-SC is aware that the trigger transmission to the terminal is possible, i) the device trigger request message stored in itself or a third node, i) the SMS-SC sends the device trigger request message directly to the serving node and the serving The node forwards the device trigger request message to the terminal.
  • the serving node may be a serving node that has requested to store a corresponding device trigger request message or may be another serving node.
  • the serving node to which the device trigger request message is transmitted may be a serving node informing that the terminal triggered by the SMS-SC is available.
  • the SMS-SC transmits the device trigger request message in the SMS form to the SMS-GMSC according to the SMS method and delivers it to the terminal through the path through which the SMS is delivered; iii) the SMS-SC sends the device trigger request message to the MTC-IWF.
  • MTC-IWF forwarded and received is T5a / T5b / T5c Transmission to the terminal through at least one or more of the transmission to the terminal through the interface.
  • the MTC-IWF (or a third storage node managed by MTC-IWFo) may store a device trigger request for which transmission failed.
  • the serving node ie SGSN / MME / MSC
  • the serving node sends the device trigger request message that failed transmission to MTC-IWF for storage.
  • the MTC-IWF may continue to have the device trigger request message until the MTC-IWF receives a successful response from the serving node.
  • the serving node is sent to the MTC-IWF indicating that the device trigger request message has failed.
  • the answer may mean that the MTC-IWF keeps storing the device trigger request message.
  • Message exchange between the serving node and the MTC-IWF is done through the T5a / T5b / T5c interface.
  • a step of additionally requesting the serving node or the MTC-IWF to set information indicating that a trigger to be delivered to the UE exists due to a failure of a trigger operation in the HSS / HLR may be performed.
  • MTC-IWF is the device trigger to request the storage.
  • the serving node sends a message to the MTC-IWF indicating that the trigger can be delivered to the terminal (message exchange between the serving node and the MTC-IWF), ii) The trigger to the terminal.
  • the HSS / HLR sends a message to the MTC-IWF informing it that delivery is possible.
  • the HSS / HLR may provide the MTC-IWF with information about a serving node necessary for retrying trigger delivery.
  • MTC-IWF provides UE-related information provided by HSS / HLR. Can subscribe to a notification service).
  • MTC-IWF When MTC-IWF finds that trigger transmission to UE is possible, i) MTC-IWF requests device trigger to serving node using T5a / T5b / T5c interface. Sending a message and the serving node receiving the message forwards the device trigger request message to the terminal, where the serving node may be a serving node that requested to store the device trigger request message (or informed that the transmission failed) or another serving.
  • the serving node to which the device trigger request message is transmitted may be a serving node that informs the MTC-IWF that the terminal triggered is available, which means that the T4 interface does not exist in the MTC network or the T4 interface is present.
  • the MTC-IWF sends a device trigger request message to the SMS-SC via the T4 interface and the SMS-SC forwards to the terminal through the path through which the SMS is delivered (in this case, the device trigger request to the SMS-SC).
  • additional information a serving node that informs that the terminal triggered by the MTC-IWF may be delivered together
  • the device triggered request for transmission failure may be stored in the HSS / HLR (or a third storage node managed by the HSS / HLR).
  • the serving node ie SGSN / MME / MSC
  • the serving node that failed device trigger transmission sends the device trigger request message that failed transmission to HSS / HLR.
  • additional information may be transmitted to the HSS / HLR (for example, the address of the serving node, the number of attempts by the sender, Whether the trigger request message is in the form of SMS, etc.) may be delivered together.
  • the HSS / HLR may send a response to the device trigger storage request message received from the serving node.
  • Message exchange between the serving node and the HSS / HLR takes the form of a serving node to HSS / HLR through a direct interface.
  • the HSS / HLR sends the trigger to the terminal for the device trigger that is requested to be stored.
  • the serving node sends a message to the HSS / HLR indicating that the trigger can be delivered to the terminal (a serving node and the HSS / Message exchange between HLR), and ii) MTC-IWF that knows that trigger delivery to the UE is possible, sends a message informing HSS / HLR] (message exchange between MTC-IWF and HSS / HLR). This can be seen through.
  • the HSS / HLR When the HSS / HLR learns that the trigger can be delivered to the UE, the HSS / HLR sends a device trigger request message stored in itself or a node of the node. I) The HSS / HLR sends the device trigger request message directly to the serving node and receives the serving trigger. The node forwards the device trigger request message to the terminal, where the serving node may be the serving node that requested to store the corresponding device trigger request message or another serving node. In addition, the device trigger request message is transmitted.
  • the serving node may be a serving node that informs the HSS / HLR that the terminal triggered is available), ii) the HSS / HLR delivers a device trigger request message to the MTC-IWF, and the MTC-IWF receives the T5a / Transmit to the terminal via T5b / ⁇ 5c interface at least one or more ways to the terminal.
  • Example 2 of action when the trigger transmission fails The MTC-IWF has sent a device trigger request to SGSN or MME or MSC over the T5a or T5b or T5c interface and the transmission has failed and the device trigger request has been sent to the SMS-SC over the T4 interface and the transmission has failed.
  • the MTC-IWF saves the failed device trigger request or requests the other node to save it, and additionally, it is possible to forward the trigger to the terminal. If not, the node storing the MTC-IWF or the device trigger request message may perform the trigger retry.
  • Another node or a third node trigger request may be three examples of SMS-SC, MTC-IWF, and HSS / HLR, each of which describes the operation.
  • an SMS-SC (or a third storage node managed by the SMS-SC) may store a device trigger request for which transmission failed.
  • the MTC-IWF When the MTC-IWF receives a transmission failure response message from a serving node (ie, SGSN / MME / MSC) that has failed device trigger transmission, the MTC-IWF sends a device trigger request message that failed to be transmitted to the SMS-SC for storage.
  • a serving node ie, SGSN / MME / MSC
  • the MTC-IWF sends a device trigger request message that failed to be transmitted to the SMS-SC for storage.
  • additional information for example, the address of the failed transmission node s, the number of transmission attempts, and whether the device trigger request message is in the form of SMS
  • the SMS-SC may send a response to the device trigger storage request message received from the MTC-IWF.
  • IWF In the form of IWF vs. SMS-SC.
  • MTC-IWF or SMS-SC In addition, MTC-IWF or SMS-SC
  • the trigger that should be delivered to the terminal because the trigger action failed in the HSS / HLR A request may be made to set information that exists.
  • the SMS-SC sends a trigger message to the terminal for the device trigger that is requested to be stored.
  • the serving node sends a message to the SMS-SC indicating that the trigger can be delivered to the terminal (a serving node and an SMS-).
  • Message exchange between SCs ii) the HSS / HLR that knows that the trigger delivery to the UE is possible, sends a message informing the SMS-SC.
  • SMS-SC can subscribe to terminal-related information notification service provided by HSS / HLR
  • the MTC-IWF which has learned that the trigger delivery to the UE can be transmitted, may send a message informing the SMS-SC (message exchange between the MTC-IWF and the SMS-SC).
  • SMS knows that trigger delivery to the UE is possible—the SC sends a device trigger request message stored on itself or a third node to: i) the SMS-SC directly sending the device trigger request message to the serving node and receiving it.
  • the node forwards the device trigger request message to the terminal (wherein the serving node to which the device trigger request message is transmitted may be a serving node that informs the SMS-SC that the terminal triggered is available), ii) the SMS-SC Send SMS-GMSC device trigger request message to SMS-GMSC according to SMS method and send it to UE through the path through which SMS is delivered.
  • MTC delivers the device trigger request message to MTC-IWF and receives it.
  • the IWF is delivered to the terminal through the T5a / T5b / T5c interface (in this case, the SMS-SC stores the MTC-IWF in response to a message indicating that the terminal triggered by the SMS-SC becomes available).
  • Device trigger request message can be sent to MTC-IWF)
  • the MTC-IWF (or a third storage node managed by the MTC-IWF) may store a device trigger request for which transmission failed.
  • the serving node i.e., SGSN / MME / MSC
  • receives a transmission failure message from ungdap and stores the failed transmission device trigger request message.
  • the exchange of messages between the serving node and the MTC-IWF takes place via the T5a / T5b / T5c interface.
  • the serving node or " MTC-IWF may be requested to set the information that there is a trigger to be delivered to the terminal due to the failure of the trigger operation in the HSS / HLR may be performed.
  • the MTC-IWF sends a trigger to the terminal for the device trigger being stored.
  • the serving node sends a message to the MTC-IWF indicating that the trigger can be delivered to the terminal (that is, the triggered terminal is available. Available or reachable or able to perform device trigger propagation actions (e.g., a node is congested and unable to perform device trigger propagation actions, and then the device is able to perform a device trigger propagation action. Etc.), the exchange of messages between the serving node and the MTC-IWF), and ii) the HSS / HLR that knows the trigger delivery to the UE is able to send a message informing the MTC-IWF.
  • the HSS / HLR may provide the MTC-IWF with information about a serving node necessary for retrying trigger delivery.
  • the MTC-IWF may subscribe to a terminal-related information notification service provided by the HSS / HLR.
  • the triggered terminal is available (available or reachable) or the serving node is able to perform the device trigger forwarding operation.
  • a node may not be able to perform a device triggered hold operation, but a shake situation may be released to perform a device triggered transfer operation, etc.).
  • MTC-IWF When MTC-IWF finds that trigger transmission to UE is possible, i) MTC-IWF requests device trigger to serving node using T5a / T5b / T5c interface.
  • the serving node transmitting the message transmits the device trigger request message to the terminal (in this case, the serving node may be a serving node or another serving node that has informed the transmission failure of the device trigger request message.)
  • the serving node to which the device trigger request message is transmitted may be a serving node informing the MTC-IWF that the terminal triggered is available
  • the MTC-IWF sends the device trigger request message to the SMS-SC through the T4 interface.
  • SMS-SC to the terminal through the path through which the SMS is delivered (at this time additional information (e.g., when sending a device trigger request message to the SMS-SC).
  • additional information e.g., when sending a device trigger request message to the SMS-SC.
  • a serving node that informs the MTC-IWF that the terminal is available may be delivered together).
  • the HSS / HLR (or a third storage node managed by the HSS / HLR) can store a device trigger request for which transmission failed.
  • the MTC-IWF can serve a serving node for which a device trigger transmission has failed (i.e., SGSN / MME / Upon receipt of the transmission failure response message from MSC), and "ever saved to send the device trigger request failed message sent to HSS / HLR.
  • additional information is transmitted to the HSS / HLR (for example, the address of the failed serving node, the number of transmission attempts, and the device trigger request message is sent to the SMS Form, etc.) may be conveyed together.
  • the HSS / HLR may send a response to the device trigger store request message received from the MTC-IWF.
  • Message exchange between MTC-IWF and HSS / HLR takes the form of MTC-IWF to HSS / HLR through a direct interface.
  • the HSS / HLR sends the trigger to the terminal for the device trigger that is requested to be stored.
  • the serving node sends a message to the HSS / HLR indicating that the trigger can be delivered to the terminal (a serving node and the HSS / Message exchange between HLR), and ii) MTC-IWF that knows that trigger delivery to the UE is possible, sends a message informing the HSS / HLR (message exchange between MTC-IWF and HSS / HLR). Able to know.
  • the HSS / HLR When the HSS / HLR learns that the trigger can be delivered to the UE, the HSS / HLR sends the device trigger request message stored in itself or a third node to the serving node. Transmits the device trigger request message to the UE (wherein the serving node to which the device trigger request message is transmitted may be a HSS / HLR) may be a serving node indicating that the UE to be triggered is available) ii) HSS / HLR is MTC The device trigger request message is transmitted to the IWF and the MTC-IWF receiving the message is transmitted to the terminal through the T5a / T5b / T5c interface (in this case, the MTC-IWF is transmitted to the HSS / HLR indicating that the terminal triggered is available.
  • the device trigger request message stored by the HSS / HLR can be sent to the MTC-IWF), and iii) the HSS / HLR sends the device trigger request message to the SMS-SC and receives the received SMS.
  • the SC transmits to the terminal in at least one or more ways through the SMS transmission path to the terminal.
  • a trigger (or a short message including a trigger message) that network nodes such as MME / SGSN / MSC, MTC-IWF, HSS / HLR, and SMS-SC should be delivered to the terminal due to a failed trigger operation
  • network nodes such as MME / SGSN / MSC, MTC-IWF, HSS / HLR, and SMS-SC
  • an identifier for the terminal as illustrated below can be used. have.
  • the identifier for the terminal may be as shown in Table 5 below.
  • Trigger Refnum refers to the corresponding trigger that MTC Server sets when sending a device trigger request to MTC-IWF
  • SCSID sending device trigger request vi) SCS / Application domain name
  • the identifier is not limited to the above example, and any information can be used as long as it can identify the triggered terminal.
  • ' two or more combinations can be used to distinguish the terminal triggered.
  • different items may be used according to network nodes.
  • the HSS / HLR storing information that a trigger (or short message including a trigger message) exists may use IMSI, and the MTC-IWF storing a device trigger request message may use an external identifier.
  • MTC-IWF a method of performing a retransmission after storing a device trigger request that failed to be transmitted in the MTC-IWF (or a third storage node managed by the MTC-IWF) and a third method managed by the MTC-IWF (or MTC-IWF)
  • MTC- The IWF can utilize various interfaces such as T5a, T5b, T5c, and T4 interfaces to perform retransmission.
  • a trigger mechanism of the form cell broadcast
  • Trigger Procedure Example 1 refers to a case in which information related to retry instructs execution of a retry, that is, delegates retry to a serving node, and the description of FIG. 7 relates to retry. This is the case where the information indicates not to perform retries. Details that are not specifically described in the following examples may be replaced by the foregoing descriptions. In addition, the present invention is not limited to the following exemplary trigger procedures, and is derived from the descriptions and the foregoing descriptions. It will be apparent to those skilled in the art that other examples which may be included are within the scope of the present invention. Trigger Procedure Example 1
  • the SCS 680 determines to trigger the MTC terminal. If there is no information on the MTC-IWF that the SCS contacts to make a trigger request, the MTC may perform a DNS query to the DNS 670 by using an external identifier of the MTC terminal to be triggered or an identifier of the MTC-IWF set in the SCS. -You can determine the IP address and port number of the IWF.
  • the SCS 680 sends a device trigger request message to the MTC-IWF 660.
  • the device trigger request message may include information as shown in Table 6 below.
  • step S603 upon receiving the device trigger request message from the SCS 680, the MTC-IWF 660 performs authority verification on whether the SCS is allowed to send a trigger request to the 3GPP network. If the authorization verification fails, the MTC-IWF 660 sends a device trigger acknowledgment message to inform the SCS 680 that the device trigger request has failed. If the authority verification succeeds, the following step S604 is performed.
  • step S604 the MTC-IWF 660 sends a subscriber information request message to the HSS / HLR 650. This means that SCS is allowed to trigger the MTC terminal
  • step S605 the HSS / HLR 650 is allowed to trigger the MTC terminal SCS sending the device trigger request message Check for SCS.
  • the HSS / HLR 650 then sends a Subscriber Information Answer message to the MTC-IWF 660.
  • This message includes the identity of the serving node serving the IMSI and MTC terminal.
  • the HSS / HLR 650 may perform the MTC-IWF.
  • the subscriber information response message including the information informing the 660 is transmitted.
  • the MTC-IWF 660 sends an SCS 680 a device trigger acknowledgment message indicating that the device trigger request has failed, and subsequent steps are not performed.
  • the MTC-IWF 660 selects a trigger answering procedure based on the information received from the HSS / HLR 650 and the local policy.
  • the available serving nodes are SGSN and MME, and it is assumed that the MTC-IWF 660 selects device trigger delivery to the MME using the T5b interface as the trigger delivery procedure.
  • the MTC-IWF 660 transmits a submit request message to the MME 630.
  • the MTC-IWF 660 may include information necessary for device trigger received from the SCS 680 in step 2 as it is or in a processed form in the submission request message.
  • the MTC-IWF 660 may include information indicating that the MME performs retry by sending a device trigger request to SGSN when the device trigger operation fails. In addition, information about the number of retries may be included. It may also include information about the retry allowance time.
  • step S608 the MME 630 that receives the submission request message is the device trigger
  • the trigger message is to be delivered to the target terminal UE-1 610.
  • this delivery may fail, for example, if UE-1 is not reachable, MME is overloaded, or the E-UTRAN network is congested. If delivery fails, the process proceeds to next step S609.
  • the MME 630 performs a retry by sending a trigger request message to the SGSN 620 based on the retry related information received from the MTC-IWF 660.
  • the trigger request message may include information required for the device trigger received by the MME 630 from the MTC-IWF 660 as it is or in a processed form.
  • the MME 630 may include information necessary for itself (for example, cause of delivery failure, MTC-IWF related information, etc.).
  • step S610 the SGSN 620 receiving the trigger request message transmits a trigger message to UE-1 610, which is a target terminal of a device trigger.
  • the UE- 1 610 responds to the SGSN 620.
  • the SGSN 620 that performs the trigger operation sends a trigger answer message to the MME 620.
  • the trigger response message includes the result of the device trigger requested by the MME (whether the trigger delivery to the MTC terminal succeeded or failed).
  • step 612 the MME 630 receiving the trigger response message sends a delivery report message to the MTC-IWF 660.
  • the delivery report message includes the result of the device trigger requested by the MTC-IWF (that is, whether the trigger delivery to the MTC terminal succeeded or failed).
  • the MTC-IWF 660 transmits a device trigger report message, which is a response to the device trigger request message, to the SCS 680.
  • the device trigger report message indicates the result of the device trigger requested by the SCS (either successful or failed trigger delivery to the MTC terminal).
  • the UE-1 610 performs an operation based on the contents of the trigger payload in response to the device trigger received in S614. This operation typically involves initiating communication with the SCS or AS.
  • step S611 of the above-described description after the SGSN 620 performs the device trigger message transfer operation to the MTC ' terminal, the MME 630 gives a reply, and the MME 630 receiving the response receives the MTC-IWF in step S612. (660) was answered.
  • the SGSN 620 may send a message (for example, a delivery report message) including the delivery result to the MTC-IWF 660.
  • the SGSN 620 may further include a step of immediately sending a ACK message indicating that the MME 630 has been well received.
  • MTC-IWF performs a direct retransmission operation.
  • step S701 the SCS 780 determines to trigger the MTC terminal. If there is no information on the MTC-IWF that the SCS contacts to make a trigger request, the MTC performs a DNS query to the DNS 770 by using an external identifier of the MTC terminal to be triggered or an identifier of the MTC-IWF set in the SCS. -Of IWF
  • step S702 the SCS 780 is MTC-
  • the device trigger request message is It may include information as shown in Table 6 above.
  • step S703 the MTC-IWF 760 having received the device trigger request message from the SCS 780 performs an authority verification as to whether the SCS is allowed to send a trigger request to the 3GPP network. If the authorization verification fails, the MTC-IWF 760 sends a device trigger acknowledgment message to inform the 5 SCS 780 that the device trigger request has failed. Otherwise, if the authority verification succeeds, step S704 is performed. In step S704, the MTC-IWF 760 sends a subscriber information request message to the SS / HLR 750. It checks whether the SCS is an SCS that is allowed to trigger the MTC terminal, and performs IMSI using the identifier (external identifier or MSISDN) of the received MTC terminal.
  • step S705 the HSS / HLR 750 checks whether the SCS that sent the device trigger request message is the SCS that is allowed to trigger the MTC terminal. The HSS / HLR 750 then transmits a subscriber information answer message to the MTC-IWF 760. The subscriber information answer message serves the IMSI and the MTC terminal.
  • the HSS / HLR 750 may call the MTC-IWF 760. In this case, the MTC-IWF 760 notifies the SCS 780 that the device trigger request has failed.
  • step S706 the MTC-IWF 760 receives information and region received from the HSS / HLR 750. Select the trigger forwarding procedure based on the policy.
  • the MTC-IWF 760 selects device trigger delivery to the MME using the T5b interface as the trigger delivery procedure.
  • the MTC-IWF 760 transmits a submission request message to the MME 730.
  • the MTC-IWF 760 may include information necessary for the device trigger received from the SCS 780 in step S702 as it is or in a processed form in the submission request message.
  • the MTC-IWF 760 also includes information in the submission request message indicating that the MME should not retry when the device trigger operation fails.
  • step S708 the MME 730 that has received the submission request message intends to deliver a trigger message to the UE- 1 710 which is a target terminal of the device trigger.
  • UE-1 may be unreachable, the MME may be overloaded, the E-UTRAN network may be congested, and the like may fail.
  • the trigger operation may be performed.
  • the MME 730 sends a delivery report message to the MTC-IWF 760.
  • the delivery report message includes the result of the device trigger requested by the MTC-IWF (whether the trigger delivery to the MTC terminal succeeded or failed).
  • step S710 the MTC-IWF 760 receiving the delivery report message indicating that the trigger delivery to the MTC terminal has failed in step S709 sends a subscriber notification message to the HSS / HLR 750, Subscribe to the terminal-related information notification service provided by the HSS / HLR (750).
  • External identifier, MSISDN to indicate the MTC terminal (or subscriber to which the MTC terminal belongs) subscribes to the notification service
  • One or more of the IMSIs Information may be used.
  • the MTC-IWF 760 does not perform a retry to the SMS-SC using the T4 interface.
  • the information at least one of the information listed in the table 7 can be used.
  • the following information may be set in the MTC-IWF or obtained from other nodes such as HSS / HLR, MME, SGSN, MSC, and SMS-SC.
  • the MTC-IWF may determine to perform step S710 (that is, store and forward operation) instead of immediately retrying the T4 interface after the trigger transmission failure by using the T5 interface.
  • V network variability (core network, radio network, ⁇ 5 interface, T4 interface arc);
  • T4 T5 trigger delivery history (failure rate, etc.)
  • HSS / HLR 750 can obtain information haejyeotdaneun possible to trigger transmission to the MTC terminal from the serving node, or another node eu step>
  • HSS / HLR (750) is MTC-
  • a Notify Subscriber Information message is transmitted to inform the IWF 760 that trigger delivery to the MTC terminal is enabled.
  • This message may additionally include various information that the MTC-IWF 760 needs for the device triggering operation (eg, an identifier of a serving node serving the MTC terminal).
  • the MTC-IWF 760 selects a trigger forwarding procedure based on information received from the HSS / HLR 750 and local policy. In the following, it is assumed that the available serving node is SGSN, so the MTC-IWF 760 selects device trigger delivery to SGSN using the T5a interface as the trigger delivery procedure. Alternatively, however, the MTC-IWF 760 may select device trigger delivery to the SMS-SC using the T4 interface. Alternatively, if the available serving nodes are MME and SGSN, MTC-IWF 760 may select device trigger delivery to MME using T5b interface as the trigger delivery procedure.
  • the MTC-IWF 760 transmits a submission request message to the SGSN 720.
  • the MTC-IWF 760 may include information necessary for the device trigger received from the SCS 780 in step 2 in the submission request message as it is or in a processed form.
  • the MTC-IWF 760 includes information in the submission request message indicating that the SGSN should not retry when a device trigger operation fails.
  • step S714 the SGSN 720 that receives the submit request message is sent to the device trigger.
  • the trigger message is transmitted to the UE-1 710 which is another terminal.
  • the UE- 1 710 responds to the SGSN 720.
  • the SGSN 720 that performs the trigger operation sends a delivery report message to the MTC-IWF 760.
  • the delivery report message includes the result of the device trigger requested by the MTC-IWF (whether the trigger delivery to the MTC terminal succeeded or failed).
  • the MTC-IWF 760 is
  • the SCS 780 sends a device trigger report message, which is a response to the device trigger request message of step S702.
  • the device trigger report message includes the result of the device trigger requested by the SCS (whether the trigger delivery to the MTC terminal succeeded or failed).
  • the UE-1 7.10 performs an operation based on the contents of the trigger payload. This operation typically involves initiating communication with the SCS or AS.
  • the MTC-IWF 760 responds to the device trigger delivery failure from the MME.
  • the device trigger operation may be retried by sending a submit request to SGSN.
  • the MTC-IWF 760 performs the step.
  • step S710 after receiving a voice response message indicating a device trigger delivery failure from the MME, step S710 may be performed. These decisions include local policy, priority information of trigger request, network status, MTC-IWF status, T5 ⁇ / T5b / T5c interface status, subscriber information, MTC terminal roaming status, and MTC-IWF. Settings, terminal It may be based on various information such as availability and reachability to the terminal. In addition, in step S710, retrying to the SMS-SC using the T4 interface was not performed.
  • Step S709 Retrying to the SMS-SC is performed using the T4 interface, which may also fail and perform step S7i0.
  • the MTC-IWF may include information indicating not to retry the information related to the retry in order not to delegate retransmission to the SMS-SC. Items described in the various embodiments of the present invention described above may be applied independently or two or more embodiments may be applied at the same time.
  • 8 is a diagram illustrating a configuration of a preferred embodiment of a terminal device and a network node device according to an example of the present invention.
  • the MTC-IWF apparatus 810 may include transmit / receive modules 811, a processor 812, and a memory 813.
  • the transmit / receive modules 811 transmit various signals, data, and information to an external device (network node 820 and / or a server device (not shown)), and transmit an external device (network node 820 and / or server device ( May be configured to receive various signals, data and information).
  • the processor 812 may control the overall operation of the MTC-IWF 810, and may be configured to perform a function of processing the MTC-IWF 810 to process information to be transmitted / received with an external device.
  • the memory 813 may store the processed information and the like for a predetermined time, It may be replaced by a component such as a buffer (not shown).
  • the processor of the MTC-IWF 810 transmits information related to the trigger request and retry of the trigger request to a serving node, and the information related to the trigger request retry is Includes information on whether retry is performed when a trigger request transmission fails, and when the information on whether retry is performed indicates that retry is performed, the trigger request retry may be delegated to the first serving node.
  • the specific configuration of the MTC-IWF 810 as described above may be implemented so that the above-described matters described in various embodiments of the present invention can be applied independently or two or more embodiments are applied at the same time, overlapping content is clarity The description is omitted for the sake of brevity.
  • Embodiments of the present invention described above may be implemented through various means.
  • embodiments of the present invention may be implemented by hardware, firmware, software, or a combination thereof.
  • a method according to embodiments of the present invention may include one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), and Programmable Logic Devices (PLDs). Field programmable gate arrays (FPGAs), 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.
  • a method according to embodiments of the invention may be a module, procedure or function for performing the function or operation described above. It may be implemented in the form of.
  • the software code may be stored in a memory unit and driven by a processor.
  • the memory unit may be located inside or outside the processor, and may exchange data with the processor by various known means.
  • Embodiments of the present invention as described above may be applied to various mobile communication systems.

Landscapes

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

Abstract

본 발명의 일 실시예는, 무선통신시스템에서 MTC-IWF(InterWorking Function)가 MTC(Machine Type Communication) 트리거 요청을 수행하는 방법에 있어서, 제1 서빙노드에 상기 트리거 요청 및 상기 트리거 요청의 재시도에 관련된 정보를 전송하는 단계를 포함하며, 상기 트리거 요청 재시도에 관련된 정보는, 상기 트리거 요청 전송 실패시 재시도 수행 여부에 대한 정보를 포함하며, 상기 재시도 수행 여부에 대한 정보가 재시도 수행을 지시하는 경우 상기 트리거 요청 재시도는 상기 제1 서빙노드에게 위임되는, 트리거 요청 수행 방법이다.

Description

【명세서】
【발명의 명칭】
무선 통신 시스템에서 MTC 트리거 (TRIGGER) 방법 및 장치
【기술분야】
이하의 설명은 무선 통신 시스템에 대한 것으로 > 보다 상세하게는
MTC(Machine Type Communications) 트리거링을 수행 또는 지원하는 방법 및 장치에 대한 것이다.
【배경기술】
MTC(Machine Type Communications)는 하나 이상의 머신 (Machine)이 포함되는 통신 방식을 의미하며, M2M(Machine-to-Machine) 통신이나 사물 통신으로 칭하여지기도 한다. 여기서, 머신이란 사람의 직접적인 조작이나 개입을 필요로 하지 않는 개체 (entity)를 의미한다. 예를 들어， 이동 통신 모들이 탑재된 검침기 (meter)나 자동 판매기와 같은 장치는 물론， 사용자의 조작 /개입 없이 자동으로 네트워크에 접속하여 통신을 수행할 수 있는 스마트폰과 같은 사용자 기기도 머신의 예시쎄 해당할 수 있다. 이러한 머신의 다양한 예시들을 본 문서에서는 MTC 단말 (device) 또는 단말이라고 칭한다. 즉, MTC는 사람의 조작 /개입 없이 하나 이상의 머신 (즉, MTC 단말)에 의해서 수행되는 통신을 의미한다.
MTC는 MTC 단말 간의 통신 (예를 들어, D2D(Device-to-Device) 통신)， MTC 단말과 MTC 애플리케이션 서버 (application server) 간의 통신을 포함할 수 있다.
MTC 단말과 MTC 애플리케이션 서버 간의 통신의 예시로, 자동 판매기와 서버,
POS(Point of Sale) 장치와 서버, 전기, 가스 또는 수도 검침기와 서버 간의 통신을 들 수 있다. 그 외에도 MTC에 기반한 애플리케이션 (application)에는, 보안 (security) 운송 (transportation), 헬스 케어 (health care) 등이 포함될 수 있다.
【발명의 상세한 설명】
【기술적 과제】
본 발명에서는 MTC 단말에 대한 트리거링을 정확하고 효율적으로 수행하는 방안을 제공하는 것을 기술적 과제로 한다.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
【기술적 해결방법】
본 발명의 제 1 기술적인 측면은, 무선통신시스템에서 MTC- IWF(Inter Working Function)가 MTC(Machine Type Communication) 트리거 요청을 수행하는 방법에 있어서, 제 1 서빙노드에 상기 트리거 요청 및 상기 트리거 요청의 재시도에 관련된 정보를 전송하는 단계를 포함하며, 상기 트리거 요청 재시도에 관련된 정보는， 상기 트리거 요청 전송 실패시 재시도 수행 여부에 대한 정보를 포함하며， 상기 재시도 수행 여부에 대한 정보가 재시도 수행을 지시하는 경우 상기 트리거 요청 재시도는 상기 제 1 서빙노드에게 위임되는， 트리거 요청 수행 방법이다.
본 발명의 게 2 기술적인 측면은, 무선통신시스템에서 MTC(Machine Type
Communication) 트리거 요청을 수행하는 MTC-IWF(InterWorking Function) 장치에 있어서， 송수신 모들; 및 프로세서를 포함하며, 상기 프로세서는, 제 1 서빙노드에 상기 트리거 요청 및 상기 트리거 요청의 재시도에 관련된 정보를 전송하며, 상기 트리거 요청 재시도에 관련된 정보는, 상기 트리거 요청 전송 실패시 재시도 수행 여부에 대한 정보를 포함하며, 상기 재시도 수행 여부에 대한 정보가 재시도 수행을 지시하는 경우 상기 트리거 요청 재시도는 상기 제 1 서빙노드에게 위임되는, MTC-IWF 장치이다.
본 발명의 제 1 내지 제 2 기술적인 측면은 다음 사항들을 포함할 수 있다. 상기 트리거 요청 재시도에 관련된 정보는, 가용한 서빙노드의 개수, 네트워크 흔잡 상황, 상기 MTC 단말의 선호도， MTC 단말의 로밍 여부 증 적어도 하나 이상을 고려하여 결정될 수 있다.
상기 트리거 요청 재시도의 위임은， 상기 트리거 요청 전달 실패시 상기 제 1 서빙노드에게 제 2 서빙노드로 상기 트리거 요청을 전달하도록 지시함을 의미할 수 있다. 여기서, 상기 제 1 서빙노드가 단말에게 트리거 요청 전달을 실패하고， 상기 재시도 수행 여부에 대한 정보가 재시도 수행을 지시하는 경우, 상기 제 1 서빙노드는 상기 제 2 서빙노드에게 상기 트리거 요청을 전달하고, 상기 제 2 서빙노드는 단말에게 트리거 요청을 전송할 수 있다. 또한, 상기 트리거 요청 재시도에 관련된 정보는 재시도 횟수 또는 재시도 허용 시간 중 하나 이상을 더 포함할 수 있다. 상기 트리거 요청을 전송할 수 있는 가용한 서빙노드는 2 개 이상일 수 있다. 또한, 상기 제 .1 서빙노드 및 상기 제 2 서빙노드는 각각 SGSN(Serving GPRS(General Packet Radio Service) Supporting Node), MME(Mobility Management Entity), MSC(Mobile Switching Center) 중 어느 하나일 수 있다. 상기 제 1 서빙노드가 단말에게 트리거 요청 전달을 실패하고, 상기 재시도 수행 여부에 대한 정보가 재시도를 수행하지 않을 것을 지시하는 경우， 상기 MTC-IWF 는 상기 제 1 서빙노드로부터 상기 트리거 요청 전달 실패를 지시하는 전달 보고 메시지를 수신할 수 있다. 여기서, 상기 MCT-IWF 가 HSS(Home Subscriber Server)/HLR(Home Location Register)로 상기 단말 관련 정보 알림 서비스 가입을 위한 서브스크라이버 알림 메시지를 전송하는 단계; 및 상기 HSS/HLR 로부터 상기 단말로의 트리거 전달이 가능해졌음을 알리는 통지 서브스크라이버 정보 메시지를 수신하는 단계를 더 포함하며, 상기 통지 서브스크라이버 정보 메시지는 상기 단말로 트리거 전송이 가능한 하나 이상의 서빙노드에 대한 정보를 포함할 수 있다. 상기 통지 서브스크라이버 정보 메시지를 이용하여 상기 하나 이상의 서빙노드 중에서 제 2 서빙노드를 결정하고, 상기 제 2 서빙노드로 트리거 요청 및 트리거 요청 재시도에 관련된 정보를 전송하는 단계를 더 포함할 수 있다. 또한， 상기 하나 이상의 서빙노드에 대한 정보는, 상기 하나 이상의 서빙노드의 식별자를 포함할 수 있다.
상기 방법은, SCS(Service Capability Server)로부터 상기 트리거 요청을 수신하는 단계; 및 상기 트리거 요청이 유효한지 검증하는 단계를 더 포함할 수 있다.
【유리한 효과】
본 발명에 따르면 MTC 단말에 대한 트리거링을 정확하고 효율적으로 수행하는 방안이 제공될 수 있다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다. 【도면의 간단한 설명】
본 명세서에 첨부되는 도면은 본 발명에 대한 이해를 제공하기 위한 것으로서 본 발명의 다양한 실시형태들을 나타내고 명세서의 기재와 함께 본 발명의 원리를 설명하기 위한 것이다.
도 1은 EPC(Evolved Packet Core)의 개략적인 구조를 나타내는 도면이다. 도 2는 MTC 구조의 예시적인 모델을 나타내는 도면이다.
도 3은 MTC 단말 트리거 전달 절차를 설명하기 위한 도면이다.
도 4는 T5를 이용한 트리거 전달 절차를 설명하기 위한 도면이다ᅳ 도 5는 T4를 이용한 트리거 전달 절차를 설명하기 위한 도면이다.
도 6 내지 도 7은 본 발명의 실시예에 의한 트리거 전달 절차를 설명하기 위한 도면이다.
도 8은 본 발명의 실시예에 의한 장치 구성을 도시한 도면이다.
【발명의 실시를 위한 최선의 형태】
이하의 실시예들은 본 발명의 구성요소들과 특징들을 소정 형태로 결합한 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려될 수 있다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및 /또는 특징들을 결합하여 본 발명의 실시예를 구성할 수도 있다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대웅하는 구성 또는 특징과 교체될 수 있다. 이하의 설명에서 사용되는 특정 용어들은 본 발명의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 발명의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나， 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다. 또한, 본 명세서 전체에서 동일한 구성요소에 대해서는 동일한 도면 부호를 사용하여 설명한다.
본 발명의 실시예들은 IEEE(Institute of Electrical and Electronics Engineers) 802 계열 시스템, 3GPP 시스템, 3GPP LTE 및 LTE-A 시스템 및 3GPP2 시스템 중 적어도 하나에 관련하여 개시된 표준 문서들에 의해 뒷받침될 수 있다. 즉， 본 발명의 실시예들 중 본 발명의 기술적 사상을 명확히 드러내기 위해 설명하지 않은 단계들 또는 부분들은 상기 문서들에 의해 뒷받침될 수 있다. 또한ᅳ 본 문서에서 개시하고 있는 모든 용어들은 상기 표준 문서에 의해 설명될 수 있다. 이하의 기술은 다양한 무선 통신 시스템에서 사용될 수 있다. 명확성을 위하여 이하에서는 3GPP LTE 및 3GPP LTE-A 시스템을 위주로 설명하지만 본 발명의 기술적 사상이 이에 제한되는 것은 아니다.
본 문서에서 사용될 수 있는 용어들은 다음과 같이 정의된다.
- UMTS(Universal Mobile Telecommunications System): 3GPP에 의해서 개발된, GSM(Global System for Mobile Communication) 기반의 3 세대 (Generation) 이동 통신 기술.
- EPS(Evolved Packet System): IP 기반의 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 기반으로 제공하는 서브시스템ᅳ
- IMSl(International Mobile Subscriber Identity): 이동 통신 네트워크에서 국제적으로 고유하게 할당되는 사용자 식별자.
- MTC(Machine Type Communications): 사람의 개입 없이 머신에 의해 수행되는 ^신.
- MTC 단말 (MTC UE (또는 MTC device)): 이동통신 네트워크를 통한 통신 가능을 가지고, 특정 목적을 수행하는 단말 (예를 들어, 자판기， 검침기 등).
- MTC 서버 (MTC server): MTC 단말을 관리하는 네트워크 상의 서버. 이동통신 네트워크의 내부 .또는 외부에 존재할 수 있다. MTC 사용자가 접근 (access)할 수 있는 인터페이스를 가질 수 있다. 또한 MTC 서버는 다른 서버들에게 MTC 관련 서비스를 제공할 수도 있고 (SCS의 형태)， 자신이 MTC 애플리케이션 서버일 수도 있다.
- MTC 애플리케이션 (MTC application): MTC가 적용되는 서비스 (예를 들어, 원격 검침, 물량 이동 추적 등)
- MTC 애플리케이션 서버: MTC 애플리케이션이 실행되는 네트워크 상의 서버.
- MTC 특징 (MTC feature): MTC 애플리케이션을 지원하기 위한 네트워크의 기능. 예를 들어, MTC 모니터링 (monitoring)은 원격 검침 등의 MTC 애플리케이션에서 장비 분실 등을 대비하기 위한 특징이고， 낮은 이동성 (low mobility)은 자판기와 같은 MTC 단말에 대한 MTC 애플리케이션을 위한 특징이다.
- MTC 서브스크라이버 (MTC subscriber): 네트워크 오퍼레이터와 접속 관계를 갖고 있으며 하나 이상의 MTC 단말에게 서비스를 제공하는 엔티티이다ᅳ
- MTC 그룹 (MTC Group): 적어도 하나 이상의 MTC 특징을 공유하며， MTC 서브스크라이버에 속한 MTC 단말의 그룹을 의미한다.
- SCS(Services Capability Server): HPLMN 상의 MTC-IWF(MTC InterWorking
Function) 및 MTC 단말과 통신하기 위한 엔티티로써, 3GPP 네트워크와 접속되어 ■ 있다.
- 외부 식별자 (External Identifier): 3 GPP 네트워크의 외부 엔티티 (예를 들면, SCS 또는 Application Server)가 MTC 단말 (또는 MTC 단말이 속한 가입자)을 가리키기 (또는 식별하기) 위해 사용하는 식별자 (identifier)로 globally unique하다. 외부 식별자는 다음과 같이 도메인 식별자 (Domain Identifier)와 로컬 식별자 (Local Identifier)로 구성된다: - 도메인 식별자 (Domain Identifier): 이동통신망 사업자의 제어 하에 있는 도메인을 식별하기 위한 식별자. 하나의 사업자는 서로 다른 서비스로의 접속을 제공하기 위해 서비스 별로 도메인 식별자를 사용할 수도 있다.
- 로컬 식별자 (Local Identifier): IMSI(International Mobile Subscriber Identity)를 유추하거나 획득하는데 사용되는 식별자. 로컬 식별자는 애플리케이션 도메인 내에서는 unique 해야 하며 , 아동통신망 사업자에 의해 관리된다.
- RAN(Radio Access Network): 3 GPP 네트워크에서 NodeB, eNodeB 및 이들을 제어하는 RNC(Radio Network Controller)를 포함하는 단위. 단말 간에 존재하며 코어 네트워크로의 연결을 제공한다ᅳ
- HLR(Home Location Register)/HSS(Home Subscriber Server): 3 GPP 네트워크 내의 가입자 정보를 가지고 있는 데이터베이스. 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 프로토콜 스택에서 단말과 코어 네트워크간의 시그널링, 트래픽 메시지를 주고 받기 위한 기능적인 계층. 단말의 이동성을 지원하고， 단말과 PDN GW 간의 IP 연결을 수립 및 유지하는 세션 관리 절차를 지원하는 것을 주된 기능으로 한다. 이하에서는 위와 같이 정의된 용어를 바탕으로 설명한다.
도 1은 EPC(Evolved Packet Core)의 개략적인 구조를 나타내는 도면이다.
EPC는 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), PDN GW(Packet Data Network Gateway),
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 또는 GE AN(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 네트워크 (예를 들어, 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에서는 다양한 레퍼런스 포인트들 (예를 들어, Sl-U, S1-MME 등)을 도시한다. 3GPP 시스템에서는 E-UTRAN 및 EPC의 상이한 기능 개체 (functional entity)들에 존재하는 2 개의 기능을 연결하는 개념적인 링크를 레퍼런스 포인트 (reference point)라고 정의한다. 다음의 표 1은 도 1에 도시된 레퍼런스 포인트를 정리한 것이다. 표 1의 예시들 외에도 네트워크 구조에 따라 다양한 레퍼런스 포인트들이 존재할 수 있다.
【표 1】
Figure imgf000015_0001
Figure imgf000016_0001
도 1에 도시된 레퍼런스 포인트 중에서 S2a 및 S2b는 비 -3GPP 인터페이스에 해당한다. S2a는 신뢰되는 비 -3GPP 액세스 및 PDNGW 간의 관련 제어 및 이동성 지원을 사용자 플레인에 제공하는 레퍼런스 포인트이다. S2b는 ePDG 및 PDN GW 간의 관련 제어 및 이동성 지원을 사용자 플레인에 제공하는 레퍼런스 포인트이다. _ 도 2는 MTC 구조의 예시적인 모델을 나타내는 도면이다.
MTC를 위해서 사용되는 단말 (또는 MTC 단말)와 MTC 애플리케이션 간의 단-대-단 애플리케이션은， 3GPP 시스템에 의해서 제공되는 서비스들과 MTC 서버에 의해서 제공되는 선택적인 서비스들을 이용할 수 있다. 3GPP 시스템은， MTC를 용이하게 하는 다양한 최적화를 포함하는 수송 및 통신 서비스들 (3GPP 베어러 서비스, IMS 및 SMS 포함)을 제공할 수 있다. 도 2에서는 MTC를 위해 사용되는 단말이 Um/Uu/LTE-Uu 인터페이스를 통하여 3GPP 네트워크 (UTRAN, E- UTRAN, GERAN, I-WLAN 등)으로 연결되는 것을 도시한다. 도 2의 구조 (architecture)는 다양한 MTC 모델 (Direct 모델, Indirect 모델， Hybrid 모델)들을 포함한다.
먼저, 도 2에서 도시하는 개체 (entity)들에 대하여 설명한다.
도 2에서 애플리케이션 서버는 MTC 애플리케이션이 실행되는 네트워크 상의 서버이다. MTC 애플리케이션 서버에 대해서는 전술한 다양한 MTC 애플리케이션의 구현을 위한 기술이 적용될 수 있으며, 이에 대한 구체적인 설명은 생략한다. 또한, 도 2에서 MTC 애플리케이션 서버는 레퍼런스 포인트 API를 통하여 MTC 서버에 액세스할 수 있으며, 이에 대한 구체적인 설명은 생략한다ᅳ 또는, MTC 애플리케이션 서버는 MTC 서버와 함께 위치될 (collocated) 수도 있다.
MTC 서버 (예를 들어 도시된 SCS 서버)는 MTC 단말을 관리하는 네트워크 상의 서버이며, 3GPP 네트워크에 연결되어 MTC를 위하여 사용되는 단말 및 PLMN의 노드들과 통신할 수 있다.
MTC-IWF(MTC-InterWorking Function)는 MTC 서버와 오퍼레이터 코어 네트워크 간의 상호동작 (interworking)을 관장하고， MTC 동작의 프록시 역할을 할 수 .있다. MTC 간접 또는 하이브리드 모델을 지원하기 위해서， 하나 이상의 MTC- IWF가 홈 PLMN(HPLMN) 내에 존재할 수 있다. 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 Gate Way)는 단문서비스 (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 Data Network-Gateway)는 코어 네트워크와 외부 네트워크의 연결을 담당하는 게이트웨이 기능을 할 수 있다.
다음의 표 2는 도 2에서의 주요 레퍼런스 포인트를 정리한 것이다.
【표 2】
Figure imgf000019_0001
Figure imgf000020_0001
상기한 T5a,T5b,T5c 중 하나 이상의 레퍼런스 포인트를 T5라고 지칭한다. 한편, 간접 및 하이브리드 모델의 경우에 MTC 서버와의 사용자 플레인 통신, 및 직접 및 하이브리드 모델의 경우에 MTC 애플리케이션 서버와의 통신은, 레퍼런스 포인트 Gi 및 SGi를 통해서 기존의 프로토콜을 사용하여 수행될 수 있다.
도 2에서 설명한 내용과 관련된 구체적인 사항은 3GPP TS 23.682 문서를 참조함으로써 본 문서에 병합될 수 있다 (incorporated by reference).
MTC의 경우에, 일반적인 사용자 기기보다 많은 개수의 MTC 단말이 네트워크 상에 존재할 것으로 예상된다. 따라서, MTC를 위해서 최소한의 네트워크 자원 사용, 최소한의 시그널링 사용， 최소한의 전력 사용 등이 요구된다. 또한, MTC 단말은 시스템 자원을 최소로 사용하기 위해서 평상시에는 MTC 애플리케이션 서버와의 IP 연결을 수립하지 않을 수 있다. 만약 MTC 단말이 IP 연결을 수립하지 않아서 MTC 애플리케이션 서버가 MTC 단말로의 데이터 전송에 실패하는 경우, MTC 단말로 하여금 IP 연결을 수립하도록 요청 또는 지시할 수 있는데， 이를 트리거 지시라고 칭한다. 즉, MTC 단말 트리거링은 MTC 단말에 대한 IP 주소가 MTC 애플리케이션 서버에 의해서 이용가능 (available)하지 않거나 도달가능 (reachable)하지 않은 경우에 요구된다 (어떤 개체에 또는 해당 개체의 주소에 도달가능하지 않다는 의미는， 해당 개체가 해당 주소에 부재중인 (absent) 등의 이유로, 메시지를 전달하려는 시도가 실패하는 것을 의미한다). 이를 위해서， MTC 단말은 네트워크로부터 트리거 지시를 수신할 수 있고， 트리거 지시를 받은 경우 MTC 단말은 단말 내의 MTC 애플리케이션의 동작을 수행하고 /수행하거나 MTC 애플리케이션 서버와의 통신을 수립할 것이 요구된다. 여기서, MTC 단말이 트리거 지시를 수신할 때, a) MTC 단말이 오프라인인 (네트워크에 어태치되어 있지 않은) 경우， b) MTC 단말이 온라인이지만 (네트워크에 어태치되어 있지만) 데이터 연결은 수립되지 않은 경우, 또는 c) MTC 단말이 온라인이고 (네트워크에 어태치되어 있고) 데이터 연결이 수립된 경우를 가정할 수 있다.
요컨대， MTC 단말에 대한 트리거링은, 해당 MTC 단말이 MTC 애플리케이션 서버로부터 데이터를 수신할 수 있는 IP 연결 (또는 PDN 연결)이 수립되어 있지 않은 경우에 (또는 해당 MTC 단말이 기본적인 제어 신호는 수신할 수 있지만 사용자 데이터는 수신할 수 없는 상태인 경우), 트리거링 메시지를 이용해서 해당
MTC 단말이 단말 내 MTC 애플리케이션의 동작을 수행하고 /수행하거나 MTC 애플리케이션 서버에 대해서 IP 연결 요청을 수행하도록 하는 동작이라고 할 수 있다. 또한， 트리거링 메시지는, 네트워크로 하여금 메시지를 적절한 MTC 단말에게 라우팅하도록 하고， MTC 단말로 하여금 메시지를 적절한 MTC 단말내의 애플리케이션으로 라우팅하도록 하는 정보 (이하에서는 트리거링 정보라고 칭함)를 포함하는 메시지라고 표현할 수도 있다.
보다 상세한 MTC 트리거링 절차를 도 3을 참조하여 설명한다.
SCS(380)는 MTC 단말을 트리거할 것을 결정할 수 있다 (S301). SCS가 트리거 요청을 하기 위해 접속하는 MTC-IWF에 대한 정보가 없으면, 트리거하려는 MTC 단말의 외부 식별자 (External identifier) 또는 SCS 내에 설정되어 있는 MTC-IWF의 식별자를 사용하여 DNS(370)에게 DNS 쿼리를 수행함으로써 MTC-IWF의 IP 주소 및 포트 번호를 결정할 수 있다. 이후 SCS(380)는 MTC-IWF(360)에게 장치 트리거 요청 메시지를 보낸다 (S302). 상기 장치 트리거 요청 메시지는 다음 표 3 같은 정보를 포함할 수 있다.
【표 3】 i) 외부 식별자 또는 MSISDN: 트리거 하려는 MTC 단말 (또는 MTC 단말이 속한 가입자)의 식별 ii) SCS식별자: 상기 장치 트리거 요청 메시자를 보내는 SCS의 식별자 iii)트리거 참조 번호 (trigger reference number): 상기 전송하는 장치 트리거 요청 메시지의 참조 번호 iv)유효 구간 (validity period): 장치 트리거 요청이 유효한 시간구간으로, 트리거가 MTC 단말로 전달되지 못하는 경우， 네트워크 엔티티 (예를 들어， MTC- IWF)로 하여금 장치 트리거 요청을 저장해야 하는 기간을 알려줌，
V)우선순위 (priority): 장치 트리거 요청의 전달 우선순위 vi)트리거 페이로드 (trigger payload): MTC 단말 상의 MTC 애플리케이션으로 전달되는 정보
SCS(380)로부터 장치 트리거 요청 메시지를 수신한 MTC-IWF(360)는 SCS가 3GPP 네트워크로 트리거 요청을 보내는 것이 허용되는 지에 대한 권한 검증을 수행한다 (S303). 만약 상기 권한 검증이 실패하면, MTC-IWF(360)는 SCS(380)에게 상기 장치 트리거 요청이 실패했음을 알리는 장치 트리거 확인 메시지를 보낸다. 이와 달리 상기 권한 검증이 성공하면 다음 단계를 수행할 수 있다.
MTC-IWF(360)는 HSS/HLR(350)에게 서브스크라이버 정보 요청 (Subscriber Information Request) 메시지를 보낸다 (S304). 이는 상기 SCS가 상기 MTC 단말을 트리거하는 것이 허용되는 SCS인지를 검사하고, 상기 단계 S302에서 수신한 MTC 단말의 식별자 (외부 식별자 또는 MSISDN)를 이용하여 IMSI를 획득하고, MTC 단말을 서빙하는 서빙노드 (서빙노드)의 식별자를 포함하는 라우팅 정보를 획득하기 위함이다.
HSS/HLR(350)은 상기 장치 트리거 요청 메시지를 보낸 SCS가 상기 MTC 단말을 트리거 하도록 허용되는 SCS 인지를 검사한다 (S305). 이후에 HSS/HLR(350)은 MTC-IWF(360)에게 서브스크라이버 정보 웅답 (Subscriber Information Response) 메시지를 전송한다. 이는 IMSI와 MTC 단말을 서빙하는 서빙노드의 식별자를 포함한다. 만약 검사 결과 상기 SCS가 상기 MTC 단말을 트리거 하도록 허용되지 않거나， 또는 HSSHLR(350)에 상기 MTC 단말과 관련한 유효한 서브스크립션 정보가 존재하는 않는다면, HSS/HLR(350)은 MTC- IWF(360)에게 이를 알리는 정보를 포함하는 서브스크라이버 정보 웅답 메시지를 전송한다. 이 경우, MTC-IWF(360)는 SCS(380)에게 상기 장치 트리거 요청이 실패했음을 알리는 장치 트리거 확인 메시지를 보내고， 이후의 단계는 수행하지 않는다.
MTC-IWF(360)는 HSS/HLR(350)로부터 수신한 정보 및 지역적 정책 (local policy)에 기반하여 트리거 전달 절차 (delivery procedure)를 선택한다. (S306a)
만약 T5 를 이용한 전달 절차가 선택되면, MTC-IWF(360)는 T5 트리거 전달 절차를 수행한다 (S306b) 상세한 T5 트리거 전달 절차는 도 4에 대한 설명에서 후술한다. 만약 상기 단계 S306a에서 T4를 이용한 전달 절차가 선택되었거나， 상기 단계 S306b의 결과 T5 전달이 실패했다면， MTC-IWF(360)는 T4 트리거 전달 절차를 수행한다 (S306c~306d). T4 트리거 전달 절차의 상세는 도 5에 대한 설명에서 후술한다.
MTC-IWF(360)는 SCS(380)에게 상기 단계 S302의 장치 트리거 요청 메시지에 대한 웅답인 장치 트리거 보고 (Device Trigger Report) 메시지를 전송한다 (S307). 장치 트리거 보고 메시지는 상기 SCS가 요청한 장치 트리거의 결과 MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지를,알려준다.
수신한 장치 트리거에 대한 웅답으로 UE-1(310)은 트리거 페이로드의 내용에 기반한 동작을 수행한다 (S308). 이러한 동작은 전형적으로는 SCS 또는
AS (애플리케이션 서버)와의 통신 개시를 포함한다. 도 4는 T5 트리거 전달 절차를 설명하기 위한 도면이다. 도 3의 단계 S302에서 MTC-IWF가 SCS로부터 장치 트리거 요청을 수신하면, MTC-IWF는 HSS/HLR로부터 수신한 정보와 지역 정책에 기반하여 적절한 트리거 전달 절차를 선택한다 (도 3의 단계 S304 〜 S306a). 그 결과, MTC-IWF는 T5a 인터페이스를 통해 SGSN으로, T5b 인터페이스를 통해 MME로, T5c. 인터페이스를 통해 MSC로 (T5a, T5b, T5c 인터페이스를 통한 장치 트리거를 †5 장치 트리'거라고 명칭할 수 있다.) 또는 T4 인터페이스를 통해 SMS-SC로 장치 트리거 요청을 보낼 수 있다. 예를 들어, 도 4를 참조하면, HSS/HLR로부터 획득한 정보에 기반하여 가용한 서빙노드가 다수개인 경우, MTC-IWF(440)는 적절한 서빙노드를 선택한다. MTC-IWF(440)는 선택한 서빙노드 (420)에게 제출 요청 (Submit Request) 메시지를 전송한다 (S401). 상술한 바와 같이 만약 선택한 서빙노드가 SGSN이면 T5a, MME이면 T5b ：또는 MSC면 T5c 인터페이스를 통해 제출 요청 메시지를 전송한다.
제출 요청 메시지를 수신한 서빙노드 (420)는 장치 트리거의 타겟 단말인 UE-
1(410)에게 트리거 메시지를 전달한다 (S402). 상기 트리거 동작을 수행한 서빙노드 (420)는 MTC-IWF(460)에게 전달 보고 (Delivery Report) 메시지를 보낸다. 상기의 전달 보고 메시지는 MTC-IWF가 요청한 장치 트리거의 결과 MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지를 알려준다. 도 5는 T4 트리거 전달 절차를 설명하기 위한 도면이다. 도 5를 참조하면，
MTC-IWF(560)는 SCS(580)로부터 수신한 장치 트리거 요청 메시지가 포함하는 정보 및 HSS/HLR(550)로부터 수신한 서브스크라이버 정보 응답 메시지가 포함하는 정보에 기반하여 SMS-SC(540)에게 제출 트리거 (Submit Trigger) 메시지를 전송한다 (S501). SMS-SC(540)는 제출 트리거 메시지를 수신 (accept) 하였음을 웅답하는 제출 트리거 확인 메시지를 MTC-IWF(560)에게 전송한다 (S502). SMS- SC(540)로부터 제출 트리거 확인 메시지를 수신한 MTC-IWF(560)는 SCS(580)에게 SCS가 보낸 장치 트리거 요청 메시지가 수신 (accept) 되었음을 알리는 장치 트리거 확인 메시지를 전송한다 (S503).
SMS-SC(540)가 보낸 장치 트리거 메시지를 담은 단문 메시지가 서빙노드 (520)에게 전달된다 (S504). 이 때, 상기 SMS-SC(540)는 수신한 장치 트리거 메시지가 라우팅 정보 (서빙노드에 대한 정보)를 포함하고 있다면 이를 획득하기 위해 HSS/HLR(550)와의 질의 (interrogation)를 수행할 필요가 없다. SMS- SC(540)는 단문 메시지 전송이 실패할 경우를 대비하여 MTC-IWF(560)로부터 수신한 정보 중 라우팅 정보를 제외한 필요한 정보를 저장한다.
다음으로， 서빙노드 (520)는 UE-1(510)에게 단문 메시지를 전달한다 (S505). 장치 트리거 메시지를 포함하는 단문 메시지를 수신한 UE-1(510)은 서빙노드 (520)에게 웅답을 할 수 있다. '서빙노드 (520)는 SMS-SC(540)에게 전달 보고 메시지를 보낸다 (S506). 전달 보고 메시지는 상기 SMS-SC가 요청한 단문 메시지 전달의 결과 MTC 단말로의 short message 전달이 성공했는지 또는 실패했는지를 알려줄 수 있다. 만약, 단문 메시지 전달이 실패했다면 SMS- SC(540)는 HSS/HLR(550)과의 질의 (interrogation)를 통해 UE-1(510)로 단문 메시지를 전달하기 위한 라우팅 정보를 획득한 후， 단계 S504에서 저장한 정보를 이용하여 재전송을 수행할 수 있다. SMS-SC(540)는 MTC-IWF(560)에게 MTC- IWF가 요청한 장치 트리거의 결과 MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지를 알리기 위해 메시지 전달 보고 (Message Delivery Report) 메시지를 보낸다 (S507). 상술한 MTC 트리거 절차에서 장치 트리거 요청 동작이 실패한 경우， MTC-
IWF가 트리거 재시도를 수행 할 수 있다. 구체적으로， T5 트리거 전달이 실패했다면, MTC-IWF는 T4 트리거를 통해 장치 트리거를 재시도 할 수 있다. 또한, T4 트리거 절차가 사용되는 경우에도, 트리거 메시지를 포함하는 단문 메시지의 전송이 실패한 경우에는 SMS-SC가 재전송을 수행할 수 있다ᅳ 또한 장치 트리거 요청을 T5 인터페이스를 통해 MTC-IWF로부터 수신한 서빙노드들 (SGSN, MME, MSC) 역시 장치 트리거 동작이 실패한 경우 재시도를 수행할 수 있다.
즉, 동일한 MTC 단말을 트리거하기 위한 재시도 동작이 다수의 네트워크 노드에서 발생할 수 있다. 이는 장치 트리거링이 비효율적이며 불명확하게 운영될 수 있는 가능성을 내포한다. 따라서, 이하에서는 상술한 문제점을 해결할 수 있는 효율적인 MTC 단말의 트리거에 대해 설명한다. 본 발명에서는 MTC-IWF가 서빙노드 (SGSN, MME, MSC) 또는 SMS-SC에게 트리거 요청을 전송할 때, 트리거 요청의 재시도에 관련된 정보를 함께 전송하는 방법을 제안한다. 특히， 트리거 요청의 재시도에 관련된 정보는 트리거 요청 전달 실패시 재시도를 수행할 것인지 여부에 대한 정보를 포함하며， 이 정보가 재시도를 수행할 것을 지시하는 경우 트리거 요청 재시도는 다음 노드에게 위임될 수 있다
여기서 트리거 요청 재시도의 위임은 트리거 요청 전달 실패시 다음 노드에게 트리거 요청을 전달하도록 지시함을 의미한다. 또한, 다음 노드란， MTC- IWF가 서빙노드 (SGSN, MME, MSC)에게 트리거 요청을 전송하는 경우에는 서빙노드를， MTC-IWF가 SMS-SC에게 트리거 요청을 전송하는 경우에는 SMS- SC를 의미할 수 있다. 또한， 언급된 '재시도，는 MTC-IWF으로부터 장치 트리거 요청을 받은 노드가 단말로의 트리거 동작이 실패한 후, 다음 중 하나 이상의 동작을 수행함을 의미한다. i) 전송 실패한 장치 트리거 요청을 저장하였다가 (자신이 저장하거나 제 3의 노드에 저장) 자신이 단말로의 트리거 동작을 다시 수행, H) 트리거 동작이 실패함으로 인해 단말로 전달되어야 하는 트리거가 존재한다는 정보를 (또는 계속 증인 있는 트리거가 존재한다는 정보 또는 대기 중인 트리거가 존재한다는 정보를) 저장, iii) 전송 실패한 장치 트리거 요청을 네트워크의 다른 노드에게 전송함으로써 다른 노드 또는 제 3의 노드가 저장해 놓도록 함， iv) 단말로의 트리거 전달이 가능해짐을 안 경우 (즉, 트리거되는 단말이 가용해짐 (available 또는 reachable)을 안 경우 또는 자신이 장치 트리거 전달 동작을 수행할 수 있게 된 경우, 예를 들어, 노드가 흔잡하여 장치 트리거 전달 동작을 수행할 수 없다가 흔잡 상황이 해제되어 장치 트리거 전달 동작을 수행할 수 있게 되는 등)， 이를 네트워크의 다른 노드에게 알리는 동작, 즉, 다른 노드 또는 제 3의 노드로 하여금 트리거 재시도를 수행하게끔 할 수 있다.
설명에 앞서, 본 발명에서의 트리거 방법은 MTC-IWF가 사용하는 장치 트리거 요청이 SMS 기반인 경우, NAS 기반인 경우, 유저 플레인 (user plane) 기반인 경우 등 다양한 경우에 적용 가능하다. 또한， MTC 단말이 속한 (attach)한 도메인이 PS 도메인, CS 도메인, IMS 도메인 중 하나 이상일수 있으며, MTC 단말이 접속한 액세스 망은 GERAN, UTRAN, E-UTRAN, WLAN, 3GPP2 중 하나 이상일 수 있다. 또한, 본 발명은 온라인 (online) 및 오프라인 (offline) 장치 트리거링 모두에 적용 가능하다： 또한, MTC-IWF는 SCS 또는 애플리케이션 서버와 함께 위치 (C0-l0Cate)되어 있을 수도 있고 별도의 노드일 수도 있다. 또는 기존의 다른 네트워크 노드에 함께 위치되어 있을 수도 있다. 또한, 이하에서 설명되는 MTC-IWF 노드의 역할은 다른 노드 (가령, SCS 또는 Application Server)가 수행할 수도 있다. 트리거 요청의 재시도에 관련된 정보
트리거 요청의 재시도에 관련된 정보에 대해 구체적으로 살펴보면, 이하에서 설명되는 정보들을 포함할 수 있다. 여기서, 트리거 요청은 MTC-IWF가 T5 인터페이스를 통해 서빙노드에게 트리거 요청을 전송 또는 T4 인터페이스를 통해 SMS-SC로 SMS 기반의 트리거 요청을 전송으로 구분될 수 있는데, 양자 모두 다음 정보들을 트리거 요청의 재시도에 관련된 정보에 포함시킬 수 있다. 첫 번째로， 재시도를 수행하지 않을 것을 지시하는 정보 (또는, 한번의 시도만 수행할 것을 가리키는 정보)를 포함할 수 있다. 재시도를 수행하지 않을 것을 지시하는 정보는 명시적 또는 암시적으로 포함될 수 있다. 또한 상기의 정보를 포함시키지 않음으로써 재시도를 수행하지 말 것을 지시할 수도 있다. 또한 다수의 정보가 복합적으로 재시도를 수행하지 말 것을 지시할 수도 있다. 두 번째로, 재시도를 수행할 것을 지시하는 정보 (또는, 다수 번의 재시도를 수행할 것을 가리키는 정보, 또는 다음 노드에게 재시도를 위임함을 알리는 정보)를 포함할 수 있다. 재시도를 수행할 것을 가리키는 정보는 명시적 또는 암시적으로 포함될 수 있다. 또한 이러한 정보를 포함시키지 않음으로써 재시도를 수행할 것을 지시할 수도 있다. 또한 다수의 정보가 복합적으로 재시도를 수행할 것을 지시할 수도 있다.
세 번째로, 재시도 횟수 (Number of Retry, 또는 시도 횟수 (Number of Try))를 포함할 수 있다. MTC-IWF은 상기 재시도를 수행할 것을 가리키는 정보 (또는， 다수번의 시도를 수행할 것을 가리키는 정보)를 포함시키지 않고 0보다 크게 설정된 재시도 횟수 또는 1보다 크게 설정된 시도 흿수만을 포함시켜 장치 트리거 요청을 다음 노드에게 보낼 수도 있다. 이러한 재시도 횟수 (또는 시도 횟수)는 재시도를 수행하라는 의미를 내포한다. 또한 MTC-IWF은 재시도를 수행하지 않올 것을 가리키는 정보 (또는, 한번의 시도를 수행할 것을 가리키는 정보)를 포함시키지 않고 0으로 설정된 재시도 횟수 또는 1로 설정된 시도 횟수만을 포함시켜 장치 트리거 요청을 다음 노드에게 보낼 수도 있다. 이러한 재시도 횟수 (또는， 시도 횟수)는 재시도를 수행하지 않을 것을 지시하는 의미를 내포한다.
네 번째로, 재시도 허용 시간 (Validity Time of Retry, 또는 시도 허용 시간
(Validity Time of Try))를 포함할 수 있다. 이는 다양한 형태로 나타낼 수 있으며 상세한 사항은 3GPP TS 23.040의 허용 /유효 구간 (Validity Period) 관련 내용이 참조될 수 있다. 또한, 상기 정보는 허용 /유효구간포맷 (Validity Period Format) 파라미터를 수반할 수 있다. 또한, 상기 재시도 허용 /유효 시간 값은 MTC-IWF가 SCS로부터 받은 허용 /유효 시간 (Validity time, 또는 Validity period) 값에 기반할 수 있다. 이 때 재시도 허용 시간을 SCS로부터 받은 허용 시간 값과 동일하게 설정할 수도 있고, 재시도 허용 시간을 SCS로부터 받은 유효 시간 값 보다 더 작은 값으로 설정할 수도 있다. SCS가 장치 트리거 요청에 Validity time을 포함시키지 않은 경우 MTC-IWF는 configure되어 있는 값 (operator policy에 기반, SCS로부테 미리 획득한 값 등) 그리고 /또는 네트워크의 상황 (예를 들어， congestion) 등에 기반하여 상기 재시도 허용 시간을 설정할 수 있다.
MTC-IWF은 재시도를 수행하지 말 것을 가리키는 정보 (또는 한번의 시도를 수행할 것을 가리키는 정보)를 포함시키지 않고 0으로 설정된 재시도 허용 시간 (또는 시도 허용 시간)만을 포함시켜 장치 트리거 요청을 다음 노드에게 보낼 수도 있다. 0으로 설정된 재시도 허용 시간 (또는 시도 허용 시간)은 재시도를 수행하지 않을 것을 지시한다. 또한 MTC-IWF은 상기 재시도를 수행할 것을 가리키는 정보 (또는, 다수 번의 시도를 수행할 것을 가리키는 정보)를 포함시키지 않고 0이 아닌 값으로 설정된 재시도 허용 시간 (또는, 시도 허용 시간)만을 포함시켜 장치 트리거 요청을 다음 노드에게 보낼 수도 있다.
MTC-IWF가 T4 인터페이스를 통해 SMS-SC로 SMS 기반의 트리거 요청을 전송하는 경우, 앞서 설명된 정보들을 포함하기 위해 SMS 메시지에 있는 필드를 이용하거나， 새로운 필드를 정의하여 이용하거나, 장치 트리거 요청을 위해 정의된 새로운 메시지 (SMS 메시지를 캡슐화 (encapsulate)한 메시지 등)에 새롭게 정의된 필드를 이용할 수 있다. 재시도 허용 시간은 재시도가 아니더라도 만약 네트워크 흔잡 (network congestion) 등의 이유로 SMS— SC가 장치 트리거 동작을 연기 (defer)한 경우에도 (즉, 네트워크 흔잡이 해소될 때까지 장치 트리거 동작을 미루는 경우) 적용 가능하다. 즉， 이러한 경우 재시도 허용 시간이 종료하기 전에 장치 트리거 동작을 수행하는 것이 가능해졌다면 이를 수행하고, 상기 재시도 허용 시간이 종료했는데 장치 트리거 동작을 수행하는 것이 여전히 불가능하다면 MTC-IWF에게 장치 트리거의 실패를 알린다. 여기서 MTC-IWF는 MTC 서버로부터 트리거 요청을 수신한 것일 수 있다.
MTC-IWF가 T5 인터페이스를 통해 서빙노드에게 트리거 요청을 전송하는 경우， 상기 트리거 요청의 재시도에 관련된 정보는 다음 정보들을 더 포함할 수 있다.
첫 번째로, SGSN과 MME 간의 S3 인터페이스를 통해 상대 노드로 (즉，
SGSN의 경우 MME로, MME의 경우 SGSN으로) 장치 트리거 요청을 보냄으로써 재시도를 수행할 것을 가리키는 정보를 포함할 수 있다. 상기 정보는 상대 노드의 주소 정보를 의미 또는 포함할 수 있디-.
두 번째로, SGSN과 MSC 간의 인터페이스 (예를 들어, Gs 또는 Sv)를 통해 상대 노드로 (즉， SGSN의 경우 MSC로, MSC의 경우 SGSN으로) 장치 트리거 요청을 보냄으로써 재시도를 수행할 것을 가리키는 정보를 포함할 수 있다. 상기 정보는 상대 노드의 주소 정보를 의미 또는 포함할 수 있다.
세 번째로， MME와 MSC 간의 인터페이스 (예를 들어， SGs 또는 Sv)를 통해 상대 노드로 (즉， MME의 경우 MSC로, MSC의 경우 MME로) 장치 트리거 요청을 보냄으로써 재시도를 수행할 것을 가리키는 정보를 포함할 수 있다. 상술한 정보들, 즉 다른 서빙노드로 재시도를 수행할 것을 가리키는 정보는 명시적 또는 암시적으로 포함될 수 있다. 또한 상기의 정보를 포함시키지 않음으로써 다른 서빙노드로 재시도를 수행할 것을 지시할 수도 있다. 또한 다수의 정보가 복합적으로 다른 서빙노드로 재시도를 수행할 것을 지시할 수도 있다.
한편， 재시도에 관련된 정보에 재시도 횟수 및 재시도 허용시간 정보가 모두 포함되고 재시도가 전송 실패한 장치 트리거 요청을 저장하였다가 (자신이 저장하거나 제 3의 노드에 저장) 자신이 단말로의 트리거 동작을 다시 수행 것을 의미하는 경우, 재시도 횟수 및 재시도 허용시간 중 하나가 초과되면 MTC- IWF으로부터 장치 트리거 요청을 받은 노드는 더 이상 단말로의 트리거 동작을 수행하지 않는다. 이와 함께 저장해 놓은 상기 장치 트리거 요청을 삭제할 수 있다.
또한， 재시도에 관련된 정보에 재시도 횟수 및 재시도 허용시간 정보 모두 포함되고 재시도가 트리거 동작이 실패함으로 인해 단말로 전달되어야 하는 트리거가 존재한다는 정보를 (또는 계속 중인 있는 트리거가 존재한다는 정보 또는 대기 중인 트리거가 존재한다는 정보를) 저장할 것을 의미하는 경우， 재시도 허용시간 값이 초과하면 MTC-IWF으로부터 장치 트리거 요청을 받은 노드는 저장해 놓은 단말로 전달되어야 하는 트리거가 존재한다는 정보를 삭제한다. 이와 함께, 전송 실패한 장치 트리거 요청을 네트워크의 다른 노드에게 전송함으로써 다른 노드 또는 제 3의 노드가 저장해 놓도록 이전에 수행했던 경우 저장된 요청을 삭제할 것을 알리는 메시지를 보낼 수 있다.
앞서 설명된 재시도에 관련된 정보들을 포함하가 위해 기존의 메시지 (NAS 메시지, SMS 메시지, SMS 메시지를 캡슬화한 NAS 메시지 등)에 있는 기존의 필드를 이용하거나， 기존의 메시지에 새로운 필드를 정의하여 이용하거나， 장치 트리거 요청을 위해 정의된 새로운 메시지에 새롭게 정의된 필드를 이용할 수 있다. 재시도 허용 시간은 재시도가 아니더라도 만약 네트워크 흔잡 등의 이유로
MSC, SGSN 또는 MME가 장치 트리거 동작을 지연한 경우에도 (즉, network congestion이 resolve될 때까지 장치 트리거 동작을 미루는 경우) 적용 가능하다. 즉， 이러한 경우 상기 재시도 허용 시간이 종료하기 전에 장치 트리거 동작을 수행하는 것이 가능해졌다면 이를 수행하고, 상기 재시도 허용 시간이 종료했는데 장치 트리거 동작을 수행하는 것이 여전히 불가능하다면 MTC- IWF에게 장치 트리거의 실패를 알린다.
상술한 재시도에 관련된 정보를 포함시킬지 여부를 결정함에 있어서 다음 표 4와 같은 예시적인 사항들이 고려될 수 있다.
【표 4】 i) 장치 트리거요청을 보낼 다음 노드 그리고 /또는 인터페이스의 가용성 ii) 가용한 서빙노드의 수 iii) 사업자 정책 (Operator policy) iv) 네트워크 흔잡 상황, 각 인터페이스 (Tsp, T4, T5a, T5b, T5c)의 흔잡 상황 v) MTC-IWF의 흔잡 상황, 다음 노드 (들)의 흔잡'상황 vi) SCS로부터 수신한 장치 트리거 요청 메시지에 포함된 정보 (예를 들면, Validity Time, priority 등) vii) SCS 또는 MTC 사용자 또는 MTC 서브스크라이버로부터 미리 획득한 장치 트리거와 관련한 정보 (예를 들면, 선호도 등) viii) 이전의 장치 트리거 시도와 관련한 히스토리 정보 (여 1를 들면， 각 다음 노드로의 장치 트리거 요청에 대한 성공률， 재시도 횟수) ix) 다음 노드로부터 수신한 장치 트리거 요청에 대한 응답 Pi 웅답에 포함된 정보 (예를 들면， 실패 이유, 실패 횟수 등)
X) MTC 단말의 로밍 여부 xi) MTC 단말의 능력 정보 그리고 /또는 특성 다만, 상기의 결정에 기반이 되는 사항들로 상기의 예시에 한정되는 것은 아니며, 재시도에 관련된 정보를 포함시킬지 여부를 결정하는데 필요한 정보라면 어떤 것이든 사용 가능하다.
또한, 상술한 재시도에 관련된 정보들은 최초로 트리거 요청을 수행하는 경우뿐 아니라 재시도를 수행하는 경우에도 적용될 수 있다. 상술한 바와 같은 재시도에 관련된 정보와 함께 트리거 요청올 MTC-IWF가 전송하였는데, 만약 장치 트리거 동작이 성공하지 못한 경우, 장치 트리거 재시도가 적용될 수 있다. 이하에서는 이에 대해 설명한다. 이하에서 재시도는 이전의 트리거 요청을 전송한 노드와 동일한 노드를 통해 수행될 수도 있고， 다른 노드를 통해 수행될 수도 있는데， 이전과 다른 노드를 통해 수행되는 경우를 폴백 (fallback) 모드로 명칭할 수 있다. 트리거 전송 실패시의 동작의 예시 1
MTC-IWF가 T5a, T5b 또는 T5c 인터페이스를 통해 SGSN, MME 또는 MSC로 장치 트리거 요청을 보냈는데 전송이 실패한 경우， MTC-IWF가 다음 노드에게 재시도를 수행할 것을 가리켰었다면, 다음 노드는 전송 실패한 장치 트리거 요청을 네트워크의 다른 노드.에게 전송함으로써 다른 노드 또는 제 3의 노드가 저장해 놓도록 할 수 있다. 또는 단말로의 트리거 전달이 가능해짐을 안 경우 이를 네트워크의 다른 노드에게 알리는 동작 (이 동작은 상기의 다른 노드 또는 제 3의 노드로 하여금 트리거 재시도를 수행하게끔 할 수 있다)을 수행할 수 있다. 다른 노드 또는 제 3의 노드로의 트리거 저장 요청은 SMS-SC, MTC-IWF, HSS/HLR 세가지 경우의 예를 들 수 있는데, 각 예시의 경우에서 동작을 각각 설명한다. 첫 번째로, SMS-SC (또는 SMS-SC가 관리하는 제 3의 저장 노드)에서 전송이 실패한 장치 트리거 요청을 저장할 수 있다. 장치 트리거 전송이 실패한 서빙노드 (즉， SGSN/MME/MSC)가 SMS-SC로 전송 실패한 장치 트리거 요청 메시지를 보내 저장토록 한다. 이 때 장치 트리거 요청 메시지 .외에 SMS-SC로 추가적인 정보 (예를 들어, 서빙노드의 주소， 자신이 전송 시도한 횟수, 장치 트리거 요청 메시지가 SMS 형태인지 여부 등)가 함께 전달될 수 있다. SMS-SC는 서빙노드로부터 수신한 장치 트리거 저장 요청 메시지에 대한 응답을 보낼 수 있다. 서빙노드와 SMS-SC 간의 메시지 교환은 서로 직접적인 인터페이스가 존재하는 경우 '서빙노드 대 SMS-SC' 의 형태로 직접 이루어질 수도 있고， '서빙노드 대 MTC-IWF 대 SMS-SC' 의 형태로 T5a/T5b/T5c와 T4 인터페이스를 통해 이루어질 수도 있고, '서빙노드 대 SMS-GMSC (또는 SMS-IWMSC) 대 SMS- SC의 형태로 이루어질 수도 있다. 상기의 경우들에 대해 추가적으로는 서빙노드，
SMS-SC 또는 중간 노드가 HSS/HLR에 트리거 동작이 실패함으로 인해 단말로 전달되어야 하는 트리거가 존재한다는 정보를 설정하도록 요청하는 단계가 수행될 수 있다.
SMS-SC는 상기 저장을 요청 받은 장치 트리거에 대해서' 단말로의 트리거 전달이 가능해짐을 i) 서빙노드가 SMS-SC에게 단말로의 트리거 전달이 가능해짐을 알리는 메시지를 보냄 (서빙노드와 SMS-SC 간의 메시지 교환), ii) 단말로의 트리거 전달이 가능해짐을 알게 된 HSS/HLR이 SMS-SC에게 이를 알리는 메시지를 보냄. (HSS/HLR, SMS-IWMSC, SMS-SC 간의 메시지 교환 또는 HSS/HLR와 SMS-SC 간의 메시지 교환), 이를 위해 SMS-SC는 HSS/HLR이 제공하는 단말 관련 정보 알림 서비스에 가입할 수 있음， iii) 단말로의 트리거 전달이 가능해짐을 알게 된 MTC-IWF가 SMS-SC에게 이를 알리는 메시지를 보냄 (MTC-IWF와 SMS-SC 간의 메시지 교환). 중 적어도 하나 이상을 통해 알 수 있다.
단말로의 트리거 전달이 가능해짐을 알게 된 SMS-SC는 자신 또는 제 3의 노드에 저장해 놓은 장치 트리거 요청 메시지를 i) SMS-SC가 서빙노드로 장치 트리거 요청 메시지를 직접 전송하고 이를 수신한 서빙노드가 상기 장치 트리거 요청 메시지를 단말로 전달. 이 때 상기 서빙노드는 해당 장치 트리거 요청 메시지를 저장할 것을 요청했던 서빙노드 일 수도 있고 다른 서빙노드 일 수도 있다. 또한, 이 때 장치 트리거 요청 메시지가 전송되는 상기 서빙노드는 SMS- SC에게 트리거되는 단말이 가용해짐을 알린 서빙 노드 일 수 있다. ii) SMS-SC가 SMS 방식에 따라 SMS-GMSC에게 SMS 형태의 장치 트리거 요청 메시지를 전송하고 SMS가 전달되는 경로를 통해 단말로 전달， iii) SMS-SC가 MTC-IWF으로 장치 트리거 요청 메시지를 전달하고 이를 수신한 MTC-IWF은 T5a/T5b/T5c 인터페이스를 통해 단말로 전달 중 적어도 하나 이상을 통해 단말로 전송할 수 있다. 두 번째로, MTC-IWF (또는 MTC-IWFo 관리하는 제 3의 저장 노드)에서 전송이 실패한 장치 트리거 요청을 저장할 수 있다. 장치 트리거 전송이 실패한 서빙노드 (즉， SGSN/MME/MSC)가 MTC-IWF으로 전송 실패한 장치 트리거 요청 메시지를 보내 저장토록 한다. 이 때 MTC-IWF가 서빙노드로부터 전송을 성공했다는 웅답을 받기 전에는 상기 장치 트리거 요청 메시지를 계속 가지고 있을 수도 있는데 이러한 경우에는 서빙노드가 상기 장치 트리거 요청 메시지에 대한 전송 실패를 알리는 MTC-IWF으로의 웅답이 MTC-IWF으로 하여금 장치 트리거 요청 메시지를 계속 저장할 것을 의미할 수 있다. 서빙노드와 MTC-IWF 간의 메시지 교환은 T5a/T5b/T5c 인터페이스를 통해 이루어진다. 이 방안에서 추가적으로는 서빙노드 또는 MTC-IWF가 HSS/HLR에 트리거 동작이 실패함으로 인해 단말로 전달되어야 하는 트리거가 존재한다는 정보를 설정하도록 요청하는 단계가 수행될 수 있다.
MTC-IWF은 상기 저장을 요청 받은 장치 트리거에. 대해서 단말로의 트리거 전달이 가능해짐을 i) 서빙노드가 MTC-IWF에게 단말로의 트리거 전달이 가능해짐을 알리는 메시지를 보냄 (서빙노드와 MTC-IWF 간의 메시지 교환), ii) 단말로의 트리거 전달이 가능해짐을 알게 된 HSS/HLR이 MTC-IWF에게 이를 알리는 메시지를 보냄. 이 때 HSS/HLR은 트리거 전달 재시도에 필요한 서빙노드에 대한 정보를 MTC-IWF에게 제공할 수도 있다. (HSS/HLR과 MTC-IWF 간의 메시지 교환, 이를 위해 MTC-IWF은 HSS/HLR이 제공하는 단말 관련 정보 알림 서비스에 가입할 수 있음) 중 적어도 하나 이상을 통해 알 수 있다.
단말로의 트리거 전달이 가능해짐을 알게 된 MTC-IWF은 자신 또는 제 3의 노드에 저장해 놓은 장치 트리거 요청 메시지를 i) MTC-IWF가 T5a/T5b/T5c 인터페이스를 이용하여 서빙노드로 장치 트리거 요청 메시지를 전송하고 이를 수신한 서빙노드가 상기 장치 트리거 요청 메시지를 단말로 전달 (이 때 상기 서빙노드는 해당 장치 트리거 요청 메시지를 저장할 것을 요청했던 (또는 전송 실패를 알렸던) 서빙노드일 수도 있고 다른 서빙노드 일 수도 있음. 또한, 장치 트리거 요청 메시지가 전송되는 상기 서빙노드는 MTC-IWF에게 트리거되는 단말이 가용해짐을 알린 서빙 노드일 수 있음 이는, MTC 네트워크에 T4 인터페이스가 존재하지 않거나, T4 인터페이스가 존재하더라도 트리거 되는 단말이 MSISDN-less 단말이라 기존의 SMS 방식의 전송을 사용할 수 없는 경우 에 효과적일 수 있다), ii) MTC-IWF가 T4 인터페이스를 통해 SMS-SC로 장치 트리거 요청 메시지를 전송하고 SMS-SC가 SMS가 전달되는 경로를 통해 단말로 전달 (이 때 SMS-SC로 장치 트리거 요청 메시지를 전송할 때 추가적인 정보 (MTC-IWF에게 트리거되는 단말이 가용해짐을 알린 서빙 노드 등)가 함께 전달될 수 있음) 증 적어도 하나 이상의 방법으로 단말로 전송한다. 세 번째로, HSS/HLR (또는， HSS/HLR이 관리하는 제 3의 저장 노드)에서 전송이 실패한 장치 트리거 요청을 저장할 수 있다. 장치 트리거 전송이 실패한 서빙노드 (즉， SGSN/MME/MSC)가 HSS/HLR로 전송 실패한 장치 트리거 요청 메시지를 보내 저장토록 한다. 이 때 장치 트리거 요청 메시지 외에 HSS/HLR로 추가적인 정보 (예를 들어, 서빙노드의 주소, 자신이 전송 시도한 횟수, 장치 트리거 요청 메시지가 SMS 형태인지 여부 등)가 함께 전달될 수 있다. HSS/HLR은 서빙노드로부터 수신한 장치 트리거 저장 요청 메시지에 대한 응답을 보낼 수 있다. 서빙노드와 HSS/HLR 간의 메시지 교환은 직접적인 인터페이스를 통해 서빙노드 대 HSS/HLR 의 형태로 이루어진다.
HSS/HLR은 상기 저장을 요청 받은 장치 트리거에 대해서 단말로의 트리거 전달이 가능해짐을 i) 서빙노드가 HSS/HLR에게 단말로의 트리거 전달이 가능해짐을 알리는 메시지를 보냄 (서빙노드와 HSS/HLR 간의 메시지 교환), ii) 단말로의 트리거 전달이 가능해짐을 알게 된 MTC-IWF가 HSS/HLR에거] 이를 알리는 메시지를 보냄 (MTC-IWF와 HSS/HLR 간의 메시지 교환) 중 적어도 하나 이상을 통해 알 수 있다.
단말로의 트리거 전달이 가능해짐을 알게 된 HSS/HLR은 자신 또는 게 3의 노드에 저장해 놓은 장치 트리거 요청 메시지를 i) HSS/HLR이 서빙노드로 장치 트리거 요청 메시지를 직접 전송하고 이를 수신한 서빙노드가 상기 장치 트리거 요청 메시지를 단말로 전달 (이 때 상기 서빙노드는 해당 장치 트리거 요청 메시지를 저장할 것을 요청했던 서빙노드 일 수도 있고 다른 서빙노드 일 수도 있다. 또한， 이 때 장치 트리거 요청 메시지가 전송되는 상기 서빙노드는 HSS/HLR에게 트리거되는 단말이 가용해짐을 알린 서빙 노드 일 수 있다), ii) HSS/HLR이 MTC-IWF으로 장치 트리거 요청 메시지를 전달하고 이를 수신한 MTC-IWF은 T5a/T5b/丁 5c 인터페이스를 통해 단말로 전달 증 적어도 하나 이상의 방밥으로 단말로 전송한다. 트리거 전송 실패시의 동작의 예사 2 MTC-IWF가 T5a 또는 T5b 또는 T5c 인터페이스를 통해 SGSN 또는 MME 또는 MSC로 장치 트리거 요청을 보냈는데 전송이 실패한 경우 및 T4 인터페이스를 통해 SMS-SC로 장치 트리거 요청을 보냈는데 전송이 실패한 경우， MTC-IWF가 다음 노드에게 재시도를 수행하지 말 것을 지시했다면, 전송 실패한 장치 트리거 요청을 MTC-IWF가 저장하거나 또는 다른 노드에 저장을 요청해 저장해 놓도록 하고, 추가적으로는 단말로의 트리거 전달이 가능해짐을 안 경우 MTC-IWF 또는 상기 장치 트리거 요청 메시지를 저장한 노드가 트리거 재시도를 수행하는 동작을 수행할 수 있다. 다른 노드.또는 제 3의 노드가 트리거 요청은 SMS-SC, MTC-IWF, HSS/HLR 세가지 경우의 예를 들 수 있는데， 각 예시의 경우에서 동작을 각각 설명한다. 첫 번째로， SMS-SC (또는, SMS-SC가 관리하는 제 3의 저장 노드)에서 전송이 실패한 장치 트리거 요청을 저장할 수 있다. MTC-IWF가 장치 트리거 전송이 실패한 서빙노드 (즉, SGSN/MME/MSC)로부터 전송 실패 응답 메시지를 수신하면, SMS-SC로 전송 실패한 장치 트리거 요청 메시지를 보내 저장토록 한다. 이 때 장치 트리거 요청 메시지 외에 SMS-SC로 추가적인 정보 (예를 돌어, 전송 실패한 서빙노드 (s)의 주소， 전송 시도한 횟수, 장치 트리거 요청 메시지가 SMS 형태인지 여부 등)가 함께 전달될 수 있다. SMS-SC는 MTC-IWF으로부터 수신한 장치 트리거 저장 요청 메시지에 대한 응답을 보낼 수 있다.
MTC-IWF과 SMS-SC 간의 메시지 교환은 T4 인터페이스를 이용하여 'MTC-
IWF 대 SMS-SC，의 형태로 이루어진다. 추가적으로 MTC-IWF 또는 SMS-SC가
HSS/HLR에 트리거 동작이 실패함으로 인해 단말로 전달되어야 하는 트리거가 존재한다는 정보를 설정하도록 요청하는 단계가 수행될 수 있다.
SMS-SC는 상기 저장을 요청 받은 장치 트리거에 대해서 단말로의 트리거 전달이 가능해짐을 i) 서빙노드가 SMS-SC에게 단말로의 트리거 전달이 가능해짐을 알리는 메시지를 보냄 (서빙노드와 SMS-SC 간의 메시지 교환)， ii) 단말로의 트리거 전달이 가능해짐을 알게 된 HSS/HLR이 SMS-SC에게 이를 알리는 메시지를 보냄. (HSS/HLR, SMS-IWMSC, SMS-SC 간의 메시지 교환 또는 HSS/HLR과 SMS-SC 간의 메시지 교환, 이를 위해 SMS-SC는 HSS/HLR이 제공하는 단말 관련 정보 알림 서비스에 가입할 수 있다), Hi) 단말로의 트리거 전달이 가능해짐을 알게 된 MTC-IWF가 SMS-SC에게 이를 알리는 메시지를 보냄 (MTC-IWF과 SMS-SC 간의 메시지 교환) 증 적어도 하나 이상을 통해 알 수 있다.
단말로의 트리거 전달이 가능해짐을 알게 된 SMS— SC는 자신 또는 제 3의 노드에 저장해 놓은 장치 트리거 요청 메시지를 i) SMS-SC가 서빙노드로 장치 트리거 요청 메시지를 직접 전송하고 이를 수신한 서빙노드가 상기 장치 트리거 요청 메시지를 단말로 전달 (이 때 장치 트리거 요청 메시지가 전송되는 상기 서빙노드는 SMS-SC에게 트리거되는 단말이 가용해짐을 알린 서빙 노드 일 수 있다), ii) SMS-SC가 SMS 방식에 따라 SMS-GMSC에게 SMS 형태의 장치 트리거 요청 메시지를 전송하고 SMS가 전달되는 경로를 통해 단말로 전달， iii) SMS-SC가 MTC-IWF으로 장치 트리거 요청 메시지를 전달하고 이를 수신한 MTC-IWF은 T5a/T5b/T5c 인터페이스를 통해 단말로 전달 (이 경우， 상기 MTC-IWF가 SMS- SC에게 트리거되는 단말이 가용해짐올 알리는 메시지에 대한 응답으로 SMS- SC가 저장해 놓았던 장치 트리거 요청 메시지를 MTC-IWF에게 보낼 수 있다) 중 적어도 하나 이상의 방법으로 단말로 전송한다. 두 번째로, MTC-IWF (또는, MTC-IWF이 관리하는 제 3의 저장 노드)에서 전송이 실패한 장치 트리거 요청을 저장할 수 있다. MTC-IWF가 장치 트리거 '전송이 실패한 서빙노드 (즉， SGSN/MME/MSC)로부터 전송 실패 웅답 메시지를 수신하면， 전송 실패한 장치 트리거 요청 메시지를 저장한다. 서빙노드와 MTC- IWF 간의 메시지 교환은 T5a/T5b/T5c 인터페이스를 통해 이루어진다. 추가적으로 서빙노드 또는" MTC-IWF가 HSS/HLR에 트리거 동작이 실패함으로 인해 단말로 전달되어야 하는 트리거가 존재한다는 정보를 설정하도록 요청하는 단계가 수행될 수 있다.
MTC-IWF은 상기 저장 중인 장치 트리거에 대해서 단말로의 트리거 전달이 가능해짐을 i) 서빙노드가 MTC-IWF에게 단말로의 트리거 전달이 가능해짐을 알리는 메시지를 보냄 (즉, 트리거되는 단말이 가용해짐을 (available or reachable) 또는 자신이 장치 트리거 전달 동작을 수행할 수 있게 되었음 (예를 들어, 노드가 혼잡하여 장치 트리거 전달 동작을 수행할 수 없다가 흔잡 상황이 해제되어 장치 트리거 전달 동작을 수행할 수 있게 되는 등)， 서빙노드와 MTC-IWF 간의 메시지 교환), ii) 단말로의 트리거 전달이 가능해짐을 알게 된 HSS/HLR이 MTC-IWF에게 이를 알리는 메시지를 보냄. 이 때 HSS/HLR은 트리거 전달 재시도에 필요한 서빙노드에 대한 정보를 MTC-IWF에게 제공할 수도 있다. (HSS/HLR과 MTC-IWF 간의 메시지 교환). 이를 위해 MTC-IWF은 HSS/HLR이 제공하는 단말 관련 정보 알림 서비스에 가입할 수 있다. (즉, 트리거되는 단말이 가용해짐을 (available or reachable) 또는 서빙노드가 장치 트리거 전달 동작을 수행할 수 있게 되었음을 (예를 들어, 노드가 흔잡하여 장치 트리거 잔달 동작을 수행할 수 없다가 흔잡 상황이 해제되어 장치 트리거 전달 동작을 수행할 수 있게 되는 등))， 중 적어도 하나를 통해 알 수 있다.
단말로의 트리거 전달이 가능해짐을 알게 된 MTC-IWF은 자신 또는 제 3의 노드에 저장해 놓은 장치 트리거 요청 메시지를 i) MTC-IWF가 T5a/T5b/T5c 인터페이스를 이용하여 서빙노드로 장치 트리거 요청 메시지를 전송하고 이를 수신한 서빙노드가 상기 장치 트리거 요청 메시지를 단말로 전달 (이 때 상기 서빙노드는 해당 장치 트리거 요청 메시지의 전송 실패를 알렸던 서빙노드 일 수도 있고 다른 서빙노드 일 수도 있다. 또한, 이 때 장치 트리거 요청 메시지가 전송되는 상기 서빙노드는 MTC-IWF에게 트리거되는 단말이 가용해짐을 알린 서빙 노드 일 수 있다. ii) MTC-IWF가 T4 인터페이스를 통해 SMS-SC로 장치 트리거 요청 메시지를 전송하고 SMS-SC가 SMS가 전달되는 경로를 통해 단말로 전달 (이 때 SMS-SC로 장치 트리거 요청 쩨시지를 전송할 때 추가적인 정보 (예를 들어, MTC-IWF에게 트리거되는 단말이 가용해짐을 알린 서빙 노드 등)가 함께 전달될 수 있다) 중 적어도 하나 이상의 방법으로 단말로 전송한다ᅳ
세번째로, HSS/HLR (또는 HSS/HLR이 관리하는 제 3의 저장 노드)에서 전송이 실패한 장치 트리거 요청을 저장할 수 있다ᅳ MTC-IWF가 장치 트리거 전송이 실패한 서빙노드 (즉, SGSN/MME/MSC)로부터 전송 실패 응답 메시지를 수신하면， HSS/HLR로 전송 실패한 장치 트리거 요청 메시지를 보내 저장토록 '한다. 이 때 장치 트리거 요청 메시지 외에 HSS/HLR로 추가적인 정보 (예를 들어， 전송 실패한 서빙노드의 주소, 전송 시도한 횟수, 장치 트리거 요청 메시지가 SMS 형태인지 여부 등)가 함께 전달될 수 있다. HSS/HLR은 MTC-IWF으로부터 수신한 장치 트리거 저장 요청 메시지에 대한 웅답을 보낼 수 있다. MTC-IWF과 HSS/HLR 간의 메시지 교환은 직접적인 인터페이스를 통해 MTC-IWF 대 HSS/HLR 의 형태로 이루어진다.
HSS/HLR은 상기 저장을 요청 받은 장치 트리거에 대해서 단말로의 트리거 전달이 가능해짐을 i) 서빙노드가 HSS/HLR에게 단말로의 트리거 전달이 가능해짐을 알리는 메시지를 보냄 (서빙노드와 HSS/HLR 간의 메시지 교환)， ii) 단말로의 트리거 전달이 가능해짐을 알게 된 MTC-IWF가 HSS/HLR에게 이를 알리는 메시지를 보냄 (MTC-IWF와 HSS/HLR 간의 메시지 교환) 중 적어도 하나 이상을 통해 알 수 있다.
단말로의 트리거 전달이 가능해짐을 알게 된 HSS/HLR은 자신 또는 제 3의 노드에 저장해 놓은 장치 트리거 요청 메시지를 0 HSS/HLR이 서빙노드로 장치 트리거 요청 메시지를 직접 전송하고 이를 수신한 서빙노드가 상기 장치 트리거 요청 메시지를 단말로 전달 (이 때 장치 트리거 요청 메시지가 전송되는 상기 서빙노드는 HSS/HLR에거) 트리거되는 단말이 가용해짐을 알린 서빙 노드 일 수 있다) ii) HSS/HLR이 MTC-IWF으로 장치 트리거 요청 메시지를 전달하고 이를 수신한 MTC-IWF은 T5a/T5b/T5c 인터페이스를 통해 단말로 전달 (이 경우, MTC- IWF가 HSS/HLR에게 트리거되는 단말이 가용해짐을 알리는 메시지에 대한 웅답으로 HSS/HLR이 저장해 놓았던 장치 트리거 요청 메시지를 MTC-IWF에게 보낼 수 있다)， iii) HSS/HLR이 SMS-SC로 장치 트리거 요청 메시지를 전송하고 이를 수신한 SMS-SC가 SMS가 전달되는 경로를 통해 단말로 전달 증 적어도 하나 이상의 방법으로 단말로 전송한다. 상술한 설명에서, MME/SGSN/MSC, MTC-IWF, HSS/HLR, SMS-SC와 같은 네트워크 노드들이 트리거 동작이 실패함으로 인해 단말로 전달되어야 하는 트리거 (또는 트리거 메시지를 포함하는 단문 메시지)가 존재한다는 정보, 계속증 /대기 증인 트리거가 존재한다는 정보 또는 전송 실패한 장치 트리거 요청 메시지를 저장 시 저장 및 추후 검색용 인덱스로써， 이하에서 예시되는, 것과 같은 상기 단말에 대한 식별자 (identifier)를 사용할 수 있다. 여기서, 단말에 대한 식별자는 다음 표 5와 같은 것일 수 있다.
【표 5】 i) 외부 식별자 (External Identifier, 외부 식별자 값 자체가 사용될 수도 있고, 이를 구성하는 일부의 값 (Local Identifier)만 사용될 수도 있음) ii) MSISDN
iii) IMSI
iv) 트리거 참조번호 (MTC Server가 MTC-IWF에게 장치 트리거 요청을 보낼 때 설정한 해당 트리거에 대한 참조번호를 의미)
V) 장치 트리거 요청을 보낸 SCSID vi) SCS/애플리케이션 도메인 네임 (Application domain name) 다만， 상기 식별자가 위 예시에 한정되는 것은 아니며, 트리거 되는 단말을 구분할 수 있는 정보라면 어떤 것아든 사용 가능하다. 또한, '2개 이상의 조합이 사용되어 트리거 되는 단말을 구분할 수도 있다. 또한， 네트워크 노드에 따라 서로 다른 항목을 사용할 수도 있다 예를 들어, 단말로 전달되어야 하는 트리거 (또는 트리거 메시지를 포함하는 단문 메시지)가 존재한다는 정보를 저장하는 HSS/HLR은 IMSI를 사용하고, 장치 트리거 요청 메시지를 저장하는 MTC-IWF은 외부 식별자를 사용할 수 있다. 상술한 바와 같이 MTC-IWF (또는 MTC-IWF가 관리하는 제 3의 저장 노드)에서 전송 실패한 장치 트리거 요청을 저장 후 재전송을 수행하는 방안 및 MTC-IWF (또는 MTC-IWF가 관리하는 제 3의 저장 노드) 외의 다른 노드에서 전송 실패한 장치 트리거 요청올 저장하였으나 단말로의 트리거 전달이 가능해짐을 안 후 MTC-IWF에게 상기 장치 트리거 요청 메시지를 전달하여 재전송을 수행토록 하는 방안의 장점은, MTC-IWF가 재전송 수행을 위해 T5a, T5b, T5c, T4 인터페이스와 같은 다양한 인터페이스를 활용할 수 있다는 점이다. 또한, SMS- SC와 비교하여 MTC-IWF에서 재전송 기능을 제공 시 얻을 수 있는 잇점은, 동일한 MTC 그룹에 속한 MTC 단말들을 동시에 트리거해야 하는 경우, SMS- SC의 경우 상기 각각의 단말에게 장치 트리거 메시지가 포함된 SMS를 전송하는 반면， MTC-IWF가 재전송을 수행 시 셀 브로드캐스트 (cell broadcast)와 같은 형태의 트리거 메커니즘을 사용함으로써 효율적으로 트리거 메시지가 MTC 단말들로 전송될 수 있다. 이하에서는 상술한 설명들을 바탕으로, 본 발명의 실시예에 의한 예시적인 트리거 절차에 대해 도 6 내지 도 7을 참조하여 설명한다. 구체적으로, 도 6에 대한 설명은 재시도에 관련된 정보가 재시도 수행을 지시， 즉, 재시도를 서빙노드에 위임하는 경우에 대한 것이며, 도 7에 대한 설명은 재시도에 관련된 정보가 재시도를 수행하지 않을 것을 지시하는 경우에 대한 것이다. 이하의 예시에서 구체적으로 상세되지 않은 내용들은 앞선 설명들에 의해 대체될 수 있다ᅳ 또한, 본 발명이 이하의 예시적인 트리거 절차에만 한정되는 것은 아니며， 이하에서 설명되는 에시들 및 앞선 설명들을 통해 도출할 수 있는 다른 예시도 본 발명의 범주에 속함은 당업자에게 명확할 것이다. 트리거 절차 실시예 1
도 6을 참조하면, 단계， S601에서 SCS(680)는 MTC 단말을 트리거할 것을 결정한다. SCS가 트리거 요청을 하기 위해 contact하는 MTC-IWF에 대한 정보가 없으면, 트리거하려는 MTC 단말의 외부 식별자 또는 SCS 내에 설정되어 있는 MTC-IWF의 식별자를 사용하여 DNS(670)에게 DNS 쿼리를 수행함으로써 MTC- IWF의 IP 주소 및 포트 번호를 결정할 수 있다. 단계, S602에서 SCS(680)는 MTC-IWF(660)에게 장치 트리거 요청 메시지를 보낸다. 상기 Device 트리거 요청 메시지는 다음 표 6과 같은 정보를 포함할 수 있다.
【표 6】 i) 외부 식별자 또는 MSISDN: 트리거 하려는 MTC 단말 (또는 MTC 단말이 속한 가입자)의 식별자 ii) SCS 식별자: 상기 장치 트리거 요청 메시지를 보내는 SCS의 식별자 iii) 트리거 참조 번호: 상기 전송하는 장치 트리거 요청 메시지의 참조 번호 iv) 유효구간 (validity period): 장치 트리거 요청이 유효한 시간으로, 장치 트리거가 MTC 단말로 전달되지 못하는 경우, 네트워크 엔티티 (예를 들어, MTC-IWF)로 하여금 장치 트리거 요청올 저장해야 하는 기간을 알려줌. 유효구간 정보 값이 0이거나 존재하지 않는 경우, 네트워크 엔티티 (예를 들어， MTC-IWF)는 단말 트리거 재시도를 수행하지 않을 수 있다.
V) 장치 트리거 요청의 전달 우선순위 vi) MTC 단말 상의 MTC 애플리케이션으로 전달되는 정보인 트리거 페이로드 vii) 재전송 요청 정보: 네트워크 엔티티 (예를 들어, MTC-IWF)로 하여금 단말 트리거 재시도를 수행하도록 하는 정보. 이 정보 대신 상기의 유효구간 정보로 네트워크 엔티티 (예를 들어, MTC-IWF)에게 재전송 요청을 명시적으로 또는 암시적으로 지시할 수도 있다. 단계, S603에서ᅳ SCS(680)로부터 장치 트리거 요청 메시지를 수신한 MTC- IWF(660)는 SCS가 3GPP 네트워크로 트리거 요청을 보내는 것이 허용되는 지에 대한 권한 검증을 수행한다. 만약 상기 권한 검증이 실패하면， MTC-IWF(660)는 SCS(680)에게 상기 장치 트리거 요청이 실패했음을 알리는 장치 트리거 확인 메시지를 보낸다. 권한 검증이 성공하면 다음 단계 S604를 수행한다.
단계, S604에서 MTC-IWF(660)는 HSS/HLR(650)에게 서브스크라이버 정보 요청 메시지를 보낸다. 이는 SCS가 상기 MTC 단말을 트리거하는 것이 허용되는
SCS인지를 검사하고， 수신한 MTC 단말의 식별자 (외부 식별자 또는 MSISDN)를 이용하여 IMSI를 획득하고， MTC 단말을 서빙하는 서빙노드의 식별자 (identity)를 포함하는 라우팅 정보를 획득하기 위함이다. 단계, S605에서 HSS/HLR(650)은 장치 트리거 요청 메시지를 보낸 SCS가 MTC 단말을 트리거 하도록 허용되는 SCS인지를 검사한다. 이후 HSS/HLR(650)은 MTC-IWF(660)에게 서브스크라이버 정보 웅답 메시지를 전송한다. 이 메시지는 IMSI와 MTC 단말을 serve하는 서빙노드의 식별자 (identity)를 포함한다. 만약 검사의 결과 상기 SCS가 상기 MTC 단말을 트리거하도록 허용되지 않거나， 또는 HSS/HLR(650)에 상기 MTC 단말과 관련한 유효한 서브스크립션 정보가 존재하는 않는다면， HSS/HLR(650)은 MTC- IWF(660)에게 이를 알리는 정보를 포함하는 서브스크라이버 정보 응답 메시지를 전송한다. 이 경우, MTC-IWF(660)는 SCS(680)에게 상기 장치 트리거 요청이 실패했음을 알리는 장치 트리거 확인 메시지를 보내고, 이후의 단계는 수행하지 않는다.
단계, S606에서 MTC-IWF(660)는 HSS/HLR(650)로부터 수신한 정보 및 지역 정책에 기반하여 트리거 웅답 절차를 선택한디-. 이하에서는, 가용한 서빙노드가 SGSN과 MME라고 가정하며, MTC-IWF(660)이 트리거 전달 절차로 T5b 인터페이스를 이용하는 MME로의 장치 트리거 전달을 선택하는 것으로 가정한다. 단계, S607에서 MTC-IWF(660)는 MME(630)에게 제출 (Submit) 요청 메시지를 전송한다. 이 때 MTC-IWF(660)은 제출 요청 메시지에 상기 단계 2에서 SCS(680)로부터 수신한 장치 트리거에 필요한 정보들을 그대로 또는 가공된 형태로 포함시킬 수 있다. 또한, MTC-IWF(660)은 상기 제출 요청 메시지에 MME로 하여금 장치 트리거 동작 실패 시， SGSN으로 장치 트리거 요청을 보냄으로써 재시도를 수행할 것을 가리키는 정보를 포함시킬 수 있다. 추가적으로 재시도 횟수에 대한 정보를 포함시킬 수도 있다. 또한， 재시도 허용 시간에 대한 정보를 포함시킬 수도 있다.
단계, S608에서 상기 제출 요청 메시지를 수신한 MME(630)는 장치 트리거의 타겟 단말인 UE-1(610)에게 트리거 메시지를 전달하고자 한다. 그러나, 이 전달은, 예를 들어, UE-1이 도달가능하지 하지 않거나, MME가 오버로드 상태이거나, E- UTRAN 망이 흔잡한 등의 경우에 실패할 수 있다. 전달이 실패하는 경우 다음 단계 S609로 진행한다.
단계, S609에서 MME(630)는 MTC-IWF(660)로부터 수신한 재시도 관련 정보에 기반하여 SGSN(620)으로 트리거 요청 메시지를 보냄으로써 재시도를 수행한다. 상기 트리거 요청 메시지에는 MME(630)가 MTC-IWF(660)로부터 수신한 장치 트리거에 필요한 정보들을 그대로 또는 가공된 형태로 포함시킬 수 있다. 또한, MME(630)가 자체적으로 필요한 정보 (예를 들어, 전달 실패 원인， MTC-IWF 관련 정보 등)를 포함시킬 수도 있다.
단계, S610에서 상기 트리거 요청 메시지를 수신한 SGSN(620)은 장치 트리거의 타겟 단말인 UE-1(610)에게 트리거 메시지를 전달한다. 상기 트리거 메시지를 수신한 UE-1(610)은 SGSN(620)에게 웅답을 한다. 단계, S611에서 트리거 동작을 수행한 SGSN(620)은 MME(620)에게 트리거 웅답 메시지를 보낸다. 트리거 웅답 메시지는 MME가 요청한 장치 트리거의 결과 (MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지)를 포함한다. 단계， S612에서 트리거 응답 메시지를 수신한 MME(630)는 MTC-IWF(660)에게 전달 보고 메시지를 보낸다. 전달 보고 메시지는 MTC-IWF가 요청한 장치 트리거의 결과 (즉, MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지)를 포함한다. 단계， S613에서 MTC- IWF(660)는 SCS(680)에게 장치 트리거 요청 메시지에 대한 웅답인 장치 트리거 보고 메시지를 전송한다. 장치 트리거 보고 메시지는 SCS가 요청한 장치 트리거의 결과 (MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지)를 포함한다. 단계， S614에서 수신한 장치 트리거에 대한 웅답으로 UE-1(610)은 트리거 페이로드의 내용에 기반한 동작을 수행한다. 이러한 동작은 전형적으로는 SCS 또는 AS와의 통신 개시를 포함한다.
상술한 설명의 단계 S611에서는 SGSN(620)이 MTC '단말로의 장치 트리거 메시지 전달 동작을 수행 후， MME(630)에게 웅답을 주고, 응답을 수신한 MME(630)가 단계 S612에서 MTC-IWF(660)으로 응답을 하였다. 이와 달리 SGSN(620)이 MTC 단말로의 장치 트리거 메시지 전달 동작을 수행 후， MTC- IWF(660)으로 전달 결과를 포함하는 메시지 (예를 들어, 전달 보고 메시지)를 보낼 수도 있다. 이러한 경우, 단계 S609에서 MME(630)로부터 트리거 요청 메시지를 수신한 후, SGSN(620)이 이를 잘 수신했다는 웅답 메시지를 바로 MME(630)에게 보내는 동작을 추가적으로 포함할 수 있다. 트리거 절차 실시예 2
이하， 재시도에 관련된 정보가 재시도를 수행하지 않을 것을 지시하는 경우에 있어서, 트리거 절차에 대해 도 7을 참조하여 설명한다. MTC-IWF은 직접 재전송 동작을 수행한다.
단계, S701에서， SCS(780)는 MTC 단말을 트리거할 것을 결정한다. SCS가 트리거 요청을 하기 위해 접촉하는 MTC-IWF에 대한 정보가 없으면， 트리거하려는 MTC 단말의 외부 식별자 또는 SCS 내에 설정되어 있는 MTC- IWF의 식별자를 사용하여 DNS(770)에게 DNS 쿼리를 수행함으로써 MTC-IWF의
IP 주소 및 포트 번호를 결정할 수 있다. 단계， S702에서， SCS(780)는 MTC-
IWF(760)에게 장치 트리거 요청 메시지를 보낸다. 장치 트리거 요청 메시지는 앞서 표 6과 같은 정보를 포함할 수 있다.
단계， S703에서, SCS(780)로부터 장치 트리거 요청 메시지를 수신한 MTC- IWF(760)는 SCS가 3GPP 네트워크로 트리거 요청을 보내는 것이 허용되는 지에 대한 권한 검증을 수행한다. 만약 권한 검증이 실패하면, MTC-IWF(760)는 5 SCS(780)에게 장치 트리거 요청이 실패했음을 알리는 장치 트리거 확인 메시지를 보낸다. 이와 달리 권한 검증이 성공하면 단계 S704를 수행한다. 단계, S704에서， MTC-IWF(760)는 SS/HLR(750)에게 서브스크라이버 정보 요청 메시지를 보낸다. 이는 SCS가 MTC 단말을 트리거하는 것이 허용되는 SCS인지를 검사하고， 수신한 MTC 단말의 식별자 (외부 식별자 또는 MSISDN)를 이용하여 IMSI를
10 획득하고, MTC 단말올 서빙하는 서빙노드의 식별자를 포함하는 라우팅 정보를 획득하기 위함이다. 단계, S705에서, HSS/HLR(750)은 장치 트리거 요청 메시지를 보낸 SCS가 MTC 단말을 트리거 하도록 허용되는 SCS 인지를 검사한다. 이후에 ' HSS/HLR(750)은 MTC-IWF(760)에게 서브스크라이버 정보 웅답 메시지를 전송한다. 서브스크라이버 정보 웅답 메시지는 IMSI와 MTC 단말을 서빙하는
15 서빙노드의 식별자를 포함한다. 만약 검사의 결과 SC l" MTC 단말을 트리거 하도록 허용되지 않거나, 또는 HSS/HLR(750)에 MTC 단말과 관련한 유효한 서브스크립션 정보가 존재하는 않는다면， HSS/HLR(750)은 MTC-IWF(760)에게 이를 알리는 정보를 포함하는 서브스크라이버 정보 웅답 메시지를 전송한다. 이 경우, MTC-IWF(760)는 SCS(780)에게 장치 트리거 요청이 실패했음을 알리는 장치
20 트리거 확인 메시지를 보내고， 이후의 단계는 수행하지 않는다. 단계, S706에서， MTC-IWF(760)는 HSS/HLR(750)로부터 수신한 정보 및 지역 정책에 기반하여 트리거 전달 절차를 선택한다. 이하에서 가용한 서빙노드가
MME라고 가정하며, 이에 MTC-IWF(760)은 트리거 전달 절차로 T5b 인터페이스를 이용하는 MME로의 장치 트리거 전달을 선택한다. 단계， S707에서, MTC-IWF(760)는 MME(730)에게 제출 요청 메시지를 전송한다. 이 때 MTC-IWF(760)은 제출 요청 메시지에 단계 S702에서 SCS(780)로부터 수신한 장치 트리거에 필요한 정보들을 그대로 또는 가공된 형태로 포함시킬 수 있다. 또한, MTC-IWF(760)은 제출 요청 메시지에 MME로 하여금 장치 트리거 동작 실패 시, 재시도를 수행하지 말 것을 가리키는 정보를 포함시킨다. 단계, S708에서， 제출 요청 메시지를 수신한 MME(730)는 장치 트리거의 타겟 단말인 UE- 1(710)에게 트리거 메시지를 전달하고자 한다. 그러나， 예를 들어, UE-1이 도달가능하지 않거나, MME가 오버로드 상태아거나, E-UTRAN 망이 흔잡한 등의 이유 전달이 실패할 수 있다ᅳ 단계, S709에서, 트리거 동작을 수행한 MME(730)는 MTC-IWF(760)에게 전달 보고 메시지를 보낸다. 전달 보고 메시지는 MTC-IWF가 요청한 장치 트리거의 결과 (MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지)를 포함한다.
단계, S710에서， 단계 S709에서 MTC 단말로의 트리거 전달이 실패했음을 알리는 전달 보고 메시지를 수신한 MTC-IWF(760)은 HSS/HLR(750)에게 서브스크라이버 알림 (Subscribe Notification) 메시지를 보내, HSS/HLR(750)이 제공하는 단말 관련 정보 알림 서비스에 가입한다. 알림 서비스에 가입하는 MTC 단말 (또는 MTC 단말이 속한 가입자)를 나타내기 위해 외부 식별자， MSISDN,
IMSI 중 하나 이상의 : 정보가 사용될 수 있다. 도 7에서는 MTC-IWF(760)이 T4 인터페이스를 이용하여 SMS-SC로의 재시도를 수행하지 않는 것을 결정함을 가정한다. 상기와 같이 MTC-IWF이 T4 인터페이스를 이'용하여 SMS-SC로의 재시도를 수행하지 않는 것을 결정하는 기준으로 다음 표 7에 열거된 정보 중 하나 이상의 정보가 사용될 수 있다. 그러나 다음의 정보에 국한하는 것은 아니며 다양한 정보를 기준으로 사용할 수 있다. 다음의 정보는 MTC-IWF에 설정되어 있거나 HSS/HLR, MME, SGSN, MSC, SMS-SC와 같은 다른 노드로부터 획득할 수 있다. 또한, MTC-IWF은 설정 등에 의해 T5 인터페이스를 이용하여 트리거 전송 실패 후에, 곧바로 T4 인터페이스로 재시도를 수행하는 대신 단계 S710(즉, store and forward 동작)을 수행하는 것을 결정할 수도 있다.
【표 7】 i) T4 인터페이스가 존재하지 않음.
ii) 가용한 서빙노드의 수 그리고 /또는 종류
iii) 가용한 서빙노드의 capability (예를 들어 ,T5 지원 여부, SMS 지원 여부 등) iv) 단말의 capability (예를 들어 ,T5 지원 여부)
V) 네트워크의 흔잡도 (core network, radio network, Τ5 인터페이스 , T4 인터페이스의 호 ·ς: 드、
vi) MTC-IWF의 흔잡도
vii) 트리거 요청의 priority
viii)T5로의 트리거 전달 실패 원인
ix) T4, T5 트리거 전달 관련 history (실패율 등)
X) 단말의 가용 여부 그리고 /또는 단말로의 도달가능 여부 단계, S711에서， HSS/HLR(750)은 단계 S710에서 MTC-IWF(760)로부터 받은 알림 서비스에 해당하는 MTC 단말로의 트리거 전달이 가능해짐올 안다. HSS/HLR(750)은 서빙노드 또는 다른 노드로부터 MTC 단말로의 트리거 전달이 가능해졌다는 정보를 얻을 수 있다ᅳ 단계 >S712에서, HSS/HLR(750)은 MTC-
IWF(760)에게 MTC 단말로의 트리거 전달이 가능해짐을 알리기 위해 통지 서브스크라이버 정보 (Notify Subscriber Information) 메시지를 전송한다. 이 메시지는 MTC-IWF(760)가 장치 트리거 동작을 위해 필요로 하는 다양한 정보 (예를 들어, MTC 단말을 서빙하는 서빙노드의 식별자 등)를 추가적으로 포함할 수 있다. MTC-IWF(760)은 HSS/HLR(750)로부터 수신한 정보 및 지역정책에 기반하여 트리거 전달 절차를 선택한다. 이하에서는， 가용한 서빙노드가 SGSN이라고 가정하며， 이에 MTC-IWF(760)은 트리거 전달 절차로 T5a 인터페이스를 이용하는 SGSN으로의 장치 트리거 전달을 선택한다. 그러나 이와는 달리， MTC-IWF(760)은 T4 인터페이스를 이용하는 SMS-SC로의 장치 트리거 전달을 선택할 수도 있다. 또는, 가용한 서빙노드가 MME와 SGSN이라면， MTC-IWF(760)은 트리거 전달 절차로 T5b 인터페이스를 이용하는 MME로의 장치 트리거 전달을 선택할 수도 있다.
단계, S713에서， MTC-IWF(760)는 SGSN(720)에게 제출 요청 메시지를 전송한다. 이 때 MTC-IWF(760)은 제출 요청 메시지에 단계 2에서 SCS(780)로부터 수신한 장치 트리거에 필요한 정보들을 그대로 또는 가공된 형태로 포함시킬 수 있다. 또한， MTC-IWF(760)은 제출 요청 메시지에 SGSN으로 하여금 장치 트리거 동작 실패 시， 재시도를 수행하지 말 것을 가리키는 정보를 포함시킨다.
단계, S714에서, 제출 요청 메시지를 수신한 SGSN(720)은 장치 트리거의 타¾ 단말인 UE-1(710)에게 트리거 메시지를 전달한다. 트리거 메시지를 수신한 UE-1(710)은 SGSN(720)에게 웅답을 한다. 단계, S715에서, 트리거 동작을 수행한 SGSN(720)은 MTC-IWF(760)에게 전달 보고 메시지를 보낸다. 전달 보고 메시지는 MTC-IWF가 요청한 장치 트리거의 결과 (MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지)를 포함한다. 단계， S716에서, MTC-IWF(760)는
SCS(780)에게 단계 S702의 장치 트리거 요청 메시지에 대한 응답인 장치 트리거 보고 메시지를 전송한다. 장치 트리거 보고 메시지는 SCS가 요청한 장치 트리거의 결과 (MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지)를 포함한다. 단계, S717에서, 수신한 장치 트리거에 대한 응답으로 UE-1(7.10)은 트리거 payload의 내용에 기반한 동작을 수행한다. 이러한 동작은 전형적으로는 SCS 또는 AS와의 통신 개시를 포함한다. 상술한 단계 S705에서 HSS/HLR(750)로부터 수신한 정보에 가용한 서빙노드가 다수개인 경우 (예를 들면, MME와 SGSN), MTC-IWF(760)은 MME로부터 장치 트리거 전달 실패를 알리는 웅답 메시지를 받은 후, 단계
S710을 수행하는 대신 SGSN으로 제출 요청을 보냄으로써 장치 트리거 동작을 재시도 힐- 수 있다. 그러나 이와는 달리 단계 S705에서 HSS/HLR(750)로부터 수신한 정보에 가용한 서빙노드가 다수개 인 경우라도, MTC-IWF(760)은 단계
S709에서 MME로부터 장치 트리거 전달 실패를 알리는 웅답 메시지를 받은 후， 단계 S710을 수행할 수도 있다. 이러한 결정은 지역정책， 트리거 요청의 우선순위 정보, 네트워크의 흔잡 상황, MTC-IWF의 흔잡 상황， T5^/T5b/T5c 인터페이스의 흔잡 .상황, 가입자 정보, MTC 단말의 로밍 상황, MTC-IWF 내의 설정, 단말의 가용 여부， 단말로의 도달가능 여부 등 다양한 정보에 근거할 수 있다. 또한, 단계 S710에서는 T4 인터페이스를 이용한 SMS-SC로의 재시도를 수행하지 않았으나, 이와는 달리 MTC-IWF(760)이 단계 S709에서 MTC 단말로의 트리거 전달이 실패했음을 알리는 전달 보고 메시지를 수신한 후, T4 인터페이스를 이용하여 SMS-SC로의 재시도를 수행하고, 이 또한 실패하여 단계 S7i0을 수행할 수도 있다. 이러한 경우 MTC-IWF이 SMS-SC로 재시도를 수행 시， SMS-SC에게 재전송을 위임하지 않기 위해 재시도에 관련된 정보에 재시도를 수행하지 말 것을 가리키는 정보를 포함시킬 수 있다. 상술한 본 발명의 다양한 실시예들에서 설명한 사항들은 독립적으로 적용되거나 또는 2 이상의 실시예가 동시에 적용될 수 있다. 도 8은 본 발명의 일례에 따른 단말 장치 및 네트워크 노드 장치에 대한 바람직한 실시예의 구성을 도시한 도면이다.
도 8올 참조하여 본 발명에 따른 MTC-IWF 장치 (810)는, 송수신모들 (811), 프로세서 (812) 및 메모리 (813)를 포함할 수 있다. 송수신모들 (811)은 외부 장치 (네트워크 노드 (820) 및 /또는 서버 장치 (미도시))로 각종 신호， 데이터 및 정보를 송신하고, 외부 장치 (네트워크 노드 (820) 및 /또는 서버 장치 (미도시))로 각종 신호， 데이터 및 정보를 수신하도록 구성될 수 있다. 프로세서 (812)는 MTC- IWF(810) 전반와 동작을 제어할 수 있으며, MTC-IWF(810)가 외부 장치와 송수신할 정보 등을 연산 처리하는 기능을 수행하도록 구성될 수 있다. 메모리 (813)는 연산 처리된 정보 등을 소정시간 동안 저장할 수 있으며, 버퍼 (미도시) 등의 구성요소로 대체될 수 있다.
본 발명의 일 실시예에 따른 MTC-IWF(810)의 프로세서는, 게 1 서빙노드에 상기 트리거 요청 및 상기 트리거 요청의 재시도에 관련된 정보를 전송하며, 트리거 요청 재시도에 관련된 정보는, 상기 트리거 요청 전송 실패시 재시도 수행 여부에 대한 정보를 포함하며， 상기 재시도 수행 여부에 대한 정보가 재시도 수행을 지시하는 경우 상기 트리거 요청 재시도는 상기 제 1 서빙노드에게 위임될 수 있다. 또한， 위와 같은 MTC-IWF(810)의 구체적인 구성은, 전술한 본 발명의 다양한 실시예에서 설명한 사항들이 독립적으로 적용되거나 또는 2 이상의 실시예가 동시에 적용되도록 구현될 수 있으며， 중복되는 내용은 명확성을 위하여 설명을 생략한다.
상술한 본 발명의 실시예들은 다양한 수단을 통해 구현될 수 있다. 예를 들어, 본 발명의 실시예들은 하드웨어， 펌웨어 (firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다.
하드웨어에 의한 구현의 경우， 본 발명의 실시예들에 따른 방법은 하나 또는 그 이상의 ASICs(Application Specific Integrated Circuits), DSPs(Digital Signal Processors), DSPDs(Digital Signal Processing Devices), PLDs(Programmable Logic Devices), FPGAs(Field Programmable Gate Arrays), 프로세서， 컨트를러, 마이크로 컨트롤러， 마이크로 프로세서 등에 의해 구현될 수 있다.
—펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명의 실시예들에 따른 방법은 이상에서 설명된 기능 또는 동작 ：을 수행하는 모들, 절차 또는 함수 등의 형태로 구현될 수 있다. 소프트웨어 코드는 메모리 유닛에 저장되어 프로세서에 의해 구동될 수 있다. 상기 메모리 유닛은 상기 프로세서 내부 또는 외부에 위치하여, 이미 공지된 다양한 수단에 의해 상기 프로세서와 데이터를 주고 받을 수 있다.
상술한 바와 같이 개시된 본 발명의 바람직한 실시예들에 대한 상세한 설명은 당업자가 본 발명을 구현하고 실시할 수 있도록 제공되었다. 상기에서는 본 발명의 바람직한 실시예들을 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 본 발명의 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다. 예를 들어, 당업자는 상술한 실시예들에 기재된 각 구성을 서로 조합하는 방식으로 이용할 수 있다ᅳ 따라서, 본 발명은 여기에 나타난 실시형태들에 제한되려는 것이 아니라, 여기서 개시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여하려는 것이다.
본 발명은 본 발명의 정신 및 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있다. 따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고ᅳ 본„발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다. 본 발명은 여기에 나타난 실시형태들에 제한되려는 것이 아니라, 여기서 개시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여하려는 것이다. 또한， 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함할 수 있다. 【산업상 이용가능성】
상술한 바와 같은 본 발명의 실시형태들은 다양한 이동통신 시스템에 적용될 수 있다.

Claims

【청구의 범위】
【청구항 1】
무선통신시스템에서 MTC-IWF(InterWorking Function)가 MTC(Machine Type Communication) 트리거 요청을 수행하는 방법에 있어서,
제 1 서빙노드에 상기 트리거 요청 및 상기 트리거 요청의 재시도에 관련된 정보를 전송하는 단계;
를 포함하며,
상기 트리거 요청 재시도에 관련된 정보는， 상기 트리거 요청 전송 실패시 재시도 수행 여부에 대한 정보를 포함하며， 상기 재시도 수행 여부에 대한 정보가 재시도 수행을 지시하는 경우 상기 트리거 요청 재시도는 상기 제 1 서빙노드에게 위임되는， 트리거 요청 수행 방법ᅳ
【청구항 2】
제 1항에 있어서,
상기 트리거 요청 재시도에 관련된 정보는， 가용한 서빙노드의 개수， 네트워크 흔잡 상황， 상기 MTC 단말의 선호도 , MTC 단말의 로밍 여부 증 적어도 하나 이상을 고려하여 결정되는， 트리거 요청 수행 방법.
【청구항 3】
제 1항에 있어서，
상기 트리거 요청 재시도의 위임은， 상기 트리거 요청 전달 실패시 상기 제 1 서빙노드에게 제 2 서빙노드로 상기 트리거 요청을 전달하도록 지시함을 의미하는, 트리거 요청 수행 방법. .
【청구항 4】 제 3항에 있어서,
상기 제 1 서빙노드가 단말에게 트리거 요청 전달을 실패하고, 상기 재시도 수행 여부에 대한 정보가 재시도 수행을 지시하는 경우，
상기 제 1 서빙노드는 상기 제 2 서빙노드에게 상기 트리거 요청을 전달하고, 상기 제 2 서빙노드는 단말에게 트리거 요청을 전송하는, 트리거 요청 수행 방법.
【청구항 5】
, 제 3항에 있어서，
상기 트리거 요청 재시도에 관련된 정보는 재시도 횟수 또는 재시도 허용 시간 중 하나 이상을 더 포함하는, 트리거 요청 수행 방법.
【청구항 6]
제 3항에 있어서,
상기 트리거 요청을 전송할 수 있는 가용한 서빙노드는 2 개 이상인, 트리거 요청 수행 방법.
【청구항 7】
제 3항에 있어서,
상기 제 1 서빙노드 및 상기 게 2 서빙노드는 각각 SGSN(Serving GPRS(General Packet Radio Service) Supporting Node), MME(Mobility Management Entity), MSC(Mobile Switching Center) 중 어느 하나인, 트리거 요청 수행 방법.
【청구항 8】
제 1항에 있어서, 상기 제 1 서빙노드가 단말에게 트리거 요청 전달을 실패하고, 상기 재시도 수행 여부에 대한 정보가 재시도를 수행하지 않을 것을 지시하는 경우, 상기 MTC-IWF 는 상기 제 1 서빙노드로부터 상기 트리거 요청 전달 실패를 지시하는 전달 보고 메시지를 수신하는, 트리거 요청 수행 방법.
【청구항 10】
제 9항에 있어서,
상기 MCT-IWF 가 HSS(Home Subscriber Server)/HLR(Home Location Register)로 상기 단말 관련 정보 알림 서비스 가입을 위한 서브스크라이버 알림 메시지를 전송하는 단계; 및
상기 HSS/HLR 로부터 상기 단말로의 트리거 전달이 가능해졌음올 알리는 통지 서브스크라이버 정보 메시지를 수신하는 단계;
를 더 포함하며，
상기 통지 서브스크라이버 정보 메시지는 상기 단말로 트리거 전송이 가능한 하나 이상의 서빙노드에 대한 정보를 포함하는， 트리거 요청 수행 방법.
【청구항 11】
제 10항에 있어서,
상기 통지 서브스크라이버 정보 메시지를 이용하여 상기 하나 이상의 서빙노드 중에서 제 2 서빙노드를 결정하고, 상기 제 2 서빙노드로 트리거 요청 및 트리거 요청 재시도에 관련된 정보를 전송하는 단계;
를 더 포함하는， 트리거 요청 수행 방법.
【청구항 12】
제 10항에 있어서, 상기 하나 이상의 서빙노드에 대한 정보는, 상기 하나 이상의 서빙노드의 식별자를 포함하는， 트리거 요청 수행 방법 .
【청구항 13]
제 1항에 있어서,
SCS(Service Capability Server)로부터 상기 트리거 요청을 수신하는 단계; 및 상기 트리거 요청이 유효한지 검증하는 단계;
를 더 포함하는, 트리거 요청 수행 방법.
【청구항 14】
무선통신시스템에서 MTC(Machine Type Communication) 트리거 요청을 수행하는 MTC-IWF(InterWorking Function) 장치에 있어서，
송수신 모들; 및
프로세서;
를 포함하며,
상기 프로세서는， 제 1 서빙노드에 상기 트리거 요청 및 상기 트리거 요청의 재시도에 관련된 정보를 전송하며, 상기 트리거 요청 재시도에 관련된 정보는， 상기 트리거 요청 전송 실패시 재시도 수행 여부에 대한 정보를 포함하며, 상기 재시도 수행 여부에 대한 정보가 재시도 수행을 지시하는 경우 상기 트리거 요청 재시도는 상기 제 1 서빙노드에게 위임되는, MTC-IWF 장치.
PCT/KR2012/009545 2011-11-13 2012-11-13 무선 통신 시스템에서 mtc 트리거(trigger) 방법 및 장치 WO2013070051A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/357,991 US9392396B2 (en) 2011-11-13 2012-11-13 Method and device for triggering machine-type communication MTC in wireless communication system

Applications Claiming Priority (12)

Application Number Priority Date Filing Date Title
US201161559121P 2011-11-13 2011-11-13
US61/559,121 2011-11-13
US201161565426P 2011-11-30 2011-11-30
US61/565,426 2011-11-30
US201161570779P 2011-12-14 2011-12-14
US61/570,779 2011-12-14
US201261587670P 2012-01-18 2012-01-18
US61/587,670 2012-01-18
US201261593336P 2012-02-01 2012-02-01
US61/593,336 2012-02-01
US201261678635P 2012-08-02 2012-08-02
US61/678,635 2012-08-02

Publications (1)

Publication Number Publication Date
WO2013070051A1 true WO2013070051A1 (ko) 2013-05-16

Family

ID=48290340

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/009545 WO2013070051A1 (ko) 2011-11-13 2012-11-13 무선 통신 시스템에서 mtc 트리거(trigger) 방법 및 장치

Country Status (2)

Country Link
US (1) US9392396B2 (ko)
WO (1) WO2013070051A1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9025445B2 (en) 2012-09-28 2015-05-05 Intel Corporation Machine type communication monitoring framework for 3GPP systems
EP3092836B1 (en) 2014-01-08 2021-01-20 Alcatel Lucent Method and apparatuses for delivering a trigger report for machine type communications
US10917215B2 (en) 2012-09-28 2021-02-09 Apple Inc. Systems and methods for semi-persistent scheduling of wireless communications
CN113038395A (zh) * 2014-07-03 2021-06-25 康维达无线有限责任公司 用于支持多种传输机制的网络的应用数据传递服务

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014002355A1 (en) * 2012-06-29 2014-01-03 Nec Corporation Optimization of mtc device trigger delivery
EP2880782B8 (en) * 2012-08-03 2021-01-13 Apple Inc. Device trigger recall/replace feature for 3gpp/m2m systems
US9526022B2 (en) 2012-08-03 2016-12-20 Intel Corporation Establishing operating system and application-based routing policies in multi-mode user equipment
US8913518B2 (en) 2012-08-03 2014-12-16 Intel Corporation Enhanced node B, user equipment and methods for discontinuous reception in inter-ENB carrier aggregation
US9191828B2 (en) 2012-08-03 2015-11-17 Intel Corporation High efficiency distributed device-to-device (D2D) channel access
US9036603B2 (en) 2012-08-03 2015-05-19 Intel Corporation Network assistance for device-to-device discovery
WO2014078837A1 (en) * 2012-11-19 2014-05-22 Interdigital Patent Holdings, Inc. Device initiated triggers
CN103906023B (zh) * 2012-12-28 2019-06-18 中兴通讯股份有限公司 机器类型设备mtc设备的触发信息的处理方法及装置
WO2015021608A1 (zh) * 2013-08-14 2015-02-19 华为技术有限公司 发送触发消息的方法及设备
US20150195717A1 (en) * 2014-01-06 2015-07-09 Puneet K. Jain Techniques for communication between interworking function and short message service nodes for device trigger replacement/recall
US9894464B2 (en) * 2014-03-14 2018-02-13 Intel IP Corporation Conveyance of application communication patterns from an external application server to a 3rd generation partnership project system
WO2016003034A1 (ko) * 2014-06-30 2016-01-07 엘지전자 주식회사 무선 통신 시스템에서 메시지의 포워딩을 위한 방법 및 장치
US10129689B2 (en) 2015-11-02 2018-11-13 Definition Networks, Inc. Systems and methods for machine-type communication
US10219198B2 (en) 2016-05-24 2019-02-26 At&T Intellectual Property I, L.P. System and method for short message delivery in a mobility network
EP3264804B1 (en) * 2016-06-27 2020-08-05 Vodafone GmbH Delivering a message to a mobile device in a mobile communication network
CN109996302A (zh) * 2018-01-02 2019-07-09 中国移动通信有限公司研究院 一种SGsMSC的选择方法、装置及设备
US11388273B2 (en) * 2019-05-05 2022-07-12 International Business Machines Corporation Achieving atomicity in a chain of microservices

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20110122643A (ko) * 2010-05-04 2011-11-10 엘지전자 주식회사 이동통신 시스템에서의 ｍｔｃ 서비스 네트워크 오버로드의 제어 방법 및 그 장치

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9113355B2 (en) * 2011-04-07 2015-08-18 Htc Corporation Method of handling signaling and data transmission for machine-type communication
US9756009B2 (en) * 2011-11-07 2017-09-05 Telefonaktiebolaget Lm Ericsson (Publ) Message forwarding among disparate communication networks

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20110122643A (ko) * 2010-05-04 2011-11-10 엘지전자 주식회사 이동통신 시스템에서의 ｍｔｃ 서비스 네트워크 오버로드의 제어 방법 및 그 장치

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"System Improvements for Machine-Type Communications (Release 11)", 3GPP TR 23.888 V1.5.0, 31 October 2011 (2011-10-31) *
NOKIA SIMENS NETWORK ET AL.: "Direct Delivery using T5a/T5b procedure", 3GPP SA WG2 #88, 7 November 2011 (2011-11-07), pages 2 - 115165 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9025445B2 (en) 2012-09-28 2015-05-05 Intel Corporation Machine type communication monitoring framework for 3GPP systems
US9386486B2 (en) 2012-09-28 2016-07-05 Intel Corporation Machine type communication monitoring framework for 3GPP systems
US9942791B2 (en) 2012-09-28 2018-04-10 Intel Corporation Machine type communication monitoring framework for 3GPP systems
US10524156B2 (en) 2012-09-28 2019-12-31 Intel Corporation Machine type communication monitoring framework for 3GPP systems
US10917215B2 (en) 2012-09-28 2021-02-09 Apple Inc. Systems and methods for semi-persistent scheduling of wireless communications
US11089500B2 (en) 2012-09-28 2021-08-10 Apple Inc. Machine type communication monitoring framework for 3GPP systems
EP3092836B1 (en) 2014-01-08 2021-01-20 Alcatel Lucent Method and apparatuses for delivering a trigger report for machine type communications
CN113038395A (zh) * 2014-07-03 2021-06-25 康维达无线有限责任公司 用于支持多种传输机制的网络的应用数据传递服务
CN113038395B (zh) * 2014-07-03 2022-10-28 康维达无线有限责任公司 用于支持多种传输机制的网络的应用数据传递服务

Also Published As

Publication number Publication date
US9392396B2 (en) 2016-07-12
US20140307632A1 (en) 2014-10-16

Similar Documents

Publication Publication Date Title
WO2013070051A1 (ko) 무선 통신 시스템에서 mtc 트리거(trigger) 방법 및 장치
US10051405B2 (en) Method and apparatus for MTC in a wireless communication system
US10624004B2 (en) Serving node relocating method in wireless communication system and device for same
JP6453973B2 (ja) 無線通信システムにおける多重優先順位制御方法及び装置
US9191806B2 (en) Method and apparatus for retransmitting MTC group message in wireless communication system
CN107113598B (zh) 演进分组系统中的移动台终止的通信的支持
US9344836B2 (en) Method and apparatus for triggering MTC group in wireless communication system
US9609632B2 (en) Method and device for managing RAN resources in wireless communication system
US20180146357A1 (en) Method and device for controlling multipriority in wireless communication system
KR101623021B1 (ko) 무선 통신 시스템에서 장치 트리거 /스몰 데이터 교체 /회수 방법 및 장치
US9775021B2 (en) Method and device for supporting MTC trigger of serving node in wireless communication system
KR20150032524A (ko) 무선 통신 시스템에서 영역 갱신 방법 및 장치
CN102884817A (zh) 改善的短消息递送
CN103929730A (zh) 触发消息发送的方法、设备及系统
WO2014148795A1 (ko) 근접 서비스 제공 방법 및 장치
US9967905B2 (en) Method and device for cancelling device trigger in wireless communication system
EP2805436A1 (en) Control method and device based on multiple priorities in wireless communication system
JP2013239837A (ja) ネットワークノード及びサーバ

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: 12847323

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14357991

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 12847323

Country of ref document: EP

Kind code of ref document: A1