COMMUNICATION

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This patent document claims the benefit of U.S. Provisional Patent Application

No. 61/935,810, filed on February 4, 2014, and U.S. Provisional Patent Application No.

61/938,098, filed on February 10, 2014. The entire contents of the before-mentioned patent applications are incorporated by reference herein.

BACKGROUND

[0002] This document relates to machine-to-machine (M2M) communication.

[0003] M2M communication generally refers to communication between two different devices, which is not explicitly triggered by a user. Devices may perform M2M communication using wired or wireless connectivity. The communication is typically initiated by an application residing on one of the machine to gather or send information to a counterpart application on the other machine. Present day M2M communication techniques are not able to reap all the benefits offered by this technology due to the challenges faced in vertical integration of different layers of the protocol stack in typical M2M solution implementations.

SUMMARY

[0004] This document describes technologies, among other things, for facilitating communication between M2M devices. Using the disclosed techniques, communication packets can be routed between end points of the M2M communication. Using the disclosed techniques, policies related to routing of M2M packets can be enforced.

[0005] In one aspect, methods, systems and apparatus for facilitating M2M

communications include obtaining at a middle node destination information of an infrastructure node, selecting a network connection to support a routing of a request based on priority or policy information associated with the request and forwarding the request using the selected network connection.

[0006] In another aspect, methods, systems and apparatus for facilitating connectivity over a fixed network of a user equipment operable in a wireless network include sending a request from an infrastructure node to a middle node, performing, upon receiving a response from the middle node, a message exchange between the middle node and the infrastructure node, and performing, in the absence of the response from the middle node, a triggering event to provide a connection between the middle node and the infrastructure node.

[0007] These and other aspects, and their implementations and variations are set forth in the drawings, the description and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 depicts example wireless network architecture.

[0009] FIG. 2 is a block diagram of a radio device operable in a wireless network.

[0010] FIG. 3 shows an example M2M communication system.

[0011] FIG. 4 shows an example method of facilitating M2M communication.

[0012] FIG. 5 shows an example method of facilitating M2M communication.

[0013] FIG. 6 shows an example method of M2M communication performed at an infrastructure node.

[0014] FIG. 7 shows an example M2M communication system.

[0015] FIG. 8 shows examples of messages exchanged among various entities in an

M2M communication system.

[0016] Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

M2M communication generally refers to communication occurring between two devices over a network, in which the communication may not be started by an explicit user command at the time of the communication. The communication may be, e.g., pre-programmed by a user application to occur at a certain time, or upon occurrence of a certain event. Often, such communication occurs between a user device such as a utility meter or an electric light bulb or a user's mobile phone and a service provider's application server, e.g., a power utility provider's billing server, and so on.

[0018] Service Layer specifications developed by organizations such as oneM2M, ETSI

TC M2M, TIA TR-50 etc.(M2M SDOs) need to support efficient deployment of M2M Solutions by a wide range of market-focused (vertical) organizations. With the focus on the Service Layer, such organizations have been taking transport network-independent view of the end-to-end services. Yet, they need to make sure that their Service Layer specifications can be used effectively for interfacing with different types of transport networks. Such transport networks include but are not limited to the wireless and wireline networks being defined by industry standards organizations such as 3GPP, 3GPP2, IEEE, IETF and BBF.

[0019] Organizations developing transport network specifications have been providing enhancements and optimizations for their networks for supporting M2M services. Some transport network standards development committees, such as the 3 GPP and the 3GPP2 have taken a Service Layer independent approach while defining architectural enhancements for supporting M2M services. The 3GPP and the 3GPP2 have defined a set of M2M deployment scenarios also for facilitating different business models. Such deployment scenarios have evolved from the types of services offered and from the nature of interactions between different "players" in the M2M ecosystem.

[0020] While recognizing the role of different "players" in the E2E M2M ecosystem, it is important for M2M SDOs to provide the capability for such M2M industry players to be able to integrate their systems and services seamlessly, independent of the development platform and independent of the players they are interacting with. It should not be necessary for such players to know the protocol details and technical nuances of their interacting peers. It should also be possible for such players in the M2M ecosystem to be able to continue to support their existing deployments as they migrate their systems towards the relevant industry standards.

[0021] In M2M communications, the two endpoints between which communication occurs often are in different networks. In a typical application scenario, one endpoint may be a sensor or a utility box that may go offline for extended time periods and another endpoint may be an application server such as a utility billing server or an M2M server that may be deployed in a managed network. Data packets traveling back and forth between these two end points may be routable via various routing options. For example, one endpoint may have connectivity over a licensed spectrum (e.g., Long Term Evolution) or an unlicensed spectrum (e.g., Wi-Fi). When one endpoint is offline for extended time periods, e.g., days or weeks, the way in which packets were routed to that end point during a last communication session may not necessarily the way in which the packets can be routed in a current communication session. Furthermore, various routing options may incur various costs (e.g., bandwidth charges or power dissipation during transmission). [0022] This document discloses, inter alia, technologies that can be used to define and use policies for facilitating routing of data packets in M2M communications. This document also discloses techniques that can be used in practice to establish a network route used for data packet transfer during an M2M session.

[0023] In some embodiments, a communication services layer may include service functions that enable oneM2M Applications (via management, discovery and policy enforcement to name a few).

[0024] In some embodiments, a Common Services Entity (CSE) is an instantiation of

Common Services Functions (CSFs). Common Services Entity provides a subset of CSFs that could be used and shared by M2M Applications. Common Services Entity can utilize Underlying Network capabilities and can interact with each other to fulfil the service.

[0025] The Mca reference point designates communication flows between an Application

Entity (AE) and a Common Services Entity (CSE). The Mca reference point shall allow an AE to use the services provided by the CSE, and for the CSE to communicate with the AE.

[0026] The services offered via the Mca reference point are dependent on the

functionality supported by the CSE.

[0027] The Mcc reference point designates communication flows between two Common

Service Entities (CSEs). The Mcc reference point shall allow a CSE to use the services of another CSE in order to provide needed functionality. The services offered via the Mcc reference point are dependent on the functionality supported by the CSEs.

[0028] Network Services Entity (NSE). The Men reference point shall allow a CSE to use the services (other than transport and connectivity services) provided by the Underlying NSE in order to provide the needed functionality.

[0029] The services offered via the Men reference point are dependent on the services provided by the Underlying NSE

[0030] Examples of Nodes:

[0031] As functional objects, such Nodes are not necessarily mapped to actual physical objects, although they may be mapped to actual physical objects.

[0032] Application Service Node (ASN):

[0033] An Application Service Node is a Node that contains one Common Services

Entity and contains at least one Application Entity. [0034] An Application Service Node may communicate over a Mcc reference point with either:

[0035] - exactly one Middle Node;

[0036] - or exactly one Infrastructure Node.

[0037] Example of physical mapping: an Application Service Node could reside in an M2M Device.

[0038] Application Dedicated Node (ADN):

[0039] An Application Dedicated Node is a Node that contains at least one Application

Entity and does not contain a Common Services Entity. An Application Dedicated Node communicates with a Middle Node or an Infrastructure Node over an Mca reference point.

Example of physical mapping: an Application Dedicated Node could reside in a constrained M2M Device.

[0040] Middle Node (MN) :

[0041] A Middle Node is a Node that contains one Common Services Entity and contains zero or more Application Entities. A Middle Node communicates with: either an IN or another MN over Mcc, plus at least an IN / MN / ASN over Mcc, or an ADN over Mca.

[0042] Example of physical mapping: a Middle Node could reside in an M2M Gateway.

[0043] Infrastructure Node (IN):

[0044] An Infrastructure Node is a Node that contains one Common Services Entity and contains zero or more Application Entities. An Infrastructure Node communicates over respective Mcc reference points with: one or more Middle Node(s); and/or one or more

Application Service Node(s).

[0045] In addition, an Infrastructure Node communicates with one or more Application

Dedicated Nodes over respective Mca reference points.

[0046] Example of physical mapping: an Infrastructure Node could reside in an M2M

Server Infrastructure

[0047] Communication between different Nodes within an oneM2M Service Provider domain (SP) happens via the exchange of Request and Response messages between the CSEs at the peer Nodes. The AEs and the CSEs at oneM2M Nodes Register with the peer CSEs, thereby providing information that enable them to use M2M services. The routing of such information between the CSEs over the Mcc reference point needs to be transported between oneM2M Nodes via the transport services provided by the Underlying Networks. Routing of the CSE communication payload needs to be in conformance with the "policy" associated with the payload and the availability schedule of the Underlying Networks. Some example methods for the routing of the CSE communication payload between oneM2M Nodes include:

[0048] · Routing Upstream: from CSEs in the Field Domain towards the CSE in the

Infrastructure Domain

[0049] · Routing Downstream: from the CSE in the Infrastructure Domain towards the

CSEs in the Field Domain.

[0050] In addition, the following aspects, among others, have also been disclosed in the present specification:

[0051] · Recovery actions to be taken in the case of (consistent) failure in the routing of messages upstream.

[0052] · Recovery actions to be taken in the case of (consistent) failure in the routing of messages downstream. Such actions downstream include aspects such as "device triggering" for the Underlying Networks that support such device triggering capability.

[0053] FIG. 1 shows an example of a wireless communication network or system. This wireless communication network can include one or more base stations (BSs) 105, 107 and one or more wireless devices 110. A base station 105, 107 can transmit a signal on a forward link (FL), known as a downlink (DL) signal, to one or more wireless devices 110. A wireless device 110 can transmit a signal on a reverse link (RL), known as an uplink (UL) signal, to one or more base stations 105, 107. A wireless communication system can include one or more core networks 125 to control one or more base stations 105, 107. One or more base stations form a radio access network. A base station, due to its nature of providing radio access for a wireless device, either alone or in combination with one or more other base stations, can be referred to as an access point (AP), an access network (AN) or eNodeB. Examples of wireless communication systems that can implement the present techniques and systems include, among others, wireless communication systems based on Code division Multiple Access (CDMA) such as CDMA2000 lx, High Rate Packet Data (HRPD), Long-Term Evolution (LTE), Universal Terrestrial Radio Access Network (UTRAN), and Worldwide Interoperability for Microwave Access (WiMAX). The M2M communication techniques described in the present document could be implemented in the system depicted in FIG. 1. [0054] FIG. 2 shows an example of a radio transceiver station for implementing a wireless device, a base station or other wireless communication modules. Various examples of radio stations include base stations and wireless devices in FIG. 1. A radio station 205 such as a base station or a wireless device can include processor electronics 210 such as a microprocessor that implements methods such as one or more of the techniques presented in this document. A radio station 205 can include transceiver electronics 215 to send and/or receive wireless signals over one or more communication interfaces such as one or more antennas 220. A radio station 205 can include other communication interfaces for transmitting and receiving data. In some implementations, a radio station 205 can include one or more wired communication interfaces to communicate with a wired network. A radio station 205 can include one or more memories 225 configured to store information such as data and/or instructions. In some implementations, processor electronics 210 can include at least a portion of transceiver electronics 215 and a memory 225.

[0055] In some implementations, radio stations 205 can communicate with each other based on a CDMA or GSM based air interface. In some implementations, radio stations 205 can communicate with each other based on an orthogonal frequency-division multiplexing (OFDM) air interface which can include Orthogonal Frequency-Division Multiple Access (OFDMA) air interface. In some implementations, radio stations 205 can communicate using one or more wireless technologies such as CDMA2000 lx, HRPD, WiMAX, GSM, LTE, and Universal Mobile Telecommunications System (UMTS).

[0056] In some implementations, a radio station 205 may additionally be configured with a local area network connectivity such as a 802.11 (a/b/g/n) interface. The availability of such an interface may make it possible to communicatively couple the radio station 205 to the Internet via the local area connection. For example, a user may access services over her user equipment (UE) by connecting to the service via a wireless local area network connection (e.g., home Wi-Fi access) through a fixed broadband network such as a cable modem network or a DSL network. The radio transceiver station depicted in FIG. 2 could be used to implement the techniques disclosed in the present document.

[0057] Example M2M Deployment Scenarios

[0058] FIG. 3 illustrates an example deployment scenario 301 where two M2M Service

Providers, SP1 and SP2 provide services to M2M devices by the use of their respective Infrastructure Nodes, INI and IN2. Middle Node-1 (MNl) supports services for SPl only, whereas MN2 can host services for both SPl and SP2. End M2M Nodes, ADNl and ASN2 host applications provided by SPl and SP2 respectively.

[0059] AEs on ADNl register with MN1-CSE. ADNl-AEs and MNl-CSE communicate via the transport services provided by Underlying Network- 1 (ULNet-1). MNl-CSE is registered with IN1-CSE. MNl-CSE is registered with MN2-CSE as well.

[0060] AEs on ASN2 register with the CSE local on ASN2. ASN2-CSE is registered with MN2-CSE. ASN2-AEs and MN2-CSE communicate via the transport services provided by ULNet-5. MN2 provides services for both service providers, SPl and SP2. Hence MN2 hosts two CSEs, one for each SP domain. MNl-CSE is registered with MN2-CSE(SP1). Whereas, ASN2-CSE is registered with MN2-CSE(SP2). MN2-CSE(SP1) and MN2-CSE(SP2) are registered with INI -CSE and IN2-CSE respectively.

[0061] MNl-CSE can communicate with IN1-CSE via the transport services over

ULNet-2; and with MN2-CSE via transport services over ULNet-3. MN2-CSE communicates with the CSEs in INI and IN2 via services provided by ULNet-4. Communication between MN2-CSE and the CSEs in INI and IN2 is as per Mcc reference point via the transport services provided by Underlying Network ULNet-4. Some Underlying Networks may provide "device triggering" capability by providing an Interworking-IWF that is located at the edge of such Underlying Networks. Such device triggering related communication between the Interworking- IWF and the INI and IN2 Nodes is as per Men reference point, and has been disclosed in the presence document. In this example scenario, ULNet-4 can be a 3GPP LTE network. ULNet-2 in this example deployment scenario can be a network based on Wi-Fi technology.

[0062] Registration aspects

[0063] In order to communicate, different entities in the service layer may perform registration with peer entities.

[0064] Registration of an AE with a CSE results in the creation of an <application> resource at the registered-to CSE. Registration of a CSE with a peer CSE results in the creation of <remoteCSE> resource at both CSEs. Attribute "App-Inst-ID" within the <application> resource, and attribute "pointOfAccess" within <remoteCSE> resource help with the routing aspects for the forwarding of Request and Response messages between the CSEs. The "pointOfAccess" attribute in the <remoteCSE> resource is the address of the peer Node and can be in the form of an FQDN, IP address, a MAC address etc.

[0065] Representation for Underlying Networks

[0066] The CSEs communicate over Mcc reference point via the transport services provided by one-or-more Underlying Networks. Depending on the technology used by the Underlying Network, it can have characteristics that are unique in terms of data throughput rate, bit-error rate, end-to-end delay, associated costs etc. Such Underlying Network specific characteristics can be represented by a set of attributes. It may be noted that one "set" of such attributes specific to each Underlying Network connection is available at a oneM2M Node.

[0067] The Underlying Networks can have their respective availability "schedule" as well; such as a mobile communication network can be scheduled for cost-effective M2M communications during off-peak hours. Whereas an Underlying Network based on the WiFi technology may be used any time of the day, though with limited throughput and possibly higher bit-error rates (best effort basis). For high priority, guaranteed bit error rate services and emergency traffic, high throughput, guaranteed bit rate mobile communication could be used any time of the day, at higher costs though. Such Underlying Network schedule can be represented by "ULnetSchedule Ji]" attribute.

[0068] Example Routing Algorithm at oneM2M Nodes

[0069] The following is an example for the routing of a Request message from a CSE to another CSE over an Underlying Network. The set of attributes associated with the Underlying Networks assist in the routing decisions based on the "policy" associated with the Request message.

[0070] Two sets of procedures are discussed: Routing Upstream and Routing

Downstream. The difference between these two procedures relates to how "failure to forward the message" or "destination unreachable" situations may be handled. Such routing failures can occur due of factors such as stale or missing "pointOfAccess" (e.g., stale IP address or IP address not available) for the next hop CSE as in <remoteCSE> resource; stale or missing A/AAAA records in the DNS, failure to Register with the peer-CSE/expired CSE Registrations, bad configurations etc. [0071] As illustrated in the example deployment scenario in FIG. 3; one-or-more

Underlying Network connections may be available at a Node for the forwarding of a Request towards the target Receiver. For example, in order to forward a Request from MN1-CSE to the Receiver at IN1-CSE (to: parameter set to the /URI of IN1-CSE); MN1 has the option to choose from ULNet-2 or ULNet-3 Underlying Network connections. ULNet-2 and ULNet-3 offer different sets of "ULnetQoSCharacteristics_[i]" and different set of availability

"ULnetSchedule_[i]". The choice of which Underlying Network connection to choose could depend on factors such as the policies, priorities, suitable time etc. associated with the delivery of the Request message. Such policies will usually be configured within the MN1-CSF. For example, as per "policy" at MN1-CSE, messages with high priority/emergency (life threatening situations) need to be delivered over high quality, guaranteed bit rate connections with minimum delay. Routine (low priority) messages could wait for some time (e.g., based on the request expiration times associated with the Requests) and may be delivered on connections offering best-effort services. Some example algorithm for the routing of the messages at MN1 and INI are described below for the Upstream and the Downstream Routing scenarios respectively.

[0072] Routing Upstream at a Middle Node

[0073] The example flow chart 401 in FIG. 4 illustrates the forwarding of an UPDATE

Request from MN1-CSE, with the target being a resource in IN1-CSE. The following

assumptions and configurations are considered.

[0074] In this example, MN1-CSE has a Request pending to be forwarded towards IN1-

CSE. It is assumed that the request priority is "low," implying that best-effort, cost-effective connection is suitable for the forwarding of this Request. In some embodiments, a non- blocking messaging procedure is used, wherein the Receiver acknowledges the receipt of the Request immediately, without waiting for the final processing of the Request. The actual result of the processing of the Request can be conveyed to the Originator (MN1-CSE in this case) at a later time.

[0075] The "pointOfAccess" attribute in <remoteCSE> for IN1-CSE provides destination CSE address. A DNS query, if needed, may be used to resolve the Destination CSE URI to IP address.

[0076] Two Underlying Network connections are available at MN1 Node that can be used for the forwarding of the Request towards the INI Node (ULNet-2 and ULNet-3). ULNet-2 is a low-cost, low bit rate, best effort based connection. The availability schedule of this connection is persistent.

[0077] MN1-CSE has available to it a set of attributes relating to ULNet-2, that represent the characteristics for ULNet-2 connection.

[0078] At 409, attribute "ULnetworkID" for this connection is set to "ULNet-2".

[0079] "ULnetQoSCharacteristics_[i]" set of attributes are set to reflect it being a low- cost, low bit rate, best effort connection

[0080] The "ULnetScheldue_[i]" set of attributes indicate that it is a persistent connection.

[0081] Similarly, INI -CSE has available to it a set of attributes corresponding to ULNet-

2 with various attributes set as above.

[0082] ULNet-3 is a higher-cost, high throughput, guaranteed bit rate connection. Costs can be lower if used during off-peak hours, such as night time.

[0083] MN1-CSE has available to it a set of attributes (as in section xxx) relating to

ULNet-3, that represent the characteristics for ULNet-3 connection.

[0084] Attribute "ULnetworkID" for this connection is set to "ULNet-3".

[0085] "ULnetQoSCharacteristics_[i]" set of attributes are set to reflect it being a higher cost, high throughput, guaranteed bit rate connection.

[0086] The "ULnetScheldue[i]" set of attributes indicate that it is best used (for lower cost) during off-peak hours, such as 11pm to 5am

[0087] Similarly, MN2-CSE has available to it a set of attributes corresponding to

ULNet-3 with various attributes set as above.

[0088] Optionally, A/AAAA records for CSEs at INI , MN1 and MN2 are supported in the public DNS infrastructure. Such records consist of public domain names of CSEs at INI, MNl and MN2 and their corresponding IP addresses.

[0089] MNl -CSE is registered with INI -CSE, resulting in <remoteCSE> resources in the

CSEs at both MNl and INI . "pointOfAccess" attribute in the <remoteCSE> resource is the address of the peer CSE. Such addresses can be in the form of a FQDN, IP address, MAC address etc.

[0090] Similarly, MNl -CSE is registered with MN2-CSE, resulting in <remoteCSE> resources in the CSEs at both MNl and MN2 [0091] Under these assumptions and configurations, MNl-CSE needs to send a Request for UPDATing a resource at INl-CSE. "pointOfAccess" attribute in <remoteCSE> resource for INl-CSE at MNl-CSE provides the destination address for the routing decisions for the Request. If routable IP address for reaching INl-CSE is not available in "pointOfAccess" attribute, DNS query to public DNS infrastructure may be used, if such public DNS infrastructure is supported.

[0092] Based on the destination of the Request, MN1 determines two possible

Underlying Network connections available for the routing of the Request (407). As per the "priority" associated with the Request (e.g., "low" priority for UPDATing back-end records) and associated "policy" at MNl-CSE, ULNet-2 is selected (409). In this embodiment, ULNet-2 provides low cost, low bit rate, best effort connection. Likewise, if the Request pertains to an emergency/high priority life threatening event, likely a high bandwidth, guaranteed bandwidth connection such as ULNet-3 would be selected, despite higher associated costs. The Request is forwarded to IN-CSE over ULNet-2 (411) and the Originator (MNl-CSE) waits for the

Response.

[0093] Successful routing examples

[0094] MNl-CSE receives Response to the Request message within certain timeframe

(413). This marks successful routing of the Request message (419).

[0095] Routing failure examples

[0096] MNl-CSE fails to receive Response to the Request that has been forwarded via the transport service provided by ULNet-2. Likely causes could be bad ULNet-2 connection, non-routable or stale destination IP address, possibly due of DNS records not having been updated timely etc. Such scenario results in the routing entity at MN1 receiving ICMP:

Destination Unreachable message. Such information can be used at MN1 node for taking recovery actions. Recovery actions could include administrative actions such as bootstrapping MN1 for the re-registration of MN1 with INI, thereby refreshing the IP addresses, and corresponding refreshing of the attributes in <remoteCSE> resources, refreshing DNS entries etc. Catastrophic failures may require removing ULNet-2 from service, thereby causing all

Request/Responses to be transported over ULNet-3 etc.

[0097] Alternatively or additionally, more deterministic procedures can be devised for recognizing the failure in the delivery of Requests. One such method (415) could be based on parameters such as an ackt timer (acknowledgment timer) and mrtry (max-number-of retries). Such optional parameters can be part of mi (meta-information) for the Requests. Failure to receive Response within the pre-defined time-period determined by ackt timer results in retries for routing the Request, till the number of retries equal to mrtry count have been made (417). At that stage failure to route the Request can be declared and recovery actions initiated (421).

[0098] Examples of Routing Downstream at an Infrastructure Node

[0099] The example is based on a scenario for forwarding a Request from IN2-CSE, with the target being a resource in ASN2-CSE. Similar to the example depicted in FIG. 4, the following assumptions and configurations are considered:

[00100] IN2-CSE has a Request pending to be forwarded towards ASN2-CSE.

[00101] Request priority is "high," implying that guaranteed bit rate connection is preferred for the forwarding of this Request.

[00102] Non- blocking messaging procedure is used, wherein the Receiver acknowledges the receipt of the Request immediately, without waiting for the final processing of the Request. The actual result of the processing of the Request can be conveyed to the Originator (IN2-CSE in this case) at a later time.

[00103] Only one Underlying Network connection is available at IN2 Node (ULNet-4).

[00104] ULNet-4 Underlying Network is based on a technology that supports M2M

Device Triggering.

[00105] In addition, ULNet-4 offers guaranteed bit rate connection. Connection costs can vary with the time of the day, and day of the week etc. Costs can be lower if used during off peak hours, such as night time and during weekends.

[00106] IN2-CSE has available to it a set of attributes relating to ULNet-4, that represent the characteristics of ULNet-4 connection.

[00107] Attribute "ULnetworkID" for this connection is set to "ULNet-4."

[00108] "ULnetQoSCharacteristics_[i]" set of attributes are set to reflect it being a higher cost, high throughput, guaranteed bit rate connection.

[00109] The "ULnetScheldue_[i]" set of attributes indicate that it is best used (for lower cost) during off-peak hours, such as 11pm to 5am.

[00110] "ULpeerNodePointOfAccess_[i]" attribute(s) is applicable only at Infrastructure

Nodes (e.g., IN2 in this case) and for Underlying Networks that are based on technologies that support device triggering. For such Underlying Networks, this attribute is set to the address of the Interworking-IWF entity used for device triggering. For example, for Underlying Networks based on 3GPP and 3GPP2 technologies, this attribute is set to the address of MTC-IWF and M2M-IWF respectively (e.g., FQDN, IP address).

[00111] Similarly, the next hop MN2-CSE has available to it a set of attributes

corresponding to ULNet-4 with various attributes set as above.

[00112] "ULpeerNodePointOfAccessJi]" attribute(s) is not supported at MN2 though.

[00113] Optionally, A/AAAA records for CSEs at IN2, MN2 and ASN2 are supported in the public DNS infrastructure. Such records consist of public domain names of CSEs at IN2, MN2 and ASN2 and their corresponding IP addresses.

[00114] Optionally, A/AAAA records relating of "ULpeerNodePointOfAccess_[i]" are supported for Underlying Networks that support device triggering.

[00115] MN2-CSE is registered with IN2-CSE, resulting in <remoteCSE> resources in the

CSEs at both MN2 and IN2. "pointOfAccess" attribute in the <remoteCSE> resource is the address of the peer CSEs. Such addresses can be in the form of a FQDN, IP address, MAC address etc.

[00116] Under these assumptions and configurations, IN2-CSE needs to send a Request to a resource at ASN2-CSE. The URI of target ASN2-CSE (to=/{ASN2-CSE}) resolves to an IP address. It is assumed that DNS query to public DNS can be used for the resolution to a routable IP address. Underlying Network routing algorithm determines that such Request can be routed to the final destination over ULNet-4 with first hop being the CSE in MN2 (MN2-CSE). The Request is forwarded to MN2-CSE over ULNet-4 and the Originator (IN2-CSE) waits for the Response. This is an interim response from MN2-CSE, while MN2-CSE waits for forwarding the Request to the final target at ASN2-CSE over ULNet-5; based on the characteristics and schedule of ULNet-5.

[00117] Successful routing examples

[00118] IN2-CSE receives Response from MN2-CSE acknowledging the Request. This confirms connectivity between IN2-CSE and ASN2-CSE over Mcc reference point, and that the resolved IP address for the URI for ASN2-CSE (to=/{ASN2-CSE}) is current. [00119] Routing failure examples

[00120] IN2-CSE fails to receive Response from MN2-CSE within certain time frame.

Likely cause can be non-routable, stale address or no address resolution for ASN2-CSE. E.g., the first hop MN2 Node (wireless gateway) is in power saving mode and/or the A/AAAA entry for ASN2-CSE in DNS infrastructure is stale. Yet another scenario can be that ASN2-CSE has no A/AAAA entry in the DNS infrastructure, hence IN2-CSE cannot determine how to route the Request to ASN2-CSE.

[00121] In some embodiments, IN2 determines that the Underlying Network UNet-4 supports device triggering and that the Interworking-IWF can be used for "triggering" the first hop MN2 Node.

[00122] FIG. 5 is a flow chart representation of a process 300 for facilitating M2M communication. FIG. 5 shows an exemplary procedure for routing upstream from a middle node at a field domain to an infrastructure node at an infrastructure domain. For example, the process 300 may be implemented at MN1 or MN2.

[00123] At 302, a destination information of an infrastructure node is obtained. In some implementations, the destination information may include an IP address of the infrastructure node. The destination information may also be specified in terms of a network assigned number.

[0100] At 304, a network connection for supporting the routing of the request is selected based on priority or policy information associated with the request. In some implementations, if the routing request has high priority, the network connection may be selected to provide at least one of high throughput and guaranteed bit rate connection. In some implementations, if the routing request has low priority, the network connection may be selected to provide at least one of low cost, low bit rate, and best effort based connection.

[0101] FIG. 6 is a flow chart representation of a process 400 for facilitating M2M communication. FIG. 6 shows an exemplary procedure for routing downstream from the infrastructure node in the Infrastructure domain to the middle node in the field domain.

[0102] At 402, a request is sent from the infrastructure node to the middle node. The request may be, e.g., a request for routing an M2M message. The request may be, e.g., for triggering an M2M device. [0103] At 404, a message exchange is performed between the middle node and the infrastructure node upon receiving a response from the middle node. This document discloses example messages exchanged between a middle note and an infrastructure node.

[0104] At 406, a triggering event is performed to provide a connection between the middle node and the infrastructure node in the absence of the response from the middle node.

[0105] In some implementations, the triggering event proceeds as follows. A triggering request is sent from the infrastructure node. An available triggering mechanism is selected and triggering procedures are performed using the selected triggering mechanism. The results of the triggering procedures are reported to the infrastructure node. The communication between the middle node and the infrastructure node is initiated based on the results of the triggering procedures.

[0106] In some implementations, an alternative triggering mechanism is further selected when the results of the triggering procedures are not successful.

[0107] In some implementations, prior to the selecting of the available triggering mechanism, the validity of the triggering request is checked.

[0108] In some implementations, the underlying network may be represented by resources including point of access information and scheduling information. In some

implementations, the device triggering function may be provided by an interworking module located at the edge of the underlying network.

[0109] Communication between different Nodes within an oneM2M Service Provider domain (SP) happens via the exchange of Request and Response messages between the CSEs at the peer Nodes. The AEs and the CSEs at oneM2M Nodes Register with the peer CSEs, thereby providing information that enable them to use M2M services. The routing of such information between the CSEs over the Mcc reference point needs to be transported between oneM2M Nodes via the transport services provided by the Underlying Networks. Routing of the CSE

communication payload needs to be in conformance with the "policy" associated with the payload and the availability schedule of the Underlying Networks.

[0110] Attributes for Representing Underlying Networks

[0111] The following lists some example attributes used by oneM2M Nodes for realizing the routing of information between CSEs over the Mcc reference point. Such information needs to be transported between oneM2M Nodes via the transport services provided by the Underlying Networks.

[0112] Table 1 lists the attributes used by Infrastructure Nodes for the purpose of device triggering over Men reference point.

[0113] Some nodes may use services of multiple Underlying Networks. Hence, such attributes need to be differentiated for each of the Underlying Networks.

Table 1

n er y ng etwor .

Others .. TBD ..

[0114] M2M device triggering

[0115] Device triggering is the means by which an Infrastructure Node sends information to an M2M Node in the Field Domain via an Underlying Network to cause the M2M Node to connect to the Underlying Network, if needed, and perform service layer specific actions. Such actions include initiating communication with the Infrastructure Node or responding to the device triggering payload received from the Infrastructure Node. With such communication from the M2M Node over the Mcc reference point, the "pointOfAccess" attribute for that M2M Node at the Infrastructure Node (IN-CSE) can be updated

[0116] FIG. 7 illustrates a deployment scenario 700 for describing device triggering aspects. In this example illustration, Underlying Network-4 (ULNet-4) supports device triggering capability. An Interworking-IWF is provided by the Operator of the Underlying Network (e.g., MNO). Such Interworking-IWF communicates with INI and IN2 Nodes provided by M2M Service Providers SP1 and SP2. Such communication is between the Interworking-IWF and Underlying Network Services Entity (NSE) in INI and IN2 Nodes over Men reference point. In this example illustration, the point of connectivity of ULNet-4 at INI and IN2 is represented by respective "ULpeerNodePointOfAccess_[i]" attribute(s). Underlying Network Operator has business relationship with SP1 and SP2 such that oneM2M specific identities of M2M Nodes (CSE-IDs) can be mapped to their respective addresses that are valid in the Underlying Network Operator domain (e.g., M2M External Identifier for 3GPP type networks). In this example deployment scenario, mapping of MN2-CSE ID to an ID that is known in the ULNet-4 domain is possible at INI and IN2. For example, for ULNet-4 based on 3 GPP LTE technology, MN2-CSE ID can be mapped to its "M2M External Identifiers" at INI and IN2.

[0117] In the M2M Device Trigger messages 800 exchanged illustrated in FIG. 8, for simplicity the Infrastructure Node is referred to as M2M Server. Some oneM2M Nodes such as ASNs and MNs deployed within the Underlying Network Operator domain are referred to as M2M Nodes. In the example illustration in FIG. 8, M2M Node is the entity that receives the device trigger payload as first hop within the Underlying Network, even if it is not the final destination for such payload. For example, in the deployment scenario in FIG. 1, IN2-CSE needs to send a (CRUD) message to a resource hosted at ASN2-CSE, i.e., ASN2-CSE is the Hosting CSE for the target resource. The ASN2-CSE is reachable from MN2-CSE via ULNet-5. Since ASN2-CSE is not directly reachable via ULNet-4, two (2) hops are needed for delivering the (CRUD) message to the target resource in the Hosting CSE. MN2-CSE receives the (CRUD) message as part of "ULtriggerPayload" of device trigger over first hop, performs necessary processing local to MN2-CSE, and then forwards the (CRUD) message to the ASN2-CSE (Hosting CSE) over ULNet-5. Device triggering aspects disclosed in this document may be used only on the first hop i.e., between IN2-CSE and MN2-CSE over ULNet-4. [0118] Device triggering procedure described here is general for all types of Underlying

Networks that support such capability. The procedure can comprise of the exchange of Device Trigger Request, Device Trigger Confirm, Device Trigger Report and Device Trigger Report Ack messages between the M2M Server and the Interworking-IWF. Not all of these messages may be used by all types of Underlying Networks.

[0119] The M2M Server is located within the M2M Service Provider domain

(Infrastructure Domain) and the Interworking-IWF is located at the edge of Underlying Network Operator domain (Field Domain).

[0120] The CSE in M2M Server (IN2-CSE) determines the need to send a CRUD message to a CSE in an M2M Node in the Underlying Network (MN2-CSE). Such Request can be due to certain processing within the M2M Server execution environment or based on a (CRUD) message received from an AE that needs to be forwarded to the M2M Node. Some of the possible scenarios include: no IP address ("pointOfAccess") for the target M2M Node (ASN2) is available at the M2M Server for routing such (CRUD) message to the target M2M Node over Mcc reference point. Alternatively, such Request may have been for sending small infrequent data to the M2M Node for which no "pointOfAccess" is available at the M2M Server. Or that an IP address ("pointOfAccess") for the M2M Node has resulted in routing failure for reasons such as stale or non-routable IP address (see section xxx2). Hence, M2M Server determines the need to trigger the M2M Node. The M2M Server determines if a target entity/Node is triggerable over a specific Underlying Network based on the associated subscription information.

[0121] From target CSE URI (to=/ASN2-CSE) in the (CRUD) message, M2M Server determines that it can be reached via MN2-CSE as the first hop. M2M Server maps the identifier associated with the CSE of the first hop M2M Node (MN2-CSE) to an identifier that is an equivalent identity of the M2M Node within the Underlying Network domain, if needed (e.g., M2M External Identifier for 3 GPP networks).

[0122] Next, the M2M Server needs to determine how to communicate with the

Interworking-IWF from which first hop M2M Node can be reached. From the External Identifier of the M2M Node (MN2), M2M Server determines that it can be reached via the Interworking- IWF. If M2M Server has no contact details for the Interworking-IWF, e.g.,

"ULpeerNodePointOfAccess_[i]" attribute(s) for the ULNet-4 does not resolve to a routable IP address, the M2M Server may determine the IP address/port of the Interworking-IWF by performing a DNS query using the External Identifier of M2M Node or using a locally configured identifier for the Interworking-IWF.

[0123] M2M Server sends a Device Trigger Request message to the Interworking-IWF.

The message contains information that allows the Underlying Network to route the device trigger to the appropriate M2M Node (MN2), and for the M2M Node (MN2-CSE) to route the message to the appropriate final destination (e.g., to the appropriate resource within ASN2-CSE). Such information is available as "ULtriggerSpecificParams_[i]" set of attributes for the Underlying Network (ULNet-4).

[0124] An example of the information in Device Trigger Request message would be, the

External Identifier of the M2M Node, M2M Server Identifier, Application Port Identifier, a Ref- ID for identifying the Device Trigger Request message and "ULtriggerPayload" etc.

"ULtriggerPayload" contains the payload information (and associated meta-information mi) destined for the M2M Node, along with the information that may be needed for routing such information to a specific resource within the CSE at the M2M Node (e.g., address/URI for the resource at the CSE in M2M Node). Other information such as the priority and validity period associated the Device Trigger Request message is also examples of the information that may be included in the Device Trigger Request.

[0125] Interworking-IWF may check if the M2M Server is authorized to send trigger requests to the M2M Node (e.g., based on subscription information) and perform other tasks such as verifying that the M2M Server has not exceeded its quota or rate of trigger submissions. If such checks fail, the Interworking-IWF may send a Device Trigger Confirm message to the M2M Server with a cause value indicating the reason for the failure condition and the call flow stops at Step-5. Such Device Trigger Confirm message acknowledges the receipt of Device Trigger Request by the Interworking-IWF. Based on the cause value, M2M Server may take appropriate follow-up actions. Examples of such follow-up actions include stop sending further device triggers for this M2M Node, rate-limiting actions, or appropriate administrative actions as per the cause value returned by the Interworking-IWF.

[0126] Otherwise, the Interworking-IWF continues to interact with Underlying Network specific entities for tasks such as obtaining the Underlying Network Specific identity (e.g., Internal ID) for the M2M Node, and to select device-trigger mechanisms for triggering the M2M Node, in case multiple device-trigger mechanisms are supported by the Underlying Network.

[0127] Device Trigger Confirm message may be returned to the M2M Server that includes parameters such as External Identifier, Ref-ID etc., as acknowledgment of the Device Trigger Request, with appropriate cause value. M2M Server can keep "ULtriggerStatus" attribute for ULNet-4 kept updated for triggering this M2M Node.

[0128] If multiple device trigger mechanisms are supported by the Underlying Network, the Interworking-IWF can select a device trigger mechanism to use. Assuming device trigger Mechanism- 1 is selected or that is the only mechanism available, the entities in the Underlying Network perform procedures specific to the device trigger Mechanism- 1. On successful device trigger, the "ULtriggerPayload" is delivered to the M2M Node (to MN2-CSE).

[0129] Depending on successful or unsuccessful delivery of the device trigger to the

M2M Node using Mechanism- 1, the Interworking-IWF may return Device Trigger Report to the M2M Server that includes parameters such as External Identifier, Ref-ID etc., indicating device trigger delivery outcome (e.g., successful, failed and the reason for failure etc.). For unsuccessful delivery of the device trigger and if no other device trigger mechanism is available in the Underlying Network, the flow stops here. For successful delivery of the device trigger the flow continues with Step- 11.

[0130] The Interworking-IWF may try alternative device trigger delivery mechanism

(e.g., Mechanism-2) if Mechanism- 1 fails. Or both Mechanism- 1 and Mechanism-2 can be performed in parallel, depending on the capabilities of the Underlying Network.

[0131] The entities in the Underlying Network perform procedures specific to device trigger Mechanism-2. On successful device trigger, the "ULtriggerPayload" is delivered to the M2M Node (MN2-CSE).

[0132] The Interworking-IWF may return Device Trigger Report to the M2M Server that includes parameters such as External Identifier, Ref-ID etc., indicating trigger delivery outcome (e.g., successful, failed and the reason for failure). For unsuccessful delivery of the device trigger and if no other device trigger mechanism is available in the Underlying Network, the flow stops here. For successful delivery of the device trigger the flow continues with Step-11.

[0133] In case of failure of the device trigger mechanism above, if yet other device trigger mechanisms are supported by the Underlying Network, the flow continues at Step-9. [0134] M2M Server my return Device Trigger Report Ack to the Interworking-IWF acknowledging the receipt of Device Trigger Report message. The M2M Server can keep "ULtriggerResult" attribute for ULNet-4 kept updated for triggering this M2M Node.

[0135] On being successfully triggered, the M2M Node (MN2-CSE) performs actions that are required in response to the "ULtriggerPayload" received in the device trigger. Such actions include initiation of communication with the CSE at the M2M Server/ AE at AS (over the Mcc reference point) immediately or later. Such actions also include responding with a (CRUD) message that is targeted to the Originator of the (CRUD) message received by the CSE at M2M Node (MN2-CSE). Such Originator of the (CRUD) message may be the CSE at the M2M Server or an Application Entity that initiated the communications at Step-1. This results in the refreshing the "pointOfAccess" attribute(s) in <remoteCSE> resources at the two peer Nodes (M2M Node and M2M Server). For the case of fresh registration between the recipient of the device trigger and the IN-CSE, <remoteCSE> resource is created at the peer Nodes, that include the "pointOfAccess" information. Communication between the CSEs at M2M Node and M2M Server can now continue over Mcc reference point.

[0136] Note: Step-12 above assumes that device trigger was initiated by a (CRUD) message from an Application Entity at the AS. Hence the communication resulting from device trigger is shown to be between the M2M Node and the AE at the AS. In case device trigger is initiated as a result of a (CRUD) message from the M2M Server, the communications resulting from the delivery of the device trigger will be between the M2M Node and the M2M Server.

[0137] It will be appreciated that techniques are disclosed for routing and policy control in M2M communication may be implemented in various manners as described in the present document.

[0138] The disclosed and other embodiments and the functional operations and modules 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.

[0139] 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.

[0140] 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).

[0141] 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.

[0142] While this 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 subcombination. 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.

[0143] 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.