WO2017168209A1

WO2017168209A1 - Reachability for an m2m service provider network

Info

Publication number: WO2017168209A1
Application number: PCT/IB2016/051803
Authority: WO
Inventors: George Foti
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-03-30
Filing date: 2016-03-30
Publication date: 2017-10-05

Abstract

A reachability server (26) interfaces with a machine-to-machine, M2M, service provider, SP, network and an access network (14) which provides data transport services for the M2M SP network. The reachability server (26) tracks reachability, from the perspective of the access network (14), of a particular M2M application instance (18) executed on an M2M device (10), based on correlating attachment of the M2M device (10) to the access network (14) and registration of the particular M2M application instance (18) with the M2M SP network. The reachability server (26) sends reachability information to a triggering node (30) in the M2M SP network indicating the tracked reachability for the particular M2M application instance (18). The triggering node (30) may receive this reachability information based on a device-agnostic pushing or pulling of the information. The triggering node (30) then triggers the particular M2M application instance (18) using the reachability information.

Description

REACHABILITY FOR AN M2M SERVICE PROVIDER NETWORK

TECHNICAL FIELD

The present application relates generally to machine-to-machine (M2M) communication, and particularly to reachability by an M2M service provider network.

BACKGROUND

Machine-to-machine (M2M) devices include devices whose end-to-end communication is not necessarily triggered by a user, at least not explicitly. An M2M device may for instance reply to a request for data contained within the device itself, or may transmit data contained within the device autonomously. M2M communication is typically initiated by an instance of an application residing on an M2M device to gather or send information to an instance of a counterpart application on another M2M node, such as the infrastructure of an M2M service providers network. As one example, an instance of an application on an M2M sensor may sense temperature and transmit that temperature through a network to an instance of a counterpart application on an M2M server that translates the temperature into meaningful information (for example, the temperature is too high). M2M is thereby a paradigm in which end- to-end communication is executed without human intervention so as to, for instance, connect non-IT objects to an IT infrastructure. M2M devices are also known as M2M nodes or machine type communication (MTC) devices.

Device triggering is a means by which a network application in the M2M service providers network sends information to an M2M device to perform a specific task. This may be because the M2M Service provider preference is to be in control of all communications from the M2M Devices to the M2M application server, and does not allow M2M Devices to randomly access the M2M application server, or because of the nature of the M2M application that for example requires pushing instructions to the M2M devices. The device triggering may be used to wake up an M2M device from a dormant state. Current device triggering mechanisms require the underlying access network to perform triggering at the device level. The network application therefore must conventionally send a triggering request that identifies the M2M device (e.g., in the form of a Mobile Station International Subscriber Directory Number, MSISDN). Conventional triggering approaches thereby impose a requirement on a network application to identify the M2M device from the access network's perspective.

SUMMARY

According to one or more embodiments herein, triggering is performed on an M2M application level as opposed to an M2M device level. A reachability server facilitates this application-level triggering by tracking the reachability of a particular instance of an M2M application from the perspective of an access network. In at least some embodiments, this reachability tracking insulates a network application from details about the reachability of an M2M device on which the M2 application instance is executed. Moreover, the network application is not required to know or maintain the device identity used by the particular instance of the M2M application. This in turn enables the network application to trigger the M2M application instance in a device-agnostic manner, e.g., without knowing the MSISDN for the device or other device-level reachability information.

More particularly, embodiments herein include a method performed by a reachability server that interfaces with a machine-to-machine, M2M, service provider, SP, network and an access network which provides data transport services for the M2M SP network. The method comprises tracking reachability, from the perspective of the access network, of a particular M2M application instance executed on an M2M device, based on correlating attachment of the M2M device to the access network and registration of the particular M2M application instance with the M2M SP network. The method also comprises sending reachability information to a triggering node in the M2M SP network indicating the tracked reachability for the particular M2M application instance.

In some embodiments, this tracking comprises receiving, from a node in the access network, access information associated with attachment of the M2M device to the access network. In this case, tracking may also entail receiving, from a node in the M2M SP network, access-related registration information indicated as being that with which the particular M2M application instance registered with the M2M SP network. Tracking may further comprise determining that a value of an information parameter included in the access-related registration information corresponds to a value of an information parameter included in the access information, and mapping the access information to the particular M2M application instance, based on that determining.

In one or more embodiments, this determining comprises determining that a value of an information parameter included in the access-related registration information is the same as a value of the same information parameter included in the access information. In this and other embodiments, the information parameter included in the access information and the information parameter included in the access-related registration information may both be an Internet Protocol (IP) address. Alternatively or additionally, the access information may comprise at least one of a Mobile Station International Subscriber Directory Number (MSISDN), an International Mobile Subscriber Identity (IMSI), and a Network Access Identifier (NAI). In this and other embodiments, the access-related registration information may be accompanied by an identifier of the M2M application and an identifier of the particular M2M application instance.

In some embodiments, the reachability information may be sent to the triggering node based on a device-agnostic pushing or pulling of the reachability information from the reachability server to the triggering node. Alternatively or additionally, the method may comprise storing access information associated with attachment of different M2M devices to the access network in different records indexed by respective IP addresses. In this case, the method may also comprise receiving access-related registration information that includes an IP address accompanied by an identifier of an M2M application and an identifier of a particular M2M application instance. The method may further comprise identifying a record indexed by the IP address included in the access- related registration information, and mapping the identified record to the identifier of an M2M application and the identifier of a particular M2M application instance accompanying the access- related registration information.

In some embodiments, tracking this reachability may entail dynamically updating the reachability upon at least one of: the M2M device detaching from the access network, the particular M2M application instance de-registering with the M2M SP network, and the M2M device entering or exiting a dormant state.

Other embodiments herein include a method performed by a triggering node in a machine-to-machine, M2M, service provider, SP, network that is provided data transport services by an access network. The method comprises receiving reachability information from a reachability server indicating reachability, from the perspective of the access network, of the particular M2 application instance executed on an M2M device. The method further comprises triggering the particular M2M application instance using the reachability information.

In one or more embodiments, reception of the reachability information is based on a device-agnostic pushing or pulling of the reachability information from the reachability server to the triggering node.

In some embodiments, this method further comprises identifying the reachability server based on an identifier of the access network to which the M2M device is attached and/or an identifier of a country in which the M2M device is located.

In some embodiments, the reachability information to be pushed or pulled is identified based on an identifier of an M2M application and an identifier of the particular M2M application instance, instead of an identifier of the M2M device or an identifier of a subscriber associated with the M2M device.

Alternatively or additionally, the triggering is performed responsive to a device-agnostic triggering request from a network application.

In any of the above described embodiments, the triggering node may be configured to trigger the particular M2M application instance by waking up the particular M2M application instance from a dormant state.

Also in any of the above described embodiments, the reachability information may indicate an identifier at which the particular M2M application instance is reachable from the perspective of the access network. In this case, the identifier may be a device identifier that identifies the M2M device or a subscriber identifier that identifies a subscriber associated with the M2M device. In this and other embodiments, the identifier may be a Mobile Station

International Subscriber Directory Number (MSISDN).

Alternatively or additionally, the reachability information may comprise at least one of reachability method and reachability status indicating whether or not the M2M device is reachable through the access network.

Alternatively or additionally, the reachability information may indicate via which of different possible methods the particular M2M application instance is reachable from the perspective of the access network. In this and other embodiments, the reachability information may indicate via which of a user plane and a control plane the particular M2M application instance is reachable from the perspective of the access network.

Embodiments also include a method performed by a registrar node in a machine- to- machine, M2M, service provider, SP, network. The method comprises receiving a registration request for registering a particular M2M application instance with the registrar node, wherein the registration request includes registration information with which the particular M2M application instance requests registration. The method further comprises, responsive to the request and using the registration information, registering the particular M2M application instance with the registrar node. The method also comprises sending to a reachability server at least some of the registration information that is access-related and indicating that the access-related registration information is for the particular M2M application instance. The access-related registration information comprises access information associated with attachment of an M2M device to the access network.

In some embodiments, the access-related registration information comprises an Internet Protocol (IP) address. Alternatively or additionally, this indicating comprises sending to the reachability server an identifier of an M2M application and an identifier of the particular M2M application instance.

Embodiments further include a method performed by a node in an access network which provides data transport services for a machine-to-machine, M2M, service provider, SP, network. The method comprises, responsive to a device attaching to the access network, determining that the device is an M2M device. The method also comprises, responsive to that determination, sending access information to a reachability server configured to track reachability of a particular M2M application instance executed on the M2M device. The access information is associated with attachment of the M2M device to the access network.

In some embodiments, the access information comprises an IP address, and at least one of a Mobile Station International Subscriber Directory Number (MSISDN), an International Mobile Subscriber Identity (IMS!), and a Network Access Identifier (NAI).

Embodiments herein further include corresponding apparatus, computer programs, and carriers associated with the above methods. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram of an M2M system according to one or more embodiments. Figure 2 is a call flow diagram illustrating processing performed by nodes in an M2M system according to one or more embodiments.

Figure 3 is a call flow diagram illustrating processing for device attachment in an M2M system according to one or more embodiments.

Figure 4A is a call flow diagram illustrating processing for application registration with a visited M2M service provider network in an M2M system according to one or more

embodiments.

Figure 4B is a call flow diagram illustrating processing for application registration with a home M2M service provider network in an M2M system according to one or more embodiments.

Figure 5 is a call flow diagram illustrating processing for device-agnostic triggering of an application entity according to one or more embodiments.

Figure 6 is a call flow diagram illustrating processing for triggering an application entity via an interworking function (IWF) according to one or more embodiments.

Figure 7 is a logic flow diagram of a method performed by a reachability server according to one or more embodiments.

Figure 8 is a block diagram of a reachability server according to one or more

embodiments.

Figure 9 is a block diagram of a reachability server according to one or more other embodiments.

Figure 10 is a logic flow diagram of a method performed by a triggering node according to one or more embodiments.

Figure 11 is a block diagram of a triggering node according to one or more

embodiments.

Figure 12 is a block diagram of a triggering node according to one or more other embodiments.

Figure 13 is a logic flow diagram of a method performed by a registrar node according to one or more embodiments.

Figure 14 is a block diagram of a registrar node according to one or more embodiments.

Figure 15 is a block diagram of a registrar node according to one or more other embodiments.

Figure 16 is a logic flow diagram of a method performed by an access network node according to one or more embodiments.

Figure 17 is a block diagram of an access network node according to one or more embodiments.

Figure 18 is a block diagram of an access network node according to one or more other embodiments. DETAILED DESCRIPTION

Figure 1 illustrates a machine-to-machine (M2M) device 10 that connects to an M2M service provider (SP) network 12 over an access network (AN) 14. The M2M device 10 in this regard first performs attachment 16 to the access network 14. As a result of attachment 16, the M2M device 10 is able to make use of the data transport services offered by the access network 14. Attachment 16 may for instance involve authentication of the M2M device 10, physical layer resource negotiation, IP address acquisition, and/or other access procedures that establish the reachability of the M2M device 10 from the perspective of the access network 14.

With the M2M device 10 attached to the underlying access network 14, a particular instance 18 of an M2M application executed on the M2M device 10 performs registration 20 with the M2M SP network 12, e.g., by registering with a registrar node 22 in the M2M SP network 12. As a result of registration 20, the particular application instance 18 is able to use the services offered by the 2M SP network 12.

For example, with the particular application instance 18 registered in this way, a network application 24 in the M2M SP network 12 may trigger the application instance 18, by sending information to the application instance 18 to perform a specific task. This task may be for example to wake up the application instance 18 from a dormant state, or to establish

communication towards the network application 24. One or more embodiments herein thereby advantageously facilitate application-level triggering, as opposed to device-level triggering.

Some embodiments enable the network application 24 to perform application-level triggering in a device-agnostic manner, e.g., without knowing the MSISDN for the M2M device 10 or other device-level reachability information (e.g., an external identifier, Ext-ID, in the oneM2M architecture). The embodiments do so even where device triggering must be performed in addition to application-level triggering (e.g., in order to wake up the particular application instance 18, the M2M device 10 itself must be woken up as well).

According to one or more embodiments in this regard, a reachability server 26 interfaces with the M2M SP network 12 and the access network 14. The reachability server 26 is configured to track reachability, from the perspective of the access network 14, of the particular instance 18 of the M2M application executed on the M2M device 10. In some embodiments, for example, the reachability tracked identifies the M2M device 10 where the particular application instance 18 is executed, reflects whether and/or how the M2M device 10 executing the particular instance 18 of the M2M application is reachable from the access network's

perspective, or the like. The reachability tracked may for instance indicate the M2M device's geographical location, the access technology type, and/or the available trigger delivery methods (such as for example SMS, paging, user plane push, etc). This reachability may be based on the time of day. That is, the reachability tracked in such embodiments characterizes device-level reachability of or associated with the particular application instance 18. The reachability server 26 may for example map reachability of the M2M device 10 (e.g., in the form of an MSISDN, network access identifier, internet IP address, or other device-level access information) to the particular application instance 18, e.g., so as to effectively index device-level reachability in terms of the application instance to which that reachability pertains.

Having tracked reachability of the particular application instance 18, the reachability server 26 sends reachability information 28 to a triggering node 30 in the M2M SP network 12 (e.g., an infrastructure common services entity, IN-CSE, in the oneM2M architecture). This reachability information 28 indicates the tracked reachability for the particular application instance 18.

For example, the reachability information determined and maintained by the reachability server may comprise identity and address of the M2M device 10 hosting the particular application instance 18, reachability status of the M2M device 10 hosting the application instance 18 and the reachability mode indicating the available trigger delivery methods (such as for example SMS, paging, user plane push, etc.). The reachability method may be based but not limited to the time of day, the device geographical location, the access technology type(s) used by the device and the access network conditions. If the access network 14 is congested, the reachability information may indicate that reachability status is temporarily unreachable. If the user plane nodes in the access network 14 are congested, the reachability information may indicate a reachability method based on SMS or any other control plane reachability method.

The reachability server may receive the necessary information to determine the reachability status and reachability method from other nodes in the access network reporting network conditions or node conditions, such as policy servers, user plane and control plane nodes.

In some embodiments, the reachability server 26 sends the reachability information 28 based on a device-agnostic pushing or pulling of that reachability information 28 from the reachability server 26 to the triggering node 30. When reachability information 28 is pulled from the reachability server 26, the triggering node 30 directly solicits that reachability information 28, e.g., at the time that the information 28 is desired, such as by sending an explicit request for that information 28. By contrast, when reachability information 28 is pushed from the reachability server 26 to the triggering node 30, no such direct solicitation occurs. Regardless, this pushing or pulling may be device-agnostic in the sense that the reachability information to be pushed or pulled is identified based on an identifier of the particular application instance 18 (and an identifier of the M2M application in embodiments where the instance identifier is not unique). The reachability information may be identified in this way instead of with an identifier of the M2M device 10 or an identifier of a subscriber associated with the M2M device 10.

In one embodiment, for example, the triggering node 30 sends a device-agnostic (pull) information request to the reachability server 26 to retrieve the reachability information 28 of the particular application instance 18. The request may be device-agnostic in the sense that it identifies the particular application instance 18 for which reachability information is requested, without identifying the particular M2M device 10. The triggering node 30 may send this device- agnostic information request to the reachability server 26 directly responsive to having in turn received a device-agnostic trigger request from a network application 24. This trigger request may also be device-agnostic because it simply identifies the particular application instance 18 for which triggering is requested, without identifying the particular 2M device 10.

In another embodiment, by contrast, the reachability server 26 sends (i.e., pushes) the reachability information 28 to the triggering node 30 without having received an explicit request for that information 28 from the triggering node 30. For example, the triggering node 30 may have previously subscribed to receive unsolicited reachability updates from the reachability server 26 pertaining to the particular application instance 18. The triggering node 30 may have subscribed to such updates at the time the particular application instance 18 performed registration. In this way, the triggering node 30 may proactively anticipate reachability changes and may dynamically receive updated reachability information when any changes to the reachability of the application instance 18 occur and are recorded by the reachability server 26. This way, when the triggering node 30 receives a device-agnostic triggering request, the triggering node 30 in some embodiments is able to directly perform triggering responsive to that request, without having to first request updated reachability information from the reachability server 26. Indeed, the triggering node 30 may have already received that updated reachability information before receiving the trigger request.

Whether pushed or pulled, therefore, the triggering node 30 may receive the reachability information 28 for the particular application instance 18 in a device-agnostic manner, e.g., without knowing the MSISDN for the M2M device 10 or other device-level reachability information. Correspondingly, the network application 24 may request that the triggering node 30 trigger the particular application instance 18 in a device-agnostic manner. In some embodiments, this insulates the network application 24 from device-level reachability, which may prove advantageous for example where that device-level reachability is not used, relevant, or available to the network application 24. The triggering node 30 may then trigger the particular application instance 18 using the reachability information 28, e.g., on behalf of or for the network application 24.

In some embodiments, the reachability server 26 tracks reachability of the particular application instance 18 based on correlating attachment 16 of the M2M device 10 to the access network 14 and registration 20 of the particular application instance 18 with the M2M SP network 12. The reachability server 26 may for example determine that the particular application instance 18 performed registration 20 with certain access-related registration information (e.g., an IP address) that corresponds to certain access information associated with the M2M device's attachment. Based on this correlation between device attachment and application registration, the reachability server 26 may map the access information associated with the M2M device's attachment to the particular application instance 18.

Figure 2 illustrates one or more embodiments in this regard. As shown, the M2M device 10 performs attachment 16 to the access network 14. Responsive to the device 10 attaching to the access network 14, a node 34 in the access network 14 (e.g., a packet data network gateway) determines that the device 10 is an M2 device (Block 36). Responsive to that determination, the access network node 34 sends access information 38 to the reachability server 26 configured to track reachability of the particular application instance 18. This access information 38 is associated with the attachment 16 of the M2M device 10 to the access network 14. The access information may include for example at least one of a Mobile Station

International Subscriber Directory Number (MSISDN), an International Mobile Subscriber Identity (IMSI), and a Network Access Identifier (NAI). The access information may further include an International Mobile Equipment Identity (IMEI) and/or an IP address.

After device attachment 16, the particular application instance 18 performs registration 20 with the M2M SP network 12. A registrar node 22 in the M2M SP network 12 correspondingly receives a registration request for registering the particular application instance 18 with the registrar node 22. This registration request includes registration information with which the particular application instance 18 requests registration. The registration information may include for instance an identifier of the particular application instance 18 and an M2M identifier of the registering node 10. The registration information also includes access-related registration information that comprises access information associated with the M2M device's attachment 16 to the access network 14, e.g., an IP address. Using this registration information, the registrar node 22 registers the particular application instance 18 with the registrar node 22 (Block 40). The registrar node 22 also sends to the reachability server 26 at least some of the registration information that is access-related 42. In doing so, the registrar node 22 indicates that this access-related registration information 42 is for the particular application instance 18, e.g., by sending the access-related registration information 42 accompanied by an identifier of the particular application instance 18 (and an identifier of the M2M application in embodiments where the instance identifier is not unique).

The reachability server 26 as shown is configured to track the reachability of the particular application instance 18 based on this access-related registration information 42, as well as the access information 38 associated with the M2M device's attachment 16 (Block 44). In some embodiments, for example, the reachability server 26 determines that the value of an information parameter included in the access-related registration information 42 corresponds to (e.g., is the same as) the value of an information parameter included in the access information 38. This determination suggests that the access information 38 characterizes (device-level) reachability of the particular application instance 18. The reachability server 26 therefore maps the access information 38 to the particular application instance 18 based on that determination. In some embodiments, the information parameter included in the access information 38 and the information parameter included in the access-related registration information 42 are parameters of different types, e.g. , such that derivation or conversion between different parameter types may be required in order to identify a correspondence. In other embodiments, though, the information parameters are the same.

In one embodiment, for example, the information parameter included in the access information 38 and the information parameter included in the access-related registration information 42 are both an IP address. In this embodiment, the reachability server 26 determines whether the value of the IP address included in the access-related registration information 42 is the same as the value of the IP address included in the access information 38.

The reachability server 26 may do so as part of an overall determination of which application instances map to which M2M devices, based on matching the IP addresses with which the application instances register to the IP addresses with which the M2M devices are attached. For example, the reachability server 26 may store access information associated with attachment of different M2M devices to the access network 14 in different records indexed by respective IP addresses. When the reachability server 26 receives access-related registration information that includes an IP address accompanied by an identifier of a particular application instance (and also an identifier of an M2M application), the reachability server 26 attempts to identify a record indexed by that IP address. In response to such identification, the reachability server 26 maps the identified record to the identifier of the particular application instance

(potentially in combination with the identifier of the M2M application) accompanying the access- related registration information. As will be explained in further embodiments, the reachability server could obtain and maintain reachability related information for the application instance such as the access technology type used by the device on which the application instance is hosted, the device identity and its address, the device type, etc.. Moreover it may keep track of the status of the device in the access network 14 and determine the best method to reach the device to trigger the application instance based on rules such as the time of day, the access technology type, the device status, the geographical area where the device is located and the access network conditions.

In any event, having tracked reachability of the particular application instance 18 (Block

44), the reachability server 26 sends the reachability information 28 to the triggering node 30. The reachability server 26 may do so based on a device-agnostic pushing or pulling of that information 28 to the triggering node.

In pulling embodiments, for example, the triggering node 30 may send a reachability information request 46 to the reachability server 26. The request 46 may be device-agnostic in the sense that it identifies the particular application instance 18 for which reachability information is requested, without identifying the particular M2M device 10. The triggering node 30 may send this request 46 directly responsive to having in turn received a trigger request 48 from a network application 24. This trigger request may also be device-agnostic because it simply identifies the particular application instance 18 for which triggering is requested, without identifying the particular M2M device 10.

In pushing embodiments, by contrast, the reachability server 26 sends (i.e., pushes) the reachability information 28 to the triggering node 30 without having received an explicit request for that information 28 from the triggering node 30 (i.e., requests 46 and 48 are not part of this embodiment). This may occur for example upon registration or upon a change in the application instance's reachability. As shown, when the triggering node 30 receives a device-agnostic triggering request 50, the triggering node 30 directly performs triggering responsive to that request, without having to first request reachability information from the reachability server 26. Indeed, the triggering node 30 already received that reachability information 28 before receiving the trigger request 50.

Whether the reachability information 28 is pushed or pulled from the reachability server 26, the triggering node 30 then triggers the particular application instance 18 using that reachability information 28 (Block 52).

As noted above, the reachability tracked may reflect whether and/or how the M2M device 10 executing the particular instance 18 of the M2M application is reachable from the access network's perspective. The reachability information in some embodiments is a device identifier that identifies the M2M device 10 or a subscriber identifier that identifies a subscriber associated with the M2M device 10. The identifier may for example be an MSISDN. In this case, the network application 24 may request the triggering node 30 to trigger a particular application instance 18 identified only by an identifier of that instance 18, without the network application 24 knowing the MSISDN of the M2M device 10. The reachability information 28 however extends in other embodiments to any identifier at which the particular application instance 18 is reachable from the perspective of the access network 14.

In still other embodiments, the reachability information 28 alternatively or additionally indicates via which of different possible methods the particular application instance 18 is reachable from the perspective of the access network 14. Different methods in this regard may include for example a Session Initiation Protocol (SIP) based method (e.g., via an IP Short Message Gateway, IP-SM-GW), a Short Messaging Service (SMS) method, or any other method specific to the underlying access network 14 and its capabilities. Similarly, the reachability information 28 may indicate via which of a user plane and a control plane the particular application instance 18 is reachable. Based on this reachability information, the triggering node 30 may determine the best method to reach the particular application instance 18 for triggering that instance 18. If the reachability information 28 indicates the instance 18 is reachable via the control plane, for example, the triggering node 30 may decide based on one or more rules to trigger the particular application instance 18 by sending an SMS to that instance 18 over the control plane. Note that in some embodiments the reachability server 26 tracks the instance's reachability on a dynamic basis. The reachability server 26 may for example dynamically update the tracked reachability upon the M2M device 10 detaching from the access network 14, to indicate that the M2M device 10 is not attached. The reachability server may alternatively or additionally dynamically update the tracked reachability upon the M2M device 10 entering or exiting a dormant state (e.g., such that awakening the instance 18 requires awakening the device 10 itself). Furthermore, the reachability server 26 may alternatively or additionally dynamically update the tracked reachability upon particular application instance 18

de-registering with the M2M SP network 12.

The reachability information 28 in these and other embodiments may therefore comprises a reachability status indicating whether or not the M2M device 10 is attached to the access network 14 and/or indicating whether or not the M2M device 10 is dormant from the perspective of the access network 14 (e.g., the device 10 may be attached, but dormant). The reachability server 26 may determine whether and/or how the particular application instance 18 is to be reached based on this reachability status, the access technology type (e.g. , WiFi™, LTE™, 5G, etc.), the time of day, access network conditions. As an example, if the device is simultaneously connected to two access technology types (e.g., WiFi and LTE), and one the access network is congested e.g., LTE, the reachability server 26 selects a reachability method that is supported by the access network type that is available, e.g., WiFi.

In some embodiments, though, instance reachability is tracked automatically and dynamically on the fly for the lifetime of the instance. Once the instance is de-registered, the instance's reachability ceases to be tracked. In this and other embodiments, reachability tracking herein proves advantageous in its simplicity of deployment. Indeed, reachability tracking herein does not require maintaining, obtaining, and deploying M2M external identifiers for the M2M devices (e.g., the M2M-Ext-IDs in oneM2M).

Note that in at least some embodiments the reachability server 26 performs as described above as part of serving one of multiple different access networks it is configured to serve. In one embodiment, for example, the reachability server 26 serves multiple different access networks within a defined geographical region (e.g., a country), with other reachability servers serving other geographical regions. Any given reachability server thereby tracks reachability of application instances that use certain access networks within a served geographic region.

A particular M2M application instance in these embodiments includes a geographical region identifier (e.g., a country name or code) in its M2M registration message. A registrar node and/or a triggering node may then identify which reachability server is to track that application instance's reachability, based on the geographical region identifier. In one embodiment, for example, a registrar node and/or a triggering node may perform a domain name system (DNS) query based on the geographical region identifier to locate the reachability server 26. In other embodiments, the reachability server 26 performs as described above as part of specifically serving the access network 14 alone. That is, the reachability server 26 is specific or dedicated to serving access network 14, with other reachability servers serving other access networks. In this case, a particular M2M application instance may include an access network identifier in its M2M registration message. A registrar node and/or a triggering node may then identify which reachability server is to track that application instance's reachability, based on the access network identifier. In one embodiment, for example, a registrar node and/or a triggering node may perform a DNS query based on the access network identifier.

In still other embodiments, a reachability server may serve either a defined geographical region or a specific access network. In this case, the M2M registration message may contain a geographical region identifier and/or an access network identifier. A registrar node and/or a triggering node may then attempt to identify a reachability server for the registering application instance based on one or both of the geographical region identifier and the access network identifier. For example, a DNS query based on the geographical region identifier may be performed first if included in the registration message. If the DNS query fails or if no

geographical region identifier was included in the registration message, a DNS query based on the access network may be performed.

Note also that the approach described above is applicable regardless of whether an application instance registers with a home M2M SP network or a visited M2M SP network. Figures 3-6 illustrate various embodiments in this regard in a oneM2M context. See. e.g., oneM2M Service Layer Core Protocol Specification (February 2016), which is incorporated by reference herein, for more details on the One M2M architecture.

The oneM2M architecture uses a layered model with entities, resources and/or objects residing in an application layer, common services layer, or a network services layer. An underlying network provides data transport services between entities in the OneM2M system .

An application entity (AE) in oneM2 resides at the application layer. Examples of the application entities can be an instance of a fleet tracking application, a remote blood sugar monitoring application, a power metering application, or a controlling application.

A common services entity (CSE) in oneM2M resides in the common services layer and represents an instantiation of a set of common services of the M2M environments. Such services are exposed to other entities through reference points Mca and Mcc. Examples of service functions offered by CSE include: Data Management, Device Management, M2M Subscription Management, and Location Services.

A network services entity (NSE) in oneM2M resides in the network services layer. A NSE provides services from the underlying network to the CSEs. Examples of such services include device management, location services and device triggering.

In these embodiments, a particular M2M application instance is referred to as an Application Entity (AE). Furthermore, a registrar node is shown in the form of a middle node common services entity (MN-CSE) or an infrastructure CSE (IN-CSE) in the home or visited domain. The triggering node is shown in the form of an IN-CSE in the home domain. The M2M device 10 may constitute an Application Dedicated Node, ADN, or an application resident on an Application Service Node, ASN, in oneM2M terminology. Note that oneM2M allows application to execute in a multitude of nodes.

As shown in Figure 3, the M2M device 10 performs attachment 16 to a serving access network (which may be in a visited or home domain). As part of attachment, a default bearer is established for the M2M device 10. The M2M device 10 also acquires an IP address. After this, a gateway (PGW) 50 in the serving access network directs or requests the reachability server 26 to create a record for the M2M device 10 in the reachability server 26. The gateway 50 may do this for example after determining that the attached device has an M2M subscription and after authenticating that subscription with the home network (Block 36). In any event, the gateway 50 in this regard sends a create record message 52 to the reachability server 26. This message 52 includes access information 38 associated with the M2M device's attachment 16. As shown for example the message 52 includes or otherwise indicates the IMEI, IMSI, MSISDN, and/or IP address associated with the attachment 16. The reachability server 26 stores all or some of this access information 38 as a record in memory associated with the reachability server 26. This record may be indexed for example using a specific parameter from the access information, e.g., using the IP address as an index. In any event, the reachability server 26 may send a confirmation or other response 56 back to the gateway 50 acknowledging record creation.

After attachment 16, an Application Entity (AE) 58 on the M2M device 10 may register with an M2M SP network. The M2M SP network with which the AE 58 registers may be either the AE's home M2M SP network (i.e., in a home domain) or a visited M2M SP network (i.e., in a visited domain) that is different than the home M2M SP network.

Figure 4A in this regard shows embodiments where the AE 58 registers with a visited M2M SP network. The AE 58 does so by sending an M2M register message 62 to a visited MN-CSE 60 in the visited M2M SP network. This M2M register message 62 as shown includes registration information in the form of an identifier of M2M device 10 (e.g., in the form of a CSE-ID or M2M-Node-ld depending on the M2M node type), and the IP address that the M2M device 10 acquired as part of attachment 16. The M2M register message 62 may also include an identifier of the AE (AE-ID) as shown, identifier of the access network (AN-ID), and/or an identifier of the country in which the AE 58 is located (Country ID).

The visited MN-CSE 60 then locates the AE's home M2M SP network (Block 64), e.g., based on at least some of the registration information included in the M2M register message 62. Having located the home M2M SP network, the visited MN-CSE 60 queries the home M2M SP network for the AE's profile, by sending a fetch profile message 68 to a home IN-CSE 66. This fetch profile message 68 as shown includes the AE-ID, an identifier of the associated M2M application (App-ID), an identifier of the visited M2M SP network (M2M SP ID), and the AN-ID and/or the Country ID.

In some embodiments, the home IN-CSE 66 locates the reachability server 26, e.g., based on information included in the fetch profile message 68. For example, the home IN-CSE 66 may perform a DSN query to locate the reachability server 26 associated with the AN-ID and/or the Country ID included in the fetch profile message 68, similar to that described above. In other embodiments, though, it is the visited MN-CSE 60 that locates the reachability server 26.

In at least some embodiments, the home IN-CSE 66 checks for the reachability server 26 location before registration of the AE 58 is accepted. If the home IN-CSE 66 fails to locate a reachability server 58 for the AE 58, the home IN-CSE 66 may cause profile fetching to fail, such that the visited MN-CSE 60 will reject the M2M registration.

The home IN-CSE 66 may also update the AE's profile based on information in the fetch profile message 68 (Block 72). For example, the home IN-CSE 66 in some embodiments updates the profile with information indicating the serving access network 14 and/or information indicating the serving M2M SP network (which in this case is the visited M2M SP network). This enables the home M2M SP network to know if the AE 58 is roaming and in which network. The home IN-CSE 66 then sends a response message 74 back to the visited MN-CSE 60. This response message 74 as shown includes profile information as well as the AE-ID allocated to the AE 58, if any. Alternatively, the AE-ID may be provided by the AE at M2M registration.

Having received this response message 74, the visited MN-CSE 60 stores the fetched profile (Block 76). The visited MN-CSE 60 also identifies the reachability server 26 serving the AE 58. In some embodiments, the home IN-CSE 66 informs the visited MN-CSE 60 of the reachability server's identification and/or location (e.g., in the form of an IP address). In other embodiments, though, the visited MN-CSE 60 itself dynamically discovers the reachability server 26 in a similar way to that described above for the home IN-CSE 66 (e.g., using DNS). In still other embodiments, the visited MN-CSE 60 is (pre)configured with an address of the reachability server 26.

Regardless of how the visited MN-CSE 60 locates the reachability server 26, the MN- CSE 60 sends the reachability server 26 at least some of the registration information for the AE 58 that is access-related. Figure 4A in this regard shows the visited MN-CSE 60 sending the reachability server 26 an update message 78 that includes the IP address with which the AE 58 performed M2M registration, e.g., the IP address included in the M2M register message 62. The update message 78 also includes the AE-ID so as to indicate that the IP address is associated with that AE 58.

The reachability server 26 then attempts to locate a record that has been indexed with the IP address included in the update record message 78, e.g., upon M2M device attachment. The reachability server 26 may for instance search the records stored in its associated memory for any record that includes that IP address. Responsive to finding such a record, the

reachability server 26 updates the found record with the AE-ID included in the update record message 78. In this way, the visited MN-CSE 60 effectively updates the reachability server 26 with the AE-ID information using the IP address as an index to locate the record for the M2M device associated with the AE-ID.

In some embodiments, the reachability server 26 returns a response 82 back to the visited MN-CSE 60, whereupon the visited MN-CSE 60 in turn sends a response 84 to the AE 58 acknowledging the registration. This enables the AE 58 to perform normal M2M operations which can be enforced by the visited MN-CSE 60 in accordance with the profile stored there in for the AE 58.

Figure 4B by contrast shows embodiments where the AE 58 registers with its home M2M SP network. The AE 58 does so by sending an M2M register message 86 to the home IN-CSE 66 in the home M2M SP network. This M2M register message 86 as shown includes registration information in the form of an identifier of M2M device 10 (e.g., in the form of a CSE-ID or M2M-Node-ld depending on the M2M node type), and the IP address that the M2M device 10 acquired as part of attachment 16. The M2M register message 86 may also include an identifier of the AE (AE-ID) as shown, identifier of the access network (AN-ID), an identifier of the country in which the AE 58 is located (Country ID), and/or any other information pertinent to registration.

The home IN-CSE 66 may also update the AE's profile based on information in the M2M registration message 86 (Block 88). For example, the home IN-CSE 66 in some embodiments updates the profile with information indicating the serving access network 14 and/or information indicating the serving M2M SP network (which in this case is the home M2M SP network). This enables the home M2M SP network to know if the AE 58 is roaming and in which network.

The home IN-CSE 66 also locates the reachability server 26. The home IN-CSE 66 in this regard may be (pre)configured with the reachability servers location. Alternatively, the home IN-CSE may dynamically discover the reachability server 26, e.g. , based on information included in the M2M register message 86. For example, the home IN-CSE 66 may perform a DSN query to locate the reachability server 26 associated with the AN-ID and/or the Country ID included in the M2M register message 86, similar to that described above.

In at least some embodiments, the home IN-CSE 66 checks for the reachability server 26 location before registration of the AE 58 is accepted. If the home IN-CSE 66 fails to locate a reachability server 58 for the AE 58, the home IN-CSE 66 may reject the M2M registration.

Regardless of how the home IN-CSE 66 locates the reachability server 26, the home IN-CSE 66 sends the reachability server 26 at least some of the registration information for the AE 58 that is access-related. Figure 4B in this regard shows the home IN-CSE 66 sending the reachability server 26 an update message 92 that includes the IP address with which the AE 58 performed M2M registration, e.g., the IP address included in the M2M register message 86. The update message 92 also includes the AE-ID so as to indicate that the IP address is associated with that AE 58.

The reachability server 26 then attempts to locate a record that has been indexed with the IP address included in the update record message 92 (Block 94), similar to that described above with respect to Figure 4A. The reachability server 26 may return a response 96 back to the home IN-CSE 66, whereupon the home IN-CSE 66 in turn sends a response 98 to the AE 58.

Note that the registration procedure in Figures 4A-4B proceeds in an analogous manner irrespective of whether the AE 58 registers with a MN-CSE or an IN-CSE. If the AE 58 registers with a MN-CSE, for example, the MN-CSE will fetch the AE's profile and store it. The home

M2M SP network in this case will store the fact that the AE 58 is roaming but is being served by an MN-CSE in the home M2M SP network.

Regardless of whether the AE 58 registers with a visited or home M2M SP network, Figures 4A-4B illustrate that after successful registration the reachability server 26 will have a record with the M2M device's access information, the IP address for the registered AE 58, and the AE-ID. This record may be exploited so that a network application is able to trigger the AE 58 in a device-agnostic manner.

Figure 5 in this regard shows that a network application 24 may send a trigger request 100 to the home IN-CSE 66 requesting triggering of the AE 58. This trigger request 100 as shown is device-agnostic in the sense that it simply identifies the AE 58 with its AE-ID, without identifying the M2M device 10. The home IN-CSE 66 correspondingly locates the reachability server that is serving the AE 58 and thereby has reachability information associated with that AE 58 (Block 102). In embodiments where serving networks are access network specific, for example, the home IN-CSE 66 may determine the serving access network associated with the AE-ID, based on the AE's profile. The home IN-CSE 66 may then locate the reachability server 26 associated with the serving access network.

Regardless of how the home IN-CSE 66 locates the reachability server serving the AE 58, the home IN-CSE 66 queries the located reachability server 26 for reachability information for that AE 58. The home IN-CSE 66 may for example send the reachability server 26 a retrieve access information message 104 that includes the AE-ID. The reachability server 26 may do so in a device-agnostic manner, by identifying only the AE 58 rather than the M2M device 10 itself. The reachability server 26 looks up reachability information associated with the provided AE-ID and returns a response 106 with that information. Figure 5 shows for example that the reachability information includes an MSISDN for the M2M device 10 and/or other device access relevant information.

Having retrieved this reachability information, the home IN-CSE 66 triggers the AE 58 (Block 108). The home IN-CSE 66 may do so indirectly via one or more other nodes, e.g., by sending a triggering command or request to one or more other nodes. Figure 6 illustrates one example in this regard in a context where the AE 58 registers with a visited M2M SP network. As shown, the home IN-CSE 66 interacts with a home interworking function (IWF) 1 14 to trigger the AE 58 using the Tsp reference point. The home IN-CSE 66 for example sends a trigger request 112 to the home IWF 1 14 associated with the home M2M SP network. This trigger request 112 may be for example a wake-up request.

Regardless, the trigger request 112 includes the AE-ID for AE 58 as well other access information. The access information may indicate for instance the serving access network and/or the serving M2M SP network. The home IWF 1 14 may use this access information to locate a visited IWF 118 associated with the visited M2M SP network (Block 116). Alternatively, the home IWF 1 14 may be (pre)configured with the visited IWF 1 18. In any event, the home IWF 1 14 then forwards the trigger request 1 12 to this visited IWF 1 18 as trigger request 120. The visited IWF 118 may then actually trigger 122 the AE 58, e.g., using conventional 3GPP procedures for such triggering.

When the AE 58 registers with the home M2M SP network, triggering proceeds in a similar manner as that shown in Figure 6, but without the involvement of a visited IWF.

ote that when an AE deregisters and/or when an M2M device detaches from the access network, the opposite takes place such that the reachability server's records are updated to reflect the AE's current reachability on a dynamic basis.

In general, therefore, some embodiments herein introduce a reachability server 26 that maintains reachability information for a particular AE residing on an M2M device, in a dynamic way so as to track changes in access network connectivity and state that affect reachability of the particular AE. The reachability server 26 may provide this reachability information for the AE upon request. This reachability information may for instance indicate the best method to reach the M2M device, the identity of the M2M device through which the AE has registered (e.g., MSISDN, IP address if user plane reachability, etc.) depending on access network capabilities, the status of the M2M device (e.g., dormant or not), routing information, or the like.

One or more embodiments create a binding between this reachability information (e.g. , in the form of a device IP address, state information etc.) and an AE. Accordingly, some embodiments herein generally facilitate application-level triggering as opposed to or instead of device-level triggering. That is, embodiments target the triggering of an AE, as opposed to targeting the triggering of an ASN or MN-CSE. By targeting the triggering of an AE residing or hosted on an M2M device, embodiments may expand triggering to any and all devices, even those that do not have a CSE. Also, some embodiments herein remove the need to maintain, obtain, and deploy external identifiers (e.g., M2M-Ext-IDs) for triggering, thereby simplifying and reducing the cost of deployment.

Note that while some of the Figures herein illustrate embodiments in the context of the oneM2M architecture, those embodiments extend likewise to other architectures besides oneM2M. Furthermore, although some embodiments have been described with reference to an MSISDN for an M2M device 10, embodiments are equally extendable to scenarios where devices are not allocated an MSISDN. In those cases, for example, an external device identifier may be used instead (e.g., an M2M-Ext-ID in oneM2M).

Still further, embodiments herein may be implemented using any sort of access network technology. For example, although some embodiments may use a Long Term Evolution (LTE) access network, embodiments may alternatively use a wireless local area network (WLAN) access with integrated evolved packet core (EPC).

Those skilled in the art will also appreciate that an M2M SP network herein may be the same as or different from an access network.

A machine-to-machine (M2M) device may also be referred to as a machine-type communications (MTC) device, a narrowband Internet of Things (NB-loT) device, etc. The M2M device may also be referred to as a user equipment (UE), however it should be noted that the UE does not necessarily have a "user" in the sense of an individual person owning and/or operating the device. In an IOT scenario, an M2M device as described herein may be, or may be comprised in, a machine or device that performs monitoring or measurements, and transmits the results of such monitoring measurements to another device or a network. Particular examples of such machines are power meters, industrial machinery, or home or personal appliances, e.g. refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a M2M device as described herein may be comprised in a vehicle and may perform monitoring and/or reporting of the vehicle's operational status or other functions associated with the vehicle.

In view of the above modifications and variations, those skilled in the art will appreciate that a reachability server 26 as described herein is generally configured to perform the method 200 in Figure 7. As shown, the method 200 comprises tracking reachability, from the

perspective of the access network 14, of a particular M2M application instance 18 executed on an M2M device 10 (Block 210). This tracking in some embodiments is based on correlating attachment of the M2M device 10 to the access network 14 and registration of the particular M2M application instance 18 with the M2M SP network. The method 200 also comprises sending reachability information to a triggering node 30 in the M2M SP network indicating the tracked reachability for the particular M2M application instance 18 (Block 220).

Note that the reachability server 26 as described above may perform any of the processing herein by implementing any functional means or units. In one embodiment, for example, the reachability server 26 comprises respective circuits or circuitry configured to perform the steps shown in Figure 7. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. In embodiments that employ memory, which may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc., the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

Figure 8 illustrates a reachability server 26 implemented in the form of a reachability server 26A in accordance with one or more embodiments. As shown, the reachability server 26A includes processing circuitry 300 and communication circuitry 310. The communication circuitry 310 is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. The processing circuitry 300 is configured to perform processing described above, e.g., in Figure 7, such as by executing instructions stored in memory 320. The processing circuitry 300 in this regard may implement certain functional means, units, or modules.

Figure 9 illustrates a reachability server 26 implemented in the form of a reachability server 26B in accordance with one or more other embodiments. As shown, the reachability server 26B implements various functional means, units, or modules, e.g., via the processing circuitry 300 in Figure 8 and/or via software code. These functional means, units, or modules, e.g., for implementing the method in Figure 7, include for instance a tracking unit or module for tracking reachability, from the perspective of the access network 14, of a particular M2M application instance 18 executed on an M2M device 10. Also included is a sending unit or module for sending reachability information to a triggering node 30 in the M2M SP network indicating the tracked reachability for the particular M2M application instance 18.

Those skilled in the art will also appreciate that a triggering node 30 as described herein is generally configured to perform the method 400 in Figure 10. As shown, the method 400 comprises receiving reachability information from a reachability server 26 indicating reachability, from the perspective of the access network 14, of a particular M2M application instance 18 executed on an M2M device 10 (Block 410). This reception in some embodiments is based on a device-agnostic pushing or pulling of the reachability information from the reachability server 26 to the triggering node 30.

Upon receiving a device agnostic trigger request from the M2M network application, the triggering node may request (PULL) the reachability information from the reachability server 26. The triggering node 30 may obtain the reachability server 26 identity from the M2M registrar node 22 or some other node (e.g., the IN-CSE in oneM2M embodiments). The reachability information may comprise but is not necessarily limited to the reachability status of the M2M device currently hosting the application instance (dormant, active, temporarily not reachable due to for example temporary congestion), the method that should be used to best reach the 2M device (user plane method or control plane method), the identity and corresponding address of the M2M device through which the application instance has registered (e.g., MSISDN, IP address if user plane reachability, etc.). The triggering node 30 then uses the reachability information to trigger the application instance. For example, upon receiving reachability information that indicates a reachability method, the triggering node 30 then uses the reachability method provided to send a triggering message or packet to the M2M application instance hosted on the device.

Alternatively, the triggering node 30 may have previously subscribed (explicitly or implicitly through the registrar node 22) to receive reachability information updates from the reachability server 26 (PUSH). Such subscription to reachability information events may have been performed at the time of application instance registration with the registrar node 22 in the M2M SP network. Upon successful registration of the application instance and the reachability server 26 receiving the registration information from the registrar node (which may include subscription of the triggering node 30 to reachability information updates), the triggering node 30 would have received the reachability information from the reachability server 26. The triggering node 30 may receive subsequent messages from the reachability server 26 if an update is made to the reachability information of the application instance that will impact the application instance triggering.

Regardless, the method 400 also comprises triggering the particular M2 application instance 18 using the reachability information (Block 420).

ote that the triggering node 30 as described above may perform any of the processing herein by implementing any functional means or units. In one embodiment, for example, the triggering node 30 comprises respective circuits or circuitry configured to perform the steps shown in Figure 10. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. In embodiments that employ memory, which may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc., the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

Figure 11 illustrates a triggering node 30 implemented in the form of a triggering node

30A in accordance with one or more embodiments. As shown, the triggering node 30A includes processing circuitry 500 and communication circuitry 510. The communication circuitry 510 is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. The processing circuitry 500 is configured to perform processing described above, e.g., in Figure 10, such as by executing instructions stored in memory 520. The processing circuitry 500 in this regard may implement certain functional means, units, or modules.

Figure 12 illustrates a triggering node 30 implemented in the form of a triggering node 30B in accordance with one or more other embodiments. As shown, the triggering node SOB implements various functional means, units, or modules, e.g., via the processing circuitry 500 in Figure 11 and/or via software code. These functional means, units, or modules, e.g., for implementing the method in Figure 10, include for instance a receiving unit or module 600 for receiving reachability information from a reachability server 26 indicating reachability, from the perspective of the access network 14, of a particular M2M application instance 18 executed on an M2M device 10. Also included is a triggering unit or module 610 for triggering the particular M2M application instance 18 using the reachability information.

Those skilled in the art will further appreciate that a registrar node 22 as described herein is generally configured to perform the method 700 in Figure 13. As shown, the method 700 comprises receiving a registration request for registering a particular M2 application instance 18 with the registrar node 22 (Block 710). This registration request includes registration information with which the particular M2M application instance 18 requests registration. The method 700 also comprises, responsive to the request and using the registration information, registering the particular M2M application instance 18 with the registrar node 22 (Block 720). The method further entails sending to a reachability server 26 at least some of the registration information that is access-related and indicating that the access-related registration information is for the particular M2M application instance 18 (Block 730). The access-related registration information comprises access information associated with attachment of an M2M device 10 to the access network.

ote that the registrar node 22 as described above may perform any of the processing herein by implementing any functional means or units. In one embodiment, for example, the registrar node 22 comprises respective circuits or circuitry configured to perform the steps shown in Figure 13. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. In embodiments that employ memory, which may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc., the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

Figure 14 illustrates a registrar node 22 implemented in the form of a registrar node 22A in accordance with one or more embodiments. As shown, the registrar node 22A includes processing circuitry 800 and communication circuitry 810. The communication circuitry 810 is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. The processing circuitry 800 is configured to perform processing described above, e.g., in Figure 13, such as by executing instructions stored in memory 820. The processing circuitry 800 in this regard may implement certain functional means, units, or modules.

Figure 15 illustrates a registrar node 22 implemented in the form of a registrar node 22B in accordance with one or more other embodiments. As shown, the registrar node 22 B implements various functional means, units, or modules, e.g., via the processing circuitry 500 in Figure 14 and/or via software code. These functional means, units, or modules, e.g., for implementing the method in Figure 13, include for instance a receiving unit or module 900 for receiving a registration request for registering a particular M2M application instance 18 with the registrar node 22. This registration request includes registration information with which the particular M2 application instance 18 requests registration and may include subscription of triggering node to reachability information change event. Also included is a registering unit or module 910 for, responsive to the request and using the registration information, registering the particular M2M application instance 18 with the registrar node 22. Further included is a sending unit or module for sending to a reachability server 26 at least some of the registration information that is access-related and indicating that the access-related registration information is for the particular M2M application instance 18. The access-related registration information comprises access information associated with attachment of an M2M device 10 to the access network.

Those skilled in the art will also appreciate that a node 34 in an access network 1 as described herein is generally configured to perform the method 1000 in Figure 16. As shown, the method 1000 comprises responsive to a device attaching to the access network, determining that the device is an 2M device 10 (Block 1010). The method 1000 also comprises, responsive to that determination, sending access information to a reachability server 26 configured to track reachability of a particular M2M application instance 18 executed on the M2M device 10 (Block 1020). The access information is associated with attachment of the M2M device 10 to the access network 14.

Note that the access network node 34 as described above may perform any of the processing herein by implementing any functional means or units. In one embodiment, for example, the access network node 34comprises respective circuits or circuitry configured to perform the steps shown in Figure 16. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more

microprocessors in conjunction with memory. In embodiments that employ memory, which may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc., the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

Figure 17 illustrates an access network node 34 implemented in the form of an access network node 34A in accordance with one or more embodiments. As shown, the access network node 34A includes processing circuitry 1 100 and communication circuitry 11 10. The communication circuitry 1 110 is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. The processing circuitry 1 100 is configured to perform processing described above, e.g., in Figure 16, such as by executing instructions stored in memory 1 120. The processing circuitry 1 100 in this regard may implement certain functional means, units, or modules.

Figure 18 illustrates an access network node 34 implemented in the form of an access network node 34 B in accordance with one or more other embodiments. As shown, the access network node 34 B implements various functional means, units, or modules, e.g., via the processing circuitry 1 100 in Figure 17 and/or via software code. These functional means, units, or modules, e.g., for implementing the method in Figure 16, include for instance a determining unit or module 1200 for, responsive to a device attaching to the access network, determining that the device is an M2M device 10. Also included is a sending unit or module 1210 for, responsive to that determination, sending access information to a reachability server 26 configured to track reachability of a particular M2M application instance 18 executed on the M2M device 10. The access information is associated with attachment of the M2M device 10 to the access network 14.

Those skilled in the art will also appreciate that embodiments herein further include corresponding computer programs.

A computer program comprises instructions which, when executed on at least one processor of a node, cause the node to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules

corresponding to the means or units described above.

Embodiments further include a carrier containing such a computer program. This carrier may comprise one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

In this regard, embodiments herein also include a computer program product stored on a non-transitory computer readable (storage or recording) medium and comprising instructions that, when executed by a processor of a node, cause the node to perform as described above.

Embodiments further include a computer program product comprising program code portions for performing the steps of any of the embodiments herein when the computer program product is executed by a computing device. This computer program product may be stored on a computer readable recording medium.

The present invention may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the invention. The present embodiments are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein. ABBREVIATIONS

ADN Application Dedicated Node

AE Application Entity

AN Access Network

ASN Application Service Node

CSE Common Services Entity

DNS Domain Name Service

EPC Evolved Packet Core

I EI International Mobile Equipment Identity

IMSI International Mobile Subscriber Identity

IN-CSE Infrastructure Common Services Entity

IP Internet protocol

IP-SM-GW IP Short Message Gateway

IWF Interworking Function

LTE Long Term evolution

M2M Machine-to-Machine

MN-CSE Middle Node Common Services Entity

MSISDN Mobile Station International Subscriber Directory Number MTC Machine-Type Communications

NAI Network Access Identifier

NB-loT Narrowband Internet of Things

NSE Network Services Entity

SIP Session Initiation Protocol

SMS Short Messaging Service

SP Service Provider

WLAN Wireless Local Area Network

Claims

What is claimed is:

1. A method (200) performed by a reachability server (26) that interfaces with a machine- to-machine, M2M, service provider, SP, network and an access network (14) which provides data transport services for the M2M SP network, the method comprising:

tracking (210) reachability, from the perspective of the access network (14), of a

particular M2M application instance (18) executed on an M2M device (10), based on correlating attachment of the M2M device (10) to the access network (14) and registration of the particular M2M application instance (18) with the M2M SP network; and

sending (220) reachability information to a triggering node (30) in the M2M SP network indicating the tracked reachability for the particular M2M application instance (18). 2. The method of claim 1 , wherein said tracking comprises:

receiving, from a node in the access network (14), access information associated with attachment of the M2M device (10) to the access network (14);

receiving, from a node in the 2 SP network, access-related registration information indicated as being that with which the particular M2M application instance (18) registered with the M2M SP network;

determining that a value of an information parameter included in the access-related registration information corresponds to a value of an information parameter included in the access information; and

mapping the access information to the particular M2M application instance (18), based on said determining.

3. The method of claim 2, wherein said determining comprises determining that a value of an information parameter included in the access-related registration information is the same as a value of the same information parameter included in the access information.

4. The method of any of claims 2-3, wherein the information parameter included in the access information and the information parameter included in the access-related registration information are both an Internet Protocol (IP) address. 5. The method of any of claims 2-4, wherein the access information comprises at least one of a Mobile Station International Subscriber Directory Number (MSISDN), an International Mobile Subscriber Identity (IMSI), and a Network Access Identifier (NAI).

6. The method of any of claims 2-5, wherein the access-related registration information is accompanied by an identifier of an M2M application and an identifier of the particular M2M application instance (18). 7. The method of any of claims 1-6, wherein said sending comprises sending the reachability information to the triggering node (30) based on a device-agnostic pushing or pulling of the reachability information from the reachability server (26) to the triggering node

(30).

The method of any of claims 1-7, further comprising:

storing access information associated with attachment of different M2M devices to the access network (14) in different records indexed by respective IP addresses; receiving access-related registration information that includes an IP address

accompanied by an identifier of an M2M application and an identifier of a particular M2M application instance (18);

identifying a record indexed by the IP address included in the access-related registration information; and

mapping the identified record to the identifier of an M2 application and the identifier of a particular M2M application instance (18) accompanying the access-related registration information.

9. The method of any of claims 1-8, wherein said tracking (210) comprises dynamically updating said reachability upon at least one of: the M2M device (10) detaching from the access network (14), the particular M2M application instance (18) de-registering with the M2M SP network, and the M2M device (10) entering or exiting a dormant state.

10. A method (400) performed by a triggering node (30) in a machine-to-machine, M2M, service provider, SP, network that is provided data transport services by an access network (14), the method comprising:

receiving (410) reachability information from a reachability server (26) indicating

reachability, from the perspective of the access network (14), of a particular M2M application instance (18) executed on an M2M device (10); and

triggering (420) the particular M2M application instance (18) using the reachability

information.

11. The method of claim 10, wherein the reachability information is received based on a device-agnostic pushing or pulling of the reachability information from the reachability server (26) to the triggering node (30).

12. The method of any of claims 10-1 1 , further comprising identifying the reachability server (26) based on an identifier of the access network (14) to which the M2M device (10) is attached and/or an identifier of a country in which the M2M device (10) is located.

13. The method of any of claims 10-12, wherein the reachability information to be pushed or pulled is identified based on an identifier of an M2M application and an identifier of the particular M2M application instance (18), instead of an identifier of the M2M device (10) or an identifier of a subscriber associated with the M2M device (10).

14. The method of any of claims 10-13, wherein said triggering is performed responsive to a device-agnostic triggering request from a network application.

15. The method of any of claims 1-14, wherein the triggering node (30) is configured to trigger the particular M2M application instance (18) by waking up the particular M2M application instance (18) from a dormant state.

16. The method of any of claims 1-15, wherein the reachability information indicates an identifier at which the particular M2M application instance (18) is reachable from the perspective of the access network (14).

17. The method of claim 16, wherein the identifier is a device identifier that identifies the M2M device (10) or a subscriber identifier that identifies a subscriber associated with the M2M device (10).

18. The method of any of claims 16-17, wherein the identifier is a Mobile Station

International Subscriber Directory Number (MSISDN).

19. The method of any of claims 1-18, wherein the reachability information comprises reachability status indicating whether or not the M2M device (10) is reachable through the access network (14).

20. The method of any of claims 1-19, wherein the reachability information indicates via which of different possible methods the particular M2M application instance (18) is reachable from the perspective of the access network (14).

21. The method of claim 20, wherein a method via which the particular M2M application instance (19) is reachable is determined based on at least one of access technology type, device status, time of day, and access network load conditions. 22. The method of any of claims 1-21 , wherein the reachability information indicates via which of a user plane and a control plane the particular M2 application instance (18) is reachable from the perspective of the access network (14).

23. A method (700) performed by a registrar node (22) in a machine-to-machine, M2M, service provider, SP, network, the method comprising:

receiving (710) a registration request for registering a particular M2M application

instance (18) with the registrar node (22), wherein the registration request includes registration information with which the particular M2M application instance (18) requests registration;

responsive to the request and using the registration information, registering (720) the particular M2M application instance (18) with the registrar node (22); and sending (730) to a reachability server (26) at least some of the registration information that is access-related and indicating that the access-related registration information is for the particular M2M application instance (18), wherein the access-related registration information comprises access information associated with attachment of an M2M device (10) to the access network (14).

24. The method of claim 23, wherein the access-related registration information comprises an Internet Protocol (IP) address.

25. The method of any of claims 23-24, wherein said indicating comprises sending to the reachability server (26) an identifier of an M2M application and an identifier of the particular M2M application instance (18). 26. A reachability server (26) that interfaces with a machine-to-machine, 2M, service provider, SP, network and an access network (14) which provides data transport services for the M2M SP network, the reachability server (26) configured to:

track reachability, from the perspective of the access network (14), of a particular M2M application instance (18) executed on an M2M device (10), based on correlating attachment of the M2M device (10) to the access network (14) and registration of the particular M2M application instance (18) with the M2M SP network; and send reachability information to a triggering node (30) in the M2M SP network indicating the tracked reachability for the particular M2M application instance (18).

27. The reachability server (26) of claim 26, configured to perform the method of any of claims 2-9 and 15-22. 28. A triggering node (30) in a m ach i ne-to- m ach i ne , M2M, service provider, SP, network that is provided data transport services by an access network (14), the triggering node (30) configured to:

receive reachability information from a reachability server (26) indicating reachability, from the perspective of the access network (14), of a particular M2M application instance (18) executed on an M2M device (10); and

trigger the particular application instance (18) using the reachability information.

29. The triggering node (30) of claim 28, configured to perform the method of any of claims

1 1-22.

30. A registrar node (22) in a machine-to-machine, M2M, service provider, SP, network, the registrar node (22) configured to:

receive a registration request for registering a particular M2 application instance (18) with the registrar node (22), wherein the registration request includes registration information with which the particular M2M application instance (18) requests registration;

responsive to the request and using the registration information, register the particular M2M application instance (18) with the registrar node (22); and

send to a reachability server (26) at least some of the registration information that is access-related and indicating that the access-related registration information is for the particular M2M application instance (18), wherein the access-related registration information comprises access information associated with attachment of an M2M device (10) to the access network (14). 31. The registrar node (22) of claim 30, configured to perform the method of any of claims 24-25.

32. A computer program, comprising instructions which, when executed on at least one processor of a node, cause the at least one processor to carry out the method according to any one of claims 1 to 25.

33. A carrier containing the computer program of claim 32, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

34. A reachability server (26) that interfaces with a machine-to-machine, 2M, service provider, SP, network and an access network (14) which provides data transport services for the M2M SP network, the reachability server (26) comprising:

a processor and a memory, the memory containing instructions executable by the

processor whereby the reachability server (26) is configured to:

track reachability, from the perspective of the access network (14), of a particular

M2M application instance (18) executed on an M2M device (10), based on correlating attachment of the M2M device (10) to the access network (14) and registration of the particular M2M application instance (18) with the M2M SP network; and

send reachability information to a triggering node (30) in the M2M SP network indicating the tracked reachability for the particular M2M application instance (18).

35. The reachability server (26) of claim 34, wherein the memory contains instructions executable by the processor whereby the reachability server (26) is configured to perform the method of any of claims 2-9 and 15-22. 36. A triggering node (30) in a machine-to-machine, M2M, service provider, SP, network that is provided data transport services by an access network (14), the triggering node (30) comprising:

a processor and a memory, the memory containing instructions executable by the

processor whereby the triggering node (30) is configured to:

receive reachability information from a reachability server (26) indicating

37. The triggering node (30) of claim 36, wherein the memory contains instructions executable by the processor whereby the triggering node (30) is configured to perform the method of any of claims 1 1-22.

8. A registrar node (22) in a machine-to-machine, M2M, service provider, SP, network, the registrar node (22) comprising:

a processor and a memory, the memory containing instructions executable by the

processor whereby the registrar node (22) is configured to: receive a registration request for registering a particular M2M application

responsive to the request and using the registration information, register the

particular M2M application instance (18) with the registrar node (22); and send to a reachability server (26) at least some of the registration information that is access-related and indicating that the access-related registration information is for the particular M2M application instance (18), wherein the access-related registration information comprises access information associated with attachment of an M2M device (10) to the access network (14).

39. The registrar node (22) of claim 38, wherein the memory contains instructions executable by the processor whereby the registrar node (22) is configured to perform the method of any of claims 24-25.

40. A reachability server (26) that interfaces with a machine-to-machine, 2M, service provider, SP, network and an access network (14) which provides data transport services for the M2M SP network, the reachability server (26) comprising:

a tracking module (400) for tracking reachability, from the perspective of the access network (14), of a particular M2M application instance (18) executed on an M2M device (10), based on correlating attachment of the M2M device (10) to the access network (14) and registration of the particular M2M application instance (18) with the M2M SP network; and

a sending module (410) for sending reachability information to a triggering node (30) in the M2M SP network indicating the tracked reachability for the particular M2M application instance (18). 41. The reachability server (26) of claim 40, configured to perform the method of any of claims 2-9 and 15-22.

42. A triggering node (30) in a machine-to-machine, 2M, service provider, SP, network that is provided data transport services by an access network (14), the triggering node (30) comprising:

a receiving module (600) for receive reachability information from a reachability server (26) indicating reachability, from the perspective of the access network (14), of a particular 2 application instance (18) executed on an M2M device (10); and a triggering module (610) for triggering the particular M2M application instance (18) using the reachability information.

43. The triggering node (30) of claim 42, configured to perform the method of any of claims 1 1-22.

44. A registrar node (22) in a machine-to-machine, M2M, service provider, SP, network, the registrar node (22) comprising:

a receiving module (900) for receiving a registration request for registering a particular M2M application instance (18) with the registrar node (22), wherein the registration request includes registration information with which the particular instance (18) of the M2M application requests registration;

a registering module (910) for, responsive to the request and using the registration

information, registering the particular M2M application instance (18) with the registrar node (22); and

a sending module (920) for sending to a reachability server (26) at least some of the registration information that is access-related and indicating that the access- related registration information is for the particular 2M application instance (18), wherein the access-related registration information comprises access information associated with attachment of an M2M device (10) to the access network (14).

45. The registrar node (22) of claim 44, configured to perform the method of any of claims 24-25.