WO2013074849A1

WO2013074849A1 - Triggering machine-to-machine device communication in wireless networks

Info

Publication number: WO2013074849A1
Application number: PCT/US2012/065368
Authority: WO
Inventors: Rajesh Bhalla
Original assignee: ZTE USA Inc
Current assignee: ZTE USA Inc
Priority date: 2011-11-15
Filing date: 2012-11-15
Publication date: 2013-05-23
Anticipated expiration: 2014-05-15

Abstract

Systems, devices and techniques for machine to machine (M2M) wireless communication between a client machine and a server machine include signal exchanges to provide response to trigger requests from the server machine under the scenarios of the client state being one of an active state, a dormant state and an inactive state are provided. In some implementations, the disclosed techniques may be implemented in a CDMA2000 network.

Description

TRIGGERING MACHINE-TO-MACHINE DEVICE

COMMUNICATION IN WIRELESS NETWORKS

CROSS REFERENCE TO RELATED APPLICATIONS [0001] This patent application claims the benefit of U.S. Provisional Patent

Application No. 61/560,237, filed on November 15, 2011, and U.S. Provisional Patent Application No. 61/592,507, filed on January 30, 2012. The entire contents of the before- mentioned patent applications are incorporated by reference as part of the disclosure of this application.

TECHNICAL FIELD

[0002] This patent document relates to systems, devices and techniques for Machine- to-machine communication in a wireless communications system.

BACKGROUND [0003] Machine-to-Machine (M2M) communications is a form of data

communications that involves one or more entities that do not need human interaction when activating or receiving communications. M2M communications can be initiated and consummated by interactions between two communication devices without human intervention.

[0004] In wireless communication networks, such as cdma2000 and 802.16, M2M communications is typically performed using an internet protocol (IP) address assigned to a client machine. However, M2M client machines may require infrequent communication (e.g., once every week or once every month) and may go into a dormant state between such a communication. Such a usage scenario may be susceptible to interruptions in traditional IP communication. SUMMARY

[0005] This patent document provides, among others, systems, devices and techniques for Machine-to-Machine (M2M) communication in a wireless communications network to provide improved M2M communications.

[0006] In one aspect, methods, apparatus and computer program products are disclosed directed to techniques for facilitating machine to machine communications, including receiving machine to machine (M2M) device identification information comprising a first machine identifier and performing a radio access network (RAN) based triggering operation using a second machine identifier, different from the first machine identifier.

[0007] In another aspect, methods, apparatus and computer program products are disclosed directed to techniques for facilitating machine to machine communications, including receiving machine to machine (M2M) device identification information comprising a first machine identifier and performing a packet data serving node (PDSN) based triggering operation using a second machine identifier, different from the first machine identifier.

[0008] This and other aspects and their implementations are described in greater detail in the drawings, the description and the claims. BRIEF DESCRIPTION OF DRAWINGS

[0009] FIG. 1 is a block diagram representation of a wireless communications network.

[0010] FIG. 2 is a block diagram representation of a wireless communications device.

[0011] FIG. 3 is a block diagram showing operational states of a machine to machine (M2M) device.

[0012] FIG. 4 shows signal exchanges during M2M device identification stage.

[0013] FIG. 5 shows signal exchanges during M2M session establishment stage.

[0014] FIG. 6 shows signal exchanged in an M2M device initiated communication. [0015] FIG. 7 shows an example of signals exchanged during an M2M device triggering operation when the M2M device is in Active or Connected state.

[0016] FIG. 8 shows another example of signals exchanged during an M2M device triggering operation when the M2M device is in the Active or Connected state.

[0017] FIG. 9 shows an example of signals exchanged during an M2M device triggering operation when the M2M device is in the Dormant state.

[0018] FIG. 10 shows another example of signals exchanged during an M2M device triggering operation when the M2M device is in the Dormant state.

[0019] FIG. 11 shows an example of signals exchanged during an M2M device triggering operation when the M2M device is not roaming and is in the Null/Inactive state.

[0020] FIG. 12 shows another example of signals exchanged during an M2M device triggering operation when the M2M device is not roaming and is in the Null/Inactive state.

[0021] FIG. 13 shows an example of signals exchanged during an M2M device triggering operation when the M2M device is roaming and is in the Null/Inactive state.

[0022] FIG. 14 shows another example of signals exchanged during an M2M device triggering operation when the M2M device is not roaming and is in the Null/Inactive state.

[0023] FIG. 15 shows yet another example of signals exchanged during an M2M device triggering operation when the M2M device is not roaming and is in the Null/Inactive state.

[0024] FIG. 16 is a flowchart representation of a process of wireless communication.

[0025] FIG. 17 is a block diagram representation of a wireless communications apparatus.

[0026] FIG. 18 is a flowchart representation of a process of wireless communication.

[0027] FIG. 19 is a block diagram representation of a wireless communications apparatus.

DETAILED DESCRIPTION

[0028] This patent document discloses techniques for facilitating M2M session establishment, triggering of M2M devices in an active/connected state, triggering of M2M devices in a dormant state, triggering of non-roaming M2M devices in a null/inactive state and triggering of non-roaming M2M devices in a null/inactive state. As further described below, the subject technology may be implemented in wireless networks such as cdma2000, Long Term Evolution (LTE), Wi-MAX, 4G and others.

[0029] FIG. 1 shows an example of a wireless communication system. A wireless communication system can include one or more base stations (BSs) 105a, 105b, one or more wireless devices 110a, 110b, 110c, l lOd, and an access network 125. A base station 105a, 105b can provide wireless service to wireless devices 110a, 110b, 110c and l lOd in one or more wireless sectors. In some implementations, a base station 105a, 105b includes directional antennas to produce two or more directional beams to provide wireless coverage in different sectors.

[0030] The access network 125 can communicate with one or more base stations

105a, 105b. In some implementations, the access network 125 includes one or more base stations 105a, 105b. In some implementations, the access network 125 is in communication with a core network (not shown in FIG. 1) that provides connectivity with other wireless communication systems and wired communication systems. The core network may include one or more service subscription databases to store information related to the subscribed wireless devices 110a, 110b, 110c and l lOd. A first base station 105a can provide wireless service based on a first radio access technology, whereas a second base station 105b can provide wireless service based on a second radio access technology. The base stations 105a and 105b may be co-located or may be separately installed in the field according to the deployment scenario. The access network 125 can support multiple different radio access technologies.

[0031] Various examples of wireless communication systems and access networks that can implement the present techniques and systems include, among others, wireless communication systems based Code division Multiple Access (CDMA) such as CDMA2000 lx, High Rate Packet Data (HRPD), evolved HRPD (eHRPD), Universal Mobile

Telecommunications System (UMTS), Universal Terrestrial Radio Access Network

(UTRAN), Evolved UTRAN (E-UTRAN), Long-Term Evolution (LTE), and Worldwide Interoperability for Microwave Access (WiMAX). In some implementations, a wireless communication system can include multiple networks using different wireless technologies. A dual-mode or multi-mode wireless device includes two or more wireless technologies that could be used to connect to different wireless networks. In some implementations, a wireless device can support Simultaneous Voice-Data Operation (SV-DO).

[0032] FIG. 2 is a block diagram representation of a portion of a radio station 205. A radio station 205 such as a base station or a wireless device can include processor electronics 210 such as a microprocessor that implements one or more of the wireless techniques presented in this document. The radio station 205 can include transceiver electronics 215 to send and/or receive wireless signals over one or more communication interfaces such as antenna 220. The radio station 205 can include other communication interfaces for transmitting and receiving data. Radio station 205 can include one or more memories configured to store information such as data and/or instructions. In some implementations, the processor electronics 210 can include at least a portion of the transceiver electronics 215. It will be appreciated that the disclosed techniques may be implemented to execute on the radio station 205.

[0033] Only for the sake of illustration, various embodiments directed to cdma2000 networks are now discussed. However, the disclosed subject matter can be practiced in a variety of wireless communication networks, with a cdma2000 network being one example.

[0034] In a typical M2M communication scenario, data is exchanged between an entity in the network, e.g., an M2M server that executes an M2M application and an M2M device in the network. The M2M device may be, e.g., a laptop, a smartphone, a tablet device, a utility meter, a controller of a heating, ventilation and air conditioning (HVAC) system, and so on.

[0035] FIG. 3 is a state diagram 300 depicting three states among which a wireless device may transition in a wireless network: an Active or Connected state 302, a Dormant state 304 in which and a Null or Inactive state 306. In the Active or Connected state 302, the device has an address assigned to it (e.g., an internet protocol, or IP, address), and may use the packet data services to actively receive data/signaling from and transmit

data/signaling to, the wireless network. In the Null or Inactive state 306, the packet data service is not activated and is not available. Also, the device does not have any address associated with it that can be used for packet communication. In the Dormant state 304, the packet data service is not activated but is available. In this state, typically a server that controls data transfer to/from the device is aware of the address assigned to the device and is also aware that the device is offline (i.e., will not respond to messages sent to the assigned address unless the device is woken up in some other way).

[0036] For cdma2000 packet data services, the M2M Server initiates

communications with M2M devices using the IP address assigned to them. Typical cdma2000 packet data networks require user devices to be in Active/Connected state or in Dormant state in order to have a valid IP address assigned to them. Usually communication with M2M devices would be needed very infrequently, e.g., on weekly or monthly basis, or yet only when some special-event reporting etc. is needed. Maintaining a very large number of M2M devices in Active or Dormant state will require significant network resources. Therefore, a method is needed wherein the M2M Server can "trigger" or "wake-up" M2M devices that are in Null/Inactive state, whenever there is a need for initiating

communications with them. M2M Server identifies the M2M device that needs to be triggered by passing device's "Identity" to a cdma2000 network entity called "M2M

InterWorking Function" (M2M-rWF). The M2M-IWF interfaces the M2M Server with the cdma2000 network.

[0037] When triggering an M2M device, the M2M Server may pass some

"application specific information" also in the "device trigger" message. Such "application specific information" could be passed either transparently or non-transparently over the cdma2000 network to the M2M device and interpreted by the M2M device to determine how to process the "trigger" request. For example, the device trigger request may require the M2M device to initiate the set up of a cdma2000 Packet Data Session and communicate with a peer-application identified by the "application specific information". Such communication over the established packet data session may be initiated either by the M2M Server or by the M2M device. Or the "trigger" request may require the M2M device to respond at a later time to the peer- application after setting up a packet data session; or yet respond to the peer- application by the use of cdma2000 control plane signaling channel(s) only without setting up a packet data session such as by using Short Message Service (SMS) or by passing a short amount of data over the signaling channel(s); or to just process the information received via the trigger request message without setting up a packet data session etc. [0038] This document describes methods that can be used for delivering device triggers to M2M devices over cdma2000 packet data networks using control plane/signaling channels. This document discusses the methods for delivering device triggers when the M2M device is in its subscribed Home service provider network as well as for the case when the M2M device is roaming in a Visited service provider network.

1. M2M Device Identifiers

[0039] Each M2M device is identified by an "Identifier" which may uniquely identify the M2M device in a given context (e.g., in a radio access network or an IP address space). For Device Triggering discussions in this document, two types of identifiers have been defined:

[0040] Internal Identifier

[0041] Internal Identifier is the identity that the entities within the cdma2000 network use for addressing an M2M device.

[0042] For example, MIN (mobile identification number) and IMSI (International mobile station identity) are used as Internal Identifiers in cdma2000 lx networks. MIN and IMSI are referred to as "lx Subscription Identifier" also. Typically MIN and IMSI are not exposed outside the cdma2000 network.

[0043] For packet data services, the Internal Identifier is the "Packet Data Access Subscription Identifier". It is constructed in the form of username® realm (NAI - Network Access Identifier) as defined in RFC4282.

[0044] External Identifier

[0045] External Identifier is the identity by which an M2M device is known to the

M2M Server.

[0046] The External Identifier and the Internal Identifier may be different. However, for the case when the M2M Server is within the cdma2000 packet data network operator domain, Packet Data Access Subscription Identifier (for simplicity referred to as network address identifier, or NAI) may be used as External Identifier also. 2. M2M Device Communication Procedures: M2M Session Establishment [0047] With reference to FIG. 4, in order to establish an M2M Session, the M2M device 424 initiates a packet data (HRPD) session with the cdma2000 network, or any other radio access network (RAN), e.g., a point coordination function PCF in the RAN 426, and establishes a PPP or another type of Link Layer connection with the PDSN 406 (401). M2M session establishment procedure may be invoked by the M2M device by initiating connectivity with the cdma2000 network autonomously or as a result of being paged by the network.

[0048] M2M device 424 initiates packet data (HRPD) session establishment procedure with the RAN 426 either autonomously or as a result of being Paged by the cdma2000 network. During this procedure the RAN 426 does not receive a UATI for an existing HRPD session, and an HRPD session is established between the M2M device and the RAN. The M2M device 424 may perform access authentication with the AN- AAA (not shown in FIG. 4). On successful access level authentication, if needed, the RAN/PCF 426 performs Al l-RRQ/RRP procedures with the PDSN, resulting in the establishment of the Main Service Connection and PPP/Link Layer connection between the M2M device and the PDSN, and the selection of the authentication protocol (401).

[0049] In some embodiments, the M2M device 424 and the PDSN establish PPP connection as per known procedures. In some embodiments, an alternative Link Layer protocol and corresponding procedures may also be specified between the M2M device and the PDSN.

[0050] At 402, the M2M device 424 performs authentication and authorization with the accounting, authentication and authorization (AAA) in the home network (HAAA) via the PDSN using the selected authentication protocol. An IP address is assigned to the M2M device. Several IP address assignment procedures with PPP as the link layer protocol are well known. For an alternative Link Layer protocol, IP address assignment procedures can be specified separately.

[0051] At 403, upon successful authorization, information such as M2M device

Subscriber Profile, configuration information etc. is available at the PDSN. The PDSN passes relevant subscription parameters to the RAN as per known procedures (not shown in FIG. 4). [0052] At 404, the PDSN 406 notifies the HAAA 414 of the IP address assigned to the M2M device 424. In addition, M2M device routing information, such as the serving BS ID, Cell ID, serving PDSN etc. is also notified to the HAAA. M2M device reachability information e.g., session UATI, M2M device state information (e.g., online/dormant) etc. may also be notified to the HAAA. As an example, Accounting Request/Response (Start) message can be used for the purpose of notifying the HAAA of various parameters or information specific to the M2M Device 424.

[0053] If an interface is defined between the PDSN 406 and the M2M-IWF 416,

Status Update Request/Response message 405 can be used by the PDSN 406 to notify the M2M-IWF 416 of the IP address assigned to the M2M device 424. Other M2M device specific information, such as routing, reachability, configuration information etc. may also be notified to the M2M-IWF 416.

3. M2M Device Initiated Communications - M2M Device in Active/Connected State

[0054] With reference to FIG. 5, an example embodiment of a procedure 500 for

M2M device initiated communications is depicted. The procedure 500 is applicable both for the non-roaming and roaming scenarios.

[0055] The procedure 500 is applied when M2M device 424 has an established point to point (PPP)/Link Layer connection with the PDSN 406 and is in Active/Connected state. In this state, a physical traffic channel exists between the M2M device 424 and the RAN 426 and an IP address is assigned to the M2M device 424.

[0056] The M2M device 424 can communicate with the peer-entity over the

PPP/Link Layer connection. At 501, the M2M device 424 sends a user plane packet that is addressed to a peer- application entity in the M2M Server 418 (or elsewhere in the network) over the established PPP/Link Layer connection with the PDSN 406. The IP address/Port information of the peer-application entity may be known to the M2M device 424 in advance (e.g., by way of configurations) or may have been communicated to the M2M device 424 as a part of the Device Trigger procedure described in this document. For (Proxy)MIP type services, an HA/LMA 408 is in the path of the IP traffic between the M2M Device 424 and the peer- application entity, e.g., the M2M server 418. [0057] At 502, End-to-End IP communications between the M2M device424 and the peer-application entity, e.g., the M2M server 418, continues.

Device Triggering - M2M Device in Active/Connected State

[0058] M2M device Triggering is a 3GPP2 network provided service which gives applications of M2M Service Provider (e.g., applications resident on the M2M Server or applications registered at the M2M Server) the capability of triggering their M2M devices to communicate with the M2M applications. To facilitate such capabilities, the cdma2000 system provides a set of control plane and possibly user plane functions also to deliver the device trigger request to the M2M device.

[0059] FIG. 6 depicts an exemplary sequence 600 of signals exchanged during M2M device triggering when M2M device is in Active/Connected state. FIG. 7 depicts another exemplary sequence 700 of signals exchanged during M2M device triggering when M2M device is in Active/Connected state .

[0060] While triggering an M2M device, the M2M Server may include "application specific information" in the device trigger requests. Such "application specific information" is transported transparently over the cdma2000 network and is interpreted by the M2M device to identify how to process the trigger request. For example, the device trigger request may require M2M device to initiate setting up of the cdma2000 packet data session and communicate with the peer- application identified by the "application specific information"; or may require the M2M device to respond at a later time to the peer-application after setting up a packet data session; or yet respond to the peer- application by the use of cdma2000 control plane signaling channel(s) only without setting up a packet data session, such as by using SMS (short messaging service) or by passing a short amount of data over the signaling channel(s); or to just process the information received via the trigger request message without setting up the packet data session etc.

[0061] This document discloses several techniques for delivering device trigger requests to the M2M device via control plane/signaling channel functions provided by the cdma2000 network. In some implementations, when M2M Server includes "application specific information" in the device trigger request, such information is also delivered to the M2M device via control plane/signaling channels. Alternatively, when user plane based procedures are used, "application specific information" may be delivered to the M2M device after a packet data session has been established for the M2M device.

[0062] In addition to the signal exchanges disclosed in this document, "accounting" procedures may be performed for the device trigger requests by the cdma2000 network. Depending on the cdma2000 operator policy, accounting can be performed for the received trigger requests.

4. First exemplary embodiments - Device Triggering in Active mode

[0063] With reference to FIG. 6, the device triggering procedure illustrated below is applicable both for the non-roaming and roaming scenarios.

[0064] When M2M Server wants to initiate communications with an M2M device and if it does not know the IP address that is assigned to the M2M device, or identifies the need to recover IP connectivity, e.g., the M2M device is not responding because the IP address is not valid any longer; it first determines M2M-r F that serves the M2M device. One possible method could be the use of DDNS procedures using M2M device's "External Identifier" as the key to query public DNS infrastructure. As M2M-r F assigned to a particular M2M device will change rarely, the M2M Server performs such a DNS query to obtain the assigned M2M-r F address infrequently. Another approach for determining the identity of the M2M-r F could be to construct the M2M device External Identifier with a "Domain Identifier" component. The "Domain Identifier" component could be assigned by the cdma2000 network operator so as to identify the M2M-r F to be used for accessing the M2M device, either explicitly within the "Domain Identifier" component or implicitly by way of configurations at the M2M Server. Once the serving M2M-r F address is known, the M2M Server requests the M2M-IWF for the IP address assigned to the M2M device (601).

[0065] The M2M device "External Identifier" included in request 601 is the identity by which the M2M device is known to the M2M Server. In addition, the M2M device may be assigned an "Internal Identifier" also, which is the identity that the entities within the cdma2000 network use for accessing the M2M device. MIN and IMSI could be used as "Internal Identifiers" in cdma2000 networks. MIN and IMSI are referred to as "lx

Subscription Identifier" also. Typically MIN and IMSI are not exposed outside the cdma2000 network. Therefore, External Identifier and Internal Identifier will usually be different. However, for the case when the M2M Server is within the cdma2000 network operator domain, MIN/IMSI may be used as External Identifier as well.

[0066] As previously discussed, in this scenario, M2M Server 418 wants to initiate communications with the M2M device 424. If it does not know the IP address information for the M2M device 424 or identifies a need to recover IP connectivity; the M2M Server 418 queries the M2M-r F 416 for the IP address assigned to the M2M device 424 by sending a Trigger Request message (601). Trigger Request message includes M2M device External Identifier. Peer- application specific information may also be included in the Trigger Request message to inform M2M device how to process the trigger request, the identity of the peer- application entity etc.

[0067] M2M-IWF 416 may authorize the Trigger Request message based on operator policy. If M2M-r F cannot derive M2M device Internal Identifier from the External Identifier received in the Trigger Request message, it queries the home AAA server (HAAA) 414 for such information (602). M2M-IWF 416 queries the HAAA 414 for M2M device IP address also if such information is not available in the local cache. As the M2M device is in Active/Connected state, the HAAA 414 returns the IP address assigned to the M2M device.

[0068] At 603, MTC-IWF 416 returns M2M device IP address and other information as needed, to the M2M Server 418.

[0069] At 604, the M2M Server 418 is ready to communicate with the M2M device.

At 604, M2M Server 418 sends user plane packets addressed to the M2M device 424.

[0070] At 605, end-to-End IP communications between the M2M device and the peer- application entity (at the M2M Server) continues.

5. Second exemplary embodiment - Device Triggering in Active mode

[0071] With reference to FIG. 7, device triggering procedure illustrated in signal exchanges 700 is applicable for both, the non-roaming and the roaming scenarios.

[0072] When M2M Server wants to initiate communications with an M2M device and if it does not know the IP address that is assigned to the M2M device, or identifies the need to recover IP connectivity, e.g., the M2M device is not responding because the IP address is not valid any longer; it first determines M2M-IWF in the Home network of the M2M device that serves the M2M device. One possible method for determining the M2M- IWF that serves the M2M device could be the use of Dynamic DNS procedures using M2M device's "External Identifier" as the key to query public DNS infrastructure. As the M2M- IWF assigned to a particular M2M device will change rarely, the M2M Server will need to perform such DNS query to obtain the assigned M2M-IWF address infrequently. Another approach for determining the identity of the M2M-IWF could be to construct the M2M device External Identifier with a "Domain Identifier" component. The "Domain Identifier" component could be assigned by the cdma2000 network operator, such that it identifies the M2M-IWF to be used for accessing the M2M device explicitly by way of the information within the "Domain Identifier" component; or implicitly by way of configurations at the M2M Server. Once the serving M2M-IWF address is known, the M2M Server requests the M2M-IWF for the IP address assigned to the M2M device.

[0073] It may be noted that the M2M Server communicates with an M2M-r F that is within the Home Domain 422 of the M2M device. M2M device subscription related information, M2M device configuration information, M2M device "Internal Identifier-to- External Identifier mapping" information, and M2M device reachability information etc. are stored at the Home AAA server. The M2M-r F in the Home network 422 can access the HAAA for querying such information.

[0074] At 701, M2M Server wants to initiate communications with an M2M device.

If it does not know the IP address assigned to the M2M device or identifies a need to recover IP connectivity e.g., the IP address known for the M2M device is invalid and/or the device is not responding; the M2M Server queries the M2M-r F in the Home domain of the M2M device for the IP address assigned to the M2M device by sending a Trigger Request message. The Trigger Request message includes M2M device External Identifier. Peer- application specific information may also be included in the Trigger Request message to inform M2M device how to process the trigger request.

[0075] M2M-IWF may authorize the Trigger Request message based on operator policy. If M2M-IWF cannot derive M2M device Internal Identifier from the External Identifier received in the Trigger Request message, it queries the HAAA for such

information (702). Μ2Μ-ΓΛΤ queries the HAAA for M2M device IP address also if such information is not available in the local cache. As the M2M device is in Active/Connected state, an IP address is assigned to the device. The HAAA returns the IP address assigned to the M2M device.

[0076] At 703, M2M-IWF returns M2M device IP address and other information as needed, to the M2M Server.

[0077] At 704, the M2M Server is ready to communicate with the M2M device.

M2M Server sends user plane packets addressed to the M2M device.

[0078] At 705, end-to-End IP communications between the M2M device and the peer- application entity (at the M2M Server) continues.

Device Triggering - M2M Device in Dormant State

[0079] With reference to FIG. 8 and FIG. 9, device triggering procedures that are applicable to both scenarios in which the M2M device is in home network and visited network (the non-roaming and the roaming).

6. First exemplary embodiment - Device Triggering in Dormant mode

[0080] When M2M Server wants to initiate communications with an M2M device and it does not know the IP address assigned to the M2M device or identifies a need to recover IP connectivity e.g., M2M device is not responding because the IP address is not valid any longer; it first determines the M2M-IWF that serves the M2M device. A procedure to determining M2M-IWF was previously discussed. M2M Server then queries the M2M-IWF for the IP address assigned to the M2M device. M2M Server uses the device IP address returned by the M2M-IWF to initiate communications with the M2M device. On the receipt of the IP packet addressed to the M2M device, RAN/PCF "Pages" the M2M device to initiate establishment of the HRPD session, and forwards the IP packet to the M2M device once traffic channel is available.

[0081] At 801, M2M Server wants to initiate communications with the M2M device.

If it does not know the IP address information for the M2M device or identifies a need to recover IP connectivity; the M2M Server queries the M2M-IWF for the IP address of the M2M device by sending a Trigger Request message. Trigger Request message includes M2M device External Identifier. Peer- application specific information may also be included in the Trigger Request message.

[0082] At 802, M2M-IWF may authorize the Trigger Request message based on operator policy. If M2M-r F cannot derive M2M device Internal Identifier from the External Identifier received in the Trigger Request message, it queries HAAA for such information. M2M-r F queries the HAAA for M2M device IP address also if such information is not available in the local cache. As the M2M device is in Dormant state, an IP address is available for the M2M device and HAAA returns such IP address.

[0083] At 803, M2M-rWF returns M2M device IP address and other information as needed, to the M2M Server.

[0084] At 804, the M2M Server is ready to communicate with the M2M device.

M2M Server sends user plane packet addressed to the M2M device. Such user packet arrives at the PDSN, possibly via the HA/LMA, and is forwarded to the PCF over the A10- Connection.

[0085] At 805, PCF interacts with the RAN for Paging the M2M device. UATI information of the previous HRPD session (from reachability info) may be made available to the M2M device via the Page message.

[0086] At 806, M2M device performs HRPD connection establishment procedures.

[0087] At 807, IP Packet(s) are forwarded to the M2M device over the assigned traffic channel.

[0088] At 808, End-to-End IP communications between the M2M device and the peer- application entity (in the M2M Server) continues.

7. Second exemplary embodiment - Device Triggering in Dormant mode

[0089] With reference to the signal exchanges 900 depicted in FIG. 9, as discussed previously, when M2M Server wants to initiate communications with an M2M device and it does not know the IP address assigned to the M2M device or identifies a need to recover IP connectivity e.g., M2M device is not responding because the IP address is not valid any longer; it first determines the M2M-IWF in the Home domain that serves the M2M device. M2M Server then queries the Μ2Μ-ΓΛΤ for the IP address assigned to the M2M device. M2M Server uses the device IP address returned by the M2M-r F to initiate communications with the M2M device. On the receipt of the IP packet addressed to the M2M device, RAN/PCF "Pages" the M2M device to initiate establishment of the HRPD session, and forwards the IP packet to the M2M device once the traffic channel is available.

[0090] At 901, M2M Server wants to initiate communications with an M2M device. If it does not know the IP address assigned to the M2M device or identifies a need to recover IP connectivity; the M2M Server queries the M2M-IWF in the Home domain of the M2M device for the IP address of the M2M device by sending a Trigger Request message. Trigger Request message includes M2M device External Identifier. Peer- application specific information may also be included in the Trigger Request message.

[0091] At 902, M2M-r F may authorize the Trigger Request message based on operator policy. If M2M-r F cannot derive M2M device Internal Identifier from the External Identifier received in the Trigger Request message, it queries HAAA for such information. M2M-IWF queries the HAAA for M2M device IP address also if such information is not available in the local cache. As the M2M device is in Dormant state, an IP address is available for the M2M device and HAAA returns such IP address.

[0092] At 903, M2M-rWF returns M2M device IP address and other information as needed, to the M2M Server.

[0093] At 904, M2M Server is ready to communicate with the M2M device. M2M

Server sends user plane packet addressed to the M2M device. Such user packet arrives at the PDSN, possibly via the HA/LMA, and is forwarded to the PCF over the AlO-Connection.

[0094] at 905, PCF interacts with the RAN for Paging the M2M device. The identity of the M2M device to be Paged (e.g., device UATI) is known from the M2M HRPD Session Context information that is associated with the A10 connection over which user packet is received from the PDSN.

[0095] At 906, M2M device and the RAN perform HRPD session establishment procedures and traffic channel(s) is assigned.

[0096] At 907, IP packets are forwarded to the M2M device over the assigned traffic channel.

[0097] At 908, end-to-End IP communications between the M2M device and the peer- application entity (being served by the M2M Server) continues. Device Triggering (Non-Roaming) - M2M Device in Null/Inactive State

[0098] With respect to FIG. 10 and FIG. 11, device triggering procedures 1000 and

1100 are described and are applicable for non-roaming scenarios.

[0099] When M2M Packet Data Session transitions to Null/Inactive state, the PDSN notifies the HAAA of the release of the IP address assigned to the M2M device. Reachability information relating to the last known location of the M2M device (e.g., last serving PDSN ID, Common-AlO ID, and optionally last serving BS ID) is also notified to the HAAA. HAAA retains reachability information for the M2M device. The M2M-IWF and M2M Server may also be informed of the release of the IP address assigned to the M2M device.

[00100] When M2M Server wants to initiate communications with the M2M device and it does not know the IP address assigned to the M2M device or identifies a need to recover IP connectivity e.g., M2M device is not responding because the IP address is not valid any longer; it first determines the M2M-r F in the Home domain that serves the M2M device. The M2M Server then queries the M2M-r F for the IP address assigned to the M2M device. As M2M device is in Null/Inactive state and no IP address is assigned to the M2M device, the M2M-r F initiates procedures for triggering the M2M device. On being triggered, depending on the information in the trigger request (e.g., application specific information in the trigger request), in this example scenario the M2M device initiates establishment of a packet data session with the cdma2000 network. On the establishment of the M2M Packet Data Session, information about the IP address assigned to the M2M device is forwarded to the M2M Server also. The M2M Server or the M2M device can use the device IP address to initiate communications with the peer entity over the established packet data session. In this example illustration, the M2M device initiates communications with the peer- application entity identified from the application specific information in the trigger message. Else, the identity of the peer-application entity can be determined via user plane procedures with the M2M server. For MlP/Proxy MIP type of services, an HA/LMA is also in the path of the IP traffic between the M2M device and the peer-application.

8. First exemplary embodiment - Device Triggering in (Non-roaming) Null/Inactive mode [00101] When M2M Server wants to initiate communications with the M2M device and it does not know IP address assigned to the M2M device or identifies a need to recover IP connectivity e.g., M2M device is not responding because the IP address is not valid any longer; it first determines the M2M-IWF that serves the M2M device, as previously discussed. M2M Server then queries the M2M-IWF for the IP address assigned to the M2M device. As M2M device is in Null/Inactive state and no IP address is assigned to the M2M device, the M2M-IWF initiates procedures for triggering the M2M device. On being triggered, depending on the information in the trigger request (e.g., communicated to the M2M device via application specific information), in this example scenario the M2M device initiates establishment of a packet data session with the cdma2000 network. Information about the IP address assigned to the M2M device is forwarded to the M2M Server also. The M2M Server or the M2M device can use the device IP address and the packet data session to initiate communications with the peer entity. In this example illustration, the M2M device initiates communications with the peer-application entity based on the information received via the application specific information in the trigger message.

[00102] At 1001, M2M device powers down and/or releases packet data session.

Packet data session (e.g., HRPD session, PPP/Link Layer connection, A8/9 and AlO/11 connections etc.) and the IP address assigned to the M2M device are released.

[00103] At 1002, PDSN notifies HAAA of the release of the IP address assigned to the M2M device. In addition, M2M device routing information, such as the last serving BS ID, Cell ID, serving PDSN information etc. is also notified to the HAAA. M2M device reachability information (e.g., UATI, Null/Inactive state info, etc.) may also be notified to the HAAA. As an example, Accounting Request/Response (Stop) message can be used for the purpose of notifying the HAAA of various parameters/information specific to the M2M device.

[00104] As an example, cdma2000 system supports several types of registrations from the mobile device. Certain types of registrations, such as power-up registration, power- down registration, timer-based registration, distance-based registration, zone-based registration and user-zone registration are performed autonomously by the mobile device (ref. 3GPP2 C.S0005). For a cdma2000 lx System, such registrations result in updating the location information of the mobile device at the Home Location Register (HLR). For M2M devices, the procedures at the RAN/PCF can be enhanced so that the above stated types of autonomous registrations originating from the M2M device, while the M2M device is in Null/Inactive state, result in updating M2M device routing/reachability information at the AAA. The RAN/PCF can use a pre-established Common-AlO connection between the RAN/PCF and the PDSN to communicate such registration information to the PDSN. Such information is then passed to the AAA using, for example Notify Request/Response procedures.

[00105] At 1003, if an interface is defined between the PDSN and the M2M-IWF,

Status Update Request/Response message can be used by the PDSN to notify the M2M-IWF of the release of the IP address assigned to the M2M device. Other M2M device specific information, such as routing and reachability information etc. may also be notified to the M2M-IWF.

[00106] At 1004, M2M-IWF may inform the M2M Server of the release of the IP address assigned to the M2M device.

[00107] At 1005, M2M Server wants to initiate communications with the M2M device. If it does not know the IP address information for the M2M device or identifies a need to recover IP connectivity; M2M Server queries the M2M IWF for the IP address of the M2M device by sending a Trigger Request message. Trigger Request message includes M2M device External Identifier. Peer-application specific information (such as the IP address/Port information etc.) may also be included in the Trigger Request message.

[00108] At 1006, M2M-r F may authorize the Trigger Request message based on operator policy. If M2M-r F cannot derive M2M device Internal Identifier from the External Identifier received in the Trigger Request message, it queries HAAA for such information. M2M-r F queries the HAAA for M2M device IP address also if such information is not available in the local cache. As the M2M device is in Null/Inactive state, an IP address is not available for the M2M device. In this case the HAAA returns the Internal Identifier (MIN/IMSI) and routing/reachability, subscription, configuration information etc. for the M2M device via Device Info Ack message to the M2M-IWF. Based on such information, M2M-r F can attempt to deliver a device trigger to the M2M device.

[00109] At 1007, if the M2M-IWF determines that it can attempt to deliver device trigger to the M2M device, it may respond with Trigger Acknowledgment message to the M2M Server to prevent M2M Server sending repeated trigger requests. Based on operator policy and capabilities of the M2M device, M2M-IWF selects trigger delivery mechanism e.g., delivery of device trigger via SMS or directly though cdma2000 network nodes e.g., RAN or PDSN etc. This proposal discusses mechanisms for the delivery of device trigger directly via the RAN and via the PDSN. M2M-IWF uses routing/ reachability information received from the HAAA in Step-6, and information received in the Trigger Request message (Step-5) e.g., application specific information etc. to construct a Trigger M2M Device message. Alternative-l:

[00110] At 1008, if device trigger mechanism via RAN is chosen: M2M-IWF forwards Trigger M2M Device-RAN Request message to the RAN. The message includes peer- application specific information also if received from the M2M Sever. The RAN-node to contact is identified from the routing information received from the HAAA.

Alternative-2:

[00111] At 1009, if device trigger mechanism via PDSN is chosen: M2M-IWF forwards Trigger M2M Device-PDSN Request message to the PDSN. The message includes peer- application specific information also if received from the M2M Server. The PDSN- node to contact is identified from the routing information received from the HAAA.

[00112] At 1009a, PDSN forwards Trigger M2M Device Request message to the

PCF via a pre-established Common-AlO connection. The PDSN identifies the PCF to interact with based on the routing PCF information received from the HAAA.

[00113] At 1010, the RAN pages the M2M device. Device trigger specific information e.g., peer- application specific information is also passed to the M2M device via the Page message.

[00114] At 1011, for Alternative-l: RAN acknowledges device trigger message by returning Trigger M2M Device-RAN Response message to the M2M-r F.

[00115] At 1012, for Alternative-2: RAN/PCF acknowledges device trigger message by returning Trigger M2M Device Response message to the PDSN. [00116] At 1012a, PDSN returns Trigger M2M Device-PDSN Response message to the M2M-IWF.

[00117] At 1013, based on the information in the trigger message, the M2M device and the cdma2000 network perform "M2M Session Establishment" procedures as previously described. M2M device performs authentication and authorization with the HAAA and an IP address is assigned to the M2M device. IP address and M2M device routing and reachability information etc. are passed to the HAAA; and possibly to the M2M-r F also.

[00118] At 1014, HAAA returns M2M device IP address etc. to the M2M-IWF.

[00119] At 1015, M2M-rWF passes M2M device IP address and other information as needed to the M2M Server.

[00120] At 1016, user plane communications can be initiated either by the M2M device or by the M2M Server. The call flow illustration above shows M2M device initiating user plane communications. M2M device sends user plane packets addressed to the peer- application entity in the M2M Server or elsewhere in the network over the established PPP/Link Layer connection with the PDSN. For (Proxy)MIP type of services, an HA/LMA is also in the path of the IP traffic between the M2M device and the peer-application.

[00121] At 1017, end-to-End IP communications between the M2M device and the peer- application entity continues. 9. Second exemplary embodiment - Device Triggering in (Non-roaming) Null/Inactive mode

[00122] With reference to FIG. 11, various depicted messages in the procedure 1100 are further described below.

[00123] As a pre-condition for this procedure, M2M Packet Data Session is in Null/Inactive state. HRPD session and the PPP/Link Layer connection have been released.

The last serving RAN, however maintains M2M HRPD Session Context for the M2M device. M2M HRPD Session Context minimally maintains an association between M2M device Internal ID, device UATI, and the last serving PDSN ID.

[00124] When M2M Packet Data Session for the M2M device transitions to

Null/Inactive state, the PDSN notifies the HAAA of the release of the IP address assigned to the M2M device. The HAAA, however maintains reachability information for the M2M device, e.g., last serving PDSN ID, Common-AlO ID, and optionally last serving BS ID.

[00125] The Common-AlO Connection between the RAN/PCF and the PDSN is established at system start-up and maintained for the duration of system operation. The Common-AlO Connection is used for the purpose of signaling between the PDSN and the RAN/PCF.

[00126] The procedures for establishing such Common-AlO Connection between the

RAN/PCF and the PDSN can be specified separately. Each Common-AlO connection between a RAN/PCF-PDSN is identified by a "Common-AlO ID".

[00127] If an interface is defined between the PDSN and the M2M-IWF, the PDSN notifies the M2M-IWF of the release of the IP address assigned to the M2M device. The M2M-IWF, may maintain reachability information for the M2M device also e.g., last serving PDSN ID, Common-AlO ID, and optionally last serving BS ID. In this case, the PDSN sends device reachability information also to the M2M-IWF. In turn, the Μ2Μ-ΓΛΤ may inform the M2M Server of the release of the IP address assigned to the M2M device.

[00128] At 1101, M2M Server wants to initiate communications with an M2M device. If it does not know the IP address assigned to the M2M device or identifies a need to recover IP connectivity; M2M Server queries the M2M IWF in the Home domain of the M2M device for the IP address assigned to the M2M device by sending a Trigger Request message. Trigger Request message includes M2M device External Identifier. Peer- application specific information (such as the IP address/Port information etc.) may also be included in the Trigger Request message.

[00129] Ar 1102, M2M-IWF may authorize the Trigger Request message based on operator policy. If M2M-r F cannot derive M2M device Internal Identifier from the External Identifier received in the Trigger Request message, it queries HAAA for such information. M2M-IWF queries the HAAA for M2M device IP address also if such information is not available in the local cache. As the M2M device is in Null/Inactive state, an IP address is not available for the M2M device. In this case the HAAA returns the Internal Identifier, and reachability, subscription, configuration information etc. for the M2M device via Device Info Ack message to the M2M-r F. Based on such information, M2M-IWF can attempt to deliver a Device Trigger to the M2M device. [00130] At 1103, if the M2M-IWF determines that it can attempt to deliver device trigger to the M2M device, it may respond with Trigger Acknowledgment message to the M2M Server to prevent the M2M Server from sending repeated trigger requests.

[00131] Based on operator policy and the capabilities of the M2M device, the M2M- IWF selects trigger delivery mechanism e.g., delivery of device trigger via SMS or directly though cdma2000 network nodes e.g., the RAN or the PDSN etc.

[00132] This document discusses mechanisms for the delivery of device trigger directly via the RAN or via the PDSN. Μ2Μ-ΓννΤ uses device reachability information received from the HAAA in Step-2, and information received in the Trigger Request message (Step-1) e.g., application specific information etc. to construct a Trigger M2M Device message.

Alternative-l:

[00133] At 1104, if device trigger mechanism via RAN is chosen: M2M-IWF forwards Trigger M2M Device-RAN Request message to the RAN. The message includes peer- application specific information also if received from the M2M Sever. The RAN-node to contact is identified from the reachability information (last serving BS ID) received from the HAAA in Step-2.

Alternative-2:

[00134] At 1105, if device trigger mechanism via PDSN is chosen: M2M-IWF forwards Trigger M2M Device-PDSN Request message to the PDSN. The message includes peer- application specific information also if received from the M2M Server. The PDSN- node to contact is identified from the reachability information (last serving PDSN) received from the HAAA in Step-2.

[00135] At 1105a, PDSN forwards Trigger M2M Device Request message to the

PCF via a pre-established Common-AlO connection. The PDSN identifies the PCF to interact with based on the reachability information (Common- A10 ID) received from the HAAA, and received in message at Step-2.

[00136] At 1106, PCF interacts with the RAN for Paging the M2M device. The RAN determines the identity of the M2M device to be Paged (device UATI) from the M2M

HRPD Context information, indexed by the Internal ID of the M2M device. Device trigger specific information e.g., application specific information is also passed to the M2M device via the Page message.

[00137] At 1107, for Alternative- 1: RAN acknowledges the delivery of the device trigger message by returning Trigger M2M Device-RAN Response message to the M2M- IWF.

[00138] At 1108, for Alternative-2: RAN/PCF acknowledges the delivery of the device trigger message by returning Trigger M2M Device Response message to the PDSN over the Common A10 connection.

[00139] At 1108a, The PDSN returns Trigger M2M Device-PDSN Response message to the M2M-IWF.

[00140] At 1109, the M2M device initiates HRPD session establishment procedures with the RAN. Traffic channel(s) is assigned to the M2M device per known HRPD procedures. For an M2M device transitioning from Null/Inactive State, M2M HRPD Session Context at the RAN is identified by the UATI received from the M2M device, and updated, as needed.

[00141] On successful access authentication (if needed) the RAN/PCF performs Al 1-

RRQ/RRP procedures with the selected PDSN, resulting in the establishment of the Main Service Connection. PPP/Link Layer connection between the M2M device and the PDSN is also established and the protocol to be used for the authentication of the M2M device is selected.

[00142] At 1110, the M2M device performs authentication and authorization with the

AAA in the Home network (HAAA) via the PDSN using the selected authentication protocol. An IP address is assigned to the M2M device. IP address assignment procedures with PPP as the link layer protocol are well known.

[00143] At 1111, on successful authorization, information such as M2M Subscriber

Profile, M2M configuration information etc. is available at the PDSN. The PDSN passes relevant subscription parameters to the RAN as per known procedures. The PDSN passes M2M device Identity (username® realm information in the form of NAI construct) and the identity of the serving PDSN (PSDN ID) also to the RAN/PCF. The signaling procedures for passing information from the PDSN to the RAN/PCF are not shown in this illustration. [00144] At 1112, as a part of Step 1110 or as a separate message, the PDSN notifies the HAAA of the IP address assigned to the M2M device. In addition, M2M device reachability information, such as the identity of the serving PDSN (PDSN ID) and the identity of the Common-AlO connection associated with the serving RAN/PCF (Common- A10 ID) are also notified to the HAAA. The identity of the Base Station (BS ID) serving the M2M device may also be notified to the HAAA. As an example, Accounting

Request/Response (Start) message can be used for the purpose of notifying the HAAA of various parameters specific to the M2M Device.

[00145] At 1113, if an interface is defined between the PDSN and the M2M-IWF, Status Update Request/Response message can be used by the PDSN to notify the M2M-IWF of the IP address assigned to the M2M device. Other M2M device specific information, such as M2M device reachability information (serving PDSN ID, Common-AlO ID), M2M configuration information etc. are also notified to the M2M-IWF. The identity of the Base Station (BS ID) serving the M2M device may also be notified to the M2M-IWF. The PDSN learns the identity of the serving M2M-IWF from the M2M configuration information in received from the HAAA in Step- 10.

[00146] At 1114, HAAA returns M2M device IP address etc. to the M2M-IWF. The

M2M-IWF, may maintain reachability information for the M2M device also e.g., last serving PDSN ID, Common-AlO ID, and optionally last serving BS ID. In this case, the HAAA sends device reachability information also to the M2M-IWF.

[00147] At 1115, M2M-IWF passes M2M device IP address and other information as needed to the M2M Server.

[00148] At 1116, user plane communications can be initiated either by the M2M device or by the M2M Server. The call flow illustration above shows M2M device initiating user plane communications. M2M device sends user plane packets addressed to the peer- application entity in the M2M Server or elsewhere in the network over the established PPP/Link Layer connection with the PDSN. The M2M device identifies the peer- application entity from the "application specific information" received via the Page message. Else, the identity of the peer- application entity can be determined via user plane procedures. For MlP/Proxy MIP type of services, an HA/LMA is also in the path of the IP traffic between the M2M device and the peer- application. [00149] At 1117, end-to-End IP communications between the M2M device and the peer- application entity continues.

10. Third Exemplary Embodiment - Device Triggering in (Non-roaming) Null/Inactive mode (Option -1)

[00150] With reference to FIG. 12, the device triggering procedure 1200 is applicable for the roaming scenario. This solution (Option - 1) assumes that there is roaming relationship between the Visited Network 420 and the Home network 422. In addition, there is trust/business relationship between the home and visited networks, such that the visited network allows sharing of the routing/ reachability information of the M2M device (e.g., last serving BS ID, Cell ID, last serving PDSB ID, UATI information etc.) with the home network.

[00151] At 1201, when M2M device powers down or releases the packet data session, the PDSN notifies (1202) the AAA in the home network (HAAA) via the AAA in the visited network (VAAA) of the release of the IP address assigned to the M2M device. Routing and reachability information for the last known location of the M2M device is also informed to the HAAA. In addition M2M-IWF in the home network and M2M Server may also be informed of the release of the IP address assigned to the M2M device by the serving PDSN.

[00152] When M2M Server wants to initiate communications with the M2M device, device trigger procedures are similar to those described previously. At 1205, M2M Server sends Trigger Request message which may contain application specific information also, to the M2M-rWF in the home network. At 1206, on query by the M2M-rWF, HAAA returns the Internal Identifier (MIN/IMSI) and routing, reachability, configuration, subscription information etc. of the M2M device to the M2M-IWF. Routing information for the M2M device points to the cdma2000 network entities (e.g., last serving BS ID, Cell ID, last serving PDSN ID etc.) that are in the visited network through which the M2M device is reachable. Since there is a trust/business relationship between the home and visited network operators, M2M-IWF in the home network can communicate directly with the cdma2000 network entities in the visited network, and depending on the trigger delivery method, forwards trigger request to the RAN or to the PDSN in the visited network. [00153] On being triggered, depending on the information in the trigger request (e.g., communicated to the M2M device via application specific information), the M2M device initiates establishment of a packet data session with the cdma2000 network. Information about the IP address assigned to the M2M device is forwarded to the M2M Server also. In this example illustration, the M2M device initiates communications with the peer- application entity based on the information received via the application specific information in the trigger message.

[00154] At 1201, M2M device is roaming in a visited operator network 420. It powers down and/or releases packet data session. Packet data session (e.g., HRPD session, PPP/Link Layer connection, A8/9 and AlO/l l connections etc.) and the IP address assigned to the M2M device are released.

[00155] At 1202, the PDSN in the visited network notifies the Home AAA via the

Visited AAA of the release of the IP address assigned to the M2M device. In addition, M2M device routing information, such as the last serving BS ID, Cell ID, last serving PDSN information etc. in the visited network is also notified to the HAAA. M2M device reachability information (e.g., UATI, Null/Inactive state info, etc.) may also be notified to the HAAA. As an example, Accounting Request/Response (Stop) message can be used for the purpose of notifying the HAAA of various parameters/information specific to the M2M device.

[00156] At 1203, if an interface is defined between the PDSN in the visited network and the M2M-IWF in the home network, Status Update Request/Response message can be used by the PDSN to notify the M2M-r F of the release of the IP address assigned to the M2M device. Other M2M device specific information, such as routing and reachability information etc. may also be notified to the M2M-r F.

[00157] At 1204, M2M-IWF in the home network may inform the M2M Server of the release of the IP address assigned to the M2M device.

[00158] At 1205, M2M Server wants to initiate communications with the M2M device. If it does not know the IP address information for the M2M device or identifies a need to recover IP connectivity; M2M Server queries the M2M IWF in the home network for the IP address of the M2M device by sending a Trigger Request message. Trigger Request message includes M2M device External Identifier. Peer- application specific information (such as the IP address/Port information etc.) may also be included in the Trigger Request message.

[00159] At 1206, M2M-IWF may authorize the Trigger Request message based on operator policy. If M2M-r F cannot derive M2M device Internal Identifier from the External Identifier received in the Trigger Request message, it queries HAAA for such information. M2M-r F queries the HAAA for M2M device IP address also if such information is not available in the local cache. As the M2M device is in Null/Inactive state, an IP address is not available for the M2M device. In this case the HAAA returns the Internal Identifier (MIN/IMSI) and routing/reachability, subscription, configuration information etc. for the M2M device via Device Info Ack message to the M2M-IWF. Based on such information, M2M-r F can attempt to deliver a device trigger to the M2M device.

[00160] At 1207, if the M2M-IWF determines that it can attempt to deliver device trigger to the M2M device in the visited network, it may respond with Trigger

Acknowledgment message to the M2M Server to prevent M2M Server sending repeated trigger requests. Based on operator policy and capabilities of the M2M device, M2M-r F selects trigger delivery mechanism e.g., delivery of device trigger via SMS or directly though cdma2000 network nodes e.g., the RAN or the PDSN etc. This proposal discusses mechanisms for the delivery of device trigger directly via the RAN and via the PDSN. M2M-IWF uses routing/ reachability information for the M2M device received from the HAAA in Step-6, and information received in the Trigger Request message (Step-5) e.g., application specific information etc. to construct a Trigger M2M Device message.

Alternative-l:

[00161] At 1208, if device trigger mechanism via RAN is chosen: M2M-IWF in the home network forwards Trigger M2M Device-RAN Request message to the RAN in the visited network. The message includes peer-application specific information also if received from the M2M Sever. The RAN-node to contact is identified from the routing information received from the HAAA. Alternative-2: [00162] At 1209, if device trigger mechanism via PDSN is chosen: M2M-IWF in the home network forwards Trigger M2M Device-PDSN Request message to the PDSN in the visited network. The message includes peer- application specific information also if received from the M2M Server. The PDSN-node to contact is identified from the routing information received from the HAAA.

[00163] At 1209a, PDSN forwards Trigger M2M Device Request message to the

PCF via a pre-established Common-AlO connection. The PDSN identifies the PCF to interact with based on the routing information received from the HAAA.

[00164] At 1210, PCF interacts with the RAN for Paging the M2M device. Device trigger specific information e.g., peer- application specific information is also passed to the M2M device via the Page message.

[00165] At 1211, for Alternative- 1: RAN in the visited network acknowledges device trigger message by returning Trigger M2M Device-RAN Response message to the M2M- r F in the home network.

[00166] At 1212, for Alternative-2: RAN/PCF acknowledges device trigger message by returning Trigger M2M Device Response message to the PDSN.

[00167] At 1212a, PDSN in the visited network returns Trigger M2M Device-PDSN

Response message to the M2M-IWF in the home network.

[00168] At 1213, based on the information in the trigger message, the M2M device and the visited cdma2000 network perform "M2M Session Establishment" procedures as previously described. M2M device performs authentication and authorization with the HAAA via the VAAA, and an IP address is assigned to the M2M device. IP address and M2M device routing and reachability information etc. are passed to the HAAA via the VAAA; and possibility to the M2M-r F also in the home network.

[00169] At 1214, HAAA returns M2M device IP address etc. to the M2M-IWF in the home network.

[00170] At 1215, M2M-rWF passes M2M device IP address and other information as needed to the M2M Server.

[00171] At 1216, user plane communications can be initiated either by the M2M device or by the M2M Server. The call flow illustration above shows M2M device initiating user plane communications. M2M device sends user plane packets addressed to the peer- application entity in the M2M Server or elsewhere in the network over the established PPP/Link Layer connection with the PDSN in the visited network. For (Proxy)MIP type of services, an HA/LMA is also in the path of the IP traffic between the M2M device and the peer- application.

[00172] At 1217, end-to-End IP communications between the M2M device and the peer- application entity continues.

11. Fourth Exemplary Embodiment - Device Triggering in (Non-roaming)

Null/Inactive mode (Option -2)

[00173] The device trigger procedure illustrated below is applicable for the roaming scenario. This solution (Option - 2) assumes that there is roaming relationship between the Visited Network and the Home Network. The level of trust/business relationship that is needed between the Visited and the Home networks to allow sharing of routing and reachability information of roaming M2M devices (e.g., last serving BS ID, Cell ID, last serving PDSN ID, UATI information etc.) does not exist; hence such routing and reachability information is not shared by the visited AAA with the home AAA.

[00174] When M2M device powers down or releases the packet data session, the

PDSN notifies the AAA in the home network (HAAA) via the AAA in the visited network (VAAA) of the release of the IP address assigned to the M2M device. Routing and reachability information for the last known location of the M2M device is informed to the VAAA but not passed to the HAAA. VAAA informs the HAAA of the identity of the serving M2M-r F in the visited network though. In addition, M2M-r F in the home network and M2M Server may also be informed of the release of the IP address assigned to the M2M device by the serving PDSN.

[00175] When M2M Server wants to initiate communications with the M2M device, device trigger procedures are similar to those described in Section 2.3 (M2M Device in Null/Inactive State - Non-Roaming). M2M Server sends Trigger Request message which may contain application specific information also, to the M2M-IWF in the home network. On query by the M2M-rWF, HAAA returns the Internal Identifier (MIN/IMSI)

configuration, subscription information etc. of the M2M device to the M2M-r F in the home network. Identity of the serving M2M-r F in the visited network is also passed to the home M2M-IWF. M2M-IWF in the home network forwards Device Trigger Request to the M2M-IWF in the visited network, along with configuration, subscription and application specific information etc.

[00176] On receiving Device Trigger Request from the home M2M-IWF, the visited M2M-IWF queries the VAAA for device routing/reachability information if such information is not available in the local cache. Routing information for the M2M device points to the cdma2000 network entities (e.g., last serving BS ID, Cell ID, last serving PDSN ID etc.) that are in the visited network through with the M2M device is reachable. Visited M2M-IWF can communicate with such cdma2000 network entities; and depending on the trigger delivery method forwards trigger request to the RAN or to the PDSN in the visited network.

[00177] On being triggered, depending on the information in the trigger request (e.g., communicated to the M2M device via application specific information), the M2M device initiates establishment of a packet data session with the cdma2000 network. Information about the IP address assigned to the M2M device is forwarded to the M2M Server also. In this example illustration, the M2M server initiates communications with M2M device based on the IP address of the M2M device received from the home Μ2Μ-ΓννΤ.

[00178] With reference to FIG. 13, at 1501, M2M device is roaming in a visited operator network. It powers down and/or releases packet data session. Packet data session (e.g., HRPD session, PPP/Link Layer connection, A8/9 and AlO/11 connections etc.) and the IP address assigned to the M2M device are released.

[00179] At 1502, the PDSN in the visited network notifies the Visited AAA of the release of the IP address assigned to the M2M device. M2M device routing information, such as the last serving BS ID, Cell ID, serving PDSN information etc. in the visited network is also notified to the VAAA. M2M device reachability information (e.g., UATI,

Null/Inactive state info, etc.) may also be notified to the VAAA. As an example, Accounting Request/Response (Stop) message can be used for the purpose of notifying the VAAA of various parameters/information specific to the M2M device.

[00180] At 15022a, Visited AAA notifies the Home AAA of the release of the IP address assigned to the M2M device. Identity of the serving M2M-IWF in the visited network is also passed to the HAAA. [00181] At 1503, if an interface is defined between the PDSN and the M2M-IWF,

Status Update Request/Response message can be used by the PDSN to notify the M2M-IWF in the visited network of the release of the IP address assigned to the M2M device, and then to the M2M-IWF in the home network also. Other M2M device specific information such as routing and reachability information etc. of the M2M device may also be notified to the M2M-IWF in the visited network. However, such information is not passed to the M2M- r F in the home network.

[00182] At 1504, M2M-rWF in the home network may inform the M2M Server of the release of the IP address assigned to the M2M device.

[00183] At 1505, M2M Server wants to initiate communications with the M2M device. If it does not know the IP address information for the M2M device or identifies the need to recover IP connectivity; M2M Server queries the M2M IWF in the home network for the IP address of the M2M device by sending a Trigger Request message. Trigger Request message includes M2M device External Identifier. Peer- application specific information (such as the IP address/Port information etc.) may also be included in the Trigger Request message.

[00184] At 1506, M2M-r F in the home network may authorize the Trigger Request message based on operator policy. If M2M-r F cannot derive M2M device Internal Identifier from the External Identifier received in the Trigger Request message, it queries HAAA for such information. M2M-IWF queries the HAAA for M2M device IP address also if such information is not available in the local cache. As the M2M device is in Null/Inactive state, an IP address is not available for the M2M device. In this case the HAAA returns the Internal Identifier (MIN/IMSI) and subscription, configuration information etc. for the M2M device via Device Info Ack message to the M2M-r F in the home network. Identity of the M2M-IWF in the visited network is also made available to the home M2M-r F. Based on such information, M2M-r F in the home network can attempt to deliver the device trigger to the M2M-IWF in the visited network.

[00185] At 1507, if the M2M-IWF in the home network determines that it can attempt to deliver device trigger to the M2M device via the M2M-IWF in the visited network, it may respond with Trigger Acknowledgment message to the M2M Server to prevent M2M Server sending repeated trigger requests. [00186] At 1508, M2M-IWF in the home network forwards Device Trigger request that contains M2M device subscription, configuration, application specific information etc. to the M2M-IWF in the visited network.

[00187] At 1509, M2M-IWF in the visited network queries VAAA for M2M device IP address if such information is not available in the local cache. As the M2M device is in Null/Inactive state, an IP address is not available for the M2M device. In this case the VAAA returns routing/reachability information for the M2M Device via Device Info Ack message to the visited M2M-r F. Based on such information, M2M-IWF in the visited network can attempt to deliver device trigger to the M2M device.

[00188] Based on operator policy and capabilities of the M2M device, Μ2Μ-ΓΛΤ in the visited network selects trigger delivery mechanism e.g., delivery of device trigger via SMS or directly though cdma2000 network nodes e.g., the RAN or the PDSN etc. This proposal discusses mechanisms for the delivery of device trigger directly via the RAN and via the PDSN. M2M-IWF in the visited network uses routing/ reachability information for the M2M device received from the VAAA in Step-9, and information received in the Device Trigger Request message (Step-8) e.g., application specific information etc. to construct a Trigger M2M Device message.

Alternative-l:

[00189] At 1510, if device trigger mechanism via RAN is chosen: M2M-IWF in the visited network forwards Trigger M2M Device-RAN Request message to the RAN in the visited network. The message includes peer-application specific information also if received from the home network M2M-IWF. The RAN-node to contact is identified from the routing information received from the VAAA.

Alternative-2:

[00190] At 1511, if device trigger mechanism via PDSN is chosen: M2M-rWF in the visited network forwards Trigger M2M Device-PDSN Request message to the PDSN in the visited network. The message includes peer-application specific information also if received from the home network M2M-IWF. The PDSN-node to contact is identified from the routing information received from the VAAA. [00191] At 151 la, PDSN forwards Trigger M2M Device Request message to the

PCF via a pre-established Common-AlO connection. The PDSN identifies the PCF to interact with based on the routing information received from the VAAA.

[00192] At 1512, PCF interacts with the RAN for Paging the M2M device. Device trigger specific information e.g., peer- application specific information is also passed to the M2M device via the Page message.

[00193] At 1513, for Alternative- 1: RAN in the visited network acknowledges device trigger message by returning Trigger M2M Device-RAN Response message to the M2M- r F in the visited network.

[00194] At 1514, for Alternative-2: RAN/PCF acknowledges device trigger message by returning Trigger M2M Device Response message to the PDSN.

[00195] At 1514a, PDSN in the visited network returns Trigger M2M Device-PDSN

Response message to the M2M-IWF in the visited network.

[00196] At 1515, M2M-r F in the visited network returns Device Trigger Response message to the M2M-r F in the home network.

[00197] At 1516, based on the information in the trigger message, the M2M device and the visited cdma2000 network perform "M2M Session Establishment" procedures as previously described. M2M device performs authentication and authorization with the HAAA via the VAAA, and an IP address is assigned to the M2M device.

[00198] IP address and M2M device routing and reachability information etc. are passed to the VAAA and possibility to the M2M-r F also in the visited network. VAAA passes the IP address assigned to the M2M device and the visited M2M-r F identity to the HAAA. Visited M2M-rWF may notify the M2M-IWF in the home network about the IP address assigned to the M2M device.

[00199] At 1517, HAAA returns M2M device IP address etc. to the M2M-IWF in the home network.

[00200] At 1518, M2M-rWF in the home network passes M2M device IP address and other information as needed to the M2M Server.

[00201] At 1519, user plane communications can be initiated either by the M2M device or by the M2M Server. The call flow illustration above shows M2M Server initiating user plane communications. M2M Server sends user plane packets addressed to the M2M device over the established PPP/Link Layer connection with the PDSN in the visited network. For (Proxy)MIP type of services, an HA/LMA is also in the path of the IP traffic between the M2M Server and the M2M device.

[00202] At 1520, end-to-End IP communications between the peer- application entity in the M2M Server and the M2M device continues.

12. Device Triggering (Roaming) - [Option -1]: M2M Device in Null/Inactive State

[00203] With reference to FIG. 14, messages exchanged in a device trigger procedure 1300, applicable for the roaming scenario, are now disclosed.

[00204] This solution, called [Option - 1], assumes a roaming relationship between the Visited Network and the Home Network operators. The level of trust/business relationship that is needed between the Visited and the Home network operators to allow for the sharing of the reachability information of roaming M2M devices (e.g., last serving PDSN ID, Common-AlO ID, BS ID, etc.) with the entities in the other operator network does not exist. Hence such reachability information is not shared by the Visited network entities with the entities in the Home network.

[00205] When M2M Packet Data Session transitions to Null/Inactive state, the PDSN notifies the AAA in the Home network (HAAA) via the AAA in the Visited network (VAAA) of the release of the IP address assigned to the M2M device. Reachability information relating to the last known location of the M2M device (last serving PDSN ID, Common-AlO ID, and optionally last serving BS ID) is notified to the VAAA but NOT passed to the HAAA. The VAAA informs the HAAA of the identity of the serving M2M- IWF in the Visited network though (V-M2M-IWF ID).

[00206] When M2M Server wants to initiate communications with an M2M device and it does not know the IP address assigned to the M2M device or identifies a need to recover IP connectivity, e.g., M2M device not responding because the IP address in not valid any longer; it first determines the M2M-r F in the Home domain of the M2M device that server the M2M device (see Section 2.1). The M2M Server then queries the M2M-r F for the IP address assigned to the M2M device, using procedures similar to those described in Section 2.3 (M2M Device in Null/Inactive State - Non-Roaming). [00207] M2M Server sends Trigger Request message which may contain application specific information also, to the M2M-IWF in the Home network for the M2M device. On query by the M2M-IWF, HAAA returns the Internal Identifier (Packet Data Access Subscription Identifier) and configuration, subscription information etc. for the M2M device to the M2M-IWF in the Home network. The identity of the serving M2M-IWF in the Visited network (V-M2M-IWF ID) is also passed to the Home M2M-IWF. M2M-IWF in the Home network forwards Device Trigger Request to the M2M-IWF in the Visited network, along with configuration, subscription and application specific information etc.

[00208] On receiving Device Trigger Request from the Home M2M-IWF, the Visited M2M-IWF queries the VAAA for device reachability information if such information is not available in the local cache. Reachability information for the M2M device points to the cdma2000 network entities (e.g., last serving PDSN ID, Common-AlO ID, BS ID, etc.) in the Visited network through with the M2M device is reachable. Visited M2M-IWF can communicate with such cdma2000 network entities. Depending on the trigger delivery method that is chosen, the M2M-IWF in the Visited network forwards trigger request to the RAN or to the PDSN in the Visited network.

[00209] On being triggered, depending on the information in the trigger request (e.g., communicated to the M2M device via application specific information), the M2M device may initiate establishment of a packet data session with the cdma2000 network. On the establishment of the M2M Packet Data Session, information about the IP address assigned to the M2M device is forwarded to the M2M Server also. The M2M Server or the M2M device can use the device IP address to initiate communications with the peer entity over the established packet data session. In this example illustration, the M2M Server initiates communications with M2M device based on the IP address of the M2M device received from the M2M-IWF in the Home network. For MIP/Proxy MIP type of services, an HA/LMA is also in the path of the IP traffic between the M2M device and the peer- application.

[00210] As a pre-condition to this procedure, M2M Packet Data Session is in

Null/Inactive state. HRPD session and the PPP/Link Layer connection have been released. The last serving RAN, however maintains M2M HRPD Session Context for the M2M device. M2M HRPD Session Context minimally maintains association between M2M device Internal ID, device UATI, the last serving PDSN ID.

[00211] When M2M Packet Data Session for the M2M device transitions to

Null/Inactive state, the PDSN notifies the VAAA of the release of the IP address assigned to the M2M device. The VAAA maintains reachability information for the M2M device, e.g., last serving PDSN ID, Common-AlO ID, and optionally last serving BS ID though.

[00212] The Common- A10 Connection between the RAN/PCF and the PDSN is established at system start-up and maintained for the duration of system operation. The Common-AlO Connection is used for the purpose of signaling between the PDSN and the RAN/PCF.

[00213] The procedures for establishing such Common-AlO Connection between the

[00214] The VAAA notifies the HAAA of the release of the IP address assigned to the M2M device. The HAAA, however, maintains information about the M2M-IWF in the Visited network (V-M2M-RVF ID) through which the M2M device is reachable.

[00215] If an interface is defined between the PDSN and the M2M-IWF in the Visited network, the PDSN notifies the M2M-r F in the Visited network of the release of the IP address assigned to the M2M device. The M2M-r F in the Visited network, may maintain reachability information for the M2M device also e.g., the last serving PDSN ID, Common- AlO ID, and optionally the last serving BS ID. In this case, the PDSN sends device reachability information also to the M2M-IWF in the Visited network.

[00216] At 1301, M2M Server wants to initiate communications with an M2M device. If it does not know the IP address assigned to the M2M device or identifies the need to recover IP connectivity; M2M Server queries the M2M IWF in the Home domain for the M2M device for the IP address of the M2M device by sending a Trigger Request message. Trigger Request message includes M2M device External Identifier. Peer- application specific information (such as the IP address/Port information etc.) may also be included in the Trigger Request message.

[00217] At 1302, M2M-rWF in the Home network may authorize the Trigger Request message based on operator policy. If M2M-r F cannot derive M2M device Internal Identifier from the External Identifier received in the Trigger Request message, it queries HAAA for such information. M2M-IWF queries the HAAA for M2M device IP address also if such information is not available in the local cache. As the M2M device is in Null/Inactive state and is reachable by an M2M-r F in the Visited Network, the HAAA returns the Internal Identifier and subscription, configuration information etc. for the M2M device via Device Info Ack message to the M2M-r F in the Home network. The identity of the M2M- r F in the Visited network that is assigned to the M2M device is also made available to the M2M-IWF in the Home network. Based on such information, M2M-r F in the Home network can attempt to deliver the device trigger to the M2M-r F in the Visited network.

[00218] At 1303, if the M2M-IWF in the Home network determines that it can attempt to deliver device trigger to the M2M device via the M2M-r F in the Visited network, it may respond with Trigger Acknowledgment message to the M2M Server to prevent the M2M Server from sending repeated trigger requests.

[00219] At 1304, M2M-r F in the Home network forwards Device Trigger request that contains M2M device subscription, configuration, application specific information etc. to the M2M-IWF in the Visited network

[00220] At 1305, M2M-rWF in the Visited network may also authorize the Trigger

Request message based on operator policy. The M2M-IWF in the Visited network queries the VAAA for M2M device IP address if such information is not available in the local cache. As the M2M device is in Null/Inactive state, an IP address is not available for the M2M device. In this case the VAAA returns reachability information for the M2M Device via Device Info Ack message to the visited M2M-r F. Based on such information, M2M- r F in the Visited network can attempt to deliver device trigger to the M2M device.

[00221] Based on operator policy and capabilities of the M2M device, M2M-r F in the Visited network selects trigger delivery mechanism e.g., delivery of device trigger via SMS or directly though cdma2000 network nodes e.g., the RAN or the PDSN etc. This document discusses mechanisms for the delivery of device trigger directly via the RAN or via the PDSN. M2M-IWF in the Visited network uses reachability information for the M2M device received from the VAAA in Step-5, and information received in the Device Trigger Request message (Step-4) from the M2M-r F in the Home network e.g., application specific information etc. to construct a Trigger M2M Device message. Alternative- 1:

[00222] At 1306, if device trigger mechanism via RAN is chosen: M2M-IWF in the

Visited network forwards Trigger M2M Device-RAN Request message to the RAN in the Visited network. The message includes peer- application specific information also if received from the M2M-IWF in the Home network. The RAN-node to contact is identified from the reachability information (last serving BS ID) received from the VAAA in Step-5.

Alternative-2:

[00223] At 1307, if device trigger mechanism via PDSN is chosen: M2M-IWF in the

Visited network forwards Trigger M2M Device-PDSN Request message to the PDSN in the Visited network. The message includes peer- application specific information also if received from the M2M-IWF in the Home network. The PDSN-node to contact is identified from the reachability information (last serving PDSN ID) received from the VAAA in Step5.

[00224] At 1307a, PDSN forwards Trigger M2M Device Request message to the

PCF via a pre-established Common-AlO connection. The PDSN identifies the PCF to interact with based on the reachability information (Common- A10 ID) received from the VAAA in Step-5.

[00225] At 1308, PCF interacts with the RAN for Paging the M2M device. The RAN determines the identity of the M2M device to be Paged (device UATI) from the M2M

HRPD Context information indexed by the Internal ID of the M2M device. Device trigger specific information e.g., peer- application specific information is also passed to the M2M device via the Page message.

[00226] At 1309, for Alternative- 1: RAN in the Visited network acknowledges device trigger message by returning Trigger M2M Device-RAN Response message to the M2M- r F in the Visited network.

[00227] At 1310, for Alternative-2: RAN/PCF acknowledges device trigger message by returning Trigger M2M Device Response message to the PDSN over the Common-AlO connection.

[00228] At 1310a, PDSN in the Visited network returns Trigger M2M Device-PDSN

Response message to the M2M-IWF in the Visited network. [00229] At 1311, M2M-IWF in the Visited network returns Device Trigger Response message to the M2M-IWF in the Home network.

[00230] At 1312, as previously discussed; the M2M device initiates HRPD session establishment procedures with the RAN and M2M HRPD Session Context at the RAN is updated. PPP/Link Layer connection between the M2M device and the PDSN is established. The M2M device performs authentication and authorization with the AAA in the Home network (HAAA) via the PDSN and the AAA in the Visited network. An IP address is assigned to the M2M device.

[00231] On successful authorization, information such as M2M Subscriber Profile, M2M configuration information etc. is available at the PDSN. The PDSN passes relevant subscription parameters to the RAN as per known procedures. The PDSN passes M2M device Identity (username® realm information in the form of NAI construct) and the identity of the serving PDSN (PSDN ID) also to the RAN/PCF.

[00232] At 1313, as a part of the Authentication and Authorization procedures in Step-1312. or as a separate message, the PDSN notifies the VAAA of the IP address assigned to the M2M device. In addition, M2M device reachability information, such as the identity of the serving PDSN (PDSN ID) and the identity of the Common- A10 connection associated with the serving RAN/PCF (Common-AlO ID) are also notified to the VAAA. The identity of the Base Station (BS ID) serving the M2M device may also be notified to the VAAA. As an example, Accounting Request/Response (Start) message can be used for the purpose of notifying the VAAA of various parameters specific to the M2M Device.

[00233] At 1314, the Visited AAA notifies the Home AAA of the IP address assigned to the M2M device and the identity of the M2M-IWF in the Visited network (V-M2M-rWF ID) that is assigned to serve the M2M device. An M2M-r F is assigned to serve the M2M device during authentication and authorization procedures in Step- 12. The HAAA maintains the association between the M2M device ID, IP address assigned to the M2M device and the identity of the M2M rWF in the Visited network that serves the M2M device (V-M2M-IWF ID).

[00234] At 1315, if an interface is defined between the PDSN and the M2M-IWF in the Visited network, Status Update Request/Response message can be used by the PDSN to notify the M2M-r F in the Visited network of the M2M device Identifier and the IP address assigned to the M2M device. Other M2M device specific information, such as M2M device reachability information (serving PDSN ID, Common-AlO ID), M2M configuration information etc. are also notified to the M2M-IWF in the Visited network. The identity of the Base Station (BS ID) serving the M2M device may also be notified to the M2M-IWF in the Visited network. The PDSN learns the identity of the serving M2M-r F in the Visited Network from the M2M configuration information in received from the HAAA in Step-12.

[00235] At 1316, any time after Step- 1314, HAAA returns M2M device IP address etc. to the M2M-IWF in the Home network.

[00236] At 1317, M2M-rWF in the Home network passes M2M device IP address and other information as needed to the M2M Server.

[00237] At 1318, user plane communications can be initiated either by the M2M device or by the M2M Server. The call flow illustration here shows M2M Server initiating user plane communications. M2M Server sends user plane packets addressed to the M2M device over the established PPP/Link Layer connection with the PDSN in the Visited network. For MIP/Proxy MIP type of services, an HA/LMA is also in the path of the IP traffic between the M2M Server and the M2M device.

[00238] At 1319, end-to-End IP communications between the peer- application entity in the M2M Server and the M2M device continues. 13. Device Triggering (Roaming) - [Option -2]: M2M Device in Null/Inactive State

[00239] With reference to FIG. 15, messages exchanged in a device trigger procedure

1400, applicable for the roaming scenario, are now disclosed.

[00240] This solution [Option-2] assumes a roaming relationship between the Visited

Network and the Home Network operators. There is an additional level of trust/business relationship between the Home and Visited network operators, such that the Visited network operator allows the sharing of the reachability information of the M2M device in the Visited network (e.g., last serving PDSN ID, Common-AlO ID, BS ID, etc.) with the entities in the Home network.

[00241] When the M2M Packet Data Session transitions to Null/Inactive state, the PDSN notifies the AAA in the Home network (HAAA) via the AAA in the Visited network (VAAA) of the release of the IP address assigned to the M2M device. Reachability information relating to the last known location of the M2M device in the Visited network is also notified to the HAAA.

[00242] When M2M Server wants to initiate communications with an M2M device and it does not know the IP address assigned to the M2M device or identifies a need to recover IP connectivity, e.g., M2M device is not responding because the IP address is not valid any longer; it first determines the M2M-IWF in the Home domain of the M2M device that serves the M2M device (see Section 2.1). The M2M server then queries the M2M-IWF for the IP address assigned to the M2M device, using procedures similar to those described in Section 2.3 (M2M Device in Null/Inactive State - Non-Roaming). The M2M Server sends Trigger Request message which may contain application specific information also, to the M2M-IWF in the Home network of the M2M device. On query by the M2M-IWF, HAAA returns the Internal Identifier (Packet Data Access Subscription Identifier) and reachability, configuration, subscription information etc. of the M2M device to the M2M- IWF. Reachability information for the M2M device points to the cdma2000 network entities (e.g., last serving PDSN ID, Common-AlO ID, last serving BS ID etc.) in the Visited network through which the M2M device is reachable. Since there is trust/business relationship between the Home and Visited network operators, the M2M-IWF in the Home network can communicate directly with the cdma2000 network entities in the Visited network. Depending on the trigger delivery method that is chosen, the M2M-IWF in the Home network forwards device trigger request to the RAN or to the PDSN in the Visited network.

[00243] On being triggered, depending on the information in the trigger request (e.g., communicated to the M2M device via application specific information), the M2M device may initiate establishment of a packet data session with the cdma2000 network. On the establishment of the M2M Packet Data Session, information about the IP address assigned to the M2M device is forwarded to the M2M Server also. The M2M Server or the M2M device can use the device IP address to initiate communications with the peer entity over the established packet data session. In this example illustration, the M2M device initiates communications with the peer- application entity identified from the information received via the application specific information in the trigger message. Else, the identity of the peer- application entity can be determined via user plane procedures with the M2M server. For ΜΙΡ/Proxy MIP type of services, an HA/LMA is also in the path of the IP traffic between the M2M device and the peer- application.

[00244] As a pre-condition to this procedure, M2M Packet Data Session is in

[00245] When M2M Packet Data Session for the M2M device transitions to

Null/Inactive state, the PDSN notifies the HAAA via the VAAA of the release of the IP address assigned to the M2M device. The HAAA, however maintains reachability information for the M2M device, e.g., last serving PDSN ID, Common-AlO ID, and optionally last serving BS ID.

[00246] The Common- A10 Connection between the RAN/PCF and the PDSN is established at system start-up and maintained for the duration of system operation. The Common-AlO Connection is used for the purpose of signaling between the PDSN and the RAN/PCF.

[00247] The procedures for establishing such Common-AlO Connection between the

[00248] If an interface is defined between the PDSN and the M2M-IWF in the Home network, the PDSN notifies the M2M-r F in the Home network of the release of the IP address assigned to the M2M device. The M2M-r F in the Home network, may maintain reachability information for the M2M device also e.g., the last serving PDSN ID, Common- AlO ID, and optionally the last serving BS ID. In this case, the PDSN sends device reachability information also to the M2M-IWF in the Home network. In turn, the M2M-r F in the Home network may inform the M2M Server of the release of the IP address assigned to the M2M device.

[00249] At 1401, M2M Server wants to initiate communications with an M2M device. If it does not know the IP address assigned to the M2M device or identifies a need to recover IP connectivity; the M2M Server queries the M2M r F in the Home domain of the M2M device for the IP address assigned to the M2M device by sending a Trigger Request message. Trigger Request message includes M2M device External Identifier. Peer- application specific information (such as the IP address/Port information etc.) may also be included in the Trigger Request message.

[00250] At 1402, M2M-r F in the Home network may authorize the Trigger Request message based on operator policy. If M2M-r F cannot derive M2M device Internal

Identifier from the External Identifier received in the Trigger Request message, it queries HAAA for such information. M2M-IWF queries the HAAA for M2M device IP address also if such information is not available in the local cache. As the M2M device is in Null/Inactive state, an IP address is not available for the M2M device. In this case the HAAA returns the Internal Identifier and reachability, subscription, configuration information etc. for the M2M device via Device Info Ack message to the M2M-r F. Based on such information, M2M- rWE in the Home network can attempt to deliver a device trigger to the M2M device.

[00251] At 1403, if the M2M-IWF in the Home network determines that it can attempt to deliver device trigger to the M2M device in the Visited network, it may respond with Trigger Acknowledgment message to the M2M Server to prevent the M2M Server from sending repeated trigger requests.

[00252] Based on operator policy and the capabilities of the M2M device, M2M-IWF selects trigger delivery mechanism e.g., delivery of device trigger via SMS or directly though cdma2000 network nodes e.g., the RAN or the PDSN etc.

[00253] This document discusses mechanisms for the delivery of device trigger directly via the RAN or via the PDSN. M2M-r F in the Home network uses device reachability information received from the HAAA in Step-2, and information received in the Trigger Request message (Step-1) e.g., application specific information etc. to construct a Trigger M2M Device message.

Alternative-l:

[00254] At 1404, if device trigger mechanism via RAN is chosen: M2M-IWF in the

Home network forwards Trigger M2M Device-RAN Request message to the RAN in the Visited network. The message includes peer- application specific information also if received from the M2M Sever. The RAN-node to contact is identified from the reachability information (last serving BS ID) received from the HAAA in Step-2. Alternative-!:

[00255] At 1405, if device trigger mechanism via PDSN is chosen: M2M-IWF in the

Home network forwards Trigger M2M Device-PDSN Request message to the PDSN in the Visited network. The message includes peer- application specific information also if received from the M2M Server. The PDSN-node to contact is identified from the reachability information (last serving PDSN ID) received from the HAAA in Step-2.

[00256] At 1405a. PDSN forwards Trigger M2M Device Request message to the

PCF via a pre-established Common-AlO connection. The PDSN identifies the PCF to interact with based on the reachability information (Common- A10 ID) received from the HAAA in Setp-2.

[00257] At 1406, PCF interacts with the RAN for Paging the M2M device. The RAN determines the identity of the M2M device to be Paged (device UATI) from the M2M HRPD Context information indexed by the Internal ID of the M2M device. Device trigger specific information e.g., application specific information is also passed to the M2M device via the Page message.

[00258] At 1407, for Alternative- 1: RAN in the Visited network acknowledges the delivery of device trigger message by returning Trigger M2M Device-RAN Response message to the M2M-r F in the Home network.

[00259] At 1408, for Alternative-2: RAN/PCF acknowledges the delivery of device trigger message by returning Trigger M2M Device Response message to the PDSN over the Common-AlO connection.

[00260] At 1408a The PDSN in the Visited network returns Trigger M2M Device-

PDSN Response message to the M2M-IWF in the Home network.

[00261] At 1409, as previously disclosed; the M2M device initiates HRPD session establishment procedures with the RAN and M2M HRPD Session Context at the RAN is updated. PPP/Link Layer connection between the M2M device and the PDSN is established. The M2M device performs authentication and authorization with the AAA in the Home network (HAAA) via the PDSN and the AAA in the Visited network. An IP address is assigned to the M2M device. [00262] On successful authorization, information such as M2M Subscriber Profile,

M2M configuration information etc. is available at the PDSN. The PDSN passes relevant subscription parameters to the RAN as per known procedures. The PDSN passes M2M device Identity (username® realm information in the form of NAI construct) and the identity of the serving PDSN (PSDN ID) also to the RAN/PCF.

[00263] At 1410, as a part of the Authentication and Authorization procedures in

Step-1409. or as a separate message, the PDSN notifies the VAAA of the IP address assigned to the M2M device. In addition, M2M device reachability information, such as the identity of the serving PDSN (PDSN ID) and the identity of the Common- A10 connection associated with the serving RAN/PCF (Common-AlO ID) are also notified to the VAAA.

The identity of the Base Station (BS ID) serving the M2M device may also be notified to the VAAA. As an example, Accounting Request/Response (Start) message can be used for the purpose of notifying the VAAA of various parameters specific to the M2M Device.

[00264] At 1411, as there a high level of trust relationship between the Home network and the Visited network such that the two networks can communicate directly with the entities in the other network, the Visited AAA notifies the Home AAA of the IP Address assigned to the M2M device and the reachability information (serving PDSN ID, Common- A10 ID) in the Visited network for the M2M device. The identity of the Base Station (BS ID) serving the M2M device may also be notified to the HAAA.

[00265] At 1412, if an interface is defined between the PDSN and the M2M-IWF in the Home network, Status Update Request/Response message can be used by the PDSN to notify the M2M-r F in the Home network of the M2M device Identifier and the IP address assigned to the M2M device. Other M2M device specific information, such as M2M device reachability information (serving PDSN ID, Common-AlO ID), M2M configuration information etc. are also notified to the M2M-r F in the Home network. The identity of the Base Station (BS ID) serving the M2M device may also be notified to the Μ2Μ-ΓΛΤ in the Home network. The PDSN learns the identity of the serving M2M-r F in the Home network from the M2M configuration information received from the HAAA in Step-9.

[00266] At 1413, HAAA returns M2M device IP address etc. to the M2M-IWF in the Home network. The M2M-IWF, may maintain reachability information for the M2M device also e.g., last serving PDSN ID, Common-AlO ID, and optionally last serving BS ID. In this case, the HAAA sends device reachability information also to the M2M-r F.

[00267] At 1414, M2M-rWF in the Home network passes M2M device IP address and other information as needed to the M2M Server.

[00268] At 1415, user plane communications can be initiated either by the M2M device or by the M2M Server. The call flow illustration here shows M2M device initiating user plane communications. M2M device sends user plane packets addressed to the peer- application entity in the M2M Server or elsewhere in the network over the established PPP/Link Layer connection with the PDSN. The M2M device identifies the peer- application entity from the "application specific information" received via the Page message. Else, the identity of the peer- application entity can be determined via user plane procedures. For MlP/Proxy MIP type of services, an HA/LMA is also in the path of the IP traffic between the M2M device and the peer- application.

[00269] At 1416, end-to-End IP communications between the M2M device and the peer- application entity continues.

[00270] FIG. 16 is a flowchart representation of a process 1600 of facilitating M2M communications in a wireless network. At 1602, an M2M device identification information comprising a first machine identifier is received at a network- side entity. As discussed with respect to FIGs. 6 to 15, the device identification may be received from an M2M server that wishes to communicate with the M2M device. At 1604, a RAN based triggering operation is performed from the network- side entity on the M2M device indicated by the first machine identifier, using a second machine identifier that is different from the first machine identifier. The identifiers may be, e.g., IMSI or another identifier, as previously described. The RAN based triggering may use "Alternative 1" signal exchanges disclosed with respect to FIGs. 6 to 15.

[00271] FIG. 17 is a block diagram representation of an apparatus 1700 for facilitating M2M communications in a wireless network. The module 1702 is for receiving, at a network-side entity, a machine to machine (M2M) device identification information comprising a first machine identifier . The module 1704 is for performing, from the network- side entity, a radio access network (RAN) based triggering operation on an M2M device indicated by the first machine identifier using a second machine identifier that is different from the first machine identifier. The apparatus 1700 and modules 1702, 1704 may further be configured to implement some of the techniques and signal exchanged described in this document.

[00272] FIG. 18 is a flowchart representation of a process 1800 of facilitating M2M communications in a wireless network. At 1802, an M2M device identification that includes a first machine identifier is received. At 1804, a PDSN-based triggering operation using a second machine identifier that is different from the first machine identifier is performed. The PDSN-based triggering operation may be performed using the previously described "Alternative 2" signal exchanges with respect to FIGs. 6 to 15.

[00273] FIG. 19 is a block diagram representation of an apparatus 1900 for facilitating M2M communications in a wireless network. The module 1902 is for receiving machine to machine (M2M) device identification information comprising a first machine identifier. The module 1904 is for performing a packet data serving node (PDSN) based triggering operation using a second machine identifier, different from the first machine identifier. The apparatus 1900 and modules 1902, 1904 may further be configured to implement some of the techniques and signal exchanged described in this document.

[00274] In one aspect, the disclosed techniques may be used to establish an M2M session between a client machine and a server machine.

[00275] In another aspect, regardless of whether the client machine is in the active state (i.e., has an IP address assigned), in a dormant state (i.e., IP address is assigned but does not have an air interface channel assigned) or in the inactive state (i.e., no IP address is assigned and no air interface channel is assigned), the disclosed techniques may be used to respond to trigger requests from the server machine to preserver IP communication between the server machine and the client machine.

[00276] It will be appreciated that several embodiments and approaches for establishing M2M communication between an M2M application server and an M2M client device in a wireless network (home or visited) are disclosed. Different signal exchanges may be performed based on whether the M2M client device is in an Active, Dormant or Inactive state. It will also be appreciated that the disclosed techniques may use RAN access, such as a point coordination function, to communicate with the M2M device. Alternatively, a packet data service node may be used to establish M2M communication with the client device.

[00277] The disclosed and other embodiments, modules and the functional operations

(e. g., M2M communication request receiver, M2M device trigger controller, M2M trigger request transmitter, M2M trigger response receiver, M2M session establisher, etc.) described in this document can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in combinations of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more them. The term "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.

[00278] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[00279] The processes and logic flows described in this document can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[00280] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of non volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[00281] While this patent document contains many specifics, these should not be construed as limitations on the scope of an invention that is claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.

[00282] Only a few examples and implementations are disclosed. Variations, modifications, and enhancements to the described examples and implementations and other implementations can be made based on what is disclosed.

Claims

CLAIMS What is claimed is what is disclosed and illustrated, including:

1. A method for facilitating machine to machine communications in a wireless network, comprising:

receiving, at a network-side entity, a machine to machine (M2M) device

identification information comprising a first machine identifier; and

performing, from the network-side entity, a radio access network (RAN) based triggering operation on an M2M device indicated by the first machine identifier using a second machine identifier that is different from the first machine identifier.

2. The method of claim 1, wherein:

the first machine identifier is an external identifier that uniquely identifies the M2M device outside the wireless network but not inside the wireless network; and

the second machine identifier is an internal identifier that uniquely identifies the M2M device inside the wireless network but not outside the wireless network.

3. The method of claim 1, wherein the performing the RAN based triggering operation includes:

transmitting a device trigger request to a point coordination function (PCF) in a radio access network (RAN) that includes the M2M device.

4. The method of claim 3, further comprising:

receiving a response to the device trigger request; and

establishing an M2M communication session with the M2M device using information in the received response.

5. The method of claim 1, wherein when the M2M device is in not in an Active or Connected mode, then performing the RAN based triggering operation includes paging the M2M device.

6. An apparatus for facilitating machine to machine communications in a wireless network, comprising:

a machine to machine (M2M) communication request receiver that receives an M2M device identification information comprising a first machine identifier; and

an M2M device trigger controller that performs a radio access network (RAN) based triggering operation on an M2M device indicated by the first machine identifier using a second machine identifier that is different from the first machine identifier.

7. The apparatus of claim 6, wherein:

8. The apparatus of claim 6, wherein the M2M device trigger controller includes: an M2M trigger request transmitter that transmits a device trigger request to a point coordination function (PCF) in a radio access network (RAN) that includes the M2M device.

9. The apparatus of claim 8, further comprising:

an M2M trigger response receiver that receives a response to the device trigger request; and

an M2M session establisher that establishes an M2M communication session with the M2M device using information in the received response.

10. The apparatus of claim 6, wherein when the M2M device is in not in an Active or Connected mode, then the M2M device trigger controller causes a page to be sent to the M2M device.

11. A computer program product comprising a non-volatile, computer readable medium having code stored thereupon, the code, when executed, causing a processor to: receive, at a server in the wireless network, a machine to machine (M2M) device identification information comprising a first machine identifier; and

perform a radio access network (RAN) based triggering operation on an M2M device indicated by the first machine identifier using a second machine identifier that is different from the first machine identifier.

12. The computer program product of claim 11, wherein:

13. A wireless communications method, comprising:

receiving machine to machine (M2M) device identification information comprising a first machine identifier; and

performing a packet data serving node (PDSN) based triggering operation using a second machine identifier, different from the first machine identifier.

14. The method of claim 13, wherein:

15. The method of claim 13, wherein the performing the RAN based triggering operation includes:

transmitting a device trigger request to the PDSN that serves the M2M device.

16. The method of claim 15, further comprising:

receiving a response to the device trigger request; and establishing an M2M communication session with the M2M device using information in the received response.

17. An apparatus for facilitating machine to machine communications, comprising:

a receiver that receives machine to machine (M2M) device identification information comprising a first machine identifier; and

a processor that performs a packet data serving node (PDSN) based triggering operation using a second machine identifier, different from the first machine identifier.

18. The apparatus of claim 17, wherein:

19. The apparatus of claim 18, wherein the M2M device trigger controller includes:

an M2M trigger request transmitter that transmits a device trigger request to the PDSN that serves the M2M device.

20. The apparatus of claim 19, further comprising:

21. A computer program product comprising a non-volatile, computer readable medium having code stored thereupon, the code, when executed, causing a processor to: receive machine to machine (M2M) device identification information comprising a first machine identifier; and perform a packet data serving node (PDSN) based triggering operation using a second machine identifier, different from the first machine identifier.

22. A wireless communication network, comprising:

a machine-to-machine (M2M) client device;

an M2M server device; and

at least one network entity configured to facilitate communication between the M2M client device and the M2M server device when the client device is in an active state, a dormant state and an inactive state.