WO2017017503A1

WO2017017503A1 - Method and apparatus for using sip-based communications in machine-to-machine networks

Info

Publication number: WO2017017503A1
Application number: PCT/IB2015/055792
Authority: WO
Inventors: George Foti
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-07-30
Filing date: 2015-07-30
Publication date: 2017-02-02

Abstract

In one aspect of the teachings herein, a Machine-to-Machine, M2M, network advantageously exploits the routing capabilities of a Session Initiation Protocol, SIP, based network, for communicatively linking M2M entities within a M2M network domain. For example, a number of SIP gateways are communicatively interlinked through an Internet Protocol Multimedia Subsystem, IMS, core network as the SIP-based network. Each SIP gateway may be regarded as defining or being associated with a localized domain within the larger M2M network domain. M2M requests involving M2M entities commonly associated with the same SIP gateway are locally routed within the corresponding localized domain, while M2M requests targeting M2M entities outside of the localized domain are advantageously routed to the SIP-based network for efficient routing.

Description

METHOD AND APPARATUS FOR USING SIP-BASED

COMMUNICATIONS IN MACHINE-TO-MACHINE NETWORKS

TECHNICAL FIELD

The present invention generally relates to Machine-to-Machine, M2M, networks, and particularly relates to the use of Session Initiation Protocol, SIP, communications in such networks.

BACKGROUND

Machine-to-Machine, M2M, networks involve the automated exchange of data and control signaling between various M2M entities. Here, a M2M "entity" is a logically distinct and separately identifiable thing within the M2M network. A M2M entity comprises, for example, the particular instance of a M2M application, as instantiated on a supporting device or node that provides a communication interface usable for communicating with one or more other M2M entities in the M2M network. While the term "M2M entity" has a logical connotation to it, it should be understood that, unless specified otherwise, the term "M2M entity" as used herein shall be understood as at least implicitly referring to the processing and communication circuitry by which the functionality of the M2M entity is realized. Of course, the same physical node may be used to implement more than one M2M entity. For example, a node having suitable processing circuitry and storage may host more than one M2M application— each such application instance operates as a distinct M2M entity within the overall M2M network and thus has its own identity and "location" within the network. Thus, unless otherwise noted for the sake of clarity, the terms "M2M entity" and "M2M node" are used interchangeably herein.

In a working M2M example, M2M nodes having various sensing capabilities are embedded in the heavy equipment used in a mining or large construction project. These M2M nodes are configured to send vehicle health and usage data to a remote application server hosting a software application that uses the reported data for scheduling vehicle maintenance. Many other examples come to mind, including the use of M2M nodes embedded in a network of geographically distributed vending machines, where each M2M node provides connectivity back to a network-based application that tracks item stock levels, machine functionality, etc. Broadly, M2M technology may be applied to an essentially unlimited range of applications and contexts and, in general, can be understood as being part of the evolving Internet of Things, IoT.

While the teachings herein are not limited to a particular body of M2M standards, nor to specific M2M network architectures, it may be helpful to refer the example teachings provided in the standardization specifications promulgated by the "oneM2M" organization. The technical specification TS-0001-V1.6.1 defines the functional architecture of a M2M network configured according to the oneM2M standards. According to oneM2M, a "Machine-to-Machine Solution is a combination of devices, software and services that operate with little or no human interaction," and a M2M network shall be understood as comprising one or more "Application Entities" or AEs.

A given AE may be an ADN-AE, where "ADN" denotes an "Application Dedicated

Node". ADN-AEs generally are part of the "field domain" of a M2M network. AEs may also exist in the so-called "middle nodes" or MNs that interconnect M2M entities in the field domain to supporting M2M entities in the "infrastructure domain". For example, a MN "Common Services Entity" or MN-CSE is a type of M2M support entity. In this disclosure, a M2M support entity or M2M SE provides supporting services to one or more other M2M entities, such as registration services, notification services, or creation, handling, or access control services for data, referred to as "resources" in the M2M lexicon.

Further, a MN-CSE or other M2M SE may act as a gateway for coupling any number of field-domain AEs to higher-layer M2M SEs, such as an Infrastructure Node CSE or IN-CSE. An IN-CSE is a type of "top-level" M2M SE within a M2M network domain, and there generally is only one IN-CSE or other top-level M2M SE within a given M2M network. An IN-CSE may include or may otherwise communicate with one or more IN- AEs. The IN- AEs comprise, for example, the top-level M2M applications that collect data from field-domain AEs and/or provide overall control or management for pluralities of field-domain AEs and their data.

In the oneM2M context, a CSE represents an instantiation of a set of common service functions that are exposed to other M2M entities through defined communication interfaces, known as "reference points". Example CSE functions include data management, subscription service management, and location services. Of course, the applicability of the teachings presented in this disclosure is not limited to M2M networks implemented according to the oneM2M standards, and it will be appreciated that CSEs can be understood as working example of a M2M SE or M2M support node. As noted, the term M2M SE broadly denotes a M2M entity that provides one or more services or functions supporting other M2M entities in a M2M network, such as by providing registration services, resource hosting, etc.

With the increasing sophistication of M2M applications and the increasing scale and diversity of M2M deployments, it is recognized herein that M2M service providers, SPs, face significant design challenges and expenses in deploying and maintaining their M2M networks. For example, the current oneM2M architecture is based on M2M nodes registering with each other so that they can process requests from each other. Specifically, registration between two M2M nodes is mandatory before anything can be exchanged between those M2M nodes. One drawback associated with this approach is that a given M2M SE receiving a request does not necessarily know how to route the request to the target. For example, if a M2M node registered at a given M2M SE sends a M2M request targeting an M2M node that is not registered within the M2M SE, then, depending on the "location" of the M2M SE within the M2M network and depending on the number or nature of any other M2M SEs with which the M2M SE is registered, there may not be any efficient mechanisms for routing the request towards its intended target. The M2M SE handling the request originator may, for example, attempt registrations towards a new M2M SE or even the top-level M2M SE of the network, in an attempt to gain access to a M2M SE having knowledge of location of the request target, or it may simply pass the request along to another M2M SE with which it is already registered. It is recognized herein that the inefficiencies of such approaches will become an acute problem as M2M networks grow to include potentially many hundreds or thousands of M2M SEs within a given M2M network domain.

SUMMARY

In one aspect of the teachings herein, a Machine-to-Machine, M2M, network advantageously exploits the routing capabilities of a Session Initiation Protocol, SIP, based network, for communicatively linking M2M entities within a M2M network domain. For example, a number of Session Initiation Protocol, SIP, gateways are communicatively interlinked through an Internet Protocol Multimedia Subsystem, IMS, core network. Each SIP gateway may be regarded as defining or being associated with a localized domain within the larger M2M network domain. M2M requests involving M2M entities commonly associated with the same SIP gateway are locally routed within the corresponding localized domain, while M2M requests involving M2M entities outside of the localized domain are advantageously routed to the SIP-based network for efficient routing.

One embodiment is directed to a method of operation in a SIP gateway that is configured for operation in a M2M network domain. The example method includes receiving, via a M2M communication interface of the SIP gateway, a M2M request message from a M2M entity within a localized domain of the SIP gateway, where a target of the M2M request message is not within the localized domain of the SIP gateway. The method further includes encapsulating the M2M request message in an outgoing SIP message, and sending, via a SIP communication interface of the SIP gateway, the outgoing SIP message towards a M2M directory server that is reachable via a SIP-based network associated with the M2M network domain. Correspondingly, the method includes receiving, via the SIP communication interface, a return SIP message that includes a M2M response message corresponding to the M2M request message, extracting the M2M response message from the return SIP message, and forwarding, via the M2M communication interface, the M2M response message towards the local M2M entity from which the M2M request message was received.

A related embodiment is directed to a SIP gateway configured for operation in a M2M network domain. The example SIP gateway includes a M2M communication interface configured for sending and receiving M2M signaling, and a SIP communication interface configured for sending and receiving SIP signaling. The SIP gateway further includes processing circuitry that is operatively associated with the M2M and SIP communication interfaces and configured to receive, via the M2M communication interface, a M2M request message from a M2M entity within a localized domain of the SIP gateway. In an example case, the target of the M2M request message is not within the localized domain of the SIP gateway and for such a case, the processing circuitry is configured to encapsulate the M2M request message in an outgoing SIP message, and send, via the SIP communication interface, the outgoing SIP message towards a M2M directory server that is reachable via a SIP-based network associated with the M2M network domain. Correspondingly, the processing circuitry is configured to receive, via the SIP communication interface, a return SIP message that includes a M2M response message corresponding to the M2M request message, extract the M2M response message from the return SIP message, and forward, via the M2M communication interface, the M2M response message towards the local M2M entity from which the M2M request message was received.

Another embodiment is directed to a method at a M2M directory server, for providing directory services within a M2M network domain. The example method includes maintaining binding information that logically M2M entities in the M2M network with their respective SIP gateways, i.e., binding information that indicates the SIP gateway affiliations of at least certain ones of the M2M entities within the M2M network. For example, the M2M directory server maintains binding information that logically associates given M2M Support Entities, SEs, in the M2M network with their respective SIP gateways. Additionally, or alternatively, for any globally addressable M2M entity residing within any of the localized domains of the various SIP gateways, the binding information indicates the SIP gateway associations of each such M2M entity. The binding information thus allows, for example, any M2M signaling directed to or identifying a given M2M SE to be routed via the intervening SIP-based network to the particular SIP gateway associated with the involved M2M SE.

Correspondingly, in an example "use case," the method further includes receiving an incoming SIP message from the SIP-based network, where the incoming SIP message encapsulates a M2M message targeted to a M2M entity, and extracting a M2M identity of the targeted M2M entity from the incoming SIP message. Correspondingly, the method includes identifying a target SIP gateway for the incoming SIP message, by indexing into the binding information with the extracted M2M identity, and forwarding the incoming SIP message towards the target SIP gateway, for decapsulation and delivery to the targeted M2M entity.

A related embodiment is directed to a M2M directory server that is configured to provide directory services within a M2M network domain. The example M2M directory server includes one or more communication interfaces, including a least a SIP interface configured for communicatively coupling the M2M directory server to a SIP-based network, and processing circuitry that is operatively associated with the one or more communication interfaces. The processing circuitry is configured to maintain binding information such as described immediately above in the context of the M2M directory server method.

The processing circuitry is further configured to receive an incoming SIP message from the SIP-based network, where the incoming SIP message encapsulates a M2M message targeted to a M2M entity, and to extract a M2M identity of the targeted M2M entity from the incoming SIP message and identify a target SIP gateway for the incoming SIP message by indexing into the binding information with the extracted M2M identity. Correspondingly, the processing circuitry is configured to forward the incoming SIP message towards the target SIP gateway, for decapsulation and delivery to the targeted M2M entity.

In another embodiment, an apparatus is configured for operation in the context of the SIP gateway processing described herein. For example, the apparatus represents functional processing circuitry implemented via the processing circuitry in a node configured for operation as a SIP gateway. The example apparatus includes a M2M communication module that is configured to receive a M2M request message from a M2M entity within a localized domain of the SIP gateway, where in this example the M2M entity targeted by the M2M request message is not within the localized domain of the SIP gateway.

The apparatus further includes an encapsulation module that is configured to encapsulate the M2M request message in an outgoing SIP message, and a SIP communication module that is configured to send the outgoing SIP message towards a M2M directory server that is reachable via a SIP-based network associated with the M2M network. The SIP communication module is further configured to receive a return SIP message that includes a M2M response message corresponding to the M2M request message, and the SIP apparatus further includes an extraction module that is configured to extract the M2M response message from the return SIP message and forward, via the M2M communication module, the M2M response message towards the local M2M entity from which the M2M request message was received.

In another example embodiment, an apparatus is configured for operation as a M2M directory server that is configured to provide directory services within a M2M network. For example, the apparatus represents functional processing circuitry implemented via the processing circuitry of a node configured for operation as a M2M directory server according to the teachings herein.

The contemplated apparatus includes a SIP communication module that is configured to communicatively couple the M2M directory server to a SIP-based network. The apparatus further includes a maintaining module that is configured to maintain binding information that logically associates M2M SEs in the M2M network with respective SIP gateways that are used to communicatively couple distributed M2M SEs via the SIP-based network. More generally, the binding module maintains binding information for all M2M entities that are globally addressable within the M2M network, so that the SIP gateways associated with such M2M entities are known to the M2M directory server. Still further, the apparatus includes an extraction module that is configured to extract a M2M identity of a targeted M2M entity from an incoming SIP message received from the SIP-based network. Here, it will be appreciated that the incoming SIP message encapsulates a M2M message targeted to a particular M2M entity referred to in this context as the "targeted" M2M entity.

The apparatus correspondingly includes an identification module that is configured to identify a target SIP gateway for the incoming SIP message by indexing into the binding information with the extracted M2M identity. Additionally, the apparatus includes a forwarding module that is configured to forward the incoming SIP message towards the target SIP gateway, via the SIP communication module, for decapsulation and delivery to the targeted M2M entity. The apparatus in at least some embodiments also includes a "backhaul" or other interface that is provided for communicating directly with the SIP gateways and receiving information indicating the associations between M2M entities in the M2M network and the corresponding SIP gateways with which those M2M entities are associated. For example, the apparatus receives information indicating the SIP gateway associations of any M2M entity within the M2M network that is intended to be globally addressable within the M2M network.

Of course, the present invention is not limited to the above features and advantages. Indeed, those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a block diagram of one embodiment of a Machine-to-Machine, M2M, network domain.

Fig. 2 is a block diagram of example details for the M2M network domain of Fig. 1. Fig. 3 is a logic flow diagram of one embodiment of a method of operation at a Session Initiation Protocol, SIP, gateway that is configured for operation in a M2M network domain.

Fig. 4 is a logic flow diagram of one embodiment of a method of operation at a M2M directory server that is configured for operation in a M2M network domain.

Figs. 5-9 are signal flow diagram of example signaling flowing in a M2M network domain.

Fig. 10 is a block diagram of functional processing modules implemented in some embodiments of a SIP gateway.

Fig. 11 is a block diagram of functional processing modules implemented in some embodiments of a M2M directory server.

DETAILED DESCRIPTION

Fig. 1 illustrates a Machine-to-Machine, M2M, network 10, which may be regarded as defining a M2M network domain. It will be appreciated that M2M networks are subject to significant variation and that the M2M network 10 is offered as a non-limiting example for discussing various embodiments of the teachings herein.

The M2M network 10 depicted in Fig. 1 advantageously includes a Session Initiation Protocol, SIP, based network 12 that, according to the teachings herein, is used for efficient routing of M2M signaling between M2M entities 14 that are in different "localized domains" 16 of the M2M network 10. By way of example, various M2M entities 14, e.g., M2M entities 14-1, 14-2 and 14-3, are within a localized domain 16-1 that is defined by or otherwise associated with a first Session Initiation Protocol, SIP, gateway 18-1. M2M entities 14-4, 14-5, ..., 14-N are within another localized domain 16-2 that is defined by or otherwise associated with a second SIP gateway 18-2. Unless suffixes are needed for clarity, the reference number 14 is used herein for both singular and plural references to given M2M entities and the term "M2M entities" may generically reference multiple types of M2M entities within the M2M network 10. Likewise, the reference number 16 is used for general reference to any given localized domain, or for reference to given localized domains. The same usage applies with respect to reference number 18 and SIP gateways.

The M2M network 10 further includes a M2M directory server that works in conjunction with the SIP-based network 12. In the example embodiment depicted in Fig. 1, the SIP-based network 12 comprises an Internet Protocol Multimedia Subsystem, IMS, "core" network.

Example details for such networks appear in the technical specification TS 23.228, which is promulgated by the Third Generation Partnership Project, 3GPP, and entitled "Architecture and Main Flows for an IMS System". Correspondingly, in the example embodiment, the SIP-based network 12 includes a "P- CSCF" node 22, where "P-CSCF" denotes "Proxy Call Session Control Function". In IMS operations, the P-CSCF node 22 serves as the first contact point for the users of the SIP-based network 12, which here are the SIP gateways 18 in a direct sense, and the M2M entities 14, in an indirect sense. In its proxy role, the P-CSCF node 22 handles SIP signaling traffic to and from respective SIP gateways 18, including validating and forwarding SIP requests and handling corresponding SIP responses in return.

The SIP-based network 12 further includes an "I-CSCF" node 24, where "I-CSCF" denotes "Interrogating Call Session Control Function". The I-CSCF node 24 is communicatively coupled to the P-CSCF 22 and cooperates with the M2M directory server 20, to determine signaling target locations for SIP-encapsulated M2M signaling being routed by the SIP-based network 12.

Still further, the SIP-based network 12 in the illustrated example includes a "S-CSCF" 26, where "S-CSCF" denotes "Serving Call Session Control Function". The S-CSCF 26 provides a central point of control for IMS services and facilitates session request routing.

According to the teachings herein, M2M signaling traffic going between M2M entities 14 within the same localized domain 16 is exchanged within the localized domain 16 as ordinary M2M signaling. Advantageously, however, the SIP-based network 12 is used for routing M2M signaling going between M2M entities 14 that operate within different localized domains 16. In this context, each SIP gateway 18 can be understood as a concentration gateway or top-level proxy for a potentially large number of M2M entities 14 that are operating within the localized domain 16 of the SIP gateway 18. Consequently, the contemplated architecture is easily scaled without increasing its underlying architectural complexity and enables the M2M network 10 to include a large plurality of M2M entities 14, e.g., clusters of entities inter-coupled through respective SIP gateways 18 and one or more supporting SIP-based networks 12 and appropriate directory services.

Either the SIP gateway 18 or a M2M SE within the localized domain 16 of the SIP gateway 18 can recognize "intra-domain" or "local" M2M signaling, where "intra-domain" refers to the localized domain 16 and not to the overall M2M network domain. That is, for intra- domain M2M signaling, the source and target M2M entities 14 are within the same localized domain 16. The M2M SE or the SIP gateway 18 provides normal handling and processing of intra-domain M2M signaling, by which is meant that the M2M signaling is handled without protocol conversions and without routing over the SIP-based network 12.

Advantageously, however, "inter-domain" or "non-local" M2M signaling is detected or otherwise differentiated, and provided to the SIP-based network 12 by the involved SIP gateway 18, for routing over the SIP-based network 12 to the particular other localized domain 16 that includes the M2M entity 14 targeted by the signaling. Unless otherwise noted, "inter-domain" in this disclosure denotes M2M signaling involving M2M entities 14 that are in different localized domains 16.

In an example embodiment, any given one of the SIP gateways 18 includes a M2M communication interface 30 that is configured for sending and receiving M2M signaling according to the applicable M2M protocols, and a SIP communication interface 32 that is configured for sending and receiving SIP signaling. The example SIP gateway 18 further includes processing circuitry 34 that is operatively associated with the M2M and SIP communication interfaces 30, 32. The processing circuitry 34 is configured to receive, via the M2M communication interface 30, a M2M request message from a M2M entity 14 within a localized domain 16 of the SIP gateway 18.

In an example case, the target of the M2M request message is not within the localized domain 16 of the SIP gateway and the processing circuitry 34 is configured to encapsulate the M2M request message in an outgoing SIP message, and send, via the SIP communication interface 32, the outgoing SIP message towards the M2M directory server 20, which is reachable via the SIP-based network 12. Further for this case, the processing circuitry 34 is configured to receive, via the SIP communication interface 32, a return SIP message that includes a M2M response message corresponding to the M2M request message, extract the M2M response message from the return SIP message, and forward, via the M2M communication interface 30, the M2M response message towards the local M2M entity 14 from which the M2M request message was received.

The processing circuitry 34 comprises fixed circuitry, or programmed circuitry, or a mix of fixed and programmed circuitry. For example, the processing circuitry 34 comprises one or more processing circuits 36, such as one or more microprocessors, Application Specific Integrated Circuits or ASICs, Field Programmable Gate Arrays or FPGAs, or other digital processing circuit.

The processing circuitry 34 further includes or is associated with storage 38, which comprises one or more types of computer-readable media. For example, the storage 38 provides working or volatile memory for the processing circuit(s) 36, along with providing longer term or non-volatile storage of a computer program 40 and registration data 42. In one or more embodiments, the processing circuitry 34 is configured or specially adapted according to the teachings herein, based at least in part on execution by the processing circuit(s) 36 of the computer program instructions comprising the computer program 40. Further, the registration data 42 in one or more embodiments identifies the M2M entities 14 that are registered within the localized domain 16 of the SIP gateway 18 and thus provides a mechanism for identifying M2M signaling as being local or non-local.

Non-limiting examples of types of computer-readable media comprising the storage 38 include SRAM or DRAM memory, and FLASH, EEPROM and/or Solid State Disk, SSD, storage. In any case, it will be appreciated that the storage 38 provides non-transitory storage for the computer program 40 and the registration data 42. Here, "non-transitory" does not necessarily mean permanent or unchanging storage, but does denote storage of at least some persistence, e.g., electronic storage supporting subsequent retrieval and processing of stored information.

However configured, the processing circuitry 34 is configured in one or more embodiments to relay local M2M traffic in non-encapsulated form according to M2M protocols and to forward non-local M2M traffic in encapsulated form according to SIP protocols. The local M2M traffic comprises given M2M signaling that is received by the SIP gateway 18 on the M2M communication interface 30 and that is going between respective M2M entities 14 within the localized domain 16 of the SIP gateway 18. Conversely, the non-local M2M traffic comprises given M2M signaling that is received by the SIP gateway 18 on the M2M

communication interface 30 and that targets any given M2M entity 14 that is outside the localized domain 16 of the SIP gateway 18.

In at least one such embodiment, the processing circuitry 34 is configured to maintain data at the SIP gateway 18 indicating the M2M identities of the M2M entities 14 that are local to the SIP gateway 18, and to determine whether any given M2M signaling received at the SIP gateway 18 via the M2M communication interface 30 comprises local M2M traffic or non-local M2M traffic, based on determining whether or not a target of the given M2M signaling matches one of the local M2M identities. For example, the processing circuitry 34 is configured to maintain the aforementioned registration data 42 at the SIP gateway 18, to retain the M2M identities of the M2M entities 14 that are registered within the localized domain 16 of the SIP gateway 18.

The SIP gateway 18 is also operative to receive SIP-encapsulated signaling incoming from the SIP-based network 12 and targeting one of the M2M entities 14 that is in the localized domain 16 of the SIP gateway 18. In an example embodiment for supporting such functionality, the processing circuitry 34 is configured to receive an incoming SIP message via the SIP communication interface 32 of the SIP gateway 18, extract an incoming M2M request message from the incoming SIP message, determine a target of the incoming M2M request message within the localized domain 16 of the SIP gateway 18, forward the incoming M2M request message towards the target, via the M2M communication interface 30 of the SIP gateway 18, receive, via the M2M communication interface 30, an incoming M2M response message corresponding to the forwarded incoming M2M request message, encapsulate the incoming M2M response message in a corresponding outgoing SIP message, and send the corresponding outgoing SIP message towards the M2M directory server 20, via the SIP communication interface 32 of the SIP gateway 18.

In one or more embodiments, the processing circuitry 34 is configured to send a given outgoing SIP message towards the M2M directory server 20, by sending the outgoing SIP message towards a CSCF node in the SIP-based network 12, for forwarding towards the M2M directory server 20. For example, the SIP gateway 18 sends the SIP-encapsulated M2M signaling to a P-CSCF node 22, where it will be understood that the SIP communication interface 32 of the SIP gateway 18 provides communicative coupling to the P-CSCF node 22. In at least some embodiments, the processing circuitry 34 is configured to encapsulate the M2M request message in the outgoing SIP message, by packaging the M2M request message in an outgoing SIP INFO message.

In further enhancements associated with one or more embodiments of the SIP gateway

18, the processing circuitry 34 is configured to establish or re-establish a session with the SIP- based network 12 upon a power-up or a reboot of the SIP gateway 18. Such behavior ensures communicative coupling and provides a form of automated start-up or recovery, for "forming" the overall M2M network 10, in association with the SIP-based network 12 and the supporting M2M directory server 20.

In the example of Fig. 1 , the M2M directory server 20 is configured to provide directory services within a M2M network 10, i.e., in support of the above-described operations of the SIP gateways 18. Enabling that role, the M2M directory server 20 in an example implementation includes one or more communication interfaces 50, including a least a SIP interface configured for communicatively coupling the M2M directory server 20 to the SIP-based network 12. The M2M directory server 20 further includes processing circuitry 54 operatively associated with the one or more communication interfaces 50 and configured to maintain binding information that logically associates each SIP gateway 18 with one or more of the M2M entities 14 that are within the localized domain 16 of the SIP gateway 18. For example, the binding information identifies each of the M2M SEs that are included within the localized domain 16. Additionally, the binding information may identify any M2M entity 14 that is within the localized domain 16 and is globally or directly addressable within the context of the overall M2M network 10.

In a non-limiting example, each localized domain 16 includes at least one M2M SE that is communicatively coupled to the associated SIP gateway 18. Any number of other M2M entities 14, such as AEs, etc., may be registered with the M2M SE. The M2M directory server 20 thus may be configured to maintain binding information that identifies the M2M SE(s) that are within the localized domain 16 of each SIP gateway 18 in the M2M network 10, as well as identifying any other M2M entities 14 that are reachable through any such M2M SEs. Here, an "M2M identity" will be understood as a unique identity used in the M2M network 10 to identify a particular M2M entity 14. The processing circuitry 54 may, for example, be configured to obtain the binding information in received signaling that identifies the M2M entities 14 within each localized domain 16, or at least identifies those M2M entities 14 within each localized domain 16 operating as M2M SEs. In some embodiments, the SIP gateways 18 send such signaling to the M2M directory server 20.

Regardless, the processing circuitry 54 of the M2M directory server 20 is configured to receive an incoming SIP message from the SIP-based network 12, where the incoming SIP message encapsulates a M2M message targeted to a M2M entity 14. The processing circuitry 54 is configured to extract a M2M identity of the targeted M2M entity 14 from the incoming SIP message, identify a target SIP gateway 18 for the incoming SIP message, by indexing into the binding information with the extracted M2M identity, and forward the incoming SIP message towards the target SIP gateway 18, for decapsulation and delivery to the targeted M2M entity 14.

The processing circuitry 54 comprises fixed circuitry, or programmed circuitry, or a mix of fixed and programmed circuitry. For example, the processing circuitry 54 comprises one or more processing circuits 56, such as one or more microprocessors, Application Specific

Integrated Circuits or ASICs, Field Programmable Gate Arrays or FPGAs, or other digital processing circuit.

The processing circuitry 54 further includes or is associated with storage 58, which comprises one or more types of computer-readable media. For example, the storage 58 provides working or volatile memory for the processing circuit(s) 56, along with providing longer term or non-volatile storage of a computer program 60 and registration data 62. Here, the registration data 62 comprises the aforementioned binding information that enables the M2M directory server 20 to identify the localized domain 16 / SIP gateway 18 targeted by any given SIP- encapsulated signaling handled by the M2M directory server 20.

In one or more embodiments, the processing circuitry 54 is configured or specially adapted according to the teachings herein, based at least in part on execution by the processing circuit(s) 56 of the computer program instructions comprising the computer program 60. Non- limiting examples of types of computer-readable media comprising the storage 58 include SRAM or DRAM memory, and FLASH, EEPROM and/or Solid State Disk, SSD, storage. In any case, it will be appreciated that the storage 58 provides non-transitory storage for the computer program 60 and the registration data 62. Fig. 2 illustrates details for an example implementation of the M2M network 10 introduced in Fig. 1. Here, there are two SIP gateways 18-1 and 18-2. The localized domain 16-1 of the SIP gateway 18-1 includes particular types of M2M entities 14; namely, the localized domain 16 includes first and second M2M SEs 70-1 and 70-2, each supporting one or more M2M Application Entities or AEs 72. In an example embodiment, the M2M SEs 70 seen in Fig. 2 are Middle Node Common Service Entities, MN-CSEs, within the meaning of the oneM2M standards. The M2M SE 70-1 supports M2M AEs 72-1, 72-2 and 72-3. Likewise, the M2M SE 70-2 supports M2M AEs 72-4 and 72-5. A similar arrangement is seen with respect to the M2M SEs 70-3 and 70-4, which operate within the localized domain 16-2 of the SIP gateway 18-2, and which provide supporting M2M services to AEs 72-6, 72-7, 72-8 and 72-9.

In a contemplated example scenario, the AEs 72-1, 72-2 and 72-3 are registered with the M2M SE 70-1, the AEs 72-4 and 72-5 are registered with the M2M SE 70-2, the AEs 72-6 and 72-7 are registered with the MSM SE 70-3, and the AEs 72-8 and 72-9 are registered with the M2M SE 70-4. In turn, the M2M SEs 70-1 and 70-2 are "registered" with or otherwise associated with the SIP gateway 18-1, and the M2M SEs 70-3 and 70-4 are registered with or otherwise associated with the SIP gateway 18-2.

The registration data 42 maintained at the SIP gateway 18-1 comprises, for example, all of the M2M identities of the M2M entities 14 included within its localized domain 16-1 and the identity of the corresponding M2M SE 70 that they can be reached through. The SIP gateway 18- 1 receives the M2M identity information from the M2M SEs 70-1 and 70-2, for example, and the AEs 72 may be unaware of the existence or operation of the SIP gateway 18-1. The registration data 42 at the SIP gateway 18-2 would be similarly populated. Correspondingly, the registration data 62 at the M2M directory server 20 would bind the SIP-based network addresses of the SIP gateways 18 with the M2M identities of the M2M SEs 70 operating under each SIP gateway 18. In support of multiple modes for addressing or targeting certain M2M entities 14 via M2M signaling within the M2M network 10, the binding information maintained at the M2M directory server 20 may link each M2M SE 70 to its respective SIP gateway 18 and additionally may identify the particular M2M entities 14 supported by, instantiated in, or reachable through, each M2M SE 70, and may link them to the appropriate SIP gateway 18. Additionally, or

alternatively, the binding information maintained at the M2M directory server 20 binds all of the M2M identities of the M2M entities 14 within each localized domain 16 to the SIP-routable address of the associated SIP gateway 18, or at least includes bindings for any M2M entity 14 that is intended to be globally addressable within the M2M network 10. In all such cases, by extracting M2M identities from SIP-encapsulated signaling flowing in the SIP-based network 12, the M2M directory server 20 identifies the SIP gateway 18 that is associated with the particular M2M entity 14 targeted to by the SIP-encapsulated signaling.

Not only does the above arrangement advantageously use the SIP-based network 12 to route inter-domain M2M signaling traffic without requiring the involved M2M entities 14 to know the network locations of the signaling targets, it also provides for efficient handling of local, intra-domain M2M signaling. That is, the processing circuitry 34 of each SIP gateway 18 is configured to relay M2M signaling going between respective ones of the local M2M SEs 70 that operate underneath it, within its localized domain 16.

Fig. 3 illustrates an example method 300 that is implemented by a SIP gateway 18 in a M2M network 10, in one or more embodiments herein. The method 300 includes receiving (Block 302), via a M2M communication interface 30 of the SIP gateway, a M2M request message from a M2M entity 14 within a localized domain 16 of the SIP gateway 18. In the example context of the method 300, the target of the M2M request message is not within the localized domain 16 of the SIP gateway, and the method 300 correspondingly includes encapsulating (Block 304) the M2M request message in an outgoing SIP message, and sending (Block 306), via a SIP communication interface 32 of the SIP gateway 18, the outgoing SIP message towards a M2M directory server 20 that is reachable via a SIP-based network 12 associated with the M2M network 10. Still further, the method 300 further includes receiving (Block 308), via the SIP communication interface 32, a return SIP message that includes a M2M response message corresponding to the M2M request message, extracting (Block 310) the M2M response message from the return SIP message, and forwarding (Block 312), via the M2M communication interface 30, the M2M response message towards the local M2M entity 14 from which the M2M request message was received. Forwarding towards the appropriate M2M entity 14 comprises, for example, sending the M2M response message towards the M2M SE 70 that supports the M2M entity 14 to which the signaling is targeted, where that relationship is known from the binding information maintained at the SIP gateway 18.

Fig. 4 illustrates an example method 400 implemented by a M2M directory server 20 as contemplated herein. The method 400 includes maintaining (Block 402) binding information that logically associates M2M entities 14 in the M2M network 10 with respective SIP gateways 18. The binding information thus enables the M2M directory server 20 to identify the destination or target SIP gateway 18 associated with a given M2M identity.

The method 400 further includes receiving (Block 404) an incoming SIP message from the SIP-based network 12, where the incoming SIP message encapsulates a M2M message targeted to a M2M entity 14. Correspondingly, the method 400 includes extracting (Block 406) a M2M identity of the targeted M2M entity 14 from the incoming SIP message, identifying (Block 408) a target SIP gateway 18 for the incoming SIP message, by indexing into the binding information with the extracted M2M identity, and forwarding (Block 410) the incoming SIP message towards the target SIP gateway 18, for decapsulation and delivery to the targeted M2M entity 14.

Fig. 5 illustrates an example signal flow that can be understood as a process for dynamically associating M2M entities 14 with their respective SIP gateways 18. At Step 1, a M2M SE 70-1 discovers its associated SIP gateway 18 using Fully Qualified Domain Name, FQDN, procedures, or based on accessing provisioned or preconfigured address information stored within the M2M SE 70-1. At Step 2, the M2M SE 70-1 publishes its information, including its M2M identity and the identity or address of its associated SIP gateway 18 to the M2M directory server 20. The M2M SE 70-1 may have a "back-end" or other network interface for communicating such information to the M2M directory server 20. Note that the M2M SE 70- 1 also may provide the M2M directory server 20 with M2M identifiers or other identifying data for any M2M entities 14 that are globally addressable or otherwise reachable through the M2M SE 70-1, for capturing in the binding information maintained at the M2M directory server 20.

At Step 3, the M2M directory server 20 updates its binding information, to record the association(s) between the reported M2M identities and the associated SIP gateway 18. At Step 4, the M2M directory server 20 provides a corresponding response to the M2M SE 70-1, to confirm receipt of the information. Steps 5-8 illustrate similar processing with respect to a second M2M SE 70-2, which may be remote relative to the first M2M SE 70-1 and reachable by the M2M SE 70-1 during "live" operation of the M2M network only through the advantageous IMS-based routing provided by the teachings herein.

Fig. 6 illustrates an example signaling flow corresponding to contemplated methods for obtaining and/or updating binding information used at a SIP gateway 18 and also the corresponding binding information used at the M2M directory server 20. At Step 1, a M2M AE 72 registers with its supporting M2M SE 70. At Step 2, the M2M SE 70 stores registration information for the M2M AE 72.

At Step 3, the M2M SE 70 determines whether M2M AE 72 should be published to the M2M directory server 20 SIP via gateway 18, for global addressability. That is, if the AE 72 is intended or otherwise configured to be a globally-addressable M2M entity 14 within the M2M network 10, then the M2M directory server 20 must obtain information indicating which SIP gateway 18 is associated with the AE 72, so that M2M signaling targeting the AE 72 can be properly routed, as needed, through the SIP-based network 12, with the assistance of the M2M director server 20. At Step 4, the M2M SE 70 sends a registration response to the M2M AE 72, and at Step 5 the M2M SE 70, after determining that the registered AE 72 can be addressed globally, sends publication information for the M2M AE 72 to the SIP gateway 18. Correspondingly, at Step 6 the SIP gateway 18 stores or otherwise updates binding information that captures the relevant affiliations. For example, the SIP gateway 18 creates or updates a table entry that links the M2M identity of the M2M AE 72 to the M2M identity of the M2M SE 70. These affiliations are propagated to the M2M directory server 20 at Step 7, and at Step 8 the M2M directory server 20 stores or updates its binding information accordingly. For example, the M2M directory server 20 creates or updates a table entry that links the M2M identities of the M2M AE 72 to the M2M SE 70, and in turn links the M2M identity of the M2M SE 70 to the address or identifier of the involved SIP gateway 18, in terms of the gateway's routing name or address within the context of the SIP-based network 12.

Fig. 7 illustrates another advantageous signaling flow that is implemented in one or more embodiments herein. Namely, to ensure that communicative links based on the SIP-based network 12 are established or re-established automatically, the SIP gateways 18 are configured to establish a permanent session, e.g., an IMS session, with the SIP-based network 12 at power up. Thus, whenever a SIP gateway 18 in such embodiments is turned on, rebooted, or otherwise restarted, it automatically establishes a session with the SIP-based network 12.

Fig. 8 illustrates a further signaling example. In this example, a first M2M SE 70-1 supports a first M2M AE 72-1, and the first M2M SE 70-1 is associated with a first SIP gateway 18-1. A second M2M SE 70-2 supports a second M2M AE 72-2, and the second M2M SE 70-2 is associated with a second SIP gateway 18-2. In other words, the first M2M AE 72-1 operates in a first localized domain 16-1 of the first SIP gateway 18-1 and the second M2M AE 72-2 operates in a second localized domain 16-2 of the second SIP gateway 18-2. Thus, any M2M signaling going between the M2M AEs 72-1 and 72-2 represents non-local M2M signaling that is routed through the SIP-based network 12 in advantageous fashion, according to the teachings herein. It is also assumed that each AE 72 registered successfully with its respective M2M SE 70.

At Step 1, the first M2M entity 72-1 originates a M2M request that targets the second M2M AE 72-2. At Step 23, the first M2M AE 72-1 receives a corresponding M2M response from the second M2M AE 72-2. The intervening Steps 2-22 illustrate mechanisms used to convey the outgoing M2M request and the correspondingly returned M2M response over the SIP-based network 12.

Of particular interest, at Step 2 the first SIP gateway 18-1 receives the M2M request and identifies its traffic type as being non-local— i.e., it recognizes the M2M request as targeting a M2M identity that is not within the localized domain 16-1 of the first SIP gateway 18-1. Thus, Step 3 includes the first SIP gateway 18-1 packaging the M2M request as a SIP message, e.g., encapsulating the M2M request in a SIP INFO message— see RFC 3261 and the appropriate extensions from the Internet Engineering Task Force, IETF, for example SIP details and message types.

The encapsulated signaling is sent at Step 4 to the SIP-based network 12, and provided to the M2M directory server 20 by the SIP-based network 12 at Step 5. At Step 6, the M2M directory server 20 performs M2M identity extraction from the encapsulated signaling and determines the targeted M2M entity 14, or at least determines the SIP gateway 18— here, 18-2— that is associated with the M2M entity 14 targeted by the encapsulated signaling.

The M2M directory server 20 provides the target information to the SIP-based network 12 at Step 7, and the SIP-based network 12 correspondingly routes the encapsulated signaling to the second SIP gateway 18-2 at Step 8. The second SIP gateway 18-2 performs message unpacking at Step 9— i.e., it extracts the SIP-encapsulated M2M signaling and forwards the extracted M2M request to the appropriate M2M SE 70-2 at Step 10, for delivery to the M2M AE 72-2. That delivery occurs at Step 11, the M2M AE 72-2 processes the M2M request at Step 12 and returns a corresponding M2M response at Step 13.

The M2M SE 70-2 forwards the M2M response to the second SIP gateway 18-2 at Step 14 and, in turn, the second SIP gateway 18-2 determines at Step 15 that the M2M response represents non-local M2M signaling and performs SIP encapsulation on it. The SIP-encapsulated M2M return message is sent at Step 16 to the SIP-based network 12, and forwarded by the SIP- based network 12 at Step 17 to the M2M directory server 20. At Step 18, the M2M directory server 20 extracts M2M identity information from the SIP-encapsulated M2M response and makes a target determination. The M2M directory server 20 provides the target information to the SIP-based network 12 at Step 19— e.g., it provides a SIP INFO message having the SIP gateway destination address of the first SIP gateway 18-1 and having the encapsulated M2M response message.

The SIP-based network 12 thus routes the SIP-encapsulated M2M response to the first SIP gateway 18-1 at Step 20, and the first SIP gateway 18-1 performs unpacking at Step 21, to recover the M2M response. At Step 22 the first SIP gateway 18-1 sends the M2M response to the M2M SE 70-1, according to normal M2M protocols, and the M2M SE 70-1 provides the M2M response to the M2M AE 72-1 at Step 23.

Note that the signal flow and processing in the example of Fig. 8 is directly adaptable to "asynchronous" contexts, which here denotes the case where the M2M response is sent later and/or where the M2M response does not necessarily follow the same route as the initiating M2M request.

As a further note, it is also contemplated herein that the M2M directory server 20 in some embodiments is configured to receive, process, and respond to direct inquiries regarding the binding information maintained by it. For example, in the context of Fig. 8, the M2M directory server 20 is interrogated by the SIP gateway 18-1 in the originating M2M network domain, to determine the target SIP gateway 18-2. Thus, Steps 4-8 would be replaced by a query request from the SIP gateway 18-1 to the M2M directory server 20 and the address of the SIP gateway 18-2 would be returned to the SIP gateway 18-1 in the response from the M2M directory server 20. The SIP gateway 18-1 inserts the returned address in its outgoing SIP request and sends the request to the SIP-based network 12, for forwarding to the SIP gateway 18-2. The same sort of query-based processing can be used in the reverse direction, with respect to Steps 14-18.

Fig. 9 illustrates a further example signal flow, involving multi-domain routing, where "domain" in this one example denotes overall M2M network domains, and not the localized domains 16 at issue in the discussion above. In Fig. 9, the M2M SE 70-1, the M2M IN-SE 74-1, and the SIP gateway 18-1 are associated with a first M2M network. On the other hand, the M2M SE 70-2, the M2M IN-SE 74-2, and the SIP gateway 18-2 are associated with a second M2M network. The M2M IN-SEs 74 shall be understood as being top-level or anchor support nodes within their respective M2M networks.

At Step 1, the M2M SE 70-1 outputs or otherwise forwards a M2M request directly or indirectly targeting the M2M SE 70-2 in the second M2M network. At Step 2, the SIP gateway 18-1 determines that the request targets a M2M entity 14 that is outside of the domain of the first M2M network 10-1 and it consequently forwards, at Step 3, the M2M request to the top-level M2M SE of the first M2M network 10-1, which in this example is denoted as IN-SE 74-1. Notably, the M2M request here may be forwarded in its native M2M signaling format, and thus may be "normally" processed by the IN-SE 74-1.

At Step 4, the IN-SE 74-1 uses inter-domain signaling to send the M2M request to the second M2M network 10-2, e.g., based on using Domain Name System, DNS, services. At Step 5, the top-level IN-SE 74-2 of the second M2M network 10-2 forwards the M2M request to a SIP gateway 18-2 in the second M2M network 10. This can be any SIP gateway 18 the IN-SE 74-2 is aware of.

At Step 6, the SIP gateway 18-2 encapsulates the M2M request as a SIP message and forwards the SIP-encapsulated M2M request towards the SIP-based network 12 at Step 7, such as in a SIP INFO message. At Step 8, the SIP-based network 12 conveys the SIP-encapsulated message to the M2M directory server 20, which extracts the relevant M2M identifier(s) from it. The M2M directory server 20 then uses its binding information at Step 9 to identify the M2M SE 70 within the second M2M network 10-2 that is targeted directly or indirectly by the M2M request— here, M2M SE 70-2. In an example of the M2M SE 70-2 being "indirectly" targeted by the M2M request, the M2M request targets a given M2M entity 14, e.g., an AE 72, that is reachable through the M2M SE 70-2.

In any case, the M2M directory server 20 at Step 10 sends, via the SIP-based network 12, the SIP-encapsulated M2M request message towards the SIP gateway 18 that is affiliated with the targeted M2M SE 70, which in this example is the SIP gateway 18-2. This can be a different SIP gateway 18 than the SIP gateway 18 in step 5. In this example, it is the same. At Step 11, the SIP-based network 12 forwards the SIP-encapsulated M2M request message to the SIP gateway 18-2, and at Step 12 the message is sent to the IN-SE 74-2, which forwards it to the M2M SE 70-2 at Step 13.

Fig. 10 illustrates an apparatus 100 configured for operation in the context of the SIP gateway processing described herein. For example, the apparatus 100 represents functional processing circuitry implemented via the processing circuitry 34 of the SIP gateway 18 introduced in Fig. 1.

The apparatus 100 includes a M2M communication module 102 that is configured to receive a M2M request message from a M2M entity 14 within a localized domain 16 of the SIP gateway 18, where a target of the M2M request message is not within the localized domain 16 of the SIP gateway 18. The apparatus 100 further includes an encapsulation module 104 that is configured to encapsulate the M2M request message in an outgoing SIP message, and a SIP communication module 106 that is configured to send the outgoing SIP message towards a M2M directory server 20 that is reachable via a SIP-based network 12 associated with the M2M network 10. The SIP communication module 106 is further configured to receive a return SIP message that includes a M2M response message corresponding to the M2M request message, and the SIP apparatus 100 further includes an extraction module 108 that is configured to extract the M2M response message from the return SIP message and forward, via the M2M

communication module 102, the M2M response message towards the local M2M entity 14 from which the M2M request message was received.

Fig. 11 illustrates an apparatus 110 that is configured for operation as a M2M directory server 20 configured to provide directory services within a M2M network 10. For example, the apparatus 110 represents functional processing circuitry implemented via the processing circuitry 54 of the M2M directory server 10 introduced in Fig. 1.

The apparatus 110 in the illustrated embodiment includes a SIP communication module 112 that is configured to communicatively couple the M2M directory server 20 to a SIP-based network 12. The apparatus 110 further includes a maintaining module 114 that is configured to maintain binding information that logically associates M2M SEs 70 in the M2M network 10 with respective SIP gateways 18 that are used to communicatively couple distributed M2M SEs 70 via the SIP-based network 12. As noted, more generally, the maintaining module 114 may maintain binding information for all globally addressable M2M entities 14 in the M2M network 10, to maintain a mapping between each such M2M entity 14 and its associated SIP gateway 18.

Still further, the apparatus 110 includes an extraction module 116 that is configured to extract a M2M identity of a targeted M2M entity 14 from an incoming SIP message received from the SIP-based network 12. Here, it will be appreciated that the incoming SIP message encapsulates a M2M message targeted to a given M2M entity referred to in this context as the "targeted" M2M entity 14.

The apparatus 110 correspondingly includes an identification module 118 that is configured to identify a target SIP gateway 18 for the incoming SIP message by indexing into the binding information with the extracted M2M identity. Additionally, the apparatus 110 includes a forwarding module 120 that is configured to forward the incoming SIP message towards the target SIP gateway 18, via the SIP communication module 112, for decapsulation and delivery to the targeted M2M entity 14.

The apparatus 110 in at least some embodiments also includes a "backhaul" or other interface that is provided for communicating directly with M2M SEs 70, or with one or more other nodes in the M2M network 10, for receiving information indicating the associations between M2M entities 14 in the M2M network 10 and the corresponding SIP gateways 18 with which those M2M entities 14 are associated. For example, the apparatus 110 receives information indicating the SIP gateway associations of any M2M entity 14 within the M2M network 10 that is intended to be globally addressable within the M2M network 10.

Notably, modifications and other embodiments of the disclosed invention(s) will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention(s) is/are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

CLAIMS What is claimed is:

1. A method (300) of operation in a Session Initiation Protocol, SIP, gateway (18) configured for operation in a Machine-to-Machine, M2M, network (10), said method (300) comprising:

receiving (302), via a M2M communication interface (30) of the SIP gateway (18), a

M2M request message from a M2M entity (14) within a localized domain (16) of the SIP gateway (18), wherein a target of the M2M request message is not within the localized domain (16) of the SIP gateway (18);

encapsulating (304) the M2M request message in an outgoing SIP message;

sending (306), via a SIP communication interface (32) of the SIP gateway (18), the

outgoing SIP message towards a M2M directory server (20) that is reachable via a SIP-based network (12) associated with the M2M network (10); receiving (308), via the SIP communication interface (32), a return SIP message that includes a M2M response message corresponding to the M2M request message; extracting (310) the M2M response message from the return SIP message; and forwarding (312), via the M2M communication interface (30), the M2M response

message towards the local M2M entity (14) from which the M2M request message was received.

2. The method (300) of claim 1 , wherein sending (306) the outgoing SIP message towards the M2M directory server (20) comprises sending the outgoing SIP message towards a Call Session Control Function, CSCF, node (22) in an Internet Protocol Multimedia Subsystem, IMS, core network as said SIP-based network (12), for forwarding towards the M2M directory server (20).

3. The method (300) of claim 2, wherein sending (306) the outgoing SIP message towards the CSCF node (22) comprises sending the outgoing SIP Message to a Proxy CSCF, P-CSCF, in the IMS core network to which the SIP gateway (18) is communicatively coupled through the SIP communication interface (32).

4. The method (300) of any of claims 1-3, wherein encapsulating (304) the M2M request message in the outgoing SIP message comprises packaging the M2M request message in an outgoing SIP INFO message.

5. The method (300) of any of claims 1-4, further comprising establishing or re-establishing a session with the SIP-based network (12) upon a power-up or a reboot of the SIP gateway (18).

6. The method (300) of any of claims 1-5, wherein the local M2M entity (14) comprises a first M2M Support Entity, SE (70-1).

7. The method (300) of claim 6, wherein the first M2M SE (70-1) is one of a two or more local M2M SEs (70) that are within the localized domain (16) of the SIP gateway (18) and wherein the method further comprises the SIP gateway (18) acting as a relay for M2M signaling going between respective ones of the local M2M SEs (70).

8. The method (300) of any of claims 1-7, further comprising relaying local M2M traffic in non-encapsulated form according to M2M protocols and forwarding non-local M2M traffic in encapsulated form according to SIP protocols, wherein the local M2M traffic comprises given M2M signaling that is received by the SIP gateway (18) on the M2M communication interface (30) and that is going between respective M2M entities (14) within the localized domain (16) of the SIP gateway (18), and wherein the non-local M2M traffic comprises given M2M signaling that is received by the SIP gateway (18) on the M2M communication interface (30) and that targets any given M2M entity (14) that is outside the localized domain (16) of the SIP gateway (18).

9. The method (300) of claim 8, further comprising maintaining data at the SIP gateway (18) indicating the M2M identities of the M2M entities (14) that are local to the SIP gateway (18), and determining whether any given M2M signaling received at the SIP gateway (18) via the M2M communication interface (30) comprises local M2M traffic or non-local M2M traffic, based on determining whether or not a target of the given M2M signaling matches one of the local M2M identities.

10. The method (300) of claim 9, further comprising maintaining registration data (42) at the SIP gateway (18) as said data, to retain the M2M identities of the M2M entities that are registered within the localized domain (16) of the SIP gateway (18) and the corresponding M2M-SE.

11. The method (300) of any of claims 1-10, further comprising:

receiving an incoming SIP message via the SIP communication interface (32); extracting an incoming M2M request message from the incoming SIP message;

determining a target of the incoming M2M request message within the localized domain

(16) of the SIP gateway (18);

forwarding the incoming M2M request message towards the target, via the M2M

communication interface (30);

receiving, via the M2M communication interface (30), an incoming M2M response

message corresponding to the forwarded incoming M2M request message;

encapsulating the incoming M2M response message in a corresponding outgoing SIP message; and

sending the corresponding outgoing SIP message towards the M2M directory server (20), via the SIP communication interface (32) of the SIP gateway (18).

12. The method (300) of claim 1, wherein the method (300) further comprises receiving a further M2M request message originating within the localized domain (16) of the SIP gateway (18) and targeting a M2M entity (14) that is outside the localized domain (16) of the SIP gateway (18), interrogating the M2M directory server 20 for SIP addressing information for the SIP gateway (18) that is associated with the targeted M2M entity (14), encapsulating the further M2M request message in an outgoing SIP message and sending the outgoing SIP message towards the SIP gateway (18) that is associated with the targeted M2M entity (14), according to the SIP addressing information returned by the M2M directory server (20).

13. A Session Initiation Protocol, SIP, gateway (18) configured for operation in a Machine - to-Machine, M2M, network (10), said SIP gateway (18) comprising:

a M2M communication interface (30) configured for sending and receiving M2M

signaling;

a SIP communication interface (32) configured for sending and receiving SIP signaling; and

processing circuitry (34) operatively associated with the M2M and SIP communication interfaces (30, 32) and configured to:

receive, via the M2M communication interface (30), a M2M request message from a M2M entity (14) within a localized domain (16) of the SIP gateway (18), wherein a target of the M2M request message is not within the localized domain (16) of the SIP gateway (18);

encapsulate the M2M request message in an outgoing SIP message; send, via the SIP communication interface (32), the outgoing SIP message towards a M2M directory server (20) that is reachable via a SIP-based network (12) associated with the M2M network (10);

receive, via the SIP communication interface (32), a return SIP message that includes a M2M response message corresponding to the M2M request message;

extract the M2M response message from the return SIP message; and forward, via the M2M communication interface (30), the M2M response message towards the local M2M entity (14) from which the M2M request message was received.

14. The SIP gateway (18) of claim 13, wherein the processing circuitry (34) is configured to send the outgoing SIP message towards the M2M directory server (20) by sending the outgoing SIP message towards a Call Session Control Function, CSCF, node (22) in an Internet Protocol Multimedia Subsystem, IMS, core network as said SIP-based network (12), for forwarding towards the M2M directory server (20).

15. The SIP gateway (18) of claim 14, wherein the processing circuitry (34) is configured to send the outgoing SIP message towards a Proxy CSCF, P-CSCF in the IMS core network, to which the SIP gateway (18) is communicatively coupled through the SIP communication interface (32).

16. The SIP gateway (18) of any of claims 13-15, wherein the processing circuitry (34) is configured to encapsulate the M2M request message in the outgoing SIP message by packaging the M2M request message in an outgoing SIP INFO message.

17. The SIP gateway (18) of any of claims 13-16, wherein the processing circuitry (34) is configured to establish or re-establish a session with the SIP-based network (12) upon a power- up or a reboot of the SIP gateway (18).

18. The SIP gateway (18) of any of claims 13-17, wherein the local M2M entity (14) comprises a first M2M Support Entity, SE (70-1).

19. The SIP gateway (18) of claim 18, wherein the first M2M SE (70-1) is one of a two or more local M2M SEs (70) that are within the localized domain (16) of the SIP gateway (18), and wherein the processing circuitry (34) is configured to relay M2M signaling going between respective ones of the local M2M SEs (70).

20. The SIP gateway (18) of any of claims 13-19, wherein the processing circuitry (34) is configured to relay local M2M traffic in non-encapsulated form according to M2M protocols and forward non-local M2M traffic in encapsulated form according to SIP protocols, wherein the local M2M traffic comprises given M2M signaling that is received by the SIP gateway (18) on the M2M communication interface (30) and that is going between respective M2M entities (14) within the localized domain (16) of the SIP gateway (18), and wherein the non-local M2M traffic comprises given M2M signaling that is received by the SIP gateway (18) on the M2M communication interface (30) and that targets any given M2M entity (14) that is outside the localized domain (16) of the SIP gateway (18).

21. The SIP gateway (18) of claim 20, wherein the processing circuitry (34) is configured to maintain data at the SIP gateway (18) indicating the M2M identities of the M2M entities (14) that are local to the SIP gateway (18), and determine whether any given M2M signaling received at the SIP gateway (18) via the M2M communication interface (30) comprises local M2M traffic or non-local M2M traffic, based on determining whether or not a target of the given M2M signaling matches one of the local M2M identities.

22. The SIP gateway (18) of claim 21, wherein the processing circuitry (34) is configured to maintain registration data (42) at the SIP gateway (18) as said data, to retain the M2M identities of the M2M entities (14) that are registered within the localized domain (16) of the SIP gateway (18) and the corresponding M2M-SE.

23. The SIP gateway (18) of any of claims 13-22, wherein the processing circuitry (34) is configured to:

receive an incoming SIP message via the SIP communication interface (32) of the SIP gateway (18);

extract an incoming M2M request message from the incoming SIP message;

determine a target of the incoming M2M request message within the localized domain

(16) of the SIP gateway (18);

forward the incoming M2M request message towards the target, via the M2M

communication interface (30) of the SIP gateway (18); receive, via the M2M communication interface (30), an incoming M2M response message corresponding to the forwarded incoming M2M request message;

encapsulate the incoming M2M response message in a corresponding outgoing SIP

message; and

send the corresponding outgoing SIP message towards the M2M directory server (20), via the SIP communication interface (32) of the SIP gateway (18).

24. The SIP gateway (18) of claim 13, wherein the processing circuitry (34) is configured to receive a further M2M request message originating within the localized domain (16) of the SIP gateway (18) and targeting a M2M entity (14) that is outside the localized domain (16) of the SIP gateway (18), interrogate the M2M directory server 20 for SIP addressing information for the SIP gateway (18) that is associated with the targeted M2M entity (14), encapsulate the further M2M request message in an outgoing SIP message and send the outgoing SIP message towards the SIP gateway (18) that is associated with the targeted M2M entity (14), according to the SIP addressing information returned by the M2M directory server (20).

25. A method (400) at a Machine-to-Machine, M2M, directory server (20) of providing directory services within a M2M network (10), said method (400) comprising:

maintaining (402) binding information that logically associates M2M entities (14) in the M2M network (10) with respective Session Initiation Protocol, SIP, gateways (18) that are used to communicatively couple distributed M2M entities (14) via a SIP-based core network (12);

receiving (404) an incoming SIP message from the SIP-based network (12), wherein the incoming SIP message encapsulates a M2M message targeted to a M2M entity (14);

extracting (406) a M2M identity of the targeted M2M entity (14) from the incoming SIP message;

identifying (408) a target SIP gateway (18) for the incoming SIP message, by indexing into the binding information with the extracted M2M identity; and forwarding (410) the incoming SIP message towards the target SIP gateway (18), for decapsulation and delivery to the targeted M2M entity (14).

26. The method (400) of claim 25, further comprising obtaining the binding information, based on receiving signaling for respective ones of the M2M entities (14), said signaling identifying M2M entity (14) and the SIP gateway (18) associated with each M2M entity (14).

27. The method (400) of claim 25, wherein each SIP gateway (18) defines a localized domain (16) within the M2M network (10), and wherein the binding information includes identifiers for any M2M entities (14) within each localized domain (16) that are globally addressable within the M2M network (10).

28. The method (400) of any of claims 25-27, wherein the method (400) further includes receiving a query from a given SIP gateway (18) that includes a M2M identity, identifying which SIP gateway (18) is associated with the M2M identity, based on the binding information, and sending a query response to the given SIP gateway (18) that indicates the associated SIP gateway (18).

29. A Machine-to-Machine, M2M, directory server (20) configured to provide directory services within a M2M network (10), said M2M directory server (20) comprising:

one or more communication interfaces (50), including a least a Session Initiation

Protocol, SIP, interface configured for communicatively coupling the M2M directory server (20) to a SIP-based network (12); and

processing circuitry (54) operatively associated with the one or more communication interfaces (50) and configured to:

maintain binding information that logically associates M2M entities (14) in the M2M network (10) with respective SIP gateways (18) that are used to communicatively couple distributed M2M entities (14) via the SIP-based network (12);

receive an incoming SIP message from the SIP-based network (12), wherein the incoming SIP message encapsulates a M2M message targeted to a M2M entity (14);

extract a M2M identity of the targeted M2M entity (14) from the incoming SIP message;

identify a target SIP gateway (18) for the incoming SIP message by indexing into the binding information with the extracted M2M identity; and forward the incoming SIP message towards the target SIP gateway (18), for decapsulation and delivery to the targeted M2M entity (14).

30. The M2M directory server (20) of claim 29, wherein the processing circuitry (54) is configured to obtain the binding information based on receiving signaling for respective ones of the M2M entities (14), said signaling identifying each M2M entity (14) and the SIP gateway (18) associated with each such M2M entity (14).

31. The M2M directory server (20) of claim 29, wherein each SIP gateway (18) defines a localized domain (16) within the M2M network (10), and wherein the binding information includes identifiers for any M2M entities (14) within each localized domain (16) that are globally addressable within the M2M network (10).

32. The M2M directory server (20) of any of claims 29-31, wherein the one or more communication interfaces (50) are configured to receive a query from a given SIP gateway (18) that includes a M2M identity, and wherein the processing circuitry (54) is configured to identify which SIP gateway (18) is associated with the M2M identity, based on the binding information, and to send a query response to the given SIP gateway (18) that indicates the associated SIP gateway (18).

33. An apparatus (100) configured for operation as a Session Initiation Protocol, SIP, gateway (18) in a Machine-to-Machine, M2M, network (10), said apparatus (100) comprising: a M2M communication module (102) configured to receive a M2M request message from a M2M entity (14) within a localized domain (16) of the SIP gateway (18), wherein a target of the M2M request message is not within the localized domain (16) of the SIP gateway (18);

an encapsulation module (104) configured to encapsulate the M2M request message in an outgoing SIP message;

a SIP communication module (106) configured to send the outgoing SIP message

towards a M2M directory server (20) that is reachable via a SIP-based network (12) associated with the M2M network (10), and further configured to receive a return SIP message that includes a M2M response message corresponding to the M2M request message;

an extraction module (108) configured to extract the M2M response message from the return SIP message and forward, via the M2M communication module (102), the M2M response message towards the local M2M entity (14) from which the M2M request message was received.

34. An apparatus (110) configured for operation as a Machine-to- Machine, M2M, directory server (20) configured to provide directory services within a M2M network (10), said apparatus (110) comprising:

a Session Initiation Protocol, SIP, communication module (112) configured to

communicatively couple the M2M directory server (20) to a SIP-based network (12); and

a maintaining module (114) configured to maintain binding information that logically associates M2M entities (14) in the M2M network (10) with respective SIP gateways (18) that are used to communicatively couple distributed M2M entities (14) via the SIP-based network (12);

an extraction module (116) configured to extract a M2M identity of a targeted M2M entity (14) from an incoming SIP message received from the SIP-based network (12), wherein the incoming SIP message encapsulates a M2M message targeting the targeted M2M entity (14);

an identification module (118) configured to identify a target SIP gateway (18) for the incoming SIP message by indexing into the binding information with the extracted M2M identity; and

a forwarding module (120) configured to forward the incoming SIP message towards the target SIP gateway (18), via the SIP communication module (112), for decapsulation and delivery to the targeted M2M entity (14).