WO2013166230A2

WO2013166230A2 - Systems and methods for providing and/or implementing a machine type communication (mtc)

Info

Publication number: WO2013166230A2
Application number: PCT/US2013/039185
Authority: WO
Inventors: Michael F. Starsinic; Paul L. Russell; Kamel Shaheen; Dorothy GELLERT; Debjani Majumder; Behrouz Aghili
Original assignee: Interdigital Patent Holdings, Inc.
Priority date: 2012-05-02
Filing date: 2013-05-02
Publication date: 2013-11-07
Also published as: WO2013166230A3

Abstract

Systems and methods for implementing a machine type communication (MTC) architecture may be disclosed. Such systems and methods may include performing device triggering. For example, a core network (CN) node such as a machine type communication inter-working function (MTC-IWF) and a services capability server (SCS) may be provided. The CN node and SCS may be configured to be used to trigger a device. Additionally, a dispatch function such as a MTC dispatch function may be provided and/or used to enable the device to be triggered.

Description

SYSTEMS AND METHODS FOR PROVIDING AND/OR IMPLEMENTING A

MACHINE TYPE COMMUNICATION (MTC)

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No.

61/641,585, filed May 2, 2012, and U.S. Provisional Patent Application No 61/650,678, filed May 23, 2012, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] Machine type communication (MTC) typically includes a form of data communication where one or more machine or device entities may communicate with each other, for example, with or without user interaction or involvement. Currently, 3 GPP has also been working on providing an architecture and/or communications associated with MTC.

Unfortunately, current architectures, communications, interfaces, and/or techniques associated with MTC may not be fully supported in 3 GPP. Additionally, in an MTC architecture, a server such as a services capability server (SCS) may want contact a device such as a UE or an application on the device, but device may not have an Internet Protocol (IP) address or the IP address may be unknown by the SCS. Currently, for an SCS to contact the device or application on, application port addressing may be used to identify whether an SMS may be a trigger and an SMS payload may be used to identify which application should receive the trigger.

Unfortunately, the SMS payload may need to be defined and/or standardized to provide suitable information for triggering, which may be problematic.

SUMMARY

[0003] Systems, methods, and/or techniques for implementing a machine type communication (MTC) architecture may be disclosed to support machine-to-machine (M2M) devices, applications, and services. Such systems, methods, and/or techniques may include performing device triggering. For example, a core network (CN) node such as a machine type communication inter-working function (MTC-IWF) and a services capability server (SCS) may be provided. The CN node and SCS may be used to trigger a device connected to a network. For example, in an embodiment, devices (e.g. a first device such as user equipment (UE) and/or a second device such as a server) connected to a network may wish to communicate (e.g. send messages such as SMS messages or other information) with each other. The first device may be contacted, but the messages and/or information including the packets therefor may not be sent as the first device may not have an IP address. As such, the second device may trigger the first device using the CN and the SCS, for example, by sending a trigger message to the first device that may indicate to the first device to establish a connection (e.g. establish an IP address) with the second device such that the second device may communicate with the first device to send messages and/or information.

[0004] For example, the SCS may want contact a UE or an application on the UE, but the

UE may not have an IP address or the IP address may be unknown by the SCS. As such, the SCS may send a trigger request to a CN node (e.g. the MTC-IWF) over an interface such as a Tsp. The trigger request may include a field (e.g. a new field) not included in a payload with information or an application identifier that may identify the recipient of a message (e.g. the recipient that the SCS may wish to contact). The CN node may send the trigger request to one or more additional CN nodes (e.g. a SMS-SC and/or an SMS server). One or more of those additional CN nodes may process the trigger request and may generate a trigger message (e.g. an SMS message for triggering such communication or an SMS trigger message) that may be sent to the UE to indicate to the UE that the SCS may wish to communicate with it. As such, in a header of the trigger message, the application identifier provided in the trigger request may be included in the application port address and another existing header field of the trigger message such as the data coding scheme (DSC) field or other existing header field included in an SMS message, for example, may be used to identify the message such as the SMS message as a trigger.

[0005] The Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, not is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to any limitations that solve any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more detailed understanding of the embodiments disclosed herein may be had from the following description, given by way of example in conjunction with the accompanying drawings.

[0007] FIG. 1A depicts a diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0008] FIG. IB depicts a system diagram of an example wireless transmit/receive unit

(WTRU) that may be used within the communications system illustrated in FIG. 1A.

[0009] FIG. 1 C depicts a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0010] FIG. ID depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0011] FIG. IE depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0012] FIG. 2 depicts an example embodiment of an architecture (e.g. a 3GPP architecture) for a machine type communication (MTC).

[0013] FIG. 3 depicts an example embodiment of a protocol stack such as an SMS protocol stack.

[0014] FIGs. 4-5 depict example embodiments of a method, process, or procedure for performing device triggering via MTC and/or using an MTC architecture.

DETAILED DESCRIPTION

[0015] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

[0016] Systems and methods implementing a machine type communication (MTC) architecture that may include performing device triggering may be disclosed herein. For example, a core network (CN) node such as a machine type communication inter-working function (MTC-IWF) and a services capability server (SCS) may be provided. The CN node and SCS may be used to trigger a device connected to a network. For example, in an embodiment, devices (e.g. a first device such as user equipment (UE) and/or a second device such as a server) connected to a network may wish to communicate (e.g. send messages such as SMS messages or other information) with each other. The first device may be contacted, but the messages and/or information including the packets therefor may not be sent as the first device may not have an IP address. As such, the second device may trigger the first device using the CN and the SCS, for example, by sending a trigger message to the first device that may indicate to the first device to establish a connection (e.g. establish an IP address) with the second device such that the second device may communicate with the first device to send messages and/or information.

[0017] In example embodiments, performing the device triggering may include one or more of the following: determining whether to trigger a device; sending a device trigger request; checking that a device trigger request may be authorized to be sent and that a quota or rate of trigger submission over a reference point may be exceeded; sending a subscriber information request message; sending a subscriber information response; selecting a trigger delivery procedure; selecting a serving CN node capable of triggering; providing an indication comprising at least one of the following: a request type; an application protocol data unit (PDU); an identifier associated with the MTC-IWF; and a reference number; generating charging data record (CDR) information; sending a delivery report message; performing the trigger delivery procedure; selecting short message service-service center (SMS-SC); sending a submit trigger confirmation message; sending a device trigger confirmation message; sending a short message; sending a message delivery report; sending a device trigger report; performing an action based on content of a trigger payload; and the like.

[0018] According to an example embodiment, a dispatch function such as an MTC dispatch function that may be configured to be used to determine an application to which to send a message may also be provided and/or used in the MTC architecture and/or device triggering associated therewith. For example, a dispatch function (e.g. that may be included in a UE) may receive such a trigger message, may decode or read the trigger message, and may provide the trigger message to the appropriate application thereon that may be the intended recipient of the trigger message (e.g. the application that the server or second device may wish to communicate or exchange messages and/or information with). Additionally, in an embodiment, a data coding scheme field may be used or configured to be used indicate whether a message may be a trigger message and, as such, may be routed to the dispatch function. An application port address field may also be used to indicate the recipient of the trigger message such as the application or device. For example, a data coding scheme field may be configured to be used to indicate whether a message should be received by the dispatch function and/or an application port field may be configured to be used to indicate which application to route a message.

[0019] FIG. 1A depicts a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.

[0020] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, and/or 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, and/or 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0021] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 1 14a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and/or 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 1 12. By way of example, the base stations 114a and/or 1 14b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 1 14a, 114b are each depicted as a single element, it will be appreciated that the base stations 1 14a, 114b may include any number of interconnected base stations and/or network elements. [0022] The base station 1 14a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 1 14a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 1 14a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0023] The base stations 114a and/or 114b may communicate with one or more of the

WTRUs 102a, 102b, 102c, and/or 102d over an air interface 1 15/116/1 17, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 1 15/116/117 may be established using any suitable radio access technology (RAT).

[0024] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 1 14a in the RAN 103/104/105 and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 1 15/116/1 17 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0025] In another embodiment, the base station 1 14a and the WTRUs 102a, 102b, and/or

102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E- UTRA), which may establish the air interface 1 15/1 16/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

[0026] In other embodiments, the base station 114a and the WTRUs 102a, 102b, and/or

102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like. [0027] The base station 1 14b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 1 14b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.1 1 to establish a wireless local area network (WLAN). In another embodiment, the base station 1 14b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 1 14b and the WTRUs 102c, 102d may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 1 14b may not be required to access the Internet 110 via the core network 106/107/109.

[0028] The RAN 103/104/105 may be in communication with the core network

106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, and/or 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.

Although not shown in FIG. 1A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0029] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a,

102b, 102c, and/or 102d to access the PSTN 108, the Internet 1 10, and/or other networks 112.

The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the

TCP/IP internet protocol suite. The networks 112 may include wired or wireless

communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT. [0030] Some or all of the WTRUs 102a, 102b, 102c, and/or 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, and/or 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1 A may be configured to communicate with the base station 1 14a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0031] FIG. IB depicts a system diagram of an example WTRU 102. As shown in FIG.

IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 1 14a and 1 14b, and/or the nodes that base stations 1 14a and 1 14b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. IB and described herein.

[0032] The processor 1 18 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it may be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0033] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface

1 15/1 16/117. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive

IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0034] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 1 15/116/117.

[0035] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.1 1, for example.

[0036] The processor 1 18 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 1 18 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random- access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 1 18 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0037] The processor 1 18 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0038] The processor 1 18 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 1 15/1 16/1 17 from a base station (e.g., base stations 114a, 1 14b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0039] The processor 1 18 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0040] FIG. 1C depicts a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 1 15. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 103 may include Node-Bs 140a, 140b, and/or 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 1 15. The Node-Bs 140a, 140b, and/or 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a and/or 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0041] As shown in FIG. 1C, the Node-Bs 140a and/or 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the

RNC142b. The Node-Bs 140a, 140b, and/or 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, and/or 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0042] The core network 106 shown in FIG. 1C may include a media gateway (MGW)

144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0043] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices.

[0044] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between and the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

[0045] As noted above, the core network 106 may also be connected to the networks 1 12, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0046] FIG. ID depicts a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 1 16. The RAN 104 may also be in communication with the core network 107.

[0047] The RAN 104 may include eNode-Bs 160a, 160b, and/or 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and/or 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 1 16. In one embodiment, the eNode-Bs 160a, 160b, and/or 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0048] Each of the eNode-Bs 160a, 160b, and/or 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. ID, the eNode-Bs 160a, 160b, and/or 160c may communicate with one another over an X2 interface.

[0049] The core network 107 shown in FIG. ID may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166.

While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0050] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and/or

160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and/or 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and/or 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0051] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and/or 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and/or 102c, managing and storing contexts of the WTRUs 102a, 102b, and/or 102c, and the like.

[0052] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

[0053] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to the networks 1 12, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0054] FIG. IE depicts a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and/or

102c over the air interface 1 17. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, and/or 102c, the RAN 105, and the core network 109 may be defined as reference points. [0055] As shown in FIG. IE, the RAN 105 may include base stations 180a, 180b, and/or

180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, and/or 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, and/or 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, and/or 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0056] The air interface 1 17 between the WTRUs 102a, 102b, and/or 102c and the RAN

105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and/or 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, and/or 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0057] The communication link between each of the base stations 180a, 180b, and/or

180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, and/or 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, and/or 102c.

[0058] As shown in FIG. IE, the RAN 105 may be connected to the core network 109.

The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0059] The MIP-HA may be responsible for IP address management, and may enable the

WTRUs 102a, 102b, and/or 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, and/or 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0060] Although not shown in FIG. IE, it should, may, and/or will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, and/or 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0061] As described herein, embodiments (e.g. Release 11 3GPP enhancements) for supporting MTC communications may be provided. FIG. 2 illustrates an example embodiment of an architecture for a MTC (e.g. 200) that may be provided and used herein. As shown, the MTC communication and architecture may include the use of a new or additional core network (CN) nodes such as a machine type communication inter- working function (MTC-IWF) (e.g. MTC-IWF 202), a modification of existing CN nodes, the use of reference points (e.g. new and/or existing reference points), the use of an identifier (e.g. a new and/or existing identifier), and/or the use of requirements (e.g. new and/or existing requirements) for user equipment (UE) of the MTC (e.g. MTC UE 204).

[0062] For example, in an embodiment, the MTC may include new architectural components or concepts as described herein including one or more of the following: an external identifier, one or more device triggers, one or more MTC UEs or gateways, a group based communication, a time controlled communication, and/or a MTC charging. Additionally, according to an embodiment, one or more of the following CN nodes may be impacted by the MTC architecture described herein (e.g. as shown in FIG. 2): a MTC-IWF such as MTC-IWF 202, a HSS such as HSS 206; serving nodes including an MME such as MME 208, a SGSN such as SGSN 210, a MSC such as MSC 212, and the like; gateway nodes including a S-GW such as S-GW 218, a P-GW and/or a GGSN such as GGSN/P-GW 214, and the like; a SMS-SC such as SMS-SC/GMSC/IWMSC 216; and the like.

[0063] MTC reference points as shown in FIG. 2 and described in Table 1 may also be provided and/or used.

Table 1. Example MTC Reference Points

[0064] As described herein, device triggering may be provided and/or used (e.g. in a

MTC such as the MTC architecture shown in FIG. 2). According to an embodiment, a device trigger may be used to initiate, start, and/or perform an action in a device or system such as an MTC device or system. The device trigger may serve various purposes. For example, the device triggers may be used to send small amounts of MTC device application data from a services capability server (SCS) such as SCS 220 to an MTC UE such as MTC UE 204 to enable communication with a server such as an application server (AS) 222a. In such an embodiment, a small amount of data may be sent to an application such as MTC UE application 223 when no response may be expected. For example, an SCS may use a device trigger to instruct a sensor to turn on. If the SCS may expect no response, then no IP connection may be provided by the UE.

[0065] Additionally, device triggers may be used to instruct an MTC device application to initiate communications with the SCS (e.g. which may subsequently communicate with the AS 222a) thereby having the MTC UE obtain an IP address if it may not already have one. Such an embodiment may be a typical scenario. For example, if an SCS may wish to address an MTC device application that does not have an IP address, a device trigger may be used and/or provided as described herein.

[0066] The MTC architecture described herein (e.g. shown in FIG. 2) may not preclude the possibility of delivering a trigger to an MTC device application that may already have an IP address. For example, an SCS may wish to establish a connection with an MTC device application, however, the SCS may not know the IP address of the device or the SCS may be unsure if the MTC device may have an IP address. In an embodiment, the MTC architecture described herein may favor an approach where the MTC-IWF may deliver the trigger to the device. An alternative approach may be for the MTC-IWF to reply to the trigger request with an indication that the device may already have an IP address and to provide the IP address.

However, in an embodiment, a drawback to such an approach may be that the network operator may not charge the SCS for delivering the trigger.

[0067] A MTC dispatch function may also be provided and/or used. In an embodiment, when an MTC UE may receive an SMS, it may be able to determine or may determine if the

SMS may be a standard SMS message, a device trigger such as an MTC device trigger, or data that may be targeted to a specific MTC application. An SMS protocol stack may identify or determine whether or not an SMS message may or should be routed to a dispatch function such as the MTC dispatch function. The MTC dispatch function that may be provided may also be used to determine what application a message may or should be sent to or towards.

[0068] Additionally, an external identifier may also be provided and/or used as described herein (e.g. in a MTC architecture). According to an embodiment, an identifier that may be used, for example, by an SCS when requesting a trigger for a device (e.g. a 3GPP device) may be an IMSI. However, the SCS may be owned by a third party, and for security reasons, CN operators may not wish to expose IMSI values to third parties. To address such a security concern, an external identifier may be provided and/or used. For example, a UE may have one IMSI and one or more globally unique external identifiers. Additionally, external identifiers for the UE that may be provided and/or used may be stored in the HSS and may include one or more of the following: a domain identifier that may be under the control of the mobile network operator (MNO); a local identifier that may be managed by the MNO, and the like. Such a local identifier may be used to derive the IMSI.

[0069] Additionally, one or more MTC gateways, a group based communication, a time controlled communication, and/or one or more MTC charging considerations may be provided and/or used (e.g. in a MTC architecture as shown in FIG. 2). Additionally, the MTC UE may initiate contact with the SCS, for example, to report or register, the SCS may initiate contact with the MTC UE, the SCS may initiate contact with a MTC group, and the like.

[0070] CN nodes and enhancements thereof may also be provided and/or used as described herein (e.g. in a MTC). For example, a MTC-IWF such as MTC-IWF 202 may be provided and/or used. The MTC-IWF may be a new CN node that may act as an interface between the core network and an MTC Service Capability Layer. In a MTC architecture (e.g. shown in FIG. 2), the service capability layer may be a SCS such as SCS 220.

[0071] With the use of the MTC-IWF, the PLMN topology may be hidden from the SCS provider. Additionally, the MTC-IWF may allow SCSs to request device triggers over a Tsp reference point. The SCS may also identify devices by an external identifier (ExID). The main responsibilities of the MTC-IWF may include one or more of the following: authorize SCSs before allowing them to communicate or make requests to the CN; accept trigger requests from the SCSs; query the HSS to resolve the ExID to an IMSI; select the trigger delivery method if more than one may be available; provide the SCS with trigger delivery reports; generate charging records for delivered triggers; query the HSS for the service node of the device; and the like.

[0072] In an example embodiment, the MTC-IWF may further take the role of an SME when interfacing to the SMS-SC over a T4 reference point. Additionally, as described herein, HSS may be provided and/or used. Permanent subscriber data and temporary subscriber data may also be provided and/or used (e.g. with HSS). Permanent subscriber data may be data that may be changed by administration methods or techniques. Temporary subscriber data may be data that may change as a result of normal operation of the system.

[0073] MTC UE subscriber information may also be provided and/or used herein in conjunction with such device triggering and/or to support the MTC communications and/or architecture shown in FIGs. 2 and 3. For example, new fields may be added to the subscriber data base (e.g. in the HSS such as HSS 206) to support MTC UEs. The new fields may be described herein (e.g. below). For example, the subscriber information for MTC UEs may include one or more of the following fields: external identifiers, information and/or identifiers indicating whether the subscriber and/or UE may be permitted for triggering, information and/or identifiers indicating whether the subscriber and/or UE may be permitted for small data, and the like.

[0074] For example, in an embodiment, lists such as an "External Identifiers" list, a

"Permitted for Triggering" list, a "Permitted for Small Data" list, and the like may be added to the subscription information of MTC devices (e.g. in the HSS or other CN node). According to an example embodiment, the "External Identifier" list may be a list of FQDNs. Additionally, the external identifier may be an MSISDN although an MSISDN field may already exist in the HLR.

[0075] The "Permitted for Triggering" list may also be added to the subscription information of MTC devices such that the MTC-IWF and SMS-SC may check which SCSs may be allowed to trigger the MTC devices. The "Permitted for Triggering" may be a list of SCS or SME identifiers. The format of each identifier may be an MSISDN, an FQDN, an IMSI, or an IP Address. Such information may be permanent subscriber data.

[0076] The "Permitted for Small Data" list may further be added to the subscription information of MTC devices such that the MTC-IWF and SMS-SC may check which SCSs may be allowed to send small data to the MTC devices. The "Permitted for Small Data" field may be a list of SCS or SME identifiers. The format of each identifier may be an MSISDN, an FQDN, an IMSI, or an IP Address. Such information may be permanent subscriber data.

[0077] According to another embodiment, a trigger quota may be established and/or used for a MTC device (e.g. per MTC device). For example, a "Device Trigger Quota" field may be added to the subscription information of MTC devices such that the MTC-IWF may check if or whether a device may have received more than its allotted number of triggers. Such a trigger quota may also be established for a MTC device (e.g. a per MTC device) per SCS. For example, a "Device Trigger Quota per SCS" list may be added to the subscription information of MTC devices such that the MTC-IWF may check if or whether a device may have received more than its allotted number of triggers from a particular SCS.

[0078] A "Preferred Trigger Delivery Method" or information associated therewith may further be added to the subscription information of MTC devices such that the MTC-IWF check which method a device may wish to use for receiving triggers (e.g. SMS Signaling, SMS over IMS, NAS signaling, and the like).

[0079] In yet another embodiment, a "Supported Trigger Delivery Method" or information associated therewith may be added to the subscription information of MTC devices such that the MTC-IWF may check which methods a device may support for receiving triggers (e.g. SMS Signaling, SMS over IMS, NAS signaling, and the like).

[0080] An SCS subscription database may also be provided and/or used. For example, a

SCS subscription database may be maintained in a core network (e.g. the 3GPP core network). The database may have an entry for each SCS that subscribed to the core network. Additionally, the SCS subscription database may be a standalone logical entity or it can reside inside of another core network entity such as the HSS. According to example embodiments, fields for the SCS subscription database entry may include one or more of the following: SCS subscription ID, SCS public ID(s), serving node, SMS capable, SCS trigger quota, and the like.

[0081] The SCS subscription identifier may be permanent subscriber data and may be used for one or more of the following purposes: authentication on the Tsp reference point;

chagrining on the Tsp reference point where the MTC-IWF may create CDRs for triggers that are generated by the SCS and the MTC-IWF may perform online charging to monitor to number of triggers that may be generated by the SCS in a given time period; and the like.

[0082] The format of the SCS Subscription ID may be an IMSI. Additionally, in an embodiment, temporary subscription identifiers may be established for security purposes, in a manner similar to how T-IMSIs are established for 3GPP UEs.

[0083] The existence of the SCS subscription ID may be used in a MTC architecture (e.g. the MTC architecture shown in FIG. 2). In an embodiment, the identifier that may be used therein may be used for chagrining for triggers on the Tsp reference point.

[0084] The SCS public identifiers ID(s) may be permanent subscriber data and may be used for the following purposes: identification on the Tsp reference point; chagrining on the Tsp reference point (e.g. in lieu of the SCS Subscription ID); and the like. The format of the SCS Public ID(s) may be an FQDN, an MSISDN, or an IP Address. The SCS may have multiple public identifiers. The existence of the SCS Public ID may be used in a MTC architecture (e.g. the MTC architecture shown in FIG. 2). In an embodiment, the identifier may be used for interactions on the Tsp reference point and as fields in the trigger messages. The SCS may be an MSISDN.

[0085] The SCS Serving Node may be temporary subscriber data and may be used for one or more the following. The SCS Serving Node may be a core network node that the SCS may be connected to for control plane communications including SMS. Other core network nodes may use such information to determine where to send control messages that may want to reach the SCS. The SCS serving node may be an MTC-IWF. The SCS serving node identifier may be an IP address. An SCS may have an established connection to multiple MTC-IWFs. According to an embodiment, the "SCS Serving Node" may be any core network node that may receive messages and forward them towards to the SCS. An SCS may have multiple serving nodes.

[0086] An SMS capable flag may be permanent subscriber data and may be used to indicate whether the SCS may be capable of receiving SMS messages.

[0087] SCS trigger quota may be permanent subscriber data and defines the number of triggers that the SCS may be allowed to request per time period. Alternatively, it may define the number of successful triggers that the SCS can initiate per time period.

[0088] As described above, serving nodes such as MSC, SGSN, MME, and the like; gateway nodes such as GGSN, P-GW, and the like; SMS-SC; and the like may be provided and/or used herein.

[0089] Additionally, a T4 reference point may be supported according to embodiments disclosed herein. For example, SMS-SC may be updated to support a T4 interface. The T4 reference point may be new and messages associated therewith may be provided and/or used. The following functionality may be provided and/or used (e.g. to support such reference points): the SMS-SC may be able to receive trigger requests from the MTC-IWF; the SMS-SC may be able to reply to the MTC-IWF with an indication if the trigger may be accepted or may not; the SMS-SC may be able to reply to the MTC-IWF with an indication if the trigger may be successfully delivered or may not; and the like.

[0090] According to an embodiment, un-authorized senders may be prevented. For example, a MTC architecture (e.g. shown in FIG. 2) may specify that the MTC-IWF may authorize trigger requests from the SCS. The MTC architecture (e.g. shown in FIG. 2) may not address the possibility of an SME (e.g. not the SCS) sending unauthorized triggers towards an MTC device.

[0091] Another problem or issue that may also not be yet addressed (e.g. by 3GPP and a

MTC architecture defined thereby) may be the possibility that an SME may send garbage SMS messages towards an MTC UE. Additionally, the energy wasted by the MTC UE when receiving the unwanted SMS messages may cause its battery to drain more quickly,

[0092] To resolve such issues or problems, the SMS-SC may inspect contents of messages (that may be sent towards MTC UEs (or inspect the "SMS Data Coding Scheme" field) and may use the MAP-C reference point to authorize messages that may not be received via the T4 reference point. If this may not be implemented, then SMS-SC may reject messages that may be marked as MTC in the "SMS Data Coding Scheme" field and that may not be received via the T4 reference point. [0093] Such requirements may indicate that the HLR may maintain a list of MSISDNs that may be allowed to trigger each MTC UE and MSISDNs that may be allowed to send data to each MTC UE.

[0094] According to an embodiment, one or more enhancements for UEs such as MTC

UEs may be provided. For example, as described above, a MTC dispatch function may be provided. The MTC dispatch function may not distinguish between a MTC trigger and MTC application data. Rather, the MTC dispatch function may recognize that the data may be intended for a particular MTC application and may then pass the data to the application. The application may act on the trigger (e.g. if necessary) and/or process the application data.

[0095] An example embodiment of an SMS protocol stack may be shown in FIG. 3. In the SMS-AL (e.g. shown in FIG. 3), there may be applications that may process messages that may be targeted to a USIM, ME, TE, and the like and message that may be message waiting indications, and the like. In an embodiment, the MTC dispatch function may live or reside inside of the SMS-AL as an SMS Application. The MTC dispatch function may further process messages that may be marked MTC by the SMS-TL.

[0096] Additionally, a SMS-TL (e.g. shown in FIG. 3) may use a data coding scheme field such as a TP-Data-Coding-Scheme field of a SMS TPDU to determine what SMS application may receive the SMS data. The TP-Data-Coding-Scheme may be a one byte field that may be encoded by any suitable encoding scheme or technique. In an embodiment, one of the reserved values of such a field may be used to indicate that the SMS may be marked for the MTC dispatch function. For example, the value 0x80 may be used to indicate that the message is marked for the MTC dispatch function.

[0097] The MTC Dispatch function may further use an application port address field such as "application port addressing 8 bit address" or "application port addressing 16 bit address" fields of a TP-User Data (TP-UD) field of the TPDU to indicate which application the SMS data should be routed towards.

[0098] If an "application port addressing" field or fields may represent an IP port number, then the TP-Data-Coding-Scheme may not need to be updated. The SMS-AL (e.g. shown in FIG. 3) may use the port number to determine where to route the SMS.

[0099] The Tsp may be a new reference point that may be used herein. The Tsp may connect the MTC-IWF to multiple SCSs and may allow the SCSs to make trigger requests to the core network. Messages on the Tsp reference point may be described herein below. The protocol that may be used on the Tsp reference point may be HTTP. The Tsp reference point may support DNS procedures to allow the SCS to look up which MTC-IWF may be associated with a given external identifier.

[0100] The T4 reference point may allow the MTC-IWF to interface to the SMS-SC and may appear like an SME to the SMS-SC. Today, SME to SMS-SC interfaces may not be specified by 3 GPP. Unlike other SMEs, the MTC-IWF may identify SMS recipients by their IMSI and may indicate the serving node of the terminating UE when sending the SMS to the SMS-SC.

[0101] The S6m reference point may connect the HSS and MTC-IWF. The S6m may be a Diameter based protocol that may be similar to S6a and S6d protocol. The S6m reference point may support one or more of the following operations: may map an E.164 MSISDN or external identifier to the IMSI of the associated UE; may retrieve serving node information for UEs (e.g. serving SGSN/MME/MSC address); may determine if a SCS may be allowed to send a device trigger to a particular UE; and the like.

[0102] MAP-C may be a reference point that the SMS-SC may use to interface to the

HLR. In an embodiment, the MAP-C reference point may be used so that the SMS-SC may verify if a sender may be allowed to trigger or send data towards the MTC-UE. New MAP-C messages may also be used (e.g. as described herein).

[0103] A procedure and/or method for implementing, enhancing, and/or providing a

MTC architecture (e.g. as shown in FIG. 2) that may include performing device triggering may be disclosed herein. For example, a procedure and/or method to trigger a device may be performed to initiate and/or start an action in a device or system such as an MTC device or system.

[0104] FIGs. 4-5 illustrate example embodiments of a method or procedure, for example, that an SCS may use to request that a trigger be sent to an MTC device. As described herein, the SCS such as the SCS 220 may want contact a UE such as the UE 204 or an application on the UE such as the application 205, but the UE may not have an IP address or the IP address may be unknown by the SCS. As shown in FIG. 4, to contact the UE, the SCS may determine whether to send a trigger request (e.g. may determine whether the SCS may not have an IP address associated with a UE it may need to contact on application on and/or may not have contacted the UE before) and, if a trigger should be sent, generate and send a trigger request to the MTC-IWF such as the MTC-IWF 204 (e.g. a CN node) over an interface such as a Tsp such that the MTC- IWF may receive the trigger request at 405. The trigger request may include a field (e.g. a new field) not included in a payload with information or an application identifier that may identify the recipient of a message (e.g. the recipient that the SCS may wish to contact). For example, when the SCS makes a trigger request on the Tsp (e.g. at 405), the request may include a field (e.g. in a diameter request) that identifies the application that should receive the trigger.

[0105] The MTC-IWF may process the trigger request received at 405. For example, the

MTC-IWF may determine that the trigger request may be a request from the SCS to

communicate with a particular application and which UE may include the application and/or whether the SCS may be authorized to trigger the UE and/or the application. The MTC-IWF may further determine whether such a UE may or may not have an IP address associated therewith. In an example embodiment, if the trigger request, based on the he information in the field, may identify an application for a UE that may already have an IP address (e.g. based on the determination), the MTC-IWF may reply to the trigger request by sending an indication that the UE may already have an IP address and/or the actual IP address to the SCS that may be received thereby at 407. Additionally, if the UE may not have an IP address, the MTC-IWF may send the trigger request to the SMS-SC such as the SMS-SC 216a or another CN node over a T4 interface or other interfaces (e.g. at 410).

[0106] The SMS-SC, for example, may receive the trigger request from the MTC-IWF at

410 and may process the trigger request sent by the MTC-IWF. For example, upon receipt of the trigger request, the SMS-SC or other CN nodes such as an SMS may generate a trigger message (e.g. an SMS message for triggering such communication or an SMS trigger message) that may be sent to the UE to indicate to the UE that the SCS may wish to communicate with an application thereon at 415.

[0107] For example, in the SMS-SC, the SMS trigger message may be generated in response to the trigger request from the SCS may be distinguished from regular SMS messages. Currently, to distinguish the SMS trigger message from other SMS messages, a specific port number such as 49152, may be used to indicate that an SMS message may be an SMS trigger message. For example, the "Application Port Addressing 16 Bit Address" field of the SMS header may currently be set to 49152 to provide an indication that a particular SMS message may, in fact, be an SMS trigger message. Additionally, the contents of the SMS payload may currently be used to indicate which application should receive the SMS trigger message. As such, currently, the payload may be used to identify what application the trigger should be routed to and may also include the specific payload for the application. Unfortunately, as described herein, using the payload to indicate the application the trigger should be routed to may be problematic as the payload may need to be to have at least a portion of the format thereof to be defined (e.g. at least a portion of the payload may need to be defined uniformly or standardized, for example, in 3 GPP). [0108] As described herein (e.g. instead of using the application port address to identify a trigger and the payload to identify the application that may be the intended recipient of the application), the SMS trigger message generated in response to the trigger request from the SCS may be distinguished from regular SMS messages by using separate header fields to identify whether an SMS message is an SMS trigger message and which application may be the intended recipient of the SMS trigger message. For example, the SMS-SC may use one or more existing fields (e.g. that may not be used for other purposes) in the SMS header such as a data coding scheme field or any other non-used field to identify an SMS message as a SMS as a trigger.

[0109] The SMS-SC may then use the dedicated port number to identifier which application may be the intended recipient of the SMS trigger message. For example, instead of using the "Application Port Addressing 16 Bit Address" to identify whether an SMS message may be an SMS trigger message, the "Application Port Addressing 16 Bit Address" may be used to identify the application that should receive the SMS trigger message. As such, in an example embodiment, the application port ID field in the SMS header may include an identifier of the application which should receive the SMS message that may have been provided in the trigger request (e.g. in a field of the diameter request) sent from the SCS.

[0110] Based on an existing, unused field in the header of the SMS message, the CN nodes and/or the UE may now be able recognize, detect, and/or determine whether a SMS message may be a regular SMS message or a SMS trigger message. Additionally, based on an application port ID field in the SMS header, the CN nodes and/or the UE may now be able recognize, detect, and/or determine which application the SMS trigger message should be directed or routed to. As such, when an SMS trigger may be sent to a UE at 415 and received thereby, the application port ID field of the SMS header may hold the application identifier that may have been received from the SCS and another existing or new header field may be used to indicate that the SMS message may be a trigger such that the UE may process the SMS trigger message and may direct it or send it to the appropriate application included thereon.

Additionally, the SMS-SC and/or SMS Router may inspect the header fields in the SMS message to determine if the SMS may be a trigger and if so, it may determine or check whether the sender may be trusted, or authorized, to send triggers to a UE and also to determine which UE to direct the SMS trigger message to.

[0111] In an example embodiment, such SMS triggers may be charged differently than regular SMS messages (e.g. may not be charged to the user). For example, as the SMS trigger message travels through the network, CDRs may be generated and using the fields that indicate that such a message is a trigger rather than a SMS message, the network (e.g. the HSS) may be able to not charge the user of the UE for the SMS message and/or may be able to charge the server requesting access to the UE and the application thereon.

[0112] More specifically, as shown in FIG. 5, at 501, the SCS may determine whether to trigger the device. If the SCS may have no contact details for an MTC-IWF, it may determine the IP address(es)/port(s) of the MTC-IWF by performing a DNS query using the External Identifier of the UE to be triggered.

[0113] At 502, the SCS may send the device trigger request (e.g.

TSP TRIGGER REQUEST) (External Identifier or MSISDN, SCS Identifier, Trigger

Reference Number, validity period, priority and trigger payload) message to the MTC-IWF. The

SCS may include a trigger payload that may include the information that may be destined for the

MTC application along with the information to route it to the MTC application.

[0114] At 503A and 503B, the MTC-IWF may check that or determine whether the SCS may be authorized to send trigger requests and that the SCS may not have exceeded its quota or rate of trigger submission over Tsp. If such a check fails, the MTC-IWF may send a device trigger confirm (e.g. TSP_TRIGGER_CONFIRM) message with a cause value indicating the reason for the failure condition and the method may stop at 503A and 503B. Otherwise, the method may continue to 504.

[0115] At 504, the MTC-IWF may send a subscriber information request (e.g.

S6M_SUBCRB_INFO_REQ see TBD) (External Identifier or MSISDN and SCS Identifier) message to the HSS to determine if SCS may be authorized to trigger the UE, to resolve the External Identifier or MSISDN to IMSI, and to retrieve the identities of the UE's serving CN node(s). In an embodiment, the MTC-IWF may cache authorization and routing information for the UE. This may increase the probability of trigger delivery attempt failures when the cached serving node information may be stale.

[0116] At 505A and 505B, the HSS may send a subscriber information response (e.g.

S6M_SUBSCRIBER_INFO_RESP see TBD) (IMSI and serving node(s) identities) message. HSS policy (possibly dependent on the VPLMN ID) may influence which serving node identities may be returned. If the cause value may indicate the SCS may not be allowed to send a trigger message to the UE or valid subscription information may not be returned by the HSS, the MTC- IWF may send a device trigger confirm message (e.g. TSP_TRIGGER_CONFIRM) with a cause value indicating the reason for the failure condition and the flow may stop at 505A and 505B. Otherwise, the method may continue to 506.

[0117] At 506, the MTC-IWF may select a trigger delivery procedure based on the information received from HSS and local policy. If T5 delivery procedure may be selected, the MTC-IWF may attempt a T5 trigger delivery procedure and may proceed or continue to 507. Otherwise, the flow may proceed or continue to 51 1. In an embodiment, T5 delivery may not be supported (e.g. in 3 GPP Rl 1).

[0118] At 507, the MTC-IWF may use the UE capabilities and/or serving CN node(s) capabilities that may be retrieved from the HSS to select a suitable serving CN node capable of T5 triggering. The MTC-IWF may send a submit request (e.g. T5_TRIGGER_SUBMIT) (IMSI, message priority, MTC-IWF ID, reference number, single delivery attempt flag (optional), validity time (optional), Request type (trigger application), application PDU) to the serving CN node. If there may be more than one serving CN node, the MTC-IWF may send the message to the serving CN node where the UE may currently be camping with the highest probability (e.g. based on information received from HSS or cached information from earlier trigger attempts).

[0119] At 508, the serving CN node may indicate (e.g.

NAS_UE_TRIGGER_REQUEST) request type (e.g. trigger application), application PDU, MTC-IWF ID, Reference number within the NAS message and may delivers such information to the UE. The UE may provide the trigger content and trigger type to the corresponding application. In an embodiment, FFS may be used to determine whether and how a generic container or SMS may be used to transport the trigger content. Additionally, if the UE may be in idle mode, the serving CN node may page the UE prior to sending a NAS message for delivering the trigger. In an embodiment, the UE may respond (NAS_UE_TRIGGER_REPORT) with the delivery status (cause), MTC-IWF ID, reference number, response type (trigger application), and optionally, application PDU.

[0120] At 509, the serving CN node may generate the CDR information for charging and may submit the CDR to the CDF (e.g. GX TRIGGER CDR SUBMIT).

[0121] At 510, the serving CN node may send a delivery report (e.g.

T5_TRIGGER_REPORT) (IMSI, cause, reference number, delivered by CN node, Response type (trigger application), and if received, application PDU) message to the MTC-IWF. Cause may indicate whether the Trigger-Message may be successfully delivered to the UE or if failed, the reason for the failure.

[0122] At 511, if T5 delivery may be unsuccessful or not supported by the serving nodes(s) or by the UE or if T4 delivery may selected during 506, the MTC-IWF may attempt a T4 trigger delivery procedure and may continue or proceed to 512. Otherwise, the method may continue to 520.

[0123] At 512, the MTC-IWF may select a suitable SMS-SC based on configured information. The MTC-IWF may send a submit trigger (e.g. T4_TRIGGER_SUBMIT) (External Identifier or MSISDN, IMSI, SCS Identifier, Trigger Reference Number, validity period, priority, serving node ID(s) , SMS Application port ID, trigger payload) message to the SMS- SC. The SMS-SC may avoid an additional HSS interrogation (SRI for SM) and may receive parameters in the submit trigger message from the MTC-IWF. The SMS Application port ID may be set to address the triggering function in the UE (the SMS Application port ID may be reserved for trigger messages). The SMS-SC may also perform segmentation for larger messages.

[0124] At 513, the SMS-SC may send a submit trigger confirm message (e.g.

T4_TRIGGER_ CONFIRM) to the MTC-IWF to confirm that the submission of the SMS may have been accepted by the SMS-SC. Then, at 514, the MTC-IWF may send a device trigger confirm message (e.g. T SP TRIGGER CONFIRM) to the SCS to confirm that the device trigger request may have been accepted for delivery to the UE.

[0125] At 515, 516, and/or 517, the short message may be delivered to the UE (e.g.

SMS_UE_TRIGGER_REQUEST). This may involve delivery attempts in MSC, SGSN and/or MME. This may also involve delivery attempts over IMS. The SMS-delivered trigger payload may be processed and handled by the triggering function in the UE. Information included within the trigger payload may be forwarded to the related or addressed UE-application.

[0126] In an embodiment, at 518, the SMS-SC may generate the CDR information and may include the SCS identifier. The SMS application port that may be included in the SM User Data Header may be included in the CDRs, for example, it may possible to perform

differentiated charging for an SMS that may be used for triggering purposes (e.g.

TBD TRIGGER CDR SUBMIT).

[0127] Additionally, at 519, the SMS-SC may send a message delivery report (e.g.

T4 TRIGGER REPORT) (cause code, trigger reference number, SCS Identifier) to the MTC- IWF. In an example embodiment, at 520, the MTC-IWF may generate the CDR information including the External Identifier or MSISDN and SCS Identifier (e.g.

RF TRIGGER CDR SUBMIT) and at 521, the MTC-IWF may send the device trigger report (e.g. TSP TRIGGER REPORT) (External Identifier or MSISDN and trigger reference number) message to the SCS with a cause value indicating whether the trigger delivery succeeded or failed and the reason for the failure (e.g. if the delivery may have failed).

[0128] At 522, in response to the received device trigger, the UE may perform an action that may take into consideration the content of the trigger payload. Such a response may typically involve initiation of an immediate or later communication with the SCS or the AS. [0129] As described herein, messages (e.g. new messages and/or existing messages that may be modified) may be provided and/or used herein. One or more of the following messages may be defined, provided, used, and/or added. Additionally, a SCS authorization and/or a DNS look up of the SCS associated with an external ID may be defined, provided, used, and/or added.

[0130] For example, Tsp messages may be defined, provided, used, and/or added. Tsp messages may include a TSP TRIGGER REQUEST that may be sent by a SCS and may be received by a MTC-IWF. The Tsp messages may include or be associated with a request from the SCS to the MTC-IWF to deliver a trigger to a particular application running on a particular device. Table 2 illustrates additional information associated with the

TSP TRIGGER REQUEST. As described herein, the Tsp messages from the SCS may include an Application Identifier (e.g. a field) that may be used by the MTC-IWF to identify the targeted application. In an example embodiment, the SCS may identify the application (e.g. the intended recipient of the trigger and/or the target application).that it may wish to communicate with on the UE using the Application Identifier included in a Tsp message.

Table 2

[0131] Tsp messages may also include a TSP TRIGGER CONFIRM that may be sent by a MTC-IWF and may be received by a SCS. For each TSP TRIGGER REQUEST, the MTCJWF may respond with a TSP TRIGGER CONFIRM. The confirm message may indicates to the SCS that the request may have been read by the MTC-IWF. The confirm message may also indicate whether the trigger request may be accepted or not.

[0132] According to an embodiment, the trigger request may be rejected for one or more of the following: the SCS may not be authorized to send trigger requests toward the particular application; the SCS may not be authorized to send trigger requests toward the particular device; the SCS may have exceeded its quota of trigger requests; the SCS may be exceeding its allowed rate of trigger requests; the External Identifier that may be indicated in the trigger request may not be valid; and the like. Table 3 illustrates additional information associated with the

TSP TRIGGER CONFIRM.

Table 3

[0133] Tsp messages may include a TSP TRIGGER REPORT that may be sent by a

MTC-IWF and may be received by a SCS. For each TSP TRIGGER CONFIRM that indicated that a trigger may be accepted, the MTC_IWF may provide the SCS with a

TSP TRIGGER REPORT. The report messages may indicates to the SCS whether or not the trigger may have been successfully delivered to the device. The trigger report may indicate why the trigger may not have been delivered. A trigger may not be delivered for one or more of the following: the device may not be authorized reachable; other; and the like. Table 4 illustrates additional information associated with the TSP TRIGGER REPORT. Table 4

[0134] Additional messages such as T4 messages, S6m messages, Rf and/or Ga messages, T5a, T5b, and/or T5c messages, MAP-C messages, and the like may be defined, provided, used, and/or added.

[0135] According to an example embodiment, the call flows or actions shown in FIGs. 4 and 5 may be merged together. Additionally, T5 and T4 triggering may be used, for example, as shown in FIG. 5. The MTC-IWF may also select the triggering method (e.g. as shown in FIGs. 4 and 5) based on the CN and UE capabilities.

[0136] Although a dispatch function may be described herein with respect to MTC applications, such a dispatch function may be used in other applications.

[0137] Additionally, although the terms UE or WTRU may be used herein, it may and should be understood that the use of such terms may be used interchangeably and, as such, may not be distinguishable.

[0138] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer- readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS What is claimed:

1. A method for performing device triggering in a machine type communication (MTC) system, the method comprising:

receiving, at a first node, a trigger request for a device, wherein a field in the trigger request comprises an identifier of an application on the device that is the intended recipient of the trigger;

generating, at the first node, in response to the trigger request, a short message service (SMS) message to trigger the device, wherein the SMS message comprises a header with fields, and wherein at least a first field in the header comprises an indication that the SMS message is a trigger message and at least a second field in the header comprises the identifier included in the trigger request of the application on the device that is the intended recipient of the trigger; and sending, from the first node, the SMS message.

2. The method of claim 1, wherein the first field in the header comprises a data coding scheme (DCS) field.

3. The method of claim 1, wherein the second field in the header comprises an application port identifier (ID) field.

4. The method of claim 3, wherein the trigger request message is received from a second node via a T4 interface.

5. The method of claim 4, wherein the first node comprises a short message service-service center (SMS-SC) and the second node comprises a machine type communication inter-working function (MTC-IWF).

6. A wireless transmit and receive unit (WTRU) for performing device triggering in a machine type communication (MTC) system, the WTRU configured to:

receive, from a network node, a short message service (SMS) message comprising a header with fields;

determine whether the SMS message is a trigger message by inspecting a first field in the header; when the first field in the header comprises an indication that the SMS message is a trigger message, determine which application on the WTRU is an intended recipient of the SMS message by inspecting an application identifier included in second field in the header; and

send the SMS message to the application associated with the application identifier included in the second field.

7. The WTRU of claim 6, wherein the WTRU is further configured to process the SMS message as a regular SMS message when the first field in the header comprises an indication the SMS message is not a trigger.

8. The WTRU of claim 6, wherein the first field in the header comprises a data coding scheme (DCS) field.

9. The WTRU of claim 6, wherein the second field in the header comprises an application port identifier (ID) field.

10. A method for performing device triggering in a machine type communication (MTC) system, the method comprising:

receiving, at a first node, a trigger request from a second node for a device, wherein a field in the trigger request comprises an identifier of an application on the device that is the intended recipient of the trigger;

determining, at the first node, whether the device that includes the application associated with the trigger request message has an Internet protocol (IP) address; and

sending, from the first node, the trigger request to a third node via a reference point to generate a trigger message for the trigger request if, based on the determination, the device does not have an IP address.

1 1. The method of claim 10, wherein the trigger message comprises a short message service (SMS) message, wherein the SMS message comprises a header with fields, and wherein at least a first field in the header comprises an indication that the SMS message is a trigger message and at least a second field in the header comprises the identifier included in the trigger request of the application on the device that is the intended recipient of the trigger.

12. The method of claim 1 1, wherein the first field in the header comprises a data coding scheme (DCS) field.

13. The method of claim 1 1, wherein the second field in the header comprises an application port identifier (ID) field.

14. The method of claim 10, further comprising: sending, from the first node, at least one of the following: an indication that the device already has an IP address or the IP address of the device if, based on the determination, the device has an IP address to the second network node via another reference point.

15. The method of claim 14, wherein the another reference point comprises a Tsp reference point.

16. A method for providing device triggering in a machine type communication (MTC) system, the method comprising:

determining, at a first node, whether to trigger a device;

generating, at the first node, a request if, based on the determination, the device should be triggered, wherein a field in a request associated with the trigger comprises an identifier of an application on the device that is the intended recipient of the trigger; and

sending, from the first node, the request to a second network node via a reference point to trigger the device and establish communication with the application thereon.

17. The method of claim 16, wherein the reference point comprises a Tsp reference point.

18. The method of claim 16, further comprising receiving, at the first node, in response to the request, an indication of whether the device may already have an IP address or an actual IP address of the device to establish communication therewith.

19. A method for authorizing device triggering in a machine type communication (MTC) system, the method comprising:

receiving, at a first node, an short message service (SMS) message to route to a device that is the intended recipient of the SMS message. determining, at the first node, that the SMS message is a trigger request based on an indication in a field of the header of the SMS message; and

determining, at the first node, if the sender of the SMS is trusted or authorized to send the trigger when the field of the header comprises an indication that the SMS message is a trigger message.

20. The method of claim 19, wherein the first node comprises a short message service-service center (SMS-SC).