WO2014054876A1 - 무선 통신 시스템에서 장치 트리거 /스몰 데이터 교체 /회수 방법 및 장치 - Google Patents

무선 통신 시스템에서 장치 트리거 /스몰 데이터 교체 /회수 방법 및 장치 Download PDF

Info

Publication number
WO2014054876A1
WO2014054876A1 PCT/KR2013/008779 KR2013008779W WO2014054876A1 WO 2014054876 A1 WO2014054876 A1 WO 2014054876A1 KR 2013008779 W KR2013008779 W KR 2013008779W WO 2014054876 A1 WO2014054876 A1 WO 2014054876A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
trigger
mtc
small data
iwf
Prior art date
Application number
PCT/KR2013/008779
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 EP13843747.0A priority Critical patent/EP2905991B1/en
Priority to US14/432,731 priority patent/US9554234B2/en
Priority to CN201380057224.XA priority patent/CN104756540B/zh
Priority to JP2015535559A priority patent/JP5997389B2/ja
Publication of WO2014054876A1 publication Critical patent/WO2014054876A1/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/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
    • 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]

Definitions

  • Device trigger / small data replacement / recovery method and device in a wireless communication system
  • the following description is for a wireless communication system, and more specifically, the MTC (Machine Type Communications) device ' triggering, small data replacement, recovery / cancellation method and apparatus.
  • MTC Machine Type Communications
  • MTCCMachine Type Communications refers to a communication method that includes one or more machines (Machine), also called M2M (Machine-to-Machine) communication or things communication.
  • Machine means an entity that does not require human intervention or intervention.
  • a device such as a meter or vending machine equipped with mobile communication modules, as well as a user machine such as a smartphone that can automatically connect and communicate with a network without user intervention / intervention.
  • MTC devices or terminals 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, D2D (Device ⁇ to-Device) communication), and communication between the MTC terminal and the MTC application server.
  • MTC terminals eg, D2D (Device ⁇ to-Device) communication
  • An example of communication between an MTC terminal and an MTC application server is a communication between a vending machine and a server, a point of sale (POS) device and a server, electricity, gas or water meter and a server.
  • MTC-based applications may include security, transportation, and health care.
  • a first technical aspect of the present invention is a method in which a Short Message Service-Service Center (SMS-SC) replaces / receives a device trigger in a wireless communication system.
  • SMS-SC Short Message Service-Service Center
  • Device trigger replacement / recovery method which stores a new trigger message that is referenced to a reference number.
  • the first technical aspect of the present invention may include all / parts of the following matters.
  • the first message may be based on a second message related to a device trigger received by the MTC-IWF from an SCSCServices Capability Server.
  • the second message related to the device trigger may be requesting either a replacement operation of the trigger or a retrieval operation of the trigger.
  • the first message may include a new trigger reference number only when the second message requests a replacement operation of the device trigger.
  • the first message may not include a new trigger reference number.
  • the second message may be rejected by the MTC-IWF when the SCS exceeds a quota or a rate of trigger submission to the Tsp interface.
  • the SMS-SC may be one of a plurality of SMS-SCs selected by the MTC-IWF as an SMS-SC to receive the first message based on configuration information.
  • a second technical aspect of the present invention provides a method for replacing / retrieving small data by MTC—IWF in a wireless communication system, based on an old small data reference number included in the first message; Which small data the IWF should replace / recover Confirming; And deleting the identified small data, wherein when the first message is related to the replacement of the small data, the MTC-IWF stores new small data together with the deletion of the small data. / Recovery method.
  • the second technical aspect of the present invention may include all / part of the followings.
  • the method may further include receiving the first message from the SCS.
  • the first message may be a request for either a small data replacement operation or a small data recovery operation certificate.
  • the first message may include a new small data reference number only when the first message requests to replace the small data.
  • the first message may be rejected by the MTC IWF when the SCS exceeds a quota or rate of trigger submission to the Tsp interface.
  • the deletion of the confirmed small data may include the checking of the confirmed small data.
  • the replacement / recovery of the small data may be regarded as failed.
  • the small data may be a device trigger message.
  • the network resources include resources for signaling and data exchange, resources for storing in the network until the device trigger / small data is successfully transmitted, and the like.
  • EPC Evolved Packet Core
  • 3 is a diagram for explaining an MTC trigger procedure.
  • FIG. 4 is a diagram for explaining a trigger procedure using T5.
  • 5 is a diagram for explaining a trigger procedure using T4.
  • 6 to 7 are views for explaining the T4 trigger replacement / recovery method according to an embodiment of the present invention.
  • FIGS. 8 to 9 are views for explaining a T5 trigger replacement / recovery method according to an embodiment of the present invention.
  • FIGS. 10 to 13 are views for explaining a T5 small data replacement / recovery method according to an embodiment of the present invention.
  • FIG. 14 is a diagram showing 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 substituted for components or features of another embodiment.
  • 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. have. That is, steps or parts which are not described to clearly reveal the technical spirit of the present invention among the embodiments of the present invention may be supported by the above documents. In addition, all terms disclosed in the present document can be described by the above standard document.
  • IEEE Institute of Electrical and Electronics Engineers
  • UMTS Universal Mobile Telecommunications System
  • GSM Global System for Mobile Communication
  • EPS Evolved Packet System
  • EPS IP-based packet switched core network
  • UMTS UMTS is an evolutionary network.
  • NodeB base station of UMTS network. Installed outdoors, the cover is the size of a macro cell.
  • ENodeB the base station of the EPS network. Installed outdoors and coverage is a macro cell.
  • 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 PDACPersonal Digital Assistant (PDA), a smartphone, a multimedia device, or the like, or may be a non-portable device such as a personal computer (PC) or a vehicle-mounted device.
  • the term terminal or terminal may refer to an MTC terminal.
  • IMSQP Multimedia Subsystem IP based multimedia services Providing subsystem.
  • IMSKlnternational Mobile Subscriber Identity An internationally uniquely assigned user identifier in a mobile communication network.
  • MTCCMachine Type Communications Communication performed by a machine without human intervention. It may also be referred to as M2M (Machine to Machine) communication.
  • MTC terminal (MTC UE (or MTC device ) ): A terminal (eg, vending machine, meter reading device, etc.) having a communication function through a mobile communication network and performing a specific purpose.
  • MTC UE vending machine, meter reading device, etc.
  • MTC server A server on a network that manages an MTC terminal. It may exist inside or outside the mobile communication network. It may have an interface that an MTC user can access. The MTC server may also provide MTC related services to other 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 tracking, meteorological sensors, etc.)
  • ⁇ MTC Application Server A server on the network on which MTC applications run.
  • 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 relationship with a network operator and provides a service to one or more MTC terminals.
  • MTC Group shares at least one MTC feature
  • a group of MTC terminals belonging to the MTC subscriber A group of MTC terminals belonging to the MTC subscriber.
  • SCSCServices Capability Server on the Home PLMN (HPLMN): An entity for communicating with the MTC Interworking Function (IWF) and the MTC terminal, which is connected to the 3GPP network.
  • External Identifier An identifier used by an external entity (e.g., SCS or Application Server) of a 3 GPP network to point to (or identify) an MTC terminal (or a subscriber to which the MTC terminal belongs). identifier is globally unique.
  • An external identifier consists of a Domain Identifier and a Local ldentifier as follows:
  • Domain Identifier An identifier for identifying a domain under the control of a mobile network operator. One provider may use a domain identifier for each service to provide access to different services.
  • KLocal Identifier An identifier used to infer or obtain an IMSKlnternational Mobile Subscriber Identity. Local identifiers must be unique within the application domain and are managed by the mobile network operator.
  • 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 a core network.
  • RNC Radio Network Controller
  • HLR Home Location Register
  • HSS Home Subscriber Server
  • RANAP RAN Application Part: an interface between a RAN and a node in charge of controlling a core network (MMEX Mobility Management Entity) / SGSN (Serving General Packet Radio Service (GPRS) Supporting Node) / Mobile Switching Center (MSC).
  • MMEX Mobility Management Entity MMEX Mobility Management Entity
  • SGSN Serving General Packet Radio Service (GPRS) Supporting Node
  • MSC Mobile Switching Center
  • PLMN Public Land Mobile Network
  • NAS Non-Access Stratum: A functional layer for sending 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. [31] Hereinafter, description will be made based on the terms defined above.
  • FIG. 1 is a diagram illustrating a schematic structure of EP XEvolved Packet Core).
  • EPC is a key element of System Architecture Evolution (SAE) to improve the performance of 3GPP technologies.
  • SAE is a research project to determine network structure supporting mobility between various kinds of networks.
  • SAE aims to provide an optimized packet-based system, for example, supporting various radio access technologies on an IP basis and providing improved data transfer capability.
  • the EPC is a core network of the IP mobile communication system for the 3GPP LTE system and can support packet-based real-time and non-real-time services.
  • conventional mobile communication systems ie, second or third generation mobile communication systems
  • CS circuit-switched
  • PS packet-switched
  • the functions of the core network have been implemented.
  • the sub-domains of CS and PS are unified into one IP domain.
  • 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 Packet Data Network Gateway (GW), an MMEC Mobility Management Entity (SGN), and a Serving GPRS (General GPRS). Packet Radio Service (Supporting Node) and ePDG (enhanced Packet Data Gateway) are shown.
  • SGW Serving Gateway
  • GW PDN Packet Data Network Gateway
  • SGN MMEC Mobility Management Entity
  • SGN MMEC Mobility Management Entity
  • General GPRS General GPRS
  • the SGW is an element that functions 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.
  • the SGW serves as a local mobility anchor point when the terminal moves over the area served by the eNodeB.
  • E-UTRAN Evolved-UMTS Jniversal defined in 3GPP Release -8 and later
  • Packets may be routed through the SGW for mobility in the Terrestrial Radio Access Network.
  • SGW also provides mobility with other 3GPP networks (RANs defined before 3GPP Release-8, such as UTRAN or GERAN (Global System for Mobile Communication (GSM) / Enhanced Data rates for Global Evolution (EDGE) Radio Access Network). It can also function as an anchor point.
  • RANs defined before 3GPP Release-8 such as UTRAN or GERAN (Global System for Mobile Communication (GSM) / Enhanced Data rates for Global Evolution (EDGE) Radio Access Network). It can also function as an anchor point.
  • GSM Global System for Mobile Communication
  • EDGE Enhanced Data rates for Global Evolution
  • the PDN GW corresponds to the termination point of the data interface toward the packet data network.
  • the PDN GW may support policy enforcement features, packet filtering, and charging support. It also supports mobility management between 3GPP networks and non-3GPP networks (eg, untrusted networks such as Interworking Wireless Local Area Networks (I-WLANs), trusted networks such as CDMA Code Division Multiple Access (CDMA) networks or WiMax). It can serve as an anchor point.
  • untrusted networks such as Interworking Wireless Local Area Networks (I-WLANs)
  • trusted networks such as CDMA Code Division Multiple Access (CDMA) networks or WiMax. It can serve as an anchor point.
  • CDMA Code Division Multiple Access
  • SGW and the PDN GW are configured as separate gateways in the example of the network structure of FIG. 1, two gateways may be implemented according to a single gateway configuration option.
  • the MME is an element that performs signaling and control functions to support access to a network connection, allocation of network resources, tracking, paging, roaming, handover, and the like.
  • the MME controls the control plane functions related to subscriber and session management.
  • the MME manages numerous eNodeBs and performs signaling for selecting a conventional gateway for handover to another 2G / 3G network.
  • the MME performs security procedures, terminal-to-network session handling, and idle terminal location management.
  • SGSN shall handle all packet data, such as a different 3GPP network, the mobility management and authentication of the user (authentication) for the (e.g., GPRS network).
  • the ePDG serves as a security node for untrusted non-3GPP networks (eg, I-WLAN, WiFi hotspots, etc.).
  • a terminal having IP capability is provided by an operator (ie, an operator) via various elements in the EPC not only for 3GPP access but also for non_30? Access.
  • Access to an IP service network eg, IMS.
  • FIG. 1 illustrates various reference points (eg, Sl-U, S1-MME, etc.).
  • a conceptual link is defined as a reference point connecting two functions existing in different functional entities of E—UTRAN and EPC.
  • Table 1 below 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.
  • FIG. 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 MTC and the MTC application may use services provided by the 3GPP system and optional services provided by the MTC server. have.
  • 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 the 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 in Figure 2 can access the MTC server through the reference point API, a detailed description thereof will be omitted.
  • the MTC application server may be collocated with the MTC server.
  • the MTC server (for example, the illustrated SCS server) is a server on a network that manages an MTC terminal, and is connected to a 3GPP network to communicate with nodes of a terminal and a PLMN used for MTC.
  • the MTC-Interworking Function manages the interworking between the MTC server and the operator core network and proxies the MTC operation. Can play a role.
  • MTC-IWF MTC-Interworking Function
  • one or more MTC-IWFs may be present in the home PLMN (HPLMN).
  • HPLMN home PLMN
  • the MTC-IWF can enable or disable specific functions in the PLMN by relaying or interpreting the signaling protocol on the reference point Tsp.
  • the MTC-IWF provides the functions of authenticating the MTC server before the MTC server establishes communication with the 3GPP network, authenticating the control plane request from the MTC server, and various functions related to trigger instructions described below. Can be done.
  • SMS-SC Short Message Service-Service Center
  • IP-SM-GW Internet Protocol Short Message GateWay
  • SMS Short Message Service
  • the SMS-SC may be responsible for relaying, storing—and delivering—short messages between the Short Message Entity (SME) (the entity that sends or receives the short message) and the mobile station.
  • SME Short Message Entity
  • the IP-SM-GW may be in charge of protocol interaction between the IP-based terminal and the SMS-SC.
  • a charging data function (CDF) / charging gateway function (CGF) may perform an operation related to charging.
  • the HLR / HSS can store subscriber information (IMSI, etc.), routing information configuration information, etc. and provide it to the MTC-IWF.
  • IMSI subscriber information
  • MTC-IWF routing information configuration information
  • the MSC / SGSN / MME may perform a control function such as mobility management, authentication, and resource allocation for network connection of the terminal. Regarding the triggering described below, a function of receiving a trigger instruction from the MTC—IWF and processing the message in the form of a message provided to the MTC terminal may be performed.
  • GGSNCGateway GPRS Support NodeVS-GW (Serving-Gateway) + P-GW (Packet Data Network-Gate way) may function as a gateway for connecting the core network and the external network.
  • GPRS Support NodeVS-GW Server-Gateway
  • P-GW Packet Data Network-Gate way
  • T5a One or more reference points of T5a, T5b, or T5c is called T5.
  • MTC 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, and minimum power usage are required for MTC.
  • 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 application server 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. . That is, MTC terminal triggering is required if the IP address for the MTC terminal is not available or reachable by the MTC application server (reachable to any entity or address of that entity). In other words, it means that an attempt to deliver a message fails because the entity is absent from the address. For this purpose, the MTC terminal can receive a trigger indication from the network.
  • MTC terminal When receiving the MTC terminal is required to perform the operation of the MTC application in the terminal and / or to establish communication with the MTC application server, where the MTC terminal receives a trigger instruction, a) MTC terminal Is offline (not attached to the network), b) the MTC terminal is online but not attached to the network. ) If the data connection is not established, or c) MTC terminal is online, and (uh uh chidoe status and the network) data can be assumed that the connection is established.
  • the triggering for the MTC terminal may include an IP connection (or PDN connection) through which the MTC terminal may receive data from the MTC application server.
  • IP connection or PDN connection
  • the MTC terminal When not established (or when the MTC terminal is in basic control. The signal can be received but the user data cannot be received), the MTC terminal performs the operation of the MTC application in the terminal using a triggering message. And / or make an IP connection request to the MTC 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. have.
  • 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 by 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.
  • External identifier or MSISDN Identification of MTC terminal (or subscriber to which MTC terminal belongs) to trigger ii)
  • SCS identifier Identifier of SCS sending the device trigger request message iii)
  • Trigger reference number reference number or reference number) a reference number of the device trigger request message to be transmitted
  • validity period a time period during which the device trigger request is valid, when a trigger is not delivered to the MTC terminal, For example, MTC ⁇ IWF tells the time period to store the device trigger request.
  • priority delivery priority of the device trigger request vi) trigger payload: MTC terminal
  • 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 authority verification fails, the MTC-IWFX360 sends a device trigger confirmation message to inform the SCS 380 that the device trigger request has failed. Alternatively, if the authority verification is successful, the next step may be performed.
  • MTC—IWF 360 sends a Subscriber Information Request message to the HSS / HLR 350 (S304).
  • the serving node 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 releases the MTC terminal. This is to obtain routing information including an identifier of (serving node (s)).
  • the HSS / HLR 350 causes the SCS to send the device trigger request message to trigger the MTC terminal. Check whether the allowed SCS (S305). Thereafter, the HSS / HLR 350 transmits a Subscriber Information Response message to the MTC-IWF 360. This includes the identifier of the serving node, which is the IMSI and the MTC terminal. If the check result indicates that the SCS is not allowed to trigger the MTC terminal or that there is no valid subscription information related to the MTC terminal in the HSS / HLR 350, the HSS / HLR 350 performs an MTC-IWF ( 360) and transmits a subscriber information response message including information informing this. In this case, the MTC-IWF 360 sends a device trigger acknowledgment message to the SCS 380 indicating that the device trigger request has failed, and subsequent steps are not performed.
  • MTC-IWF 360 sends a device trigger acknowledgment message to the SCS 380 indicating that the device trigger request has failed, and subsequent steps are not performed.
  • MTC—IWF 360 receives information and local information from HSS / HLR 350. Select a trigger delivery procedure based on local policy. (S306a)
  • the 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 ⁇ 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).
  • the device trigger report message indicates whether the trigger delivery to the MTC terminal succeeded or failed as a result of the device trigger requested by the SCS.
  • the UE-1 310 performs an operation based on the contents of the trigger payload (S308). This operation typically involves initiating communication with an SCS or AS (application server).
  • the MTC-IWF receives the device trigger request from the SCS in step S302 of FIG. 3, the MTC-IWF selects an appropriate trigger forwarding procedure based on information received from the HSS / HLR and the local policy (FIG. 3). Steps S304 to S306a).
  • the MTC ⁇ IWF may refer to a device trigger through the T5a interface to SGSN, the T5b interface to the MME, and the T5c interface to the MSC (T5a, T5b, T5c interface) as a T5 device trigger.
  • device trigger request to the SMS-SC via the T4 interface For example, referring to FIG.
  • 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 transmits a trigger message to the UE-K410, which is a target terminal of the device trigger (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.
  • the MTC—IWF 560 is based on information included in the device trigger request message received from the SCS 580 and information included in the subscriber information voice response message received from the HSS / HLR 550. On the other hand, it transmits a submit trigger message to the SMS-SCX540 (S501).
  • the SMS-SC 540 transmits a submission trigger confirmation message to the MTC-IWF 560 in response to receiving the submission trigger message (S502).
  • the MTC-IWF 560 receiving the submission trigger confirmation message from the SMS ⁇ SCX540 transmits a device trigger confirmation message to the SCS 580 indicating that the device trigger request message sent by the SCS has been received (S503).
  • SMS—SCX540) provides an MTC in case a short message transmission fails. -Stores necessary information except routing information among the information received from the IWF (560).
  • the serving node 520 transmits a short message to the UE-K510 (S505).
  • the UE- 1 510 may respond to the serving node 520.
  • Servingnode 520 is an SMS—
  • the delivery report message is SMS-
  • the SMS-SC 540 obtains routing information for delivering a short message to the UE-K510 through interrogation with the HSS / HLR 550, and then, in step S504. Retransmission can be performed using the stored information.
  • the SMS-SC 540 sends a message delivery report message to the MTC-IWF 560 to indicate whether the trigger delivery to the MTC terminal succeeded or failed as a result of the device trigger requested by the MTC-IWF. (S507).
  • Table 4 shows typical device trigger message information that must be saved after SMS-SC receives a request for device trigger message from MTC-IWF before it informs MTC-IWF of the transmission result (success or failure). .
  • External identifier or MSISDN Identification information of triggered MTC terminal (or subscriber to which the MTC terminal belongs). Used to send a Message Delivery Report message to the MTC-IWF.
  • IMSI identification information of the triggered MTC terminal (or subscriber to which the MTC terminal belongs)
  • trigger reference number or reference number a reference number of the transmitting device trigger request message. Used when sending a Message Delivery Report message to the MTC-IWF.
  • SCS identifier The identifier of the SCS that sends the device trigger request message. Used when sending a Message Delivery Report message to the MTC-IWF. .
  • Trigger payload Information delivered to the MTC application on the MTC terminal
  • Routing Information for SMS The serving node to which the short message including the device trigger message is delivered.
  • Priority The delivery priority of the device trigger request.
  • validity period The time period during which the device trigger request is valid, and when the trigger cannot be delivered to the MTC terminal, the period during which the device trigger request should be stored.
  • SMS application port ID The purpose of the short message is to trigger the device. Indicates that Allow a short message to be delivered to the triggering function in the MTC terminal.
  • the trigger for the MTC terminal transmitted through the T4 / T5 interface may fail to be available / reachable and thus may fail to be delivered to the terminal.
  • the MTC terminal may be out of coverage, unable to process a trigger message by other task processing, or there may be a lack of storage space.
  • the network node stores the trigger message and retries the transmission for the validity period of the trigger message.
  • the trigger message may be redundant or unnecessary even if the trigger message is not completed. For example, if an undelivered trigger message requires the terminal to transmit the measurement result through the sensor A, and the next trigger requires the terminal to transmit the measurement result through all the sensors, the previous trigger message is retried. It may be desirable to cancel / recall or replace with a new trigger message rather than being forwarded. In other words, if the network fails to cancel / retrieve an undelivered trigger message, an unnecessary trigger message will be delivered to the terminals or stored at the network node for delivery to the terminal, which would result in waste of network resources. Therefore, hereinafter, the trigger message for the MTC terminal will be described in the cancellation / recovery or replacement.
  • the trigger message may be replaced with small data and the small data may be replaced with the trigger message.
  • the small data may be referred to as small amounts of data or small size of data.
  • the first embodiment relates to replacing, canceling / retrieving a T4 trigger message.
  • the SMS-SC may receive a first message including an old trigger reference number from the MTC-IWF and delete a trigger message corresponding thereto.
  • trigger message replacement that is, if the first message contains a new trigger reference number
  • SMS—SC deletes the trigger message corresponding to the old trigger reference number and corresponds to the new trigger reference number. You can save the trigger message.
  • the stored new trigger message may be delivered to the terminal if the terminal is available.
  • the first message may be a submit trigger cancel / recovery message or a submit trigger replace message, as described below, wherein the first message is based on a second message related to the device trigger received by the MTC-IWF from the SCS. It can be to
  • the second message may be a request for any one of a trigger replacement operation or a retrieval / cancellation operation of the trigger.
  • the message 2 may be a device trigger cancellation / recovery request message or a device trigger replacement request message.
  • the second message may be in the form of a Device Action Request message in which the action type is set to any one of device trigger cancellation / recovery or replacement.
  • the second message may be in the form of a device trigger request message in which the request type is set to any one of device trigger cancellation / recovery or replacement.
  • the second message like the first message, also includes a new trigger reference number only when requesting a replacement of the device trigger and may not be included when requesting cancellation / retrieval of the device trigger.
  • the second message may be rejected by the MTC-IWF when the SCS exceeds a quota or rate of trigger submission to the Tsp interface.
  • the MTC—ICW may determine the SMS' SC to which the first message is sent based on the configuration.
  • the MTC-IWF may send an SMS-SC that stores old trigger messages (for example, before the MTC—IWF requested transmission of old trigger messages). After obtaining information (from another network node) about the SMS-SC, it is possible to determine the SMS-SC to which to send the first message.
  • FIG. 6 is a diagram to describe replacement of a T4 trigger message.
  • the SCS may determine whether it is necessary to cancel / recover and / or replace a previously submitted trigger message.
  • SCS can request device trigger cancel request message (External Identifier or MSISDN, SCS Identifier, old trigger reference number, new trigger reference number, validity (validity) period, priority, trigger payload, etc.) may be transmitted to the MTC ⁇ IWF.
  • the old trigger refnum may indicate the trigger refnum assigned to the previously submitted trigger message that the SCS wishes to cancel.
  • a new trigger refnum can be assigned by the SCS to a newly submitted trigger message. While the validity period, priority, and trigger payload are for the new trigger message, the external identifier, MSISDN, and SCS identifier are all associated with the old trigger message (for example, the pending witness trigger message) and the new trigger message. It is related.
  • the device trigger cancellation / recovery request message may be a newly defined message, and the device triggering procedure over Tsp operation of the existing Tsp (for details, refer to Section 5.2.1 of TS 23 ⁇ 682 ⁇ 11.2.0. It may also be a device trigger request message used for Additionally, the message may explicitly / implicitly include information indicating that a new trigger message is required to replace an existing pending trigger message.
  • a device trigger cancel / recovery request message for requesting to replace a pending trigger message may be an existing device trigger request message, i.e., a Device-Action-Request message / command.
  • a new Action-Type value for example Action-Type II "Replace" (specifically
  • a specifically enumerated value meaning "replace” or Integer value) can be defined and used.
  • the existing AVP can be extended or a new AVP can be used to include the information required for the replacement request.
  • Another example is to define a new message / command that requests canceling / retrieving and / or replacing pending trigger messages, including the action-type AVPs defined for recall and replacement respectively.
  • a message / command for requesting to cancel / recover a pending trigger message and a message / command for requesting to replace a pending trigger message may be defined and used, respectively.
  • the aforementioned device trigger cancellation / count and / or replacement request message transmitted by the SCS to the MTC-IWF may also be applied to the second and third embodiments.
  • the SCS may set the new trigger refnum to the same value as the old trigger refnum.
  • the device trigger cancel / recovery request message may include both the old trigger reference number and the new trigger reference number, or may include only one trigger reference number value.
  • the priority value for the pending trigger message is additionally taken. Can be included in a small / recovery request message.
  • the priority value associated with the pending trigger message may indicate whether there is a priority in canceling the pending trigger message.
  • the priority (or urgency) of canceling a mooring trigger message may be indicated by various types of messages and / or parameters and / or information.
  • step S602 the external identifier of the received device trigger cancellation request message
  • the MTC-IWF may identify which trigger message should be deleted in the course of the replacement with the new trigger message.
  • MTC-IWF is an external identifier
  • the MTC-IWF accepts (or rejects) the device trigger cancel / recovery request message when the SCS exceeds a quota or rate for trigger submission to the Tsp interface based on one or more of the following information: Can be determined.
  • Other device trigger related information stored in the MTC-IWF and device trigger related information obtained from another node for example, HSS.
  • the MTC-IWF may also manage quotas or rates for trigger cancellation allowed to the SCS, apart from quotas or rates for trigger submissions allowed to the SCS, in which case If the quota or rate is exceeded, the SCS may not accept (or reject) the device trigger cancel / recovery request message sent.
  • the MTC-IWF may determine whether to accept (or reject) the device trigger cancellation / recovery request message when the Tsp interface to the SCS is overloaded based on one or more of the following information.
  • MTC-IWF Device trigger related information and other nodes stored in MTC-IWF Device trigger related information obtained from (eg HSS)
  • the device trigger cancellation / recovery request message may accept (or reject) only the cancellation request of the pending trigger message and reject the request to submit a new trigger message. For example, if the SCS exceeds the quota or rate for trigger submission (or trigger cancellation) to the Tsp interface and / or is an overload situation on the Tsp interface and / or an overload situation on the T4 interface, the priority of the new trigger message If there is no priority and only pending trigger messages have priority, the MTC-IWF may only accept (or reject) a request to cancel pending trigger messages, and reject a request to submit a new trigger message.
  • the SCS may include information requesting that the cancellation of pending trigger messages be performed. have.
  • the SCS provides information requesting to reject the cancellation of pending trigger messages if the request to submit a new trigger message is explicitly and implicitly rejected. Including it may prevent the two operations from being performed in a separate form.
  • the submit trigger cancel message may be a newly defined message or a submit trigger used for an existing trigger delivery using T4 operation (see section 5.2.2 of TS 23.682 vll.2.0).
  • the message may explicitly / implicitly include information indicating that a new trigger message is required to replace an existing pending trigger message.
  • the SCS includes only one trigger refnum value in the device trigger cancel / recovery request message instead of including both the old and new trigger refnums
  • the MTC-FWF includes only one trigger refnum value in the submit trigger cancel message.
  • the old and new trigger reference numbers can be set to the trigger reference number values received from the SCS to include both.
  • the MTOIWF may request subscriber information from an HSS / HLR (not shown in FIG. 6) and / or the SCS apparatus. You can send a message requesting to check / authenticate whether the 'cancel / recover and replace' or 'replace' for a trigger is an SCS that is allowed.
  • the request message includes the request
  • the HSS / HLR receiving the request checks / authenticates whether the SCS is allowed to cancel / retrieve and / or replace the trigger for the MTC terminal.
  • the SCS then sends a response message to the MTC-IWF.
  • the answer message may include subscriber information (eg, IMSI, routing information including an identifier of a serving node serving an MTC terminal). If the inspection / authentication result does not allow the SCS to cancel / receive and / or replace the trigger for the MTC terminal, or if there is no valid subscription information related to the MTC terminal in the HSS / HLR, the HSS.
  • the MTC-IWF sends a response message containing information informing the MTC-IWF.
  • the MTC-IWF sends a message indicating to the SCS that the device trigger cancellation / recovery and / or replacement request has failed, and subsequent steps are not performed.
  • the aforementioned MTC-IWF performs interaction with the HSS / HLR may also be applied to the second and third embodiments.
  • a device trigger cancel request message sent to the MTC-IWF If not, it may be performed only or if only the external identifier is included as an identifier of the MTC terminal.
  • the SMS-SC may remove / delete the information related to the stored old trigger message (which may be pending) and / or the old trigger message identified by the old trigger reference number.
  • the SMS-SC may store information related to a new trigger message and / or a new trigger message to be delivered when the terminal is available.
  • the trigger message and / or information related to the trigger message may be the information described above in Table 4.
  • step S604 the SMS—SC sends a pending trigger message (at SMS-SC). You can send a submit trigger cancel response message to the MTC-IWF to indicate that it has been successfully replaced with a new trigger message.
  • the Submit Trigger Cancel Response message may be a newly defined message or may be used for trigger propagation operation using the existing T4 interface (see Section 5.2.2 of TS 23.682vl l.2.0). It may also be a Submit Trigger Confirm message or a Message Delivery Report message. In addition, the message may explicitly / implicitly include information indicating that the message is a response message to the message requesting to replace the existing pending trigger message with a new trigger message.
  • step S605 the MTC-IWF sends a Device Trigger Cancel Report message including an external identifier, an MSISDN, an old trigger reference number, and a new trigger reference number to determine whether the trigger cancellation is successful or failed. If so, it can be sent to the SCS with a cause value indicating the reason.
  • the device trigger cancellation report message may be a message newly defined for the present invention, and the device trigger report used for the device trigger procedure operation on the existing Tsp (see section 5.2.1 of TS 23.682vl l.2.0).
  • Message Device Trigger Report message
  • DNR Device-Notification-Request
  • the message may explicitly / implicitly include information indicating that the message is a response message to a message requesting to replace an existing pending trigger message with a new trigger message.
  • the SCS may determine whether it is necessary to cancel a previously submitted trigger message.
  • SCS device trigger cancel request message (External Identifier) or MSISDN, SCS Identifier (SCS)
  • old trigger reference number or trigger reference number can be transmitted to MTC-IWF.
  • Old trigger refnum old trigger refnum
  • the device trigger cancel / recovery request message may be a message newly defined for the present invention, or may be used for device trigger procedure operation on an existing Tsp (see Section 5.2.1 of TS 23.682vl l.2.0). It may also be a trigger request message. In addition, the message may explicitly / implicitly include information that requests to cancel an existing pending trigger message.
  • a device trigger cancel / demand request message for requesting to cancel a pending trigger message may be an existing device trigger request message, that is, a device-action-request message / command (see section 2.2.3 above).
  • the existing AVP may be extended or a new AVP may be defined and used to include information required for the retrieval request.
  • Another example would be to define a new message / command that requests retrieval or replacement of pending trigger messages, including action-type AVPs defined for retrieval and replacement, respectively.
  • the message / command requesting to cancel / recover the pending trigger message and the message / command requesting to replace the pending trigger message may be defined and used, respectively.
  • the device trigger cancellation / recovery request message transmitted by the SCS to the MTC-IWF may also be applied to the second and third embodiments.
  • the device trigger cancellation / recovery request message may additionally include a priority value for the pending trigger message.
  • the priority value associated with the pending trigger message may indicate whether there is a priority in canceling the pending trigger message.
  • the priority (or urgency) in canceling pending trigger messages may be indicated by various types of messages and / or parameters and / or information.
  • step S702 the external identifier of the received device trigger cancellation request message
  • the MTC-IWF may include an external identifier, MSISDN, IMSI, SCS identifier, old trigger reference number (or trigger reference).
  • the submission trigger cancellation message including the number) may be sent to the SMS-SC.
  • the MTC-IWF determines whether to accept (or reject) the device trigger cancel / recovery request message when the SCS exceeds the quota or rate for trigger submission to the Tsp interface based on one or more of the following information. You can decide.
  • the MTC-IWF may also manage quotas or rates for trigger cancellations allowed to the SCS, apart from the quotas or rates for trigger submissions allowed to the SCS, in which case the quotas for trigger cancellation or If the rate is exceeded, the SCS may not accept (or decline) the device trigger cancel / recovery request message sent.
  • the MTC—IWF may determine whether to accept (or reject) the device trigger cancellation / recovery request message when the Tsp interface to the SCS is overloaded based on one or more of the following information.
  • the submission trigger cancellation message may be a newly defined message or an existing message. It may also be a submit trigger message used for trigger delivery operations using the T4 interface (see Section 5.2.2 of TS 23.682vl l.2.0). In addition, the message may explicitly or implicitly include information that requests to cancel an existing pending trigger message.
  • the MTC—IWF may request the subscriber information from the HSS / HLR (not shown in FIG. 7) and / or the SCS may cancel / retrieve and And / or send a message requesting inspection / authentication to see if it is an SCS that is allowed to replace or cancel or recover
  • the request message may explicitly or implicitly include information indicating that the request is due to a cancellation / retrieval and / or replacement request for a device trigger from the SCS.
  • the HSS / HLR received the request checks / authenticates whether the SCS is an SCS that is allowed to cancel / retrieve and / or replace a trigger for the MTC terminal. The SCS then sends a response message to the MTC—IWF.
  • the answer message may include subscriber information (eg, IMSI, routing information including an identifier of a serving node serving an MTC terminal).
  • subscriber information eg, IMSI, routing information including an identifier of a serving node serving an MTC terminal.
  • the HSS / HLR sends a response message containing information informing the MTC-IWF.
  • the MTC-IWF sends a message indicating to the SCS that the device trigger cancellation / recovery and / or replacement request has failed, and subsequent steps are not performed.
  • the aforementioned MTC-IWF performs interaction with the HSS / HLR may also be applied to the second and third embodiments.
  • the above-described process of MTC ⁇ IWF to interact with the HSS / HLR does not include the MSiSDN as the identifier of the MTC terminal in the device trigger cancellation request message transmitted by the SCS to the MTC-IWF in step S701. If not, it may be performed only or if only an external identifier is included as an identifier of the MTC terminal.
  • step S703 the SMS—SC is confirmed by the old trigger reference number, stored
  • the old trigger message eg pending
  • / or other information included in the received submission trigger cancellation message eg, one or more of an external identifier, MSISDN, IMSI, SCS
  • the SMS-SC may store a new trigger message to be delivered when the terminal is available.
  • the SMS-SC may transmit a submission trigger cancel response message to the MTC-IWF to inform that the pending trigger message (in the SMS-SC) has been successfully removed / received as a new trigger message. have.
  • the submit trigger cancel response message may be a message newly defined for the present invention, or a submit trigger used for a trigger forwarding operation using an existing T4 interface (see Section 5.2.2 of TS 23.682vl l.2.0). It may also be a confirmation message or a message delivery report message. In addition, the message may explicitly / implicitly include information indicating that the message is a response message to the message requesting the cancellation of the existing pending trigger message.
  • the MTC-IWF sends a Device Trigger Cancel Report message including an external identifier, an MSISDN, and an old trigger reference number. Send to the SCS together with the indicated cause value.
  • the device trigger cancellation report message may be a message newly defined for the present invention, or a device trigger used for an existing device trigger procedure operation (see section 5.2.1 of TS 23.682vl l.2.0). It may be a report message. In addition, the message may explicitly / implicitly include information indicating that the message is a male and female answer message to the message requesting to cancel the existing pending trigger message.
  • the MTC-IWF if a plurality of SMS-SCs are connected to the MTC-IWF, the MTC-IWF generates a request message or device trigger to cancel / recover the device trigger. It is necessary to select / determine the SMS-SC to which the request message for replacement is sent. This is the oldest of the multiple SMS-SCs. This is because a replacement, cancel / recovery request message must be sent to the SMS-SC that stores the trigger message (that is, the SMS-SC previously requested by the MTC—the IWF to send the old trigger message).
  • the MTC-IWF may select / determine the SMS-SC in one or more of the following ways.
  • an SMS—SC that sends a device trigger transmission request message (submit trigger message in step S5C11 of FIG. 5) to each MTC-IWF may be configured.
  • the SMS-SC that receives the first message related to the replacement and cancellation / recovery of the T4 trigger message is configured for each terminal. That is, based on the configuration, the MTC-IWF can determine the SMS-SC to which the first message is sent.
  • SMS-SC-1 is set for terminal-1
  • terminal-2 and SMS-SC-2 is set for terminal-3 and terminal-4, so the device trigger can be replaced, canceled / recovered.
  • Request message to send is also sent to SMS-SC.
  • one or more of an external identifier and an MSISDN may be used for identification of the terminal, and other information may be used to determine / select an SMS-SC assigned / configured for a specific terminal.
  • the MTC-IWF stores an old trigger message that requires the HSS / HLR to perform a device trigger replacement, cancellation / request. Obtain and request information about the SMS—SC) that requested the transmission.
  • the HSS / HLR receives a message requesting SMS-SC information from the MTC-IWF
  • the HSS / HLR sends the SMS-SC information (eg, SMS-SC address, name, identifier, etc.) to the MTC-IWF. to provide.
  • SMS Session-Service Center mechanism
  • the HSS / HLR may store the SMS—SC address / information for the UE / UE. Based on this, HSS / HLR sends SMS—to MTC-IWF. Upon receiving a message requesting SC information, SMS-SC information may be provided. The HSS / HLR may maintain or delete the SMS-SC information after the UE / UE becomes available and sends a notification message informing the SMS-SC. In the latter case, upon receiving a message requesting SMS-SC information from the MTC-IWF, the HSS / HLR may no longer store the SMS-SC information.
  • the HSS / HLR sends an acknowledgment (explicitly or implicitly) to the MTC-IWF that it cannot provide SMS-SC information.
  • the MTC-IWF receives the response, i) sends a response message to the SCS indicating that the replacement, cancellation / retrieval request for the device trigger has failed, or H) the SCS makes a request to cancel / retrieve the device trigger, Sends a response message to the SCS indicating that the cancel / recovery request for the device trigger has failed:
  • the SCS makes a request to replace the device trigger, it performs a T4 transmission of the new trigger message.
  • SMS-SC information may be obtained from the HSS / HLR requests and / or requests subscriber information that may be performed prior to step S602 of embodiment la and step S702 of embodiment lb. May be a message exchanged to request inspection / authentication for the SCS.
  • the message may include information that implies that the MTC-IWF requests SMS—SC information, either explicitly or implicitly.
  • the aforementioned method of selecting / determining the SMS-SC can be applied throughout the present invention.
  • a method can be used even if a plurality of the control being a 'single SMS-SC is not connected to the MTC-IWF.
  • the SMS-SC selection / decision method based on the configuration described above in i) may be extended in the case of T5 type device trigger transmission according to the second embodiment. That is, when the SCS is connected to multiple MTC-IWFs, the MTC—IWF that stores the old trigger message to send a replacement, cancel / recovery request for the old trigger message (that is, the SCS previously triggered the old trigger message). The replacement, cancellation / recovery request message should be sent to the MTC-IWF requesting to send a message to the MTC-IWF. Based selection schemes can be used
  • the second embodiment relates to the replacement, cancellation / retrieval of T5 trigger messages.
  • the MTC-IWF may identify which trigger message should be canceled / counted or replaced based on the old trigger reference number included in the first message, and may delete the identified trigger message. have. If the first message is related to the replacement of the trigger message (for example, when the first message includes a new trigger reference number), the MTC-IWF deletes the trigger message corresponding to the old trigger reference number, and ( You can save a new trigger message (corresponding to the new trigger refnum). The stored new trigger message may be delivered to the terminal if the terminal is available.
  • the first message may be a submit trigger cancel / recovery message or a submit trigger replace message, which may be a message related to a device trigger received by the MTC-IWF from the SCS.
  • the first message may be a request for any one of a trigger replacement operation or a retrieval / cancellation operation of the trigger.
  • the first message may be a device trigger cancellation / recovery request message or a device trigger replacement request message.
  • the first message may be in the form of a device action request message in which the action type is set to any one of device trigger cancellation / recovery or replacement.
  • the first message may be rejected by the MTC-IWF if the SCS exceeds the quota or rate of trigger submission to the Tsp interface.
  • step S801 the SCS may determine whether it is necessary to cancel a previously submitted trigger message.
  • the SCS may send a device trigger cancel request message (including external identifier or MSISDN, SCS identifier, old trigger reference number, new trigger reference number, validity period, priority, trigger payload, etc.) to the MTC-IWF.
  • Old trigger refnum is a previously submitted trigger that the SCS wants to cancel It can indicate the trigger reference number assigned to the message.
  • the new trigger reference number may be assigned by the SCS to the newly submitted trigger message.
  • the validity period, priority, and trigger payload are for the new trigger message, whereas the external identifier,
  • the MSISDN and SCS identifiers are all associated with old trigger messages (eg pending trigger messages) and new trigger messages.
  • the device trigger cancellation / recovery request message may be a newly defined message, and the device triggering procedure over Tsp operation on the existing Tsp (for details, refer to 5.2.1 of TS 23.682vll.2.0). It may also be a device trigger request message used for reference. In addition, the message may explicitly / implicitly include information indicating that a new trigger message is required to replace an existing pending trigger message.
  • the SCS may set the new trigger reference number to the same value as the old trigger reference number.
  • the device trigger cancellation / recovery request message may include both the old trigger reference number and the new trigger reference number, or may include only one trigger reference number value.
  • priority information if the priority value for the pending trigger message and the priority value for the new trigger message are different (or the same), the priority value for the pending trigger message is additionally canceled. Can be included in the recall request message.
  • the priority value associated with the pending trigger message may indicate whether there is a priority in canceling the pending trigger message. However, the priority (or urgency) of canceling pending trigger messages may be indicated by various types of messages and / or parameters and / or information.
  • the MTC-IWF On the basis of the information of one or more of an external identifier, an MSISDN, an SCS identifier, and an old trigger reference number of the received device trigger cancellation request message, the MTC-IWF must delete any trigger message in the process of replacing it with a new trigger message. You can identify it.
  • T5 interface and / or overload situation of T4 interface-Other device trigger related information stored in MTC-IWF and device trigger related information acquired from another node (for example, HSS)
  • the MTC-IWF may also manage quotas or rates for trigger cancellations allowed to the SCS, in addition to the quotas or rates for trigger submissions allowed to the SCS, in which case the quotas or rates for trigger cancellations. If exceeded, the SCS may not accept (or reject) the device trigger cancel / recovery request message sent.
  • the MTC-IWF may determine whether to accept (or reject) the device trigger cancellation / recovery request message when the Tsp interface to the SCS is overloaded based on one or more of the following information.
  • MTC device trigger related information stored by the IWF and device trigger related information obtained from another node (eg HSS).
  • another node eg HSS
  • the device trigger cancellation / recovery request message may be requested. Only requests to cancel pending trigger messages may be accepted (or rejected), and requests to submit new trigger messages may be rejected. For example, if the SCS exceeds the quota or rate for trigger submission (or trigger cancellation) to the Tsp interface and / or the overload situation of the Tsp interface and / or the overload situation of the T5 interface, the priority of the new trigger message If there is no priority and only a pending trigger message has priority, the MTC-IWF may only accept (or reject) a request for canceling / retrieving a pending trigger message and may reject the request for submitting a new trigger message.
  • the SCS when the SCS sends a device trigger cancel / recovery request message to the MTC-IWF, information requesting that the cancel / recovery of pending trigger messages must be performed even if the request to submit a new trigger message is explicitly or implicitly rejected. It may also include.
  • SCS sends a device trigger cancel / recovery request message to the MTC—IWF, it also rejects the cancel / recovery of pending trigger messages if the request to submit a new trigger message is explicitly / implicitly rejected.
  • the two operations can be prevented from being performed in separate forms.
  • the MTC-IWF may perform an operation of replacing a pending trigger message with a new trigger message.
  • the replacement operation may differ somewhat depending on which network node the pending trigger message is stored as follows.
  • the MTC-IWF If the MTC-IWF is storing a pending trigger message (or performing a store & forward function), the MTC-IWF removes information related to the pending trigger message and / or pending trigger message. / Delete and store information related to the new trigger message and / or the new trigger message. If the serving node (ie, MSC / SGSN / MME) is storing a pending trigger message (or performing a store & forward function), the MTC-IWF is storing the pending trigger message. A message can be sent to the serving node (via the T5 interface or via another node) to request that the pending trigger message be removed and the new trigger message saved.
  • the MTOIWF A message may be sent to another node that is storing the pending trigger message (via an interface with another node or through another node) to request that the pending trigger message be removed and the new trigger message stored.
  • the MTC-IWF may display a Device Trigger Cancel Report message including an external identifier, an MSISDN, an old trigger reference number, and a new trigger reference number. If so, it can be sent to the SCS with a cause value indicating the reason.
  • the device trigger cancel message may be a newly defined message, or a device trigger report message or Device-Notification-Request (used for the operation of a device trigger procedure on an existing Tsp (see Section 5.2.1 of TS 23.682vl l.2.0).
  • DNR DNR
  • the message may explicitly / implicitly indicate information indicating that the message is a response message to a message requesting to replace an existing pending trigger message with a new trigger message.
  • the SCS may determine whether it is necessary to cancel a previously submitted trigger message.
  • the SCS may send a device trigger cancel request message (including external identifier or MSISDN, SCS identifier, old trigger reference number or trigger reference number, etc.) to MTC—IWF.
  • the old trigger reference number (or trigger reference number) may indicate the trigger reference number assigned to the previously submitted trigger message that the SCS wishes to cancel.
  • the device trigger cancel / recovery request message may be a newly defined message or a device trigger request message used for an existing device trigger procedure operation (see section 5.2.1 of TS 23.682vl l.2.0). It may be. In addition, the message may explicitly / implicitly include information that requests to cancel an existing pending trigger message.
  • the device trigger cancel / recovery request message additionally triggers pending. It may include a priority value for the message.
  • the priority value associated with the pending trigger message may indicate whether there is a priority in canceling / retrieving the pending trigger message.
  • the priority (or urgency) in canceling / retrieving pending trigger messages may be indicated by various types of messages and / or parameters and / or information.
  • the MTC-IWF determines whether to accept (or reject) the device trigger cancel / recovery request message when the SCS exceeds the quota or rate for trigger submission to the Tsp interface based on one or more of the following information. You can decide. In addition to the following information, it can be based on various information. '
  • Device trigger related information obtained from (eg HSS)
  • the MTC-IWF may also manage quotas or rates for trigger cancellations allowed to the SCS, apart from the quotas or rates for trigger submissions allowed to the SCS, in which case the quotas or rates for trigger cancellations have been exceeded.
  • the SCS may not accept (or reject) the device trigger cancel / recovery request message sent by the SCS.
  • the MTC-IWF may determine whether to accept (or reject) the device trigger cancellation / recovery request message when the Tsp interface to the SCS is overloaded based on one or more of the following information. In addition to the following information, it can be based on a variety of information.
  • MTC device trigger related information stored by the IWF and device trigger related information obtained from another node (eg HSS).
  • another node eg HSS
  • the MTC-IWF may perform an operation of canceling / retrieving a pending trigger message.
  • the cancel / recovery operation may be somewhat different depending on which network node the pending trigger message is stored as follows.
  • MTC-IWF If the MTC-IWF is storing a pending trigger message (or performing a store & forward function), the MTC—IWF removes / deletes the pending trigger message. MTC—IWF is the availability of the UE. If you have subscribed to the notification service for another node (e.g. HSS / HLR) to know its availability, you may perform the further action of disabling it, if the serving node (ie MSC / SGSN / MME).
  • the serving node ie MSC / SGSN / MME
  • MTC—IWF Stores a pending trigger message (or performs a store and forward function), MTC—IWF sends a message to the serving node that is storing the pending trigger message (via the T5 interface or Request to remove / delete pending trigger messages via another node and receive a response.
  • step S903 the MTC-IWF displays a Device Trigger Cancel Report message including an external identifier, an MSISDN, and a trigger reference number, indicating whether the trigger cancellation is successful or failed, and if so, the reason.
  • the device trigger cancellation report message may be a message newly defined for the present invention, or may be a device trigger report message used for a device trigger procedure operation on an existing Tsp (see section 5.2.1 of TS 23.682vll.2.0). .
  • the message may explicitly / implicitly include information indicating that the message is a reply message to the message requesting the cancellation of the existing pending trigger message.
  • a third embodiment relates to the replacement, cancellation / retrieval of small data using the T5 interface.
  • the replacement, cancellation, and recovery of the small data using the T5 interface may be performed by the MTC-IWF. Specifically, the MTC-IWF identifies which small data should be canceled / recovered or replaced based on the old small data reference number included in the first message, and deletes the identified small data. Can be. If the first message is related to the replacement of small data (for example, when the first message includes a new small data reference number), the MTOIWF deletes the small data corresponding to the old small data reference number. , New small data (corresponding to the new small data reference number) can be stored. The stored new small data may be delivered to the terminal if the terminal is available.
  • the message 1 may be a small data cancel / recovery message or a small data replacement message, as described below, and may be a message related to the small data received by the MTC-IWF from the SCS.
  • the first message may be a request for any one of a small data replacement operation or a retrieval / cancellation operation of the small data.
  • the first message may be a device action request message of which the action type is set to either small data cancellation / retrieval or replacement. It may also be in the form.
  • the first The message may be rejected by the MTC ⁇ IWF if the SCS exceeds the quota or rate of small data submission to the Tsp interface.
  • the SCS may determine whether it is necessary to replace the message with the previously submitted small data.
  • the SCS is responsible for device action requests (external identifier or MSISDN, SCS identifier, old small data reference number, new small data reference number, expiration date / message lifetime, priority, small data payload, etc.) whose action type is set to small data replacement request. It can send to the MTC-IWF.
  • the old small data reference number may indicate the small data reference number assigned to previously submitted small data that the SCS wishes to cancel.
  • the new small data reference number may be assigned by the SCS to the newly submitted small data message.
  • the SCS requests the MTC-IWF to include a reference number (or identifier or identifier) for the small data when requesting small data transmission.
  • the MTC-IWF may reject the device trigger action request message sent by the SCS and the action type is set to small data replacement request. have.
  • the MTC- IWF then sends a response message (with a cause value indicating the failure reason) notifying the rejection to the SCS, and subsequent steps are no longer performed.
  • step S1002 the MTC-IWF performs a small data replacement procedure on the T5 interface. A more detailed description is described below in FIG. 11.
  • the MTC-IWF may indicate success or failure of small data replacement in the device action response message to the SCS. That is, the MTC-IWF transmits a message informing the SCS of the response message or the result of the small data replacement request.
  • 11 illustrates a small data replacement procedure of the MTC-IWF in the T5 interface. Referring to FIG. 11, in step S1101, the external identifier, MSISDN, SCS identifier, and old small included in the received small data replacement request message (that is, the replacement request message for the small data requested by the SCS to be sent before). Based on the information of one or more of the data reference numbers, the MTC-IWF can identify which small data should be replaced.
  • the MTC-IWF checks whether the identified small data has already been transmitted to the terminal, or is pending in the MTC-IWF. If the small data is pending in the MTC-IWF or if the small data is transmitted to the terminal but transmission fails, steps S1102a to SlCHa may be performed. More specifically, in step SI 102a, MTC ⁇ IWF deletes the stored small data and stores new small data to be delivered when the terminal is available. In step SI 103a, in MTC-IWF, previously submitted small data is considered to have been successfully replaced. In step SI 104a, the MTC-IWF delivers new small data when the terminal is available.
  • the procedure for transferring new small data may be referred to by 3GPP TR 23.887vl.lO, 5.1.1.3.3.1.1.
  • the replacement request in step S1102b fails (for example, successful delivery or expiration). Is considered).
  • the MTC-IWF delivers new small data when the terminal is available.
  • the procedure for transferring new small data may be referred to by 3GPP TR 23.887vl.lO, 5.1.1.3.3.1.1.
  • the SCS may determine whether the small data submitted previously needs to be canceled / recovered.
  • SCS uses the device action request (external identifier or MSISDN, the action type set to Small Data Cancel / Retrieval Request).
  • the old small data reference number (or trigger reference number) is the small assigned to the previously submitted small data that the SCS wants to cancel.
  • a data reference number can be indicated.
  • the SCS may request that MTC—IWF include a reference number (or identifier or identifier) for the small data when requesting small data transmission.
  • the MTC-IWF rejects the device triggered action request message sent by the SCS with the action type set to small data cancel / recovery request. can do.
  • the MTC-IWF sends a response message (with a cause value indicating a failure reason) indicating the rejection to the SCS, and subsequent steps are no longer performed.
  • step S1202 the MTC-IWF performs a small data cancel / recovery procedure on the T5 interface. A more detailed description is given below in FIG. 13.
  • the MTC-IWF may indicate to the SCS the small data cancellation / retrieval success or failure in the device action response message. That is, the MTC-IWF transmits a message indicating a voice response message or a result of the small data recovery request to the SCS.
  • an external identifier included in a received small data cancel / recovery request message ie, a cancellation / recovery request message for small data previously requested to be sent by the SCS
  • the MTC—IWF may identify which small data should be canceled.
  • the MTC-IWF checks whether the confirmed small data has already been transmitted to the terminal or is pending in the MTC-IWF. If the small data is pending in the MTC-IWF or if the small data is transmitted to the terminal but delivery fails, steps S1302a to S1303a may be performed.
  • step S1302a the MTC—IWF deletes the stored small data.
  • step S1303a in MTC-IWF, the previously submitted small data is considered to have been successfully canceled / recovered.
  • the cancel / recovery request in step S1302b is considered to have failed (e.g., by successful delivery or expiration).
  • the MTC-IWF performing the replacement, cancellation, or recovery of the device trigger / small data is MTC-IWF in the home PLMN of the terminal or the PLMN registered by the terminal. In other words, it can be MTC- IWF in visited PLMN.
  • 17 is a diagram showing the configuration of a preferred embodiment of a terminal device and a network node device according to an example of the present invention.
  • an apparatus 1410 may include transmit / receive modules 1411, a processor 1412, and a memory 1413.
  • the transmit / receive modules 1411 are configured to transmit various signals, data, and information to an external device (network node (not shown) and / or server device (not shown)), and to receive various signals, data, and information from the external device.
  • the processor 1412 may control the overall operation of the device 1410 and may be configured to perform a function of calculating and processing information to be transmitted and received with an external device.
  • the memory 1413 may store the processed information and the like for a predetermined time and may be replaced with a component such as a buffer (not shown).
  • the processor of the apparatus 1410 may process matters necessary for the above-described embodiments to perform. *
  • the specific configuration of the apparatus 1410 as described above may be implemented so that the above-described matters described in various embodiments of the present invention may be independently applied or two or more embodiments may be applied at the same time. The description is omitted for the sake of brevity.
  • embodiments of the present invention may be implemented through various means.
  • embodiments of the present invention may be implemented by hardware, firmware, software, or a combination thereof.
  • the method according to the 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 PLDs.
  • ASICs Application Specific Integrated Circuits
  • DSPs Digital Signal Processors
  • DSPDs Digital Signal Processing Devices
  • programmable PLDs programmable PLDs.
  • Logic Devices Field Programmable Gate Arrays
  • processors controllers, microcontrollers, microprocessors, and the like.
  • the method according to the embodiments of the present invention may be implemented in the form of a module, a procedure, or a function that performs the functions or operations described above.
  • 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

본 발명의 일 실시예는, 무선통신시스템에서 SMS-SC(Short Message Service-Service Center)가 장치 트리거를 교체 /회수하는 방법에 있어서, MTC- IWF(Machine Type Communications 一 Inter Working Function)로부터 '옛 트리거 참조 번호를 포함하는 제 1 메시지를 수신하는 단계; 및 상기 옛 트리거 참조 번호에 대웅되는 트리거 메시지를 삭제하는 단계를 포함하고, 상기 제 1 메시지가 새 트리거 참조 번호를 더 포함하는 경우, 상기 SMS-SC는 상기 트리거 메시지의 삭제와 함께, 상기 새 트리거 참조 번호에 대웅되는 새 트리거 메시지를 저장하는, 장치 트리거 교체 /회수 방법이다.

Description

【명세서】
【발명의 명칭】
무선 통신 시스템에서 장치 트리거 /스몰 데이터 교체 /회수 방법 및 장치
[기술분야】
[ 1 ] 이하의 설명은 무선 통신 시스템에 대한 것으로， 보다 상세하게는 MTC(Machine Type Communications) 장치 '트리거링， 스몰 데이터의 교체， 회수 /취소 방법 및 장치에 대한 것 이다.
【배경기술】
[2] MTCCMachine Type Communications)는 하나 이상의 머신 (Machine)이 포함되는 통신 방식을 의미하며， M2M(Machine-to-Machine) 통신이나 사물 통신으로 칭하여지기도 한다. 여기서， 머신이 란 사람의 직 접 적 인 조작이나 개입을 필요로 하지 않는 개체 (entity)를 의미 한다. 예를 들어， 이동 통신 모들이 탑재된 검 침기 (meter)나 자동 판매기와 같은 장치는 물론， 사용자의 조작 /개입 없이 자동으로 네트워크에 접속하여 통신을 수행할 수 있는 스마트폰과 같은 사용자 기 기도 머신의 예시 에 해당할 수 있다. 이 러 한 머신의 다양한 예시들을 본 문서에서는 MTC 단말 (device) 또는 단말이라고 칭 한다. 즉， MTC는 사람의 조작 /개 입 없이 하나 이상의 머신 (즉， MTC 단말)에 의해서 수행되는 통신을 의미 한다ᅳ
[3 ] MTC는 MTC 단말 간의 통신 (예를 들어， D2D(Deviceᅳ to-Device) 통신), MTC 단말과 MTC 애플리 케이션 서버 (application server) 간의 통신을 포함할 수 있다. MTC 단말과 MTC 애플리 케이션 서 버 간의 통신의 예시로, 자동 판매기와 서버， POS(Point of Sale) 장치 와 서버， 전기， 가스 또는 수도 검 침기와 서버 간의 통신을 들 수 있다. 그 외에도 MTC에 기 반한 애플리 케이션 (application)에는ᅳ 보안 (security), 운송 (transportation), 헬스 케어 (health care) 등이 포함될 수 있다.
【발명의 상세한 설명】
【기술적 과제】
[4] 본 발명 에서는 트리거링 /스몰 데이터를 교체 /회수하는 방법을 제공하는 것을 기술적 과제로 한다. [5] 본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며 , 언급하지 않은 또 다른 기술적 과제들은 아래의 기 재로부터 본 발명 이 속하는 기술분야에서 통상의 지식을 가진 자에 게 명 확하게 이해될 수 있을 것 이다.
【기술적 해결방법】
[6] 본 발명 의 제 1 기술적 인 측면은， 무선통신시스템에서 SMS-SC(Short Message Service-Service Center)가 장치 트리거를 교체 /희수하는 방법 에 있어서. , MTC-IWF(Machine Type Communications - Inter Working Function)로부터 옛 트리거 참조 번호를 포함하는 제 1 메시지를 수신하는 단계 ; 및 상기 옛 트리거 참조 번호에 대웅되는 트리거 메시지를 삭제하는 단계를 포함하고， 상기 제 1 메시지가 새 트리거 참조 번호를 더 포함하는 경우, 상기 SMS-SC는 상기 트리거 메시지의 삭제와 함께， 상기 새 트리거 참조 번호에 대웅되는 새 트리거 메시지를 저 장하는， 장치 트리거 교체 /회수 방법 이다.
[7] 본 발명의 제 1 기술적 인 측면은 다음 사항들의 전 /일부를 포함할 수 있다.
[8] 상기 제 1 메시지는 상기 MTC-IWF가 SCSCServices Capability Server)로부터 수신한 장치 트리거에 관련된 제 2 메시지 에 기초할 수 있다.
[9] 상기 장치 트리거에 관련된 제 2 메시지는 트리거의 교체 동작 또는 트리거 의 회수 동작 중 어느 하나를 요청하는 것 일 수 있다.
[10] 상기 제 2 메시지가 장치 트리거 의 교체 동작을 요청하는 경우에 만 상기 제 1 메시지가 새 트리거 참조 번호를 포함할 수 있다.
[11 ] 상기 제 2 메시지가 장치 트리거의 회수 동작을 요청하는 경우ᅳ 상기 제 1 메시지는 새 트리거 참조 번호를 포함하지 않을 수 있다.
[12] 상기 제 2 메시지는 SCS가 Tsp 인터페 이스로의 트리거 제출의 쿼터 (quota) 또는 레 이트를 초과한 경우， 상기 MTC-IWF에 의해 거 절될 수 있다.
[13] 상기 SMS-SC는 복수의 SMS—SC 중, 상기 MTC—IWF가 설정 정보에 기초하여 상기 제 1 메시지를 수신할 SMS-SC로 선택한 것 일 수 있다.
[14] 본 발명의 제 2 기술적 인 측면은， 무선통신시스템에서 MTC— IWF가 스몰 데이터를 교체 /회수하는 방법에 있어서， 제 1 메시지에 포함된 옛 스몰 데이터 참조 번호에 기초하여;， MTC-IWF가 어떤 스몰 데이터를 교체 /회수하여야 할지 확인하는 단계; 및 상기 확인된 스몰 데이터를 삭제하는 단계를 포함하고， 상기 제 1 메시지가 스몰 데이터의 교체에 관련된 경우， 상기 MTC-IWF는 상기 스몰 데이터의 삭제와 함께， 새 스몰 데이터를 저장하는， 스몰 데이터 교체 /회수 방법이다.
[15] 본 발명의 제 2 기술적인 측면은 다음 사항들의 전 /일부를 포함할 수 있다.
[16] SCS로부터 상기 제 1 메시지를 수신하는 단계를 더 포함할 수 있다.
[17] 상기 제 1 메시지는 스몰 데이터의 교체 동작 또는 스몰 데이터의 회수 동작 증 어느 하나를 요청하는 것일 수 있다.
[18] 상기 게 1 메시지가 스몰 데이터의 교체 동작올 요청하는 경우에만 상기 제 1 메시지가 새 스몰 데이터 참조 번호를 포함할 수 있다.
[19] 상기 제 1 메시지는 SCS가 Tsp 인터페이스로의 트리거 제출의 쿼터 (quota) 또는 레이트를 초과한 경우ᅳ 상기 MTCᅳ IWF에 의해 거절될 수 있다.
[20] 상기 확인된 스몰 데이터의 삭제는 상기 확인된 스몰 데이터가 상기
MTC-IWF에 계류 중 또는 단말에게 상기 확인된 스몰 데이터의 전달이 실패된 경우 수행될 수 있다.
[21] 상기 확인된 스몰 데이터가 단말에게 성공적으로 전달된 경우， 상기 스몰 데이터의 교체 /회수는 실패한 것으로 간주될 수 있다.
[22] 상기 스몰 데이터는， 장치 트리거 메시지일 수 있다.
【유리한 효과】
[23] 본 발명에 따르면， 장치 트리거 /스몰 데이터를 교체 7회수할 수 있어 불필요한 트리거링으로 인한 네트워크 자원 낭비 둥을 방지할 수 있다. 상기 네트워크 자원은 시그널링 및 데이터를 교환하는 데 소요되는 자원, 장치 트리거 /스몰 데이터를 성공적으로 전송할 때까지 네트워크에서 저장하는 데 소요되는 자원 등을 포함한다ᅳ
[24] 본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며， 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
【도면의 간단한 설명】
본 명세서에 첨부되는 도면은 본 발명에 대한 이해를 제공하기 위한 것으로서 본 발명의 다양한 실시형태들을 나타내고 명세서의 기재와 함께 본 발명의 원리를 설명하기 위한 것이다.
도 1은 EPC(Evolved Packet Core)의 개략적인 구조를 나타내는 도면이다. 도 2는 MTC구조의 예시적인 모델을 나타내는 도면이다.
도 3은 MTC트리거 절차를 설명하기 위한 도면이다.
도 4는 T5를 이용한 트리거 절차를 설명하기 위한 도면이다.
도 5는 T4를 이용한 트리거 절차를 설명하기 위한 도면이다.
도 6 내지 도 7은 본 발명의 실시예에 의한 T4 트리거 교체 /회수 방법을 설명하기 위한 도면이다.
도 8 내지 도 9은 본 발명의 실시예에 의한 T5 트리거 교체 /회수 방법을 설명하기 위한 도면이다.
도 10 내지 도 13은 본 발명의 실시예에 의한 T5 스몰 데이터 교체 /회수 방법을 설명하기 위한 도면이다.
도 14는 본 발명의 실시예에 의한 장치 구성을 도시한 도면이다.
【발명의 실시를 위한 최선의 형태】
[25] 이하의 실시예들은 본 발명의 구성요소들과 특징들을 소정 형태로 결합한 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려될 수 있다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한， 일부 구성요소들 및 /또는 특징들을 결합하여 본 발명의 실시예를 구성할 수도 있다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고， 또는 다른 실시예의 대웅하는 구성 또는 특징과 교체될 수 있다.
[26] 이하의 설명에서 사용되는 특정 용어들은 본 발명의 이해를 돕기 위해서 제공된 것이며， 이러한 특정 용어의 사용은 본 발명의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
[27] 몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나， 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다. 또한， 본 명세서 전체에서 동일한 구성요소에 대해서는 동일한 도면 부호를 사용하여 설명 한다.
[28] 본 발명의 실시 예들은 IEEE(Institute of Electrical and Electronics Engineers) 802 계열 시스템， 3GPP 시스템， 3GPP LTE 및 LTE-A 시스템 및 3GPP2 시스템 중 적어도 하나에 관련하여 개시된 표준 문서들에 의해 뒷받침될 수 있다. 즉， 본 발명의 실시 예들 중 본 발명의 기술적 사상을 명 확히 드러내기 위해 설명하지 않은 단계들 또는 부분들은 상기 문서들에 의해 뒷받침될 수 있다. 또한, 본 문서에서 개시하고 있는 모든 용어들은 상기 표준 문서에 의해 설명될 수 있다.
[29 ] 이하의 기술은 다양한 무선 통신 시스템에서 사용될 수 있다. 명 확성을 위하여 이하에서는 3GPP LTE 및 3GPP LTE-A 시스템을 위주로 설명하지만 본 발명 의 기술적 사상이 이에 제한되는 것은 아니다.
[30] 본 문서에서 사용될 수 있는 용어들은 다음과 같이 정 의 된다.
- UMTS(Universal Mobile Telecommunications System): 3GPP에 의해서 개발된， GSM(Global System for Mobile Communication) 기반의 3 세대 (Generation) 이동 통신 기술.
- EPS(Evolved Packet System): IP 기 반의 packet switched 코어 네트워크인 EPCXEvolved Packet Core)와 LTE, UTRAN 등의 액세스 네트워크로 구성 된 네트워크 시스템 . UMTS가 진화된 형 태의 네트워크이다.
- NodeB: UMTS 네트워크의 기지국. 옥외에 설치하며 커 버 리지는 매크로 셀 (macro cell) 규모이다.
ᅳ eNodeB: EPS 네트워크의 기지국. 옥외에 설치하며 커버 리지는 매크로 샐 (macro cell) 규모이 다.
- 단말 (User Equipment): 사용자 기기 . 단말은 단말 (terminal), ME(Mobile Equipment), MS(Mobile Station) 등의 용어로 언급될 수도 있다. 또한， 단말은 노트북， 휴대폰, PDACPersonal Digital Assistant), 스마트 폰， 멀티미디어 기기 등과 같이 휴대 가능한 기기 일 수 있고， 또는 PC(Personal Computer), 차량 탑재 장치와 같이 휴대 불가능한 기기 일 수도 있다. MTC 관련 내용에서 단말 또는 단말이라는 용어는 MTC 단말을 지 칭할 수 있다.
一 IMSQP Multimedia Subsystem): 멀티 미 디어 서 비스를 IP 기 반으로 제공하는 서브시스템 .
- IMSKlnternational Mobile Subscriber Identity): 이동 통신 네트워크에서 국제적으로 고유하게 할당되는 사용자 식별자.
- MTCCMachine Type Communications): 사람의 개입 없이 머신에 의해 수행되는 통신. M2M(Machine to Machine) 통신이라고 지칭할 수도 있다.
- MTC 단말 (MTC UE (또는 MTC device (또는 MTC 장치)；))： 이동통신 네트워크를 통한 통신 기능을 가지고, 특정 목적을 수행하는 단말 (예를 들어， 자판기， 검침기 등).
- 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 단말의 그룹을 의미한다.
― SCSCServices Capability Server): HPLMN(Home PLMN) 상의 MTCᅳ IWF(MTC InterWorking Function) 및 MTC 단말과 통신하기 위한 엔티티로써, 3GPP 네트워크와 접속되어 있다. - 외부 식별자 (External Identifier): 3 GPP 네트워크의 외부 엔티 티 (예를 들면, SCS 또는 Application Server)가 MTC 단말 (또는 MTC 단말이 속한 가입자)을 가리키 기 (또는 식별하기 ) 위해 사용하는 식별자 (identifier)로 globally unique하다. 외부 식별자는 다음과 같이 도메인 식별자 (Domain Identifier)와 로컬 식별자 (Local ldentifier)로 구성된다:
- 도메 인 식 별자 (Domain Identifier): 이동통신망 사업자의 제어 하에 있는 도메인을 식별하기 위한 식별자. 하나의 사업자는 서로 다른 서비스로의 접속을 제공하기 위해 서비스 별로 도메인 식별자를 사용할 수도 있다.
- 로컬 식 별ᄌ KLocal Identifier): IMSKlnternational 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), °1 "이 덴티티 관리 (identity management), 1 "용자 상태 저장 등의 기능을 수행할 수 있다.
- RANAP(RAN Application Part): RAN과 코어 네트워크의 제어를 담당하는 노드 (MMEXMobility 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 연결을 수립 및 유지하는 세션 관리 절차를 지원하는 것을 주된 기능으로 한다. [31 ] 이하에서는 위와 같이 정의된 용어를 바탕으로 설명 한다.
[32] 도 1은 EP XEvolved Packet Core)의 개략적 인 구조를 나타내는 도면이다.
[33] EPC는 3GPP 기술들의 성능을 향상하기 위 한 SAE(System Architecture Evolution)의 핵심 적 인 요소이다. SAE는 다양한 종류의 네트워크 간의 이동성을 지원하는 네트워크 구조를 결정하는 연구 과제에 해당한다. SAE는， 예를 들어 , IP 기반으로 다양한 무선 접속 기술들을 지 원하고 보다 향상된 데이터 전송 능력을 제공하는 등의 최 적화된 패킷 -기반 시스템을 제공하는 것을 목표로 한다.
[34] 구체적으로， 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 서비스 구현에 필수적 인 구조이다.
[35] EPC는 다양한 구성요소들을 포함할 수 있으며， 도 1에서는 그 중에서 일부에 해당하는， SGW(Serving Gateway), PDN GW(Packet Data Network Gateway), MMECMobility Management Entity), SGSN(Serving GPRS(General Packet Radio Service) Supporting Node), ePDG(enhanced Packet Data Gateway)를 도시 한다.
[36] SGW는 무선 접속 네트워크 (RAN)와 코어 네트워크 사이 의 경 계점으로서 동작하고， eNodeB와 PDN GW 사이의 데이터 경로를 유지하는 기능을 하는 요소이다. 또한， 단말이 eNodeB에 의해서 서빙 (serving)되는 영 역에 걸쳐 이동하는 경 우 SGW는 로컬 이동성 앵커 포인트 (anchor point)의 역 할을 한다. 즉, E-UTRAN (3GPP 릴리즈 -8 이후에서 정의 되는 Evolved-UMTS Jniversal Mobile Telecommunications System) Terrestrial Radio Access Network) 내에서의 이동성을 위해서 SGW를 통해서 패킷들이 라우팅 될 수 있다. 또한， SGW는 다른 3GPP 네트워크 (3GPP 릴리즈 -8 전에 정의되는 RAN, 예를 들어， UTRAN 또는 GERAN(GSM(Global System for Mobile Communication)/EDGE(Enhanced Data rates for Global Evolution) Radio Access Network)와의 이동성을 위한 앵커 포인트로서 기능할 수도 있다.
[37] 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와 같은 신뢰되는 네트워크)와의 이동성 관리를 위 한 앵커 포인트 역할을 할 수 있다.
[38] 도 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) 등의 기능을 수행한다. ' [39] SGSN은 다른 3GPP 네트워크 (예를 들어， GPRS 네트워크)에 대한 사용자의 이동성 관리 및 인증 (authentication)과 같은 모든 패킷 데이터를 핸들링 한다. [40] ePDG는 신뢰되지 않는 비 -3GPP 네트워크 (예를 들어， I-WLAN, WiFi 핫스팟 (hotspot) 등)에 대한 보안 노드로서의 역할을 한다.
[41] 도 1을 참조하여 설명한 바와 같이， IP 능력을 가지는 단말은， 3GPP 액세스는 물론 비_30?？ 액세스 기반으로도 EPC 내의 다양한 요소들을 경유하여 사업자 (즉， 오퍼레이터 (operator))가 제공하는 IP 서비스 네트워크 (예를 들어, IMS)에 액세스할 수 있다.
[42] 또한, 도 1에서는 다양한 레퍼런스 포인트들 (예를 들어， Sl-U, S1-MME 등)을 도시한다. 3GPP 시스템에서는 E— UTRAN 및 EPC의 상이한 기능 개체 (functional entity)들에 존재하는 2 개의 기능을 연결하는 개념적인 링크를 레퍼런스 포인트 (reference point)라고 정의한다. 다음의 표 1은 도 1에 도시된 레퍼런스 포인트를 정리한 것이다. 표 1의 예시들 외에도 네트워크 구조에 따라 다양한 레퍼런스 포인트들이 존재할 수 있다.
[43] 【표 1】
Figure imgf000012_0001
Figure imgf000013_0001
[44] 도 1에 도시된 레퍼 런스 포인트 중에서 S2a 및 S2b는 비 -3GPP 인터페이스에 해당한다. S2a는 신뢰되는 비—3GPP 액세스 및 PDNGW 간의 관련 제어 및 이동성 지원올 사용자 플레인에 제공하는 레퍼 런스 포인트이다. S2b는 ePDG 및 PDN GW 간의 관련 제어 및 이동성 지원을 사용자 플레인에 제공하는 레퍼런스 포인트이다.
[45] 도 2는 MTC 구조의 예시적 인 모델을 나타내는 도면이다.
[46] 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 모델)들을 포함한다.
[47] 먼저， 도 2에서 도시하는 개체 (entity)들에 대하여 설명 한다.
[48] 도 2에서 애플리 케이션 서버는 MTC 애플리 케이션이 실행되는 네트워크 상의 서버이다. MTC 애플리 케이션 서 버 에 대해서는 전술한 다양한 MTC 애플리 케이션의 구현을 위한 기술이 적용될 수 있으몌 이 에 대한 구체적 인 설명은 생략한다. 또한， 도 2에서 MTC 애플리 케이션 서 버는 레퍼 런스 포인트 API를 통하여 MTC 서버에 액세스할 수 있으며， 이에 대한 구체적 인 설명은 생략한다. 또는， MTC 애플리 케이션 서버는 MTC 서버와 함께 위치될 (collocated) 수도 있다.
[49] MTC 서 버 (예를 들어 도시된 SCS 서버 )는 MTC 단말을 관리하는 네트워크 상의 서버 이며， 3GPP 네트워크에 연결되어 MTC를 위하여 사용되는 단말 및 PLMN의 노드들과 통신할 수 있다.
[50] MTC-IWF(MTC-InterWorking Function)는 MTC 서버와 오퍼 레이터 코어 네트워크 간의 상호동작 (interworking)을 관장하고， MTC 동작의 프록시 역할을 할 수 있다. MTC 간접 또는 하이브리드 모델을 지원하기 위해서， 하나 이상의 MTC-IWF가 홈 PLMN(HPLMN) 내에 존재할 수 있다. MTC-IWF는 레퍼 런스 포인트 Tsp 상의 시그널링 프로토콜을 중계하거나 해석하여 PLMN에 특정 기능을 작동시킬 수 있다. MTC-IWF는， MTC 서 버가 3GPP 네트워크와의 통신을 수립하기 전에 MTC 서버를 인증 (authenticate)하는 기능， MTC 서버로부터 의 제어 플레인 요청을 인증하는 기능， 후술하는 트리거 지시와 관련된 다양한 기능 등을 수행할 수 있다.
[51 ] SMS-SC(Short Message Service-Service Center)/IP-SM-GW(Internet Protocol Short Message GateWay)는 단문서 비스 (SMS)의 송수신을 관리할 수 있다. SMS-SC는 SME(Short Message Entity) (단문을 송신 또는 수신하는 개체)와 이동국 간의 단문을 중계하고 저장—및 -전달하는 기능을 담당할 수 있다. IP-SM-GW는 IP 기반의 단말과 SMS-SC간의 프로토콜 상호동작을 담당할 수 있다.
[52] CDF(Charging Data Function)/CGF(Charging Gateway Function)는 과금에 관련된 동작을 할 수 있다.
[53] HLR/HSS는 가입자 정보 (IMSI 등)， 라우팅 정 보 설정 정보 등을 저장하고 MTC-IWF에 게 제공하는 기능을 할 수 있다.
[54] MSC/SGSN/MME는 단말의 네트워크 연결을 위 한 이동성 관리， 인증, 자원 할당 등의 제어 기능을 수행할 수 있다. 후술하는 트리 거 링과 관련하여 MTC— IWF로부터 트리거 지시를 수신하여 MTC 단말에 게 제공하는 메시지 의 형 태로 가공하는 기능올 수행할 수 있다.
[55] GGSNCGateway GPRS Support NodeVS-GW(Serving-Gateway) + P- GW(Packet Data Network-Gate way)는 코어 네트워크와 외부 네트워크의 연결을 담당하는 게이트웨이 기능을 할 수 있다.
[56] 다음의 표 2는 도 2에서의 주요 레퍼 런스 포인트를 정리 한 것 이다.
[57] [표 2】
Figure imgf000015_0001
Figure imgf000016_0002
T5a, T5b, T5c 중 하나 이상의 레퍼런스 포인트를 T5라고
Figure imgf000016_0001
[59] 한편， 간접 및 하이브리드 모델의 경우에 MTC 서버와의 사용자 플레인 통신, 및 직 접 및 하이브리드 모델의 경우에 MTC 애플리 케이션 서버와의 통신은， 레퍼 런스 포인트 Gi 및 SGi를 통해서 기존의 프로토콜을 사용하여 수행될 수 있다.
[60] 도 2에서 설명한 내용과 관련된 구체적 인 사항은 3GPP TS 23.682 문서를 참조함으로써 본 문서에 병합될 수 있다 (incorporated by reference).
[61 ] MTC의 경우에， 일반적 인 사용자 기기보다 많은 개수의 MTC 단말이 네트워크 상에 존재할 것으로 예상된다. 따라서， MTC를 위해서 최소한의 네트워크 자원 사용， 최소한의 시그널링 사용， 최소한의 전력 사용 등이 요구된다.
[62] 또한, 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 단말이 온라인이고 (네트워크에 어 태치되 어 있고) 데이 터 연결이 수립된 경우를 가정할 수 있다.
[63] 요컨대， MTC 단말에 대한 트리거 링은， 해당 MTC 단말이 MTC 애플리 케이션 서버로부터 데이터를 수신할 수 있는 IP 연결 (또는 PDN 연결)이 수립되어 있지 않은 경우에 (또는 해당 MTC 단말이 기본적인 제어. 신호는 수신할 수 있지만 사용자 데이터는 수신할 수 없는 상태인 경우), 트리거링 메시지를 이용해서 해당 MTC 단말이 단말 내 MTC 애플리케이션의 동작을 수행하고 /수행하거나 MTC 애플리케이션 서버에 대해서 IP 연결 요청을 수행하도록 하는 동작이라고 할 수 있다. 또한， 트리거링 메시지는， 네트워크로 하여금 메시지를 적절한 MTC 단말에게 라우팅하도록 하고， MTC 단말로 하여금 메시지를 적절한 MTC 단말내의 애플리케이션으로 라우팅하도록 하는 정보 (이하에서는 트리거링 정보라고 칭함)를 포함하는 메시지라고 표현할 수도 있다.
[64] 보다 상세한 MTC트리거링 절차를 도 3을 참조하여 설명한다.
[65] 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 같은 정보를 포함할 수 있다.
[66] 【표 3】 i) 외부 식별자 또는 MSISDN: 트리거 하려는 MTC 단말 (또는 MTC 단말이 속한 가입자)의 식별 ii) SCS식별자: 상기 장치 트리거 요청 메시지를 보내는 SCS의 식별자 iii) 트리거 참조 번호 (trigger reference number 또는 reference number): 상기 전송하는 장치 트리거 요청 메시지의 참조 번호 iv) 유효 구간 (validity period): 장치 트리거 요청이 유효한 시간구간으로， 트리거가 MTC 단말로 전달되지 못하는 경우， 네트워크 엔티티 (예를 들어， MTCᅳ IWF)로 하여금 장치 트리거 요청을 저장해야 하는 기간을 알려줌. v) 우선순위 (priority): 장치 트리거 요청의 전달 우선순위 vi) 트리거 페이로드 (trigger payload): MTC 단말
애플리케이션으로 전달되는 정보
[67] SCS(380)로부터 장치 트리거 요청 메시지를 수신한 MTC-IWF(360)는 SCS가 3GPP 네트워크로 트리거 요청을 보내는 것이 허용되는 지에 대한 권한 검증을 수행한다 (S303). 만약 상기 권한 검증이 실패하면， MTC-IWFX360)는 SCS(380)에게 상기 장치 트리거 요청 이 실패했음올 알리는 장치 트리거 확인 메시지를 보낸다. 이와 달리 상기 권한 검증이 성공하면 다음 단계를 수행할 수 있다.
[68] MTC— IWF 360)는 HSS/HLR(350)에 게 서브스크라이버 정보 요청 (Subscriber Information Request) 메시지를 보낸다 (S304). 이는 상기 SCS가 상기 MTC 단말을 트리거하는 것 이 허용되는 SCS인지를 검사하고， 상기 단계 S302에서 수신한 MTC 단말의 식별자 (외부 식별자 또는 MSISDN)를 이용하여 IMSI를 획득하고 MTC 단말을 서방하는 서빙 노드 (serving node(s))의 식별자를 포함하는 라우팅 정보를 획득하기 위함이다.
[69] HSS/HLR(350)은 상기 장치 트리거 요청 메시지를 보낸 SCS가 상기 MTC 단말을 트리거 하도록. 허용되는 SCS 인지를 검사한다 (S305). 이후에 HSS/HLR(350)은 MTC-IWF(360)에 게 서브스크라이 버 정보 웅답 (Subscriber Information Response) 메시지를 전송한다. 이는 IMSI와 MTC 단말을 서 빙하는 서 빙 노드의 식별자를 포함한다. 만약 검사 결과 상기 SCS가 상기 MTC 단말을 트리거 하도록 허용되지 않거나, 또는 HSS/HLR(350)에 상기 MTC 단말과 관련한 유효한 서브스크립션 정보가 존재하지 않는다면， HSS/HLR(350)은 MTC-IWF(360)에 게 이를 알리는 정보를 포함하는 서브스크라이버 정보 응답 메시지를 전송한다. 이 경우， MTC-IWF(360)는 SCS(380)에 게 상기 장치 트리거 요청 이 실패했음을 알리는 장치 트리거 확인 메시지를 보내고, 이후의 단계는 수행하지 않는다.
[70] MTC— IWF(360)는 HSS/HLR(350)로부터 수신한 정보 및 지 역 적 정책 (local policy)에 기반하여 트리거 전달 절차 (delivery procedure)를 선택한다. (S306a)
[71 ] 만약 T5 를 이용한 전달 절차가 선택되면， MTC-IWF(360)는 T5 트리거 전달 절차를 수행한다 (S306b) 상세한 T5 트리거 전달 절차는 도 4에 대한 설명에서 후술한다. 만약 상기 단계 S306a에서 T4를 이용한 전달 절차가 선택되 었거나， 상기 단계 S306b의 결과 T5 전달이 실패했다면， MTC- IWF(360)는 T4 트리거 전달 절차를 수행한다 (S306c~306d). T4 트리거 전달 절차의 상세는 도 5에 대한 설명에서 후술한다.
[72] MTC-IWF(360)는 SCS(380)에게 상기 단계 S302의 장치 트리거 요청 메시지에 대한 응답인 장치 트리거 보고 (Device Trigger Report) 메시지를 전송한다 (S307). 장치 트리거 보고 메시지는 상기 SCS가 요청한 장치 트리거의 결과 MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지를 알려준다.
[73] 수신한 장치 트리거 에 대한 웅답으로 UE-1(310)은 트리거 페이로드의 내용에 기 반한 동작을 수행한다 (S308). 이 러한 동작은 전형 적으로는 SCS 또는 AS (애플리 케이션 서버)와의 통신 개시를 포함한다.
[74] 도 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 인터페 이스를 통한 장치 트리거를 T5 장치 트리거라고 명 칭할 수 있다.) 또는 T4 인터페이스를 통해 SMS-SC로 장치 트리거 요청을 보낼 수 있다. 예를 들어， 도 4를 참조하면 , HSS/HLR로부터 획득한 정보에 기 반하여 가용한 서빙노드가 다수개인 경우， MTC-IWF 440)는 적 절한 서빙노드를 선택한다. MTC-IWF(440)는 선택한 서빙 노드 (420)에 게 제출 요청 (Submit Request) 메시지를 전송한다 (S401). 상술한 바와 같이 만약 선택한 서빙노드가 SGSN이면 T5a, MME이면 T5b 또는 MSC면 T5c 인터페이스를 통해 제출 요청 메시지를 전송한다. ' [75] 제출 요청 메시지를 수신한 서빙노드 (420)는 장치 트리거의 타겟 단말인 UE-K410)에 게 트리거 메시지를 전달한다 (S402). 상기 트리거 동작을 수행한 서빙 노드 (420)는 MTC-IWF(460)에게 전달 보고 (Delivery Report) 메시지를 보낸다. 상기의 전달 보고 메시지는 MTCᅳ IWF가 요청 한 장치 트리거의 결과 MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지를 알려준다.
[76] 도 5는 T4 트리거 전달 절차를 설명하기 위한 도면이다. 도 5를 참조하면, MTC—IWF(560)는 SCS(580)로부터 수신한 장치 트리거 요청 메시지가 포함하는 정보 및 HSS/HLR(550)로부터 수신한 서브스크라이버 정보 웅답 메시지가 포함하는 정보에 기 반하여 SMS-SCX540)에게 제출 트리거 (Submit Trigger) 메시지를 전송한다 (S501). SMS-SC(540)는 제출 트리거 메시지를 수신 (accept) 하였음을 응답하는 제출 트리거 확인 메시지를 MTC- IWF(560)에 게 전송한다 (S502). SMSᅳ SCX540)로부터 제출 트리거 확인 메시지를 수신한 MTC-IWF(560)는 SCS(580)에 게 SCS가 보낸 장치 트리거 요청 메시지가 수신 (accept) 되었음을 알리는 장치 트리거 확인 메시지를 전송한다 (S503).
[77] SMS— SC(540)가 보낸 장치 트리거 메시지를 담은 단문 메시지가 서 빙노드 (520)에게 전달된다 (S504 이 때， 상기 SMS-S'C(540)는 수신한 장치 트리거 메시지가 라우팅 정보 (서빙 노드에 대한 정보)를 포함하고 있다면 이를 획득하기 위해 HSS/HLR(550)와의 질의 (interrogation)를 수행할 필요가 없다. SMS— SCX540)는 단문 메시지 전송이 실패할 경우를 대비 하여 MTC- IWF(560)로부터 수신한 정보 중 라우팅 정보를 제외 한 필요한 정보를 저장한다.
[78] 다음으로 서빙노드 (520)는 UE-K510)에 게 단문 메시지를 전달한다 (S505). 장치 트리거 메시지를 포함하는 단문 메시지를 수신한 UE- 1(510)은 서 빙 노드 (520)에 게 응답을 할 수 있다. 서빙노드 (520)는 SMS—
SC(540)에 게 전달 보고 메시지를 보낸다 (S506). 전달 보고 메시지는 상기 SMS-
SC가 요청 한 단문 메시지 전달의 결과 MTC 단말로의 단문 메시지 (short message) 전달이 성공했는지 또는 실패했는지를 알려즐 수 있다. 만약， 단문 메시지 전달이 실패했고 상기 장치 트리거 메시지에 대한 유효 구간 (validity period)이 0으로 설정되지 않았다면 SMS-SC(540)는 HSS/HLR(550)과의 질의 (interrogation)를 통해 UE-K510)로 단문 메시지를 전달하기 위한 라우팅 정보를 획득한 후， 단계 S504에서 저장한 정보를 이용하여 재전송을 수행할 수 있다. SMS-SC(540)는 MTC-IWF(560)에게 MTC-IWF가 요청 한 장치 트리거의 결과 MTC 단말로의 트리거 전달이 성공했는지 또는 실패했는지를 알리기 위해 메시지 전달 보고 (Message Delivery Report) 메시지를 보낸다 (S507).
[79] 표 4는 SMS-SC가 MTC-IWF으로부터 장치 트리거 메시지에 대한 전송 요청을 받은 후에 전송 결과 (성공 또는 실패)를 MTC-IWF에 게 알리기 전까지 저장해야 하는 대표적 인 장치 트리거 메시지 관련 정보들이다.
[80] 【표 4】 i) 외부 식 별자 또는 MSISDN: 트리거 되는 MTC 단말 (또는 MTC 단말이 속한 가입자)의 식별 정보. MTC-IWF에게 메시지 전달 보고 (Message Delivery Report) 메시지를 보낼 때 사용됨 . ii) IMSI: 트리거 되는 MTC 단말 (또는 MTC 단말이 속한 가입자)의 식 별 정보 iii) 트리거 참조 번호 (trigger reference number 또는 reference number): 상기 전송하는 장치 트리거 요청 메시지 의 참조 번호. MTC-IWF에 게 메시지 전달 보고 (Message Delivery Report) 메시지를 보낼 때 사용됨 . iv) SCS 식별자: 상기 장치 트리거 요청 메시지를 보내는 SCS의 식별자. MTC-IWF에 게 메시지 전달 보고 (Message Delivery Report) 메시지를 보낼 때 사용됨 . .
V) 트리거 페이로드 (trigger payload): MTC 단말 상의 MTC 애플리 케이션으로 전달되는 정보 vi) 단문 메시지를 위 한 라우팅 정보 (Routing Information for SMS): 장치 트리거 메시지를 포함한 단문 메시지가 전달될 서 빙노드에 대한 정보 vii) 우선순위 (pnority): 장치 트리거 요청 의 전달 우선순위 viii) 유효 구간 (validity period): 장치 트리거 요청이 유효한 시간구간으로， 트리거가 MTC 단말로 전달되지 못하는 경우， 장치 트리거 요청을 저장해야 하는 기간 viiii) SMS 애플리케이션 포트 ID: 단문 메시지의 목적이 장치 트리거링임을 나타냄. 단문 메시지가 MTC 단말 내의 트리거링 펑션 (function)으로 전달되도록 하
ᄆ -
[81] 앞서 살펴본， T4/T5 인터페이스를 통해 전달되는 MTC 단말에 대한 트리거는， 단말이 가용 /도달 가능하지 않아 단말로의 전달이 실패될 수 있다. 예를 들어， MTC 단말이 커버리지 밖에 있거나， 다른 작업 처리로 트리거 메시지를 처리할 수 없거나 또는 저장 공간의 부족 등이 있을 수 있다. 이러한 경우， 네트워크 노드는 트리거 메시지의 유효 기간동안 트리거 메시지를 저장하고 전송을 재시도한다.
[82] 위 절차에서， 트리거 메시지의 전달이 완료되지 않더라도 트리거 메시지의 전달이 잉여 또는 불필요한 것이 될 수 있다. 예를 들어, 전달되지 않은 트리거 메시지가 단말에게 센서 A를 통한 측정 결과 전송을 요구하는 것인데， 다음 번 트리거가 단말에게 모든 센서를 통한 측정 결과 전송을 요구하는 경우， 앞선 트리거 메시지는 재시도를 통해 전달되는 것 보다는 취소 (cancel)/회수 (recall) 또는 새 트리거 메시지로 교체 (replace)되는 것이 바람직할 것이다. 다시 말해， 네트워크가 전달되지 않은 트리거 메시지를 취소 /회수하지 못하는 경우， 불필요한 트리거 메시지가 단말들에게 전달되거나 단말로의 전달을 위해 네트워크 노드에서 저장될 것이고 이는 네트워크 자원의 낭비를 초래할 것이다. 따라서， 이하에서는 MTC 단말에 대한 트리거 메시지를 취소 /회수 또는 교체에 대해 설명한다. 이하의 설명에서， 트리거 메시지는 스몰 (small) 데이터로， 스몰 데이터는 트리거 메시지로 대치될 수 있다. 상기 스몰 데이터는 소량의 데이터 (small amounts of data) 또는 작은 크기의 데이터 (small size of data)로 일컬을 수도 있다. [83] 실시예 1 - T4 트리거 메시지의 교체, 취소 /회수
[84] 첫 번째 실시 예는 T4 트리거 메시지의 교체 , 취소 /회수에 관한 것이다.
[85] T4 트리거 메시지의 교체， 취소 /회수는 SMS-SC에 의해 수행될 수 있다. 구체적으로， SMS-SC는 MTC-IWF로부터 옛 트리거 참조 번호 (old trigger reference number)를 포함하는 제 1 메시지를 수신하고, 이 에 해당되는 트리거 메시지를 삭제할 수 있다. 트리거 메시지 교체의 경우， 즉 제 1 메시지가 새 트리거 참조 번호 (new trigger reference number)를 포함하는 경우， SMS—SC는 옛 트리거 참조 번호에 해당되는 트리거 메시지를 삭제하고, 새 트리거 참조 번호에 해당하는 트리거 메시지를 저장할 수 있다. 저장된 새 트리거 메시지는 단말이 가용한 경우 단말에 게 전달될 수 있다.
[86] 여기서， 제 1 메시지는 후술하는 바와 같이， 제출 트리거 취소 /회수 메시지 또는 제출 트리거 교체 메시지 일 수 있으며， 제 1 메시지는 MTC-IWF가 SCS로부터 수신한 장치 트리거에 관련된 제 2 메시지 에 기초하는 것 일 수 있다. 게 2 메시지는 트리거 의 교체 동작 또는 트리거의 회수 /취소 동작 중 어느 하나를 요청하는 것 일 수 있으며， 구체적으로 장치 트리거 취소 /회수 요청 메시지， 장치 트리거 교체 요청 메시지 일 수 있다. 또는 제 2 메시지는 액션 타입 이 장치 트리거 취소 /회수 또는 교체 중 어느 하나로 설정된 장치 액션 요청 (Device Action Request) 메시지의 형 태일 수도 있다. 또는， 제 2 메시지는 요청 타입이 장치 트리거 취소 /회수 또는 교체 중 어느 하나로 설정된 장치 트리거 요청 (Device Trigger Request) 메시지의 형 태일 수도 있다. 제 2 메시지도, 제 1 메시지와 마찬가지로， 새 트리거 참조 번호는 장치 트리거 의 교체를 요청하는 경우에 만 포함되고， 장치 트리거 의 취소 /회수를 요청하는 경우에는 포함되지 않을 수 있다. 또한， 제 2 메시지는 SCS가 Tsp 인터페이스로의 트리거 제출의 쿼터 (quota) 또는 레이트 (rate)를 초과한 경우， 상기 MTC-IWF에 의해 거절될 수 있다.
[87] 만약， 복수개의 SMSᅳ SC가 MTOIWF에 연결되어 있는 경우， 설정 (configuration)에 기 반하여 MTC— IWF가 제 1 메시.지를 전송할 SMSᅳ SC를 결정 할 수 있다. 또는， MTC-IWF는 옛 트리거 메시지를 저장하고 있는 SMS- SC (예를 들어， 이 전에 MTC— IWF가 옛 트리거 메시지에 대한 전송을 요청 한 SMS-SC)에 대한 정보를 (다른 네트워크 노드로부터 ) 획득한 후， 제 1 메시지를 전송할 SMS—SC를 결정할 수 있다.
[88] 이하， 트리거 메시지의 교체， 취소 /회수의 경우를 각각 나누어 구체적으로 살펴본다.
[89] 실시예 la - T4 트리거 메시지의 교체
[90] 도 6은 T4 트리거 메시지의 교체를 설명하기 위 한 도면이다. 도 6을 참조하면， 단계 S601에서 SCS는 이 전에 제출된 트리거 메시지를 취소 /회수 및 /또는 교체할 필요가 있는지 여부를 결정할 수 있다. SCS는 장치 트리거 취소 요청 메시지 (외부 식별자 (External Identifier) 또는 MSISDN, SCS 식별자 (SCS Identifier), 옛 트리거 참조 번호 (old trigger reference number), 새 트리거 참조 번호 (new trigger reference number), 유효 기간 (validity period), 우선순위 (priority), 트리거 페이로드 (trigger payload) 등을 포함)를 MTCᅳ IWF에 전송할 수 있다. 옛 트리거 참조 번호는 SCS가 취소하기를 원하는, 이 전에 제출된 트리거 메시지 에 할당된 트리거 참조 번호를 지시할 수 있다. 새 트리거 참조 번호는 새톱게 제출된 트리거 메시지 에 게 SCS에 의 해 할당될 수 있다. 유효 기 간， 우선순위， 트리거 페이로드가 새 트리거 메시지를 위 한 것인데 비해， 외부 식별자, MSISDN, SCS 식별자는 모두 옛 트리거 메시지 (예를 들어 , 계류 (pending) 증인 트리거 메시지 ) 및 새 트리거 메시지에 연관되어 있다.
[91 ] 장치 트리거 취소 /회수 요청 메시지는 새롭게 정의된 메시지 일 수도 있고， 기존의 Tsp 상의 장치 트리거 절차 (Device triggering procedure over Tsp) 동작 (상세한 내용은 TS 23·682ν11.2.0의 5.2.1절에 의 해 참고될 수 있다.)을 위해 사용되는 장치 트리거 요청 메시지 일 수도 있다. 추가적으로 상기 메시지는 새로운 트리거 메시지로 기존의 계류중인 트리거 메시지 (pending trigger message)를 교체할 것을 요청 한다는 정보를 명시 적 /함축적으로 포함할 수 있다.
[92 ] 예를 들면， 계류중인 트리거 메시지를 교체할 것을 요청하기 위 한 장치 트리거 취소 /회수 요청 메시지는 기존의 장치 트리거 요청 메시지 , 즉 장치 ᅳ 액션—요청 (Device-Action-Request) 메시지 /코멘드를 사용하면서 새로운 액션 타입 (Action-Type) 값， 예컨대 Action-Type 二 "Replace" (구체적으로는
"교체 (Replace)"를 의미하는 특정하게 열거된 값 (enumerated value) 또는 정수값)을 정의하여 사용할 수 있다. 또한， 이 때 교체 요청 에 필요한 정보들을 포함하기 위해 기존의 AVP를 확장하거 나 새로운 AVP를 정 의하여 사용할 수 있다. 또 다른 예로는 계류중인 트리거 메시지를 취소 /회수 및 /또는 교체하도록 요청하는 새로운 메시지 /코멘드를 정의하면서 회수 및 교체에 대해 각각 정의된 액션—타입 AVP를 포함하도록 하는 것 이다. 또는, 계류중인 트리거 메시지를 취소 /회수하도록 요청하는 메시지 /코멘드와 계류중인 트리거 메시지를 교체하도록 요청하는 메시지 /코멘드를 각각 정의하여 사용할 수도 있다. 전술한 SCS가 MTC-IWF에 게 전송하는 장치 트리거 취소 /회수 및 /또는 교체 요청 메시지 에 대한 내용은 실시 예 2 및 실시 예 3에도 적용될 수 있다.
[93] SCS는 새 트리거 참조 번호를 옛 트리거 참조 번호와 동일한 값으로 설정할 수 있다. 이 러한 경우 장치 트리거 취소 /회수 요청 메시지에 옛 트리거 참조 번호 및 새 트리거 참조 번호가 모두 포함될 수도 있고， 하나의 트리거 참조 번호 (trigger reference number) 값만 포함될 수도 있다.
[94] 우선순위 정보의 경우 계류중인 트리거 메시지에 대한 우선순위 값과 새 트리거 메시지에 대한 우선순위 값이 다른 경우 (또는 동일하더라도)， 계류중인 트리거 메시지에 대한 우선순위 값을 추가적으로 장치 트리 거 취 소 /회수 요청 메시지 에 포함시킬 수 있다. 계류중인 트리 거 메시지와 관련한 우선순위 값은 상기 계류중인 트리 거 메시지를 취소하는데 있어서 우선순위가 있는지 여부를 나타낼 수 있다. 그러나 계류증인 트리거 메시지를 취소 하는데 있어서 우선순위 (또는 긴급성 ) 여부는 다양한 형 태의 메시지 및 /또는 파라미터 및 /또는 정보로 나타낼 수도 있다.
[95] 단계 S602에서， 수신된 장치 트리거 취소 요청 메시지의 외부 식별자，
MSISDN, SCS 식별자， 옛 트리거 참조 번호 중 하나 이상의 정보에 기초해서 , MTC-IWF는 새 트리거 메시지로의 교체되는 과정에서 어떤 트리거 메시지가 삭제되어 야 할지를 확인 (identify)할 수 있다. 또한， MTC-IWF는 외부 식 별자，
MSISDN, IMSI, SCS 식별자 옛 트리거 참조 번호, 새 트리거 참조 번호， 유효 구간， 우선 순위， SMS 애플리 케이션 포트 ID, 트리거 페 이로드 등을 포함하는 제출 트리거 취소 메시지를 SMS-SC로 전송할 수 있다. [96] MTC-IWF는 다음 중 하나 이상의 정보에 기반하여 SCS가 Tsp 인터페이스로의 트리거 제출 (trigger submission)에 대한 쿼터 또는 레이트를 초과한 경우， 상기 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거절)할지 여부를 결정할 수 있다.
- 사업자 정 책 및 /또는 가입자 정보
- 계류중인 트리거 메시지를 취소 하는데 있어서 우선순위 (또는 긴급성 ) 여부
- 새 트리거 메시지의 우선순위 (또는 긴급성 ) 여부
- Tsp 인터페이스의 오버로드 (overload) 상황
- T4 인터페이스의 오버로드 상황 및 /또는 T5 인터페이스의 오버로드 상황
- 그 외 MTC-IWF가 저장하고 있는 장치 트리거 관련 정보 및 다른 노드 (예를 들어， HSS)로부터 획득한 장치 트리거 관련 정보
[97] MTC-IWF는 SCS에게 허용되는 트리거 제출에 대한 쿼터 또는 레이트와는 별도로 SCS에 게 허용되는 트리거 취소 (trigger cancellation)에 대한 쿼터 또는 레이트를 관리할 수도 있으며 , 이 러한 경우 트리거 취소에 대한 쿼터 또는 레이트를 초과한 경우 SCS가 보낸 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거 절)하지 않을 수 있다.
[98] MTC-IWF는 다음 중 하나 이상의 정보에 기 반하여 SCS로의 Tsp 인터페이스가 오버로드 상황인 경우， 상기 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거절)할지 여부를 결정할 수 있다.
- 사업자 정 책 및 /또는 가입자 정보
- 계류중인 트리거 메시지를 취소 하는데 있어서 우선순위 (또는 긴급성) 여부
― 새 트리거 메시지의 우선순위 (또는 긴급성) 여부
- Tsp 인터페이스의 오버로드 상황 '
- T4 인터페이스의 오버로드 상황 및 /또는 T5 인터페 이스의 오버로드 상황
- SCS가 Tsp 인터페이스로의 트리거 제출 (또는 트리거 취소)에 대한 쿼 터 또는 레이트를 초과했는지 여부
- 그 외 MTC-IWF가 저장하고 있는 장치 트리거 관련 정보 및 다른 노드 (예를 들어， HSS)로부터 획득한 장치 트리거 관련 정보
[99] 경우에 따라서는 상기 장치 트리거 취소 /회수 요청 메시지에서 요청하는 계류중인 트리거 메시지의 취소 요청만을 수락 (또는 거절)하고， 새 트리거 메시지의 제출 요청은 거절 (reject)할 수도 있다. 예를 들어, SCS가 Tsp 인터페이스로의 트리거 제출 (또는 트리거 취소)에 대한 쿼터 또는 레이트를 초과 및 /또는 Tsp 인터페이스의 오버로드 상황 및 /또는 T4 인터페이스의 오버로드 상황인 경우, 새 트리거 메시지의 우선순위는 없고 계류중인 트리거 메시지에만 우선순위가 있다면， MTC-IWF는 계류중인 트리거 메시지의 취소 요청만을 수락 (또는 거절)하고， 새 트리거 메시지의 제출 요청은 거절할 수도 있다. 또는 SCS가 장치 트리거 취소 /회수 요청 메시지를 MTC-IWF에게 전송 시， 명시적 /함축적으로 새 트리거 메시지의 제출 요청이 거절되더라도 계류중인 트리거 메시지의 취소는 반드시 수행해 줄 것을 요청하는 정보를 포함시킬 수도 있다. 이와 달리 SCS는 장치 트리거 취소 /회수 요청 메시지를 MTC-IWF에게 전송 시, 명시적 /함축적으로 새 트리거 메시지의 제출 요청이 거절되는 경우 계류중인 트리거 메시지의 취소도 함께 거절해 줄 것을 요청하는 정보를 포함시킴으로써， 두 개의 동작이 분리된 형태로 수행되는 것을 방지할 수도 있다.
[100] 제출 트리거 취소 메시지는 새롭게 정의된 메시지일 수도 있고， 기존의 T4 인터페이스를 사용한 트리거 전달 (Trigger Delivery using T4) 동작 (TS 23.682vll.2.0의 5.2.2절 참고)을 위해 사용되는 제출 트리거 메시지 또는 장치 트리거 요청 메시지 /코멘드일 수도 있다. 추가적으로 상기 메시지는 새로운 트리거 메시지로 기존의 계류중인 트리거 메시지를 교체할 것을 요청한다는 정보를 명시적 /함축적으로 포함할 수 있다. SCS가 장치 트리거 취소 /회수 요청 메시지에 옛 트리거 참조 번호 및 새 트리거 참조 번호를 모두 포함시키는 대신 하나의 트리거 참조 번호 값만 포함시킨 경우， MTC-FWF는 제출 트리거 취소 메시지에 하나의 트리거 참조 번호 값만 포함시킬 수도 있고, 옛 트리거 참조 번호와 새 트리거 참조 번호를 SCS로부터 수신한 트리거 참조 번호 값으로 설정하여 모두 포함시킬 수도 있다.
[101] 상기 단계 S602를 수행하기에 앞서 MTOIWF은 HSS/HLR (도 6에는 미도시)로 서브스크라이버 정보를 요청하기 위한 및 /또는 상기 SCS가 장치 트리거에 대한 '취소 /회수 및 교체 ' 또는 '교체 '가 허용되는 SCS인지 검사 /인증을 요청하는 메시지를 보낼 수 있다. 상기 요청 메시지에는 상기 요청 이
SCS로부터의 장치 트리거에 대한 취소 /회수 및 /또는 교체 요청에 의한 것 임을 알리는 정보를 명시 적으로 또는 함축적으로 포함시킬 수 있다. 상기 요청을 수신한 HSS/HLR은 상기 SCS가 상기 MTC 단말에 대한 트리거를 취소 /회수 및 /또는 교체하는 것 이 허용되는 SCS인지를 검사 /인증한다. 그리고 SCS는 MTC-IWF에게 웅답 메시지를 전송한다. 상기 웅답 메시지는 서브스크라이버 정보 (예컨대， IMSI, MTC 단말을 서빙하는 서빙노드의 식별자를 포함하는 라우팅 정보 등)를 포함할 수 있다. 만약 검사 /인증 결과 상기 SCS가 상기 MTC 단말에 대한 트리거를 취소 /회수 및 /또는 교체하는 것이 허 용되지 않거나, 또는 HSS/HLR에 상기 MTC 단말과 관련한 유효한 서브스크립션 정보가 존재하지 않는다면， HSS/HLR은 MTC-IWF에 게 이를 알리는 정보를 포함하는 웅답 메시지를 전송한다. 이 경우， MTC-IWF는 SCS에 게 상기 장치 트리거 취소 /회수 및 /또는 교체 요청 이 실패했음을 알리는 메시지를 보내고， 이후의 단계는 수행하지 않는다. 전술한 MTC-IWF이 HSS/HLR과 상호작용 (interaction)을 수행하는 내용은 실시 예 2 및 실시 예 3에도 적용될 수 있다. 또한， 전술한 MTC-IWF이 HSS/HLR과 상호작용 (interaction)을 수행하는 과정은 상기 단계 S601에서 SCS가 MTC-IWF에 전송한 장치 트리거 취소 요청 메시지 에 MTC' 단말의 식별자로 MSISDN이 포함되 어 있지 않은 경우에만 수행되거나 또는 MTC 단말의 식별자로 외부 식별자만 포함되 어 있는 경우에만 수행될 수도 있다.
[102] 단계 S603에서 , SMS-SC는 옛 트리거 참조 번호에 의해 확인된, 저 장된 옛 트리거 메시지 (계류 중일 수 있다) 및 /또는 옛 트리거 메시지에 관련된 정보를 제거 /삭제할 수 있다. SMS-SC는 단말이 가용해 질 때 전달할 새 트리거 메시지 및 /또는 새 트리거 메시지에 관련된 정보를 저장할 수 있다. 상기 트리거 메시지 및 /또는 트리거 메시지에 관련된 정보는 표 4에 전술한 정보들 일 수 있다.
[103] 단계 S604에서， SMS— SC는， (SMS-SC에서 ) 계류 중인 트리거 메시지가 새 트리거 메시지로 성공적으로 교체되 었음을 알리기 위 한 제출 트리거 취소 웅답 메시지를 MTC-IWF로 전송할 수 있다.
[104] 제출 트리거 취소 웅답 (Submit Trigger Cancel Response) 메시지는 새롭게 정의된 메시지 일 수도 있고， 기존의 T4 인터페이스를 사용한 트리거 전달 동작 (TS 23.682vl l.2.0의 5.2.2절 참고)을 위해 사용되는 제출 트리거 확인 메시지 (Submit Trigger Confirm message) 또는 메시지 전달 보고 (Message Delivery Report) 메시지 일 수도 있다. 추가적으로 상기 메시지는 새로운 트리거 메시지로 기존의 계류중인 트리거 메시지를 교체하는 것을 요청하는 메시지에 대한 웅답 메시지 임을 나타내는 정보를 명시적 /함축적으로 포함할 수 있다.
[ 105 ] 단계 S605에서， MTC-IWF는 외부 식별자， MSISDN, 옛 트리거 참조 번호， 새 트리거 참조 번호를 포함하는 장치 트리거 취소 보고 (Device Trigger Cancel Report) 메시지를 (트리거 취소가 성공인지 실패인지 , 실패라면 그 이유를 지시하는 이유 값 (cause value)와 함께) SCS로 전송할 수 있다.
[ 106 ] 장치 트리거 취소 보고 메시지는 본 발명을 위해 새롭게 정의된 메시지 일 수도 있고， 기존의 Tsp 상의 장치 트리거 절차 동작 (TS 23.682vl l.2.0의 5.2.1절 참고)을 위해 사용되는 장치 트리거 보고 메시지 (Device Trigger Report message) 또는 Device-Notification-Request (DNR) 메시지 /코멘드일 수도 있다. 추가적으로 상기 메시지는 새로운 트리거 메시지로 기존의 계류중인 트리거 메시지를 교체하는 것을 요청하는 메시지에 대한 응답 메시지 임을 나타내는 정보를 명시적 /함축적으로 포함할 수 있다.
[107] 실시예 lb - T4 트리거 메시지의 취소 /회수
[108] 도 7을 참조하면， 단계 S701에서， SCS는 이 전에 제출된 트리거 메시지를 취소할 필요가 있는지: 여부를 결정할 수 있다. SCS는 장치 트리거 취소 요청 메시지 (외부 식별자 (External Identifier) 또는 MSISDN, SCS 식 별자 (SCS
Identifier), 옛 트리거 참조 번호 (old trigger reference number) 또는 트리거 참조 번호 등을 포함)를 MTC-IWF에 전송할 수 있다. 옛 트리거 참조 번호
(또는 트리거 참조 번호)는 SCS가 취소하기를 원하는， 이 전에 제출된 트리거 메시지에 할당된 트리거 참조 번호를 지시할 수 있다. [ 109] 장치 트리거 취소 /회수 요청 메시지는 본 발명을 위해 새롭게 정의된 메시지 일 수도 있고， 기존의 Tsp 상의 장치 트리거 절차 동작 (TS 23.682vl l.2.0의 5.2.1절 참고)을 위해 사용되는 장치 트리거 요청 메시지 일 수도 있다. 추가적으로 상기 메시지는 기존의 계류중인 트리거 메시지를 취소할 것을 요청한다는 정보를 명시 적 /함축적으로 포함할 수 있다.
[110] 예를 들면， 계류중인 트리거 메시지를 취소할 것을 요청하기 위 한 장치 트리거 취소 /희수 요청 메시지는 기존의 장치 트리거 요청 메시지 , 즉 장치 - 액션 -요청 메시지 /코맨드 (상기 2.2.3절에서 설명 한)를 사용하면서 새로운 액션- 타입 값， 예컨대 Action-Type = "Recall" (구체적으로는 "Recall"을 의미 하는 특정 열거된 값 또는 정수값)을 정의하여 사용할 수 있다. 또한， 이 때 회수 요청에 필요한 정보들을 포함하기 위 해 기존의 AVP를 확장하거나 새로운 AVP를 정의하여 사용할 수 있다. 또 다른 예로는 계류중인 트리거 메시지를 회수 또는 교체하도록 요청하는 새로운 메시지 /코멘드를 정의하면서 회수 및 교체에 대해 각각 정의된 액션 -타입 AVP를 포함하도록 하는 것 이다. 또는， 계류중인 트리거 메시지를 취소 /회수하도록 요청하는 메시지 /코멘드와 계류중인 트리거 메시지를 교체하도록 요청하는 메시지 /코멘드를 각각 정의하여 사용할 수도 있다. 전술한 SCS가 MTC-IWF에 게 전송하는 장치 트리 거 취소 /회수 요청 메시지 에 대한 내용은 실시예 2 및 실시 예 3에도 적용될 수 있다.
[111 ] 장치 트리거 취소 /회수 요청 메시지는 추가적으로 계류중인 트리거 메시지 에 대한 우선순위 값을 포함할 수 있다. 계류중인 트리거 메시지와 관련한 우선순위 값은 상기 계류증인 트리거 메시지를 취소 하는데 있어서 우선순위가 있는지 여부를 나타낼 수 있다. 그러나 계류중인 트리거 메시지를 취소 하는데 있어서 우선순위 (또는 긴급성 ) 여부는 다양한 형 태의 메시지 및 /또는 파라미터 및 /또는 정보로 나타낼 수도 있다.
[112] 단계 S702에서， 수신된 장치 트리거 취소 요청 메시지의 외부 식별자，
MSISDN, SCS 식 별자， 옛 트리거 참조 번호 등에 기초해서， 어떤 트리거 메시지가 삭제되어 야 할지를 확인 (identify)할 수 있다. 또한， MTC-IWF는 외부 식별자， MSISDN, IMSI, SCS 식별자， 옛 트리거 참조 번호 (또는 트리거 참조 번호) 등을 포함하는 제출 트리거 취소 메시지를 SMS-SC로 전송할 수 있다.
[113] MTC-IWF는 다음 중 하나 이상의 정보에 기반하여 SCS가 Tsp 인터페이스로의 트리거 제출에 대한 쿼터 또는 레이트를 초과한 경우, 상기 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거절)할지 여부를 결정할 수 있다.
- 사업자 정책 및 /또는 가입자 정보
- 계류증인 트리거 메시지를 취소 하는데 있어서 우선순위 (또는 긴급성 ) 여부
- Tsp 인터페이스의 오버로드 상황
- T4 인터페이스의 오버로드 상황 및 /또는 T5 인터페이스의 오버로드 상황 - 그 외 MTC-IWF가 저장하고 있는 장치 트리거 관련 정보 및 다른 노드
(예를 들어 HSS)로부터 획득한 장치 ：트리거 관련 정보
[114] MTC-IWF는 SCS에게 허용되는 트리거 제출에 대한 쿼터 또는 레이트와는 별도로 SCS에게 허 용되는 트리거 취소에 대한 쿼 터 또는 레이트를 관리할 수도 있으며 , 이 러 한 경우 트리거 취소에 대한 쿼터 또는 레이트를 초과한 경우 SCS가 보낸 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거절)하지 않을 수 있다.
[115] MTC—IWF는 다음 중 하나 이상의 정보에 기 반하여 SCS로의 Tsp 인터페 이스가 오버로드 상황인 경우, 상기 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거 절)할지 여부를 결정할 수 있다.
― 사업자 정 책 및 /또는 가입자 정보
- 계류중인 트리거 메시지를 취소 하는데 있어서 우선순위 (또는 긴급성 ) 여부
- Tsp 인터페 이스의 오버로드 상황
- T4 인터페 이스의 오버로드 상황 및 /또는 T5 인터페 이스의 오버로드 상황 - SCS가 Tsp 인터페이스로의 트리 거 제출 (또는 트리거 취소)에 대한 쿼터 또는 레이트를 초과했는지 여부
ᅳ 그 외 MTC-IWF가 저장하고 있는 장치 트리거 관련 정보 및 다른 노드 (예를 들어， HSS)로부터 획득한 장치 트리거 관련 정보
[116] 제출 트리거 취소 메시지는 새롭게 정의된 메시지 일 수도 있고, 기존의 T4 인터페이스를 사용한 트리거 전달 동작 (TS 23.682vl l.2.0의 5.2.2절 참고)을 위해 사용되는 제출 트리거 메시지 일 수도 있다. 추가적으로 상기 메시지는 기존의 계류중인 트리거 메시지를 취소 할 것을 요청한다는 정보를 명시 적 /함축적으로 포함할 수 있다.
[117] 상기 단계 S702를 수행하기에 앞서 MTC—IWF은 HSS/HLR (도 7에는 미도시 )로 서브스크라이버 정보를 요청하기 위 한 그리고 /또는 상기 SCS가 장치 트리거에 대한 '취소 /회수 및 /또는 교체 ' 또는 '취소 /회수'가 허용되는 SCS인지 검사 /인증을 요청하는 메시지를 보낼 수 있다. 상기 요청 메시지에는 상기 요청 이 SCS로부터의 장치 트리거에 대한 취소 /회수 및 /또는 교체 요청 에 의한 것 임을 알리는 정보를 명시 적으로 또는 함축적으로 포함시 킬 수 있다. 상기 요청올 수신한 HSS/HLR은 상기 SCS가 상기 MTC 단말에 대한 트리거를 취소 /회수 및 /또는 교체하는 것이 허용되는 SCS인지를 검사 /인증한다. 그리고 SCS는 MTC— IWF에 게 웅답 메시지를 전송한다. 상기 웅답 메시지는 서브스크라이버 정보 (예컨대， IMSI, MTC 단말을 서빙하는 서빙노드의 식별자를 포함하는 라우팅 정보 등)를 포함할 수 있다. 만약 검사 /인증 결과 상기 SCS가 상기 MTC 단말에 대한 트리거를 취소 /회수 및 /또는 교체하는 것 이 허 용되지 않거나， 또는 HSS/HLR에 상기 MTC 단말과 관련한 유효한 서브스크립션 정보가 존재하지 않는다면， HSS/HLR은 MTC-IWF에 게 이를 알리는 정보를 포함하는 응답 메시지를 전송한다. 이 경우， MTC-IWF는 SCS에 게 상기 장치 트리거 취소 /회수 및 /또는 교체 요청이 실패했음을 알리는 메시지를 보내고， 이후의 단계는 수행하지 않는다. 전술한 MTC-IWF이 HSS/HLR과 상호작용 (interaction)을 수행하는 내용은 실시 예 2 및 실시 예 3에도 적용될 수 있다. 또한， 전술한 MTCᅳ IWF이 HSS/HLR과 상호작용 (interaction)을 수행하는 과정은 상기 단계 S701에서 SCS가 MTC-IWF에 전송한 장치 트리거 취소 요청 메시지에 MTC 단말의 식별자로 MSiSDN이 포함되어 있지 않은 경우에만 수행되거나 또는 MTC 단말의 식별자로 외부 식별자만 포함되어 있는 경우에 만 수행될 수도 있다.
[118] 단계 S703에서， SMS— SC는 옛 트리거 참조 번호에 의해 확인된， 저 장된 옛 트리거 메시지 (예를 들어， 계류 중인) 및 /또는 수신된 제출 트리거 취소 메시지에 포함된 기타 정보 (예를 들어， 외부 식별자, MSISDN, IMSI, SCS 중 하나 이상의 정보)를 제거할 수 있다. SMS-SC는 단말이 가용해 질 때 전달할 새 트리거 메시지를 저장할 수 있다.
[119] 단계 S704에서， SMS-SC는， (SMS-SC에서) 계류 중인 트리거 메시지가 새 트리거 메시지로 성공적으로 제거 /희수되 었음을 알리 기 위한 제출 트리거 취소 웅답 메시지를 MTC-IWF로 전송할 수 있다.
[120] 제출 트리거 취소 응답 메시지는 본 발명을 위해 새롭게 정의된 메시지 일 수도 있고， 기존의 T4 인터페이스를 사용한 트리거 전달 동작 (TS 23.682vl l.2.0의 5.2.2절 참고)을 위해 사용되는 제출 트리거 확인 메시지 또는 메시지 전달 보고 메시지 일 수도 있다. 추가적으로 상기 메시지는 기존의 계류중인 트리거 메시지를 취소 하는 것을 요청하는 메시지 에 대한 웅답 메시지 임을 나타내는 정보를 명시적 /함축적으로 포함할 수 있다.
[121 ] 단계 S705에서 , MTC-IWF는 외부 식별자, MSISDN, 옛 트리거 참조 번호를 포함하는 장치 트리거 취소 보고 (Device Trigger Cancel Report) 메시지를， (트리거 취소가 성공인지 실패 인지， 실패라면 그 이유를 지시하는 이유 값 (cause value)와 함께) SCS로 전송할 수 있다.
[122] 장치 트리거 취소 보고 메시지는 본 발명을 위해 새롭게 정의 된 메시지 일 수도 있고， 기존의 Tsp 상의 장치 트리거 절차 동작 (TS 23.682vl l.2.0의 5.2.1절 참고) 을 위 해 사용되는 장치 트리거 보고 메시지 일 수도 있다. 추가적으로 상기 메시지는 기존의 계류중인 트리거 메시지를 취소 하는 것을 요청하는 메시지에 대한 웅답 메시지 임을 나타내는 정보를 명시 적 /함축적으로 포함할 수 있다.
[123] 상술한 실시 예 la 및 /또는 lb에서 , 만약， 복수개의 SMS-SC가 MTC- IWF에 연결되어 있는 경우, MTC-IWF가 장치 트리거를 취소 /회수하기 위 한 요청 메시지 또는 장치 트리거를 교체하기 위한 요청 메시지를 전송하는 대상이 되는 SMS-SC를 선택 /결정할 필요가 있다. 이는 복수개의 SMS-SC 중， 옛 트리거 메시지를 저장하고 있는 SMS-SC (즉， 이 전에 MTC— IWF가 옛 트리거 메시지에 대한 전송을 요청 한 SMS—SC)에 게 교체， 취소 /회수 요청 메시지를 전송해야 하기 때문이다. 이에 MTC-IWF는 다음 중 하나 이상의 방법으로 SMS-SC를 선택 /결정할 수 있다.
[124] 첫 번째로， MTC-IWF에 단말 별로 장치 트리거 전송 요청 메시지 (도 5의 단계 S5C11에서 제출 트리거 (Submit Trigger) 메시지 )를 보내는 SMS— SC가 설정 (configure) 되어 있을 수 있다. 이는, T4 트리거 메시지의 교체， 취소 /회수에 관련된 제 1 메시지를 수신하는 SMS-SC가 단말 별로 설정되어 있는 것으로 이해될 수 있다. 즉ᅳ 설정 (configuration)에 기 반하여 MTC-IWF가 제 1 메시지를 전송할 SMS-SC를 결정할 수 있는 것 이다.
[125] 예를 들면， 단말— 1， 단말— 2에 대해서는 SMS-SC— 1， 그리 고 단말— 3， 단말 -4에 대해서는 SMS-SC-2가 설정 되어 있어서 장치 트리거를 교체， 취소 /회수 하기 위한 요청 메시지도 설정 되 어 있는 SMS-SC로 전송한다. 여기서 단말에 대한 식별은 외부 식 별자， MSISDN 중 하나 이상이 사용될 수 있으며 , 이외의 다른 정보도 특정 단말에 대해 할당 /설정 되 어 있는 SMS-SC를 결정 /선택하기 위 해 사용될 수 있다.
[126] 두 번째로， MTC-IWF는 HSS/HLR에게 장치 트리거 교체， 취소 /희수를 수행해야 하는 옛 트리거 메시지를 저 장하고 있는 SMS-SC (즉， 이 전에 MTC- IWF가 옛 트리거 메시지에 대한 전송을 요청 한 SMS—SC)에 대한 정보를 요청하여 획득한다. HSS/HLR이 MTC-IWF으로부터 SMS—SC 정보를 요청하는 메시지를 수신하면， HSS/HLR은 MTC-IWF에 게 SMS-SC 정보 (예를 들어， SMS- SC 주소, 이름， 식 별자 등)를 제공한다. MTC— IWF가 HSS/HLR에게 요청 메시지를 전송 시 , 외부 식 별자， MSISDN 중 하나 이상을 포함하며， 추가적으로는 SCS 식별자 등을 포함할 수 있다. 이는 SCS로부터 수신한 장치 트리거 교체 , 취소 /회수 요청 메시지에 포함된 정보에 기반한다. SMS—SC는 트리거 전송이 실패한 경우 HSS/HLR에게 단말 /UE가 가용해지면 통보해주는 것 (즉， Alert-Service Centre 메커니즘)을 요청하는데 (TS 23.682의 5.2.2절 step
8 참조) 이 요청을 수신할 때마다 HSS/HLR은 단말 /UE에 대한 SMS—SC 주소 /정보를 저장할 수 있다. 이 에 기 반하여 HSS/HLR은 MTC-IWF에 게 SMS— SC 정보를 요청하는 메시지를 수신하면 SMS-SC 정보를 제공할 수 있다. HSS/HLR은 단말 /UE가 가용해져서 SMS-SC에게 이를 알리는 통보 메시지를 전송한 이후에 SMS-SC 정보를 계속 유지할 수도 있고, 삭제할 수도 있다. 만약， 후자의 경우 MTC-IWF으로부터 SMS-SC 정보를 요청하는 메시지를 수신 시 , HSS/HLR은 SMS-SC 정보를 더 이상 저 장하고 있지 않을 수도 있다. 이 경우 HSS/HLR은 MTC-IWF에 게 SMS-SC 정보를 제공할 수 없음을 알리는 (명시 적으로 또는 암시 적으로) 웅답을 보낸다. 웅답을 수신한 MTC-IWF는 i) SCS에게 장치 트리거에 대한 교체， 취 소 /회수 요청이 실패했음을 알리는 웅답 메시지를 전송하거나， 또는 H) SCS가 장치 트리거를 취소 /회수하는 요청을 한 경우， SCS에 게 장치 트리거에 대한 취소 /회수 요청이 실패했음을 알리는 웅답 메시지를 전송한다: SCS가 장치 트리거를 교체하는 요청을 한 경우, 새 트리거 메시지 에 대한 T4 방식의 전송을 수행한다. 추가적으로는 SCS에 게 웅답을 전송할 수 있는데 응답은 옛 트리거 메시지 에' 대한 취소 /회수가 실패했음을 알리는 정보 및 /또는 새 트리거 메시지 에 대한 전송을 수행할 것 임을 알리는 정보를 포함할 수 있다. 상기 MTCᅳ IWF이 HSS/HLR로부터 SMS-SC 정보를 획득하기 위해 교환하는 메시지는 상기 실시 예 la의 단계 S602 및 실시 예 lb의 단계 S702에 앞서 수행할 수 있는 서브스크라이버 정보를 요청 그리고 /또는 SCS에 대한 검사 /인증을 요청하기 위해 교환하는 메시지가 될 수 있다. 상기 메시지는 MTC-IWF이 SMS— SC 정보를 요청함을 알리는 정보를 명시 적 또는 함축적으로 포함할 수 있다.
[127] 상술한 SMS-SC를 선택 /결정하는 방법은 본 발명 전반에 걸쳐 적용될 수 있다. 또한， 복수개가 '아닌 하나의 SMS—SC가 MTC-IWF에 연결되 어 있는 경우에도 한 방법 이 사용될 수 있다. 또한 i)에서 전술한 설정 (configuration)에 기반한 SMS— SC 선택 /결정 방법은 후술하는 실시 예 2에 관련된 T5 방식의 장치 트리거 전송의 경우에 확장 적용될 수 있다. 즉， SCS가 복수개의 MTC-IWF과 연결되 어 있을 때, 옛 트리거 메시지 에 대한 교체， 취소 /회수 요청을 보내기 위해 옛 트리거 메시지를 저장하고 있는 MTC— IWF (즉， 이 전에 SCS가 옛 트리거 메시지 에 대한 전송을 요청 한 MTC-IWF)에 게 교체， 취소 /회수 요청 메시지를 전송해야 하는 바， SCS가 적 절한 MTC— IWF을 선택 /결정하는데 한 설정에 기반한 선택 방식이 사용될 수 있다
[128] 실시예 2-T5트리거 메시지의 교체， 취소 /회수
[129] 두 번째 실시예는 T5트리거 메시지의 교체， 취소 /회수에 관한 것이다.
[130] T5 트리거 메시지의 교체, 취소 /회수는 MTC-IWF에 의해 수행될 수 있다. 구체적으로， MTC-IWF는 제 1 메시지에 포함된 옛 트리거 참조 번호 (old trigger reference number)에 기초하여 어떤 트리거 메시지를 취소 /회수 또는 교체하여야 할지를 확인 (identify)하고, 확인된 트리거 메시지를 삭제할 수 있다. 만약, 제 1 메시지가 트리거 메시지의 교체에 관련된 경우 (예를 들어， 제 1 메시지가 새 트리거 참조 번호를 포함하는 경우)， MTC-IWF는 옛 트리거 참조 번호에 해당되는 트리거 메시지를 삭제하고， (새 트리거 참조 번호에 해당하는) 새 트리거 메시지를 저장할 수 있다. 저장된 새 트리거 메시지는 단말이 가용한 경우 단말에게 전달될 수 있다.
[131] 여기서， 제 1 메시지는 후술하는 바와 같이， 제출 트리거 취소 /회수 메시지 또는 제출 트리거 교체 메시지일 수 있으며， 이는 MTC-IWF가 SCS로부터 수신한 장치 트리거에 관련된 메시지일 수 있다. 다시 말해， 제 1 메시지는 트리거의 교체 동작 또는 트리거의 회수 /취소 동작 중 어느 하나를 요청하는 것일 수 있으며， 구체적으로 장치 트리거 취소 /회수 요청 메시지， 장치 트리거 교체 요청 메시지일 수 있다. 또는， 제 1 메시지는 액션 타입이 장치 트리거 취소 /회수 또는 교체 중 어느 하나로 설정된 장치 액션 요청 메시지의 형태일 수도 있다. 또한, 제 1 메시지는 SCS가 Tsp 인터페이스로의 트리거 제출의 쿼터 또는 레이트를 초과한 경우， 상기 MTC-IWF에 의해 거절될 수 있다. ,
[132] 실시예 2a— T5트리거 메시지의 교체
[133] 도 8에는 T5 트리거 메시지의 교체 절차가 도시되어 있다. 도 8을 참조하면， 단계 S801에서 SCS는 이전에 제출된 트리거 메시지를 취소할 필요가 았는지 여부를 결정할 수 있다. SCS는 장치 트리거 취소 요청 메시지 (외부 식별자 또는 MSISDN, SCS 식별자， 옛 트리거 참조 번호， 새 트리거 참조 번호， 유효 기간， 우선순위, 트리거 페이로드 등을 포함)를 MTC-IWF에 전송할 수 있다. 옛 트리거 참조 번호는 SCS가 취소하기를 원하는, 이전에 제출된 트리거 메시지에 할당된 트리거 참조 번호를 지시할 수 있다. 새 트리거 참조 번호는 새롭게 제출된 트리거 메시지에게 SCS에 의해 할당될 수 있다. 유효 기간， 우선순위， 트리거 페이로드가새 트리거 메시지를 위한 것인데 비해, 외부 식별자,
MSISDN, SCS 식별자는 모두 옛 트리거 메시지 (예를 들어， 계류 중인 트리거 메시지) 및 새 트리거 메시지에 연관되어 있다.
[134] 장치 트리거 취소 /회수 요청 메시지는 새롭게 정의된 메시지일 수도 있고, 기존의 Tsp 상의 장치 트리거 절차 (Device triggering procedure over Tsp) 동작 (상세한 내용은 TS 23.682vll.2.0의 5.2.1절에 의해 참고될 수 있다.)을 위해 사용되는 장치 트리거 요청 메시지일 수도 있다. 추가적으로 상기 메시지는 새로운 트리거 메시지로 기존의 계류중인 트리거 메시지 (pending trigger message)를 교체할 것을 요청한다는 정보를 명시적 /함축적으로 포함할 수 있다.
[135] SCS는 새 트리거 참조 번호를 옛 트리거 참조 번호와 동일한 값으로 설정할 수 있다. 이러한 경우 장치 트리거 취소 /회수 요청 메시지에 옛 트리거 참조 번호 및 새 트리거 참조 번호가 모두 포함될 수도 있고， 하나의 트리거 참조 번호 값만 포함될 수도 있다.
[136] 우선순위 정보의 경우 계류중인 트리거 메시지에 대한 우선순위 값과 새 트리거 메시지에 대한 우선순위 값이 다른 경우 (아니면 같더라도)， 계류중인 트리거 메시지에 대한 우선순위 값을 추가적으로 장치 트리거 취소 /회수 요청 메시지에 포함시킬 수 있다. 계류중인 트리거 메시지와 관련한 우선순위 값은 상기 계류중인 트리거 메시지를 취소 하는데 있어서 우선순위가 있는지 여부를 나타낼 수 있다. 그러나 계류중인 트리거 메시지를 취소 하는데 있어서 우선순위 (또는 긴급성) 여부는 다양한 형태의 메시지 및 /또는 파라미터 및 /또는 정보로 나타낼 수도 있다.
[137] 수신된 장치 트리거 취소 요청 메시지의 외부 식별자， MSISDN, SCS 식별자， 옛 트리거 참조 번호 중 하나 이상의 정보에 기초해서, MTC-IWF는 새 트리거 메시지로의 교체되는 과정에서 어떤 트리거 메시지가 삭제되어야 할지를 확인 (identify)할 수 있다.
[138] MTC-IWF는 다음 중 하나 이상의 정보에 기반하여 SCS가 Tsp 인터페이스로의 트리거 제출 에 대한 쿼터 또는 레이트를 초과한 경우， 상기 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거 절) (거절)할지 여부를 결정할 수 있다.
- 사업자 정 책 및 /또는 가입자 정보
- 계류중인 트리거 메시지를 취소 하는데 있어서 우선순위 (또는 긴급성 ) 여부
- 새 트리거 메시지의 우선순위 (또는 긴급성 ) 여부
- Tsp 인터페이스의 오버로드 상황
- T5 인터페이스의 오버로드 상황 및 /또는 T4 인터페이스의 오버로드 상황 - 그 외 MTC-IWF가 저장하고 있는 장치 트리거 관련 정보 및 다른 노드 (예를 들어， HSS)로부터 획득한 장치 트리거 관련 정보
[139] MTC-IWF는 SCS에게 허용되는 트리거 제출에 대한 쿼터 또는 레이트와는 별도로 SCS에게 허용되는 트리거 취소에 대한 쿼 터 또는 레이트를 관리할 수도 있으며， 이 러 한 경우 트리거 취소에 대한 쿼터 또는 레이트를 초과한 경우 SCS가 보낸 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거 절)하지 않을 수 있다.
[140] MTC-IWF는 다음 중 하나 이상의 정보에 기 반하여 SCS로의 Tsp 인터페이스가 오버로드 상황인 경우, 상기 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거 절)할지 여부를 결정할 수 있다.
- 사업자 정 책 및 /또는 가입자 정보
- 계류중인 트리거 메시지를 취소 하는데 있어서 우선순위 (또는 긴급성 ) 여부
- 새 트리거 메시지의 우선순위 (또는 긴급성 ) 여부
- Tsp 인터페이스의 오버로드 상황 '
- T5 인터페이스의 오버로드 상황 및 /또는 T4 인터페 이스의 오버로드 상황 ᅳ SCS가 Tsp 인터페이스로의 트리거 제출 (또는 트리거 취소)에 대한 쿼터 또는 레이트를 초과했는지 여부
- 그 외 MTC— IWF가 저 장하고 있는 장치 트리거 관련 정보 및 다른 노드 (예를 들어， HSS)로부터 획득한 장치 트리거 관련 정보
[ 141 ] 경우에 따라서는 상기 장치 트리거 취소 /회수 요청 메시지에서 요청하는 계류중인 트리거 메시지의 취소 요청만을 수락 (또는 거 절)하고, 새 트리거 메시지의 제출 요청은 거 절할 수도 있다. 예를 들어， SCS가 Tsp 인터페이스로의 트리거 제출 (또는 트리거 취소)에 대한 쿼터 또는 레이트를 초과 및 /또는 Tsp 인터페이스의 오버로드 상황 및 /또는 T5 인터페이스의 오버로드 상황인 경우， 새 트리거 메시지의 우선순위는 없고 계류중인 트리거 메시지 에만 우선순위가 있다면, MTC-IWF는 계류중인 트리거 메시지의 취소 /회수 요청 만을 수락 (또는 거절)하고， 새 트리거 메시지의 제출 요청은 거절할 수도 있다. 또는 SCS가 장치 트리거 취소 /회수 요청 메시지를 MTC-IWF에 게 전송 시 , 명시적으로 /함축적으로 새 트리거 메시지 의 제출 요청 이 거절되더라도 계류중인 트리거 메시지 의 취소 /회수는 반드시 수행해 줄 것을 요청하는 정보를 포함시 킬 수도 있다. 이와 달리 SCS는 장치 트리거 취소 /회수 요청 메시지를 MTC— IWF에게 전송 시 , 명시 적으로 /함축적으로 새 트리거 메시지의 제출 요청 이 거 절되는 경우 계류중인 트리거 메시지의 취소 /회수도 함께 거 절해 줄 것을 요청하는 정보를 포함시 킴으로써， 두 개의 동작이 분리 된 형 태로 수행되는 것을 방지할 수도 있다.
[142] 단계 S802에서， MTC-IWF는 계류중인 트리거 메시지를 새 트리거 메시지로 교체하는 동작을 수행할 수 있다. 교체 동작은 다음과 같이 , 계류 중인 트리거 메시지가 어느 네트워크 노드에 저장되어 있는지에 따라 다소 상이할 수 있다.
[143] 만약， MTC-IWF가 계류중인 트리거 메시지를 저장하고 있는 경우 (또는 store & forward 기능을 수행하는 경우)， MTC-IWF는 계류중인 트리거 메시지 및 /또는 계류중인 트리거 메시지 에 관련된 정보를 제거 /삭제하고 새 트리거 메시지 및 /또는 새 트리거 메시지에 관련된 정보를 저장한다. 만약, 서 빙 노드 (즉, MSC/SGSN/MME)가 계류중인 트리거 메시지를 저 장하고 있는 경우 (또는 store & forward 기능을 수행하는 경우), MTC-IWF가 상기 계류중인 트리거 메시지를 저장하고 있는 서빙 노드로 메시지를 보내 (T5 인터페이스를 통해 또는 다른 노드를 거 쳐) 계류중인 트리 거 메시지를 제거하고 새 트리거 메시지를 저장할 것을 요청할 수 있다. 만약 상기 외의 다른 노드가 계류증인 트리거 메시지를 저장하고 있는 경우 (또는 store & forward 기능을 수행하는 경우), MTOIWF가 상기 계류중인 트리거 메시지를 저장하고 있는 다른 노드로 메시지를 보내 (다른 노드와 연결된 인터페이스를 통해 또는 다른 노드를 거 쳐 ) 계류중인 트리거 메시지를 트리거 메시지를 제거하고 새 트리거 메시지를 저장할 것을 요청할 수 있다.
[144] 단계 S803에서， MTC-IWF는 외부 식별자, MSISDN, 옛 트리거 참조 번호， 새 트리거 참조 번호를 포함하는 장치 트리거 취소 보고 (Device Trigger Cancel Report) 메시지를 (트리거 취소가 성공인지 실패인지， 실패라면 그 이유를 지시하는 이유 값 (cause value)와 함께) SCS로 전송할 수 있다. 장치 트리거 취소 메시지는 새롭게 정의된 메시지 일 수도 있고， 기존의 Tsp 상의 장치 트리거 절차 동작 (TS 23.682vl l.2.0의 5.2.1절 참고)을 위해 사용되는 장치 트리거 보고 메시지 또는 Device-Notification-Request (DNR) 메시지 /코멘드일 수도 있다. 추가적으로 상기 메시지는 새로운 트리거 메시지로 기존의 계류중인 트리거 메시지를 교체하는 것을 요청하는 메시지에 대한 응답 메시지 임을 나타내는 정보를 명시 적 /함축적으로 포함할 수 있다.
[145] 실시예 2b - T5 트리거 메시지의 취소 /회수
[146] 도 9를 참조하면， 단계 S901에서， SCS는 이전에 제출된 트리거 메시지를 취소할 필요가 있는지 여부를 결정할 수 있다. SCS는 장치 트리거 취소 요청 메시지 (외부 식별자 또는 MSISDN, SCS 식별자， 옛 트리거 참조 번호 또는 트리거 참조 번호 등을 포함)를 MTC— IWF에 전송할 수 있다. 옛 트리거 참조 번호 (또는 트리거 참조 번호)는 SCS가 취소하기를 원하는， 이 전에 제출된 트리거 메시지 에 할당된 트리거 참조 번호를 지시할 수 있다.
[147] 장치 트리거 취소 /회수 요청 메시지는 새롭게 정의 된 메시지 일 수도 있고， 기존의 Tsp 상의 장치 트리거 절차 동작 (TS 23.682vl l.2.0의 5.2.1절 참고)을 위해 사용되는 장치 트리거 요청 메시지 일 수도 있다. 추가적으로 상기 메시지는 기존의 계류중인 트리거 메시지를 취소할 것을 요청한다는 정보를 명시 적 /함축적으로 포함할 수 있다.
[148] 장치 트리 거 취소 /회수 요청 메시지는 추가적으로 계류중인 트리거 메시지에 대한 우선순위 값을 포함할 수 있다. 계류중인 트리거 메시지와 관련한 우선순위 값은 상기 계류중인 트리거 메시지를 취소 /회수하는데 있어서 우선순위가 있는지 여부를 나타낼 수 있다. 그러나 계류중인 트리거 메시지를 취소 /회수하는데 있어서 우선순위 (또는 긴급성) 여부는 다양한 형태의 메시지 및 /또는 파라미터 및 /또는 정보로 나타낼 수도 있다.
[149] 수신된 장치 트리거 취소 요청 메시지의 외부 식별자， MSISDN, SCS 식별자, 옛 트리거 참조 번호 중 하나 이상의 정보에 기초해서, 어떤 트리거 메시지가삭제되어야 할지를 확인 (identify)할 수 있다.
[150] MTC-IWF는 다음 중 하나 이상의 정보에 기반하여 SCS가 Tsp 인터페이스로의 트리거 제출 에 대한 쿼터 또는 레이트를 초과한 경우， 상기 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거절)할지 여부를 결정할 수 있다. 하기한 정보 외에도 다양한 정보에 기반할 수 있다. '
- 사업자 정책 및 /또는 가입자 정보
- 계류중인 트리거 메시지를 취소 /회수하는데 있어서 우선순위 (또는 긴급성) 여부
- Tsp 인터페이스의 오버로드 상황
- T5 인터페이스의 오버로드 상황 및 /또는 T4 인터페이스의 오버로드 상황 - 그 외 MTC-IWF가 저장하고 있는 장치 트리거 관련 정보 및 다른 노드
(예를 들어， HSS)로부터 획득한 장치 트리거 관련 정보
[151] MTC-IWF는 SCS에게 허용되는 트리거 제출에 대한 쿼터 또는 레이트와는 별도로 SCS에게 허용되는 트리거 취소에 대한 쿼터 또는 레이트를 관리할 수도 있으며, 이러한 경우 트리거 취소에 대한 쿼터 또는 레이트를 초과한 경우 SCS가 보낸 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거절)하지 않을 수 있다.
[152] MTC-IWF는 다음 중 하나 이상의 정보에 기반하여 SCS로의 Tsp 인터페이스가 오버로드 상황인 경우， 상기 장치 트리거 취소 /회수 요청 메시지를 수락 (또는 거절)할지 여부를 결정할 수 있다. 하기한 정보 외에도 다양한 정보에 기반할 수 있다.
一 사업자 정책 및 /또는 가입자 정보 - 계류중인 트리거 메시지를 취소하는데 있어서 우선순위 (또는 긴급성 ) 여부
- Tsp 인터페이스의 오버로드 상황
- T5 인터페이스의 오버로드 상황 및 /또는 T4 인터페이스의 오버로드 상황
- SCS가 Tsp 인터페이스로의 트리거 제출 (또는 트리거 취소)에 대한 쿼터 또는 레이트를 초과했는지 여부
- 그 외 MTC—IWF가 저장하고 있는 장치 트리거 관련 정보 및 다른 노드 (예를 들어， HSS)로부터 획득한 장치 트리거 관련 정보
[153] 단계 S902에서， MTC-IWF는 계류중인 트리거 메시지를 취소 /회수하는 동작을 수행할 수 있다. 취소 /회수 동작은 다음과 같이， 계류 중인 트리거 메시지가 어느 네트워크 노드에 저장되어 있는지에 따라 다소 상이할 수 있다.
[154] 만약, MTC-IWF가 계류중인 트리거 메시지를 저장하고 있는 경우 (또는 store & forward 기능을 수행하는 경우， MTC—IWF는 계류중인 트리거 메시지를 제거 /삭제한다. MTC—IWF가 UE의 가용성 (availability)을 알기 위해 다른 노드 (예를 들어 HSS/HLR)로 이에 대한 통지 서 비스에 가입 한 경우 이를 해제하는 작업을 추가로 수행할 수도 있다. 만약， 서빙 노드 (즉, MSC/SGSN/MME)가 계류중인 트리거 메시지를 저 장하고 있는 경우 (또는 저장 및 포워드 기능을 수행하는 경우)， MTC—IWF가 상기 계류중인 트리거 메시지를 저장하고 있는 서빙 노드로 메시지를 보내 (T5 인터페 이스를 통해 또는 다른 노드를 거쳐 ) 계류중인 트리거 메시지를 제거 /삭제할 것을 요청하고 이에 대한 웅답을 수신할 수 있다.
[155] 만약， 위 언급된 노드 외 의 다른 노드가 계류중인 트리거 메시지를 저장하고 있는 경우 (또는 저장 및 포워드 기능을 수행하는 경우， MTC-IWF가 상기 계류중인 트리거 메시지를 저 장하고 있는 다른 노드로 메시지를 보내 (다른 노드와 연결된 인터페이스를 통해 또는 다른 노드를 거 쳐 ) 계류중인 트리거 메시지를 제거 /삭제할 것을 요청할 수 있다. 계류중인 트리거 메시지를 저장하고 있는 노드가 단말의 가용성을 알기 위해 또 다른 노드 (예를 들어 HSS/HLR)로 이 에 대한 통지 서 비스에 가입 한 경우 이를 해제하는 작업을 추가로 수행할 수도 있다. [156] 단계 S903에서, MTC-IWF는 외부 식별자， MSISDN, 트리거 참조 번호를 포함하는 장치 트리거 취소 보고 (Device Trigger Cancel Report) 메시지를 (트리거 취소가 성공인지 실패인지, 실패라면 그 이유를 지시하는 이유 값 (cause value)와 함께) SCS로 전송할 수 있다. 장치 트리거 취소 보고 메시지는 본 발명을 위해 새롭게 정의된 메시지일 수도 있고， 기존의 Tsp 상의 장치 트리거 절차 동작 (TS 23.682vll.2.0의 5.2.1절 참고)을 위해 사용되는 장치 트리거 보고 메시지일 수도 있다. 추가적으로 상기 메시지는 기존의 계류중인 트리거 메시지를 취소하는 것을 요청하는 메시지에 대한 웅답 메시지임을 나타내는 정보를 명시적 /함축적으로 포함할 수 있다.
[157] 실시예 3-T5스몰 데이터의 교체， 취소 /회수
[158] 세 번째 실시예는 T5 인터페이스를 이용하는 스몰 데이터의 교체, 취소 /회수에 관한 것이다.
[159] T5 인터페이스를 이용한 스몰 데이터의 교체, 취소 /회수는 MTC-IWF에 의해 수행될 수 있다. 구체적으로， MTC-IWF는 제 1 메시지에 포함된 옛 스몰 데이터 참조 번호 (old trigger reference number)에 기초하여 어떤 스몰 데이터를 취소 /회수 또는 교체하여야 할지를 확인 (identify)하고， 확인된 스몰 데이터를 삭제할 수 있다. 만약， 제 1 메시지가 스몰 데이터의 교체에 관련된 경우 (예를 들어， 제 1 메시지가 새 스.몰 데이터 참조 번호를 포함하는 경우), MTOIWF는 옛 스몰 데이터 참조 번호에 해당되는 스몰 데이터를 삭제하고， (새 스몰 데이터 참조 번호에 해당하는) 새 스몰 데이터를 저장할 수 있다. 저장된 새 스몰 데이터는 단말이 가용한 경우 단말에게 전달될 수 있다.
[160] 여기서， 게 1 메시지는 후술하는 바와 같이， 스몰 데이터 취소 /회수 메시지 또는 스몰 데이터 교체 메시지일 수 있으며， 이는 MTC-IWF가 SCS로부터 수신한 스몰 데이터에 관련된 메시지일 수 있다. 다시 말해， 제 1 메시지는 스몰 데이터 교체 동작 또는 스몰 데이터의 회수 /취소 동작 중 어느 하나를 요청하는 것일 수 있으며， 구체적으로 액션 타입이 스몰 데이터 취소 /회수 또는 교체 중 어느 하나로 설정된 장치 액션 요청 메시지의 형태일 수도 있다. 또한， 제 1 메시지는 SCS가 Tsp 인터페이스로의 스몰 데이터 제출의 쿼터 또는 레이트를 초과한 경우， 상기 MTCᅳ IWF에 의해 거절될 수 있다.
[161] 실시예 3a-T5스몰 데이터의 교체
[162] 단계 S1001에서 SCS는 이전에 제출된 스몰 데이터를 메시지를 교체할 필요가 있는지 여부를 결정할 수 있다. SCS는 액션 타입이 스몰 데이터 교체 요청으로 설정된 장치 액션 요청 (외부 식별자 또는 MSISDN, SCS 식별자, 옛 스몰 데이터 참조 번호， 새 스몰 데이터 참조 번호， 유효 기간 /메시지 수명， 우선순위， 스몰 데이터 페이로드 등을 포함)을 MTC-IWF에 전송할 수 있다.
[163] 옛 스몰 데이터 참조 번호는 SCS가 취소하기를 원하는， 이전에 제출된 스몰 데이터에 할당된 스몰 데이터 참조 번호를 지시할 수 있다. 새 스몰 데이터 참조 번호는 새롭게 제출된 스몰 데이터 메시지에게 SCS에 의해 할당될 수 있다.
[164] 이와 같은 이전에 제출한 스몰 데이터에 대한 교체 동작을 위해 SCS는 MTC-IWF에게 스몰 데이터 전송 요청 시 스몰 데이터에 대한 참조 번호 (또는 식별자나 구분자)를 포함시켜 요청한다.
[165] SCS가 Tsp 인터페이스로의 스몰 데이터 제출에 대한 쿼터 또는 레이트를 초과한 경우， MTC-IWF는 SCS에 의해 전송된， 액션 타입이 스몰 데이터 교체 요청으로 설정된 장치 트리거 액션 요청 메시지를 거절할 수 있다. 이에 MTC— IWF은 SCS로 상기 거절을 알리는 응답 메시지 (실패 이유를 지시하는 이유 값 (cause value)와 함께)를 전송하며 이후의 단계는 더 이상 수행되지 않는다.
[166] 단계 S1002에서， MTC-IWF는 T5 인터페이스에서의 스몰 데이터 교체 절차를 수행한다. 보다 상세한 설명은 이하 도 11에서 설명된다.
[167] 단계 S1003에서 MTC-IWF는 SCS로 장치 액션 웅답 메시지 내의 스몰 데이터 교체 성공 또는 실패를 지시할 수 있다. 즉, MTC-IWF는 SCS에게 스몰 테이터 교체 요청에 대한 응답 메시지 또는 결과를 알리는 메시지를 전송한다. [168] 도 11에는 MTC-IWF는 T5 인터페이스에서의 스몰 데이터 교체 절차가 상세되어 있다. 도 11을 참조하면， 단계 S1101에서， 수신된 스몰 데이터 교체 요청 메시지 (즉, SCS가 보낸 이 전에 보내달라고 요청 했던 스몰 데이터에 대한 교체 요청 메시지 )에 포함된 외부 식별자， MSISDN, SCS 식별자， 옛 스몰 데이 터 참조 번호 중 하나 이상의 정보에 기초하여， MTC-IWF는 어떤 스몰 데이터가 교체되어 야 할지를 확인할 수 있다. MTC-IWF는 확인된 스몰 데이터가 이미 단말에 게 전송되었는지 아니 면 MTC-IWF에 계류 중인지 점검한다. 만약， 스몰 테이터가 MTC-IWF에 계류 중이거나 또는 스몰 데이터가 단말에 게 전송되었으나 전달이 실패한 경우， 단계 S1102a 내지 Sl lCHa가 수행될 수 있다. 보다 상세히， 단계 SI 102a에서 MTCᅳ IWF는 저장된 스몰 데이터를 삭제하고， 단말이 가용해 질 때 전달할 새 스몰 데이터를 저장한다. 단계 SI 103a에서， MTC-IWF에서， 이전에 제출된 스몰 데이 터는 성공적으로 교체된 것으로 간주된다. 단계 SI 104a에서， MTC-IWF는 단말이 가용한 경우 새 스몰 데이터를 전달한다. 여기서， 새 스몰 데이터의 전달 절차는 3GPP TR 23.887vl.l.O, 5.1.1.3.3.1.1에 의해 참조될 수 있다. 계속해서， 만약 스몰 데이터가 단말에 게 이미 전달되 었고， 이 전달이 성공적인 경우 또는 스몰 데이터 의 유효 기 간이 이미 만료 (expired)된 경우， 단계 S1102b에서 교체 요청은 실패 (예를 들어， 성공적 전달 또는 만료에 의해)한 것으로 간주된다. 단계 S1103b에서， MTC- IWF는 단말이 가용한 경우 새 스몰 테 이터를 전달한다. 여기서， 새 스몰 데이 터의 전달 절차는 3GPP TR 23.887vl.l.O, 5.1.1.3.3.1.1에 의해 참조될 수 있다.
[169] 실시예 3b ᅳ T5 스몰 데이터의 취소 /회수
[170] 단계 S1201에서 SCS는 이 전에 제출된 스몰 데이터를 메시지를 취소 /회수할 필요가 있는지 여부를 결정 할 수 있다. SCS는 액션 타입 이 스몰 데이 터 취소 /회수 요청으로 설정된 장치 액션 요청 (외부 식 별자 또는 MSISDN,
SCS 식 별자, 옛 스몰 데이터 참조 번호 또는 트리거 참조 번호 등을 포함)을
MTC-IWF에 전송할 수 있다. 옛 스몰 데이터 참조 번호 (또는 트리거 참조 번호)는 SCS가 취소하기를 원하는， 이 전에 제출된 스몰 데이 터에 할당된 스몰 데이터 참조 번호를 지시할 수 있다. 이와 같은 이전에 제출한 스몰 데이터에 대한 회수동작을 위해 SCS는 MTC—IWF에게 스몰 데이터 전송 요청 시 스몰 데이터에 대한 참조 번호 (또는 식별자나 구분자)를 포함시켜 요청할 수 있다.
[171] SCS가 Tsp 인터페이스로의 스몰 데이터 제출 에 대한 쿼터 또는 레이트를 초과한 경우， MTC-IWF는 SCS에 의해 전송된， 액션 타입이 스몰 데이터 취소 /회수 요청으로 설정된 장치 트리거 액션 요청 메시지를 거절할 수 있다. 이에 MTC-IWF은 SCS로 상기 거절을 알리는 응답 메시지 (실패 이유를 지시하는 이유 값 (cause value)와 함께)를 전송하며 이후의 단계는 더 이상 수행되지 않는다.
[172] 단계 S1202에서， MTC-IWF는 T5 인터페이스에서의 스몰 데이터 취소 /회수 절차를 수행한다. 보다 상세한 설명은 이하 도 13에서 설명된다.
[173] 단계 S1203에서 MTC-IWF는 SCS로 장치 액션 응답 메시지 내의 스몰 데이터 취소 /회수 성공 또는 실패를 지시할 수 있다. 즉， MTC-IWF는 SCS에게 스몰 데이터 회수 요청에 대한 웅답 메시지 또는 결과를 알리는 메시지를 전송한다.
[174] 도 13을 참조하면， 단계 S1301에서, 수신된 스몰 데이터 취소 /회수 요청 메시지 (즉， SCS가 보낸 이전에 보내달라고 요청했던 스몰 데이터에 대한 취소 /회수 요청 메시지)에 포함된 외부 식별자， MSISDN, SCS 식별자， 옛 스몰 데이터 참조 번호 중 하나 이상의 정보에 기초하여, MTC—IWF는 어떤 스몰 데이터가 취소되어야 할지를 확인할 수 있다. MTC-IWF는 확인된 스몰 데이터가 이미 단말에게 전송되었는지 아니면 MTC—IWF에 계류 중인지 점검한다. 만약, 스몰 데이터가 MTC-IWF에 계류 중이거나 또는 스몰 데이터가 단말에게 전송되었으나 전달이 실패한 경우， 단계 S1302a 내지 S1303a가 수행될 수 있다. 보다 상세히， 단계 S1302a에서 MTC—IWF는 저장된 스몰 데이터를 삭제한다. 단계 S1303a에서， MTC-IWF에서, 이전에 제출된 스몰 데이터는 성공적으로 취소 /회수된 것으로 간주된다. 계속해서， 만약 스몰 데이터가 단말에게 이미 전달되었고， 이 전달이 성공적인 경우 또는 스몰 데이터의 유효 기간이 이미 만료 (expired)된 경우， 단계 S1302b에서 취소 /회수 요청은 실패 (예를 들어， 성공적 전달 또는 만료에 의해)한 것으로 간주된다. [175] 상술한 설명에서, 장치 트리거 /스몰 데이터에 대한 교체, 취소 /회수를 수행하는 MTC-IWF는 단말이 로밍인 경우, 단말의 홈 (home) PLMN에 있는 MTC-IWF또는 단말이 등록한 PLMN, 즉 방문자 (visited) PLMN에 있는 MTC- IWF일 수 있다. [176] 본 발명의 실시예에 의한 장치 구성
[17기 도 14는 본 발명의 일례에 따른 단말 장치 및 네트워크 노드 장치에 대한 바람직한 실시예의 구성을 도시한 도면이다.
[178] 도 14를 참조하여 본 발명에 따른 장치 (1410)는， 송수신모들 (1411)， 프로세서 (1412) 및 메모리 (1413)를 포함할 수 있다. 송수신모들 (1411)은 외부 장치 (네트워크 노드 (미도시) 및 /또는 서버 장치 (미도시))로 각종 신호， 데이터 및 정보를 송신하고, 외부 장치로 각종 신호， 데이터 및 정보를 수신하도록 구성될 수 있다. 프로세서 (1412)는 장치 (1410) 전반의 동작을 제어할 수 있으며， 외부 장치와 송수신할 정보 등을 연산 처리하는 기능을 수행하도록 구성될 수 있다. 메모리 (1413)는 연산 처리된 정보 등을 소정시간 동안 저장할 수 있으며， 버퍼 (미도시) 등의 구성요소로 대체될 수 있다.
[179] 본 발명의 일 실시예에 따른 장치 (1410)의 프로세서는， 앞서 설명된 실시예들이 수행을 위해 필요한 사항들을 처리할수 있다. *
[180] 또한, 위와 같은 장치 (1410)의 구체적인 구성은, 전술한 본 발명의 다양한 실시예에서 설명한 사항들이 독립적으로 적용되거나 또는 2 이상의 실시예가 동시에 적용되도록 구현될 수 았으며, 중복되는 내용은 명확성을 위하여 설명을 생략한다.
[181] 상술한 본 발명의 실시예들은 다양한 수단을 통해 구현될 수 있다. 예를 들어， 본 발명의 실시예들은 하드웨어, 펌웨어 (firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. [182] 하드웨어에 의한 구현의 경우, 본 발명의 실시예들에 따른 방법은 하나 또는 그 이상의 ASICs(Application Specific Integrated Circuits), DSPs(Digital Signal Processors), DSPDs(Digital Signal Processing Devices), PLDs(Programmable Logic Devices), FPGAs(Field Programmable Gate Arrays), 프로세서， 컨트를러, 마이크로 컨트를러, 마이크로 프로세서 등에 의해 구현될 수 있다.
[183] 펌웨어나 소프트웨어에 의한 구현의 경우， 본 발명의 실시예들에 따른 방법은 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차 또는 함수 등의 형태로 구현될 수 있다. 소프트웨어 코드는 메모리 유닛에 저장되어 프로세서에 의해 구동될 수 있다. 상기 메모리 유닛은 상기 프로세서 내부 또는 외부에 위치하여, 이미 공지된 다양한 수단에 의해 상기 프로세서와 데이터를 주고 받을 수 있다.
[184] 상술한 바와 같이 개시된 본 발명의 바람직한 실시예들에 대한 상세한 설명은 당업자가 본 발명을 구현하고 실시할 수 있도록 제공되었다. 상기에서는 본 발명의 바람직한 실시예들을 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 본 발명의 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다. 예를 들어， 당업자는 상술한 실시예들에 기재된 각 구성을 서로 조합하는 방식으로 이용할 수 있다. 따라서, 본 발명은 여기에 나타난 실시형태들에 제한되려는 것이 아니라， 여기서 개시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여하려는 것이다.
[185] 본 발명은 본 발명의 정신 및 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있다. 따라서， 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고， 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다. 본 발명은 여기에 나타난 실시형태들에 제한되려는 것이 아니라, 여기서 개시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여하려는 것이다. 또한, 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함할 수 있다. 【산업상 이용가능성】
[186] 상술한 바와 같은 본 발명의 실시형태들은 다양한 이동통신 시스템에 적용될 수 있다.

Claims

【청구의 범위】
【청구항 1】
무선통신시스템에서 SMS-SC(Short Message Service-Service Center)가 장치 트리거를 교체 /회수하는 방법에 있어서ᅳ
MTC-IWF(Machine Type Communications - Inter Working
Function)로부터 옛 트리거 참조 번호를 포함하는 제 1 메시지를 수신하는 단계; 상기 옛 트리거 참조 번호에 대응되는 트리거 메시지를 삭제하는 단계;
를 포함하고，
상기 제 1 메시지가 새 트리거 참조 번호를 더 포함하는 경우， 상기 SMS-
SC 는 상기 트리거 메시지의 삭제와 함께, 상기 새 트리거 참조 번호에 대응되는 새 트리거 메시지를 저장하는, 장치 트리거 교체 /회수 방법.
【청구항 2】
제 1항에 있어서，
상기 제 1 메시지는 상기 MTC-IWF 가 SCS(Services Capability
Server)로부터 수신한 장치 트리거에 관련된 제 2 메시지에 기초하는, 장치 트리거 교체 /회수 방법.
【청구항 3】
제 2항에 있어서，
상기 장치 트리거에 관련된 제 2 메시지는 트리거의 교체 동작 또는 트리거의 회수 동작 중 어느 하나를 요청하는 것인, 장치 트리거 교체 /회수 방법.
【청구항 4】
제 2항에 있어서，
상기 제 2 메시지가 장치 트리거의 교체 동작을 요청하는 경우에만 상기 제 1 메시지가 새 트리거 참조 번호를 포함하는， 장치 트리거 교체 /회수 방법.
【청구항 5】
제 2항에 있어서，
상기 제 2 메시지가 장치 트리거의 회수 동작을 요청하는 경우, 상기 제 1 메시지는 새 트리거 참조 번호를 포함하지 않는， 장치 트리거 교체 /회수 방법.
【청구항 6】
제 2항에 있어서，
상기 제 2 메시지는 SCS가 Tsp 인터페이스로의 트리거 제출의 쿼터 (quota) 또는 레이트를 초과한 경우， 상기 MTC-IWF 에 의해 거절되는， 장치 트리거 교체 /회수 방법.
【청구항 7】
제 1항에 있어서，
상기 SMS-SC 는 복수의 SMS-SC 중, 상기 MTC-IWF 가 설정 정보에 기초하여 상기 제 1 메시지를 수신할 SMS-SC 로 선택한 것인, 장치 트리거 교체 /회수 방법.
【청구항 8】
무선통신시스템에서 MTC-IWF 가 스몰 데이터를 교체 /회수하는 방법에 있어서，
제 1 메시지에 포함된 옛 스몰 데이터 참조 번호에 기초하여, MTC—IWF 가 어떤 스몰 데이터를 교체 /회수하여야 할지 확인하는 단계; 및
상기 확인된 스몰 데이터를 삭제하는 단계;
를 포함하고,
상기 제 1 메시지가 스몰 데이터의 교체에 관련된 경우
상기 MTC-1WF 는 상기 스몰 데이터의 삭제와 함께， 새 스몰 데이터를 저장하는， 스몰 데이터 교체 /회수 방법.
【청구항 9】
제 8항에 있어서，
SCS로부터 상기 제 1 메시지를 수신하는 단계；
를 더 포함하는， 스몰 데이터 교체 /회수 방법.
【청구항 10]
제 9항에 있어서， 상기 제 1 메시지는 스몰 데이터의 교체 동작 또는 스몰 데이터의 회수 동작 중 어느 하나를 요청하는 것인， 스몰 데이터 교체 /회수 방법.
【청구항 11】
제 9항에 있어서,
상기 제 1 메시지가 스몰 데이터의 교체 동작을 요청하는 경우에만 상기 제 1 메시지가 새 스몰 데이터 참조 번호를 포함하는， 스몰 데이터 교체 /회수 방법.
【청구항 12]
제 9항에 있어서,
상기 제 1 메시지는 SCS가 Tsp 인터페이스로의 트리거 제출의 쿼터 (quota) 또는 레이트를 초과한 경우， 상기 MTCᅳ IWF 에 의해 거절되는, 스몰 데이터 교체 /회수 방법.
【청구항 13】
제 8항에 있어서，
상기 확인된 스몰 데이터의 삭제는 상기 확인된 스몰 데이터가 상기 MTC-
IWF 에 계류 중 또는 단말에게 상기 확인된 스몰 데이터의 전달이 실패된 경우 수행되는， 스몰 데이터 교체 /회수 방법.
【청구항 14]
제 8항에 있어서，
상기 확인된 스몰 데이터가 단말에게 성공적으로 전달된 경우, 상기 스몰 데이터의 교체 /회수는 실패한 것으로 간주되는， 스몰 데이터 교체 /회수 방법. 【청구항 15]
제 8항에 있어서，
상기 스몰 데이터는， 장치 트리거 메시지인, 스몰 데이터 교체 /회수 방법.
PCT/KR2013/008779 2012-10-01 2013-10-01 무선 통신 시스템에서 장치 트리거 /스몰 데이터 교체 /회수 방법 및 장치 WO2014054876A1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP13843747.0A EP2905991B1 (en) 2012-10-01 2013-10-01 Method and device for device trigger/small data exchange/collection in wireless communication system
US14/432,731 US9554234B2 (en) 2012-10-01 2013-10-01 Method and device for device trigger/small data exchange/collection in wireless communication system
CN201380057224.XA CN104756540B (zh) 2012-10-01 2013-10-01 一种用于设备触发/小数据交换/收集的方法和设备
JP2015535559A JP5997389B2 (ja) 2012-10-01 2013-10-01 無線通信システムにおける装置トリガー／スモールデータの交替／回収方法及び装置

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201261708594P 2012-10-01 2012-10-01
US61/708,594 2012-10-01
US201361858624P 2013-07-26 2013-07-26
US61/858,624 2013-07-26
US201361882633P 2013-09-26 2013-09-26
US61/882,633 2013-09-26

Publications (1)

Publication Number Publication Date
WO2014054876A1 true WO2014054876A1 (ko) 2014-04-10

Family

ID=50435174

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2013/008779 WO2014054876A1 (ko) 2012-10-01 2013-10-01 무선 통신 시스템에서 장치 트리거 /스몰 데이터 교체 /회수 방법 및 장치

Country Status (6)

Country Link
US (1) US9554234B2 (ko)
EP (1) EP2905991B1 (ko)
JP (2) JP5997389B2 (ko)
KR (1) KR101623021B1 (ko)
CN (1) CN104756540B (ko)
WO (1) WO2014054876A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180028458A (ko) * 2015-07-10 2018-03-16 지티이 코포레이션 디바이스 트리거 정보의 처리 방법 및 장치

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US9526022B2 (en) 2012-08-03 2016-12-20 Intel Corporation Establishing operating system and application-based routing policies in multi-mode user equipment
CN104471876B (zh) * 2012-08-03 2018-08-10 英特尔公司 包含设备触发重呼/替换特征的3gpp/m2m方法和设备
EP3537844A1 (en) * 2013-01-08 2019-09-11 IOT Holdings, Inc. Method and apparatus for triggering devices and delivering small data
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
CN106604251A (zh) * 2015-10-20 2017-04-26 上海中兴软件有限责任公司 一种触发消息处理方法、装置和系统
US10313883B2 (en) * 2017-11-06 2019-06-04 Oracle International Corporation Methods, systems, and computer readable media for using authentication validation time periods
US10542394B1 (en) * 2018-07-13 2020-01-21 Oracle International Corporation Methods, systems, and computer redable media for optimized short message service (SMS)-based Internet of Things (IoT) device triggering

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20110122643A (ko) * 2010-05-04 2011-11-10 엘지전자 주식회사 이동통신 시스템에서의 ｍｔｃ 서비스 네트워크 오버로드의 제어 방법 및 그 장치
KR20120011012A (ko) * 2010-04-28 2012-02-06 엘지전자 주식회사 이동통신 시스템에서의 ｍｔｃ 데이터의 혼잡 제어 방법
KR20120096138A (ko) * 2011-02-22 2012-08-30 삼성전자주식회사 이동통신 시스템에서 그룹 기반 ｍｔｃ 디바이스 제어 방법 및 장치

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8666367B2 (en) * 2009-05-01 2014-03-04 Apple Inc. Remotely locating and commanding a mobile device
US8989070B2 (en) * 2012-07-02 2015-03-24 Intel Corporation Apparatus and method to efficiently send device trigger messages
CN104471876B (zh) * 2012-08-03 2018-08-10 英特尔公司 包含设备触发重呼/替换特征的3gpp/m2m方法和设备

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120011012A (ko) * 2010-04-28 2012-02-06 엘지전자 주식회사 이동통신 시스템에서의 ｍｔｃ 데이터의 혼잡 제어 방법
KR20110122643A (ko) * 2010-05-04 2011-11-10 엘지전자 주식회사 이동통신 시스템에서의 ｍｔｃ 서비스 네트워크 오버로드의 제어 방법 및 그 장치
KR20120096138A (ko) * 2011-02-22 2012-08-30 삼성전자주식회사 이동통신 시스템에서 그룹 기반 ｍｔｃ 디바이스 제어 방법 및 장치

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"3GPP; TSGSSA; Machine-Type and other Mobile Data Applications Communications Enhancements (Release 12)", 3GPP TR 23.887 VO.2.1, 14 August 2012 (2012-08-14), XP055253501, Retrieved from the Internet <URL:http://www.3gpp.org/DynaReport/23887.htm> *
"3GPP; TSGSSA; System improvements for Machine-Type Communications (MTC) (Release 11)", 3GPP TR 23.888 V11.0.0, 18 September 2012 (2012-09-18), XP050915378, Retrieved from the Internet <URL:http://www.3gpp.org/DynaReport/23888.htm> *
See also references of EP2905991A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180028458A (ko) * 2015-07-10 2018-03-16 지티이 코포레이션 디바이스 트리거 정보의 처리 방법 및 장치
KR102466131B1 (ko) 2015-07-10 2022-11-11 지티이 코포레이션 디바이스 트리거 정보의 처리 방법 및 장치

Also Published As

Publication number Publication date
US20150271623A1 (en) 2015-09-24
JP6152208B2 (ja) 2017-06-21
CN104756540A (zh) 2015-07-01
EP2905991A1 (en) 2015-08-12
KR20150087839A (ko) 2015-07-30
US9554234B2 (en) 2017-01-24
JP2015534783A (ja) 2015-12-03
CN104756540B (zh) 2018-09-07
JP2016197927A (ja) 2016-11-24
EP2905991A4 (en) 2016-06-22
EP2905991B1 (en) 2019-09-18
KR101623021B1 (ko) 2016-05-20
JP5997389B2 (ja) 2016-09-28

Similar Documents

Publication Publication Date Title
JP6152208B2 (ja) 無線通信システムにおける装置トリガー／スモールデータの交替／回収方法及び装置
US9392396B2 (en) Method and device for triggering machine-type communication MTC in wireless communication system
US10051405B2 (en) Method and apparatus for MTC in a wireless communication system
US9191806B2 (en) Method and apparatus for retransmitting MTC group message in wireless communication system
EP2880782B1 (en) Device trigger recall/replace feature for 3gpp/m2m systems
US9344836B2 (en) Method and apparatus for triggering MTC group in wireless communication system
US20190028337A1 (en) Method for setting configuration of non-ip data delivery (nidd) in wireless communication system and device for same
EP2869610B1 (en) Method and device for updating area in wireless communication system
EP2905990A1 (en) Method and device for controlling multipriority in wireless communication system
US9775021B2 (en) Method and device for supporting MTC trigger of serving node in wireless communication system
US20140317195A1 (en) Method and system for sending trigger message to mtc ue, and mtc ue
EP2915358A1 (en) Method to enable optimization for small data in an evolved packet core (epc)
WO2014069748A1 (ko) 무선 통신 시스템에서 ran 자원 관리 방법 및 장치
WO2012151963A1 (zh) 一种触发信息中有效时间的处理方法和系统
KR101911277B1 (ko) 이동통신 시스템에서의 ｍｔｃ 데이터 전송 방법
US9967905B2 (en) Method and device for cancelling device trigger 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: 13843747

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14432731

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2015535559

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2013843747

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20157011670

Country of ref document: KR

Kind code of ref document: A