Patent Description:
In recent years, mobile devices have advanced from offering simple voice calling services within wireless communication networks to providing users with many new features, often utilized by Internet of Things (IoT) devices. Some networks utilize a Service Capability Exposure Function (SCEF) to support IoT devices. As the number of such devices grows, routing may become burdensome.

Patent document <CIT> and document entitled "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements to facilitate communications with packet data networks and applications (Release <NUM>)",<NPL> are representative of the available art.

Accordingly, there is provided a method, a Mobility Management Entity, MME and a non-transitory computer-readable media as detailed in the claims that follow.

The described implementations include devices, systems, and methods that provide connection establishment and routing optimization for a Service Capability Exposure Function (SCEF) in, for example, a carrier network. In some examples, a pseudo ID may be utilized by a Mobility Management Entity (MME) as a SCEF Identifier (SCEF-ID) during connection establishment. In particular, a pseudo ID may be provisioned by a Home Subscriber Server (HSS) once and used as a SCEF-ID by the MME for a plurality of connection establishment requests (e.g., for different sessions and/or different user equipment (UE)). The use of the pseudo ID may minimize HSS provisioning operations and may simplify the routing in a distributed application environment in which more than one SCEF instance is deployed.

Once the MME receives a response to the connection establishment request from a SCEF instance, the MME may store an identifier particular to the SCEF instance from the response (e.g., the "Origin Host" ID of the SCEF instance) as an updated SCEF-ID of the SCEF instance for the current session. Additionally or alternatively, the MME may determine an updated SCEF-ID based on the identifier particular to the SCEF instance, potentially in combination with other data. The MME may then use the updated SCEF-ID for subsequent requests to the SCEF instance for that session. Similarly, the SCEF instance may utilize the updated SCEF-ID from the subsequent requests as the SCEF-ID utilized in responses to the MME.

In certain described embodiments, the devices, systems, and methods disclosed herein relate to providing connection establishment and routing in an Internet-of-Things carrier network (e.g., Narrowband Internet-of-Things (NB-IoT) carrier network) that provides support for devices using Non-IP Data Delivery (NIDD). UEs may use NIDD in order to exchange data with the MME, which may pass that data to the SCEF for onward delivery to IoT application servers. Thus, NIDD may provide a path to exchange data between a user equipment (UE) and an application server (AS) without requiring the UE to support an IP stack.

In some examples, SCEF servers may securely expose the services and capabilities of carrier networks. Such services and capabilities may include support for Non-IP Data Delivery (NIDD), communication patterns (CP), monitoring events (MONTE), triggering, and other features.

By utilizing a pseudo ID as the SCEF-ID in the connection management request and, after successful connection establishment, updating the SCEF-ID based on the response from the SCEF instance, subsequent messages of the session may use the same SCEF-ID. This may provide multiple advantages. First, the HSS configuration in examples according to this disclosure may have reduced minimum specifications due to provisioning a single pseudo SCEF-ID for multiple application instances. This may reduce the overhead and complexity incurred by provisioning and maintaining many SCEF-IDs. Second, examples according to this disclosure may ensures NB-IoT session continuity in the distributed application architecture. Third, examples according to this disclosure may have the same route on subsequent messages of the session. The use of the same route may limit and/or reduce latency and may alleviate the need for an external database to store session information. Additionally, examples according to the disclosed subject matter may avoid the use of a session-aware routing agent (e.g., a Diameter Routing Agent (DRA)) in the network which may reduce complexity, cost and effort in establishing and operating the network.

While NB-IoT NIDD via SCEF may be utilized in the discussions of example embodiments throughout this disclosure, this disclosure and the appended claims are not so limited. For example, other embodiments may utilize other IoT networks, protocols, and standards to accomplish similar functions. Further, other embodiments may utilize the disclosed systems and methods for other operations such as monitoring events (MONTE).

<FIG> illustrates an example telecommunication system <NUM>, which may provide connection establishment and routing for a SCEF utilizing a pseudo ID as a SCEF Identifier (SCEF-ID) during connection establishment, according to some implementations. The system <NUM> includes user equipment (UE) <NUM>, a Mobility Management Entity (MME) <NUM>, a Home Subscriber Server (HSS) <NUM>, one or more Service Capability Exchange Function (SCEF) server(s) <NUM>, and an application server (AS) <NUM>. In some examples, the system <NUM> may be a NB-IoT network.

Generally, in some examples, the MME <NUM> may operate to authenticate user devices by interacting with the HSS <NUM>. Specifically, the MME <NUM> may send an update location request (ULR) to the HSS <NUM> upon receiving an attach request from a UE <NUM>. The ULR may cause the HSS <NUM> to authorize the requested service for the UE <NUM>. Further, the MME <NUM> may operate to connect user devices with an appropriate AS <NUM> via a Service Capability Exchange Function (SCEF) provided by SCEF instances operating on SCEF server(s) <NUM>. Specifically, the MME <NUM> may receive an update location answer (ULA) that authorizes the requested service for the UE <NUM> and which includes the pseudo ID in a SCEF-ID field. The MME <NUM> may utilize the pseudo SCEF-ID in connection management requests (CMRs) to establish sessions with a SCEF instances as discussed below.

The HSS <NUM> may provide a central database that contains user-related and subscription-related information. The functions of the HSS <NUM> can include mobility management, call and session establishment support, user authentication and access authorization. In some examples, the HSS <NUM> can manage subscription-related information in real time, for multi-access and multi-domain offerings. The HSS <NUM> can be based on Home Location Register (HLR) and Authentication Center (AuC). As mentioned above, the HSS <NUM> may provide the MME <NUM> with a pseudo SCEF-ID upon authorization of the UE. More particularly, upon initialization, the HSS <NUM> may provision a pseudo SCEF-ID once and provide the pseudo SCEF-ID to the MME <NUM> as a SCEF-ID in ULAs for a plurality of ULRs. As such, the MME <NUM> may utilize the same pseudo SCEF-ID as the SCEF-ID of multiple CMRs (e.g., for different sessions and/or different user equipment (UE)).

The SCEF server(s) <NUM> may operate to provide one or more SCEF instance(s). The SCEF instances operating on the SCEF server(s) <NUM> may expose network services and capabilities via a set of Application Programming Interfaces (APIs) and hide the underlying network topology. For example, SCEF instances may be deployed in support of IoT, whereby IoT devices (e.g., UE <NUM>) can use NIDD in order to exchange data with the MME <NUM>, which in turn passes that data to the SCEF instances for onward delivery to the AS <NUM>. In some examples, each SCEF instance may have its own identifier (e.g., SCEF-ID). As will be discussed below, the identifier of the SCEF instance may be extracted from a CMA by the MME <NUM> and utilized by the MME <NUM> as an updated SCEF-ID for the SCEF instance, replacing the pseudo SCEF-ID previously stored for the session.

The UE <NUM> may comprise a communication device configured to communicate over a wireless and/or wireline network. UE <NUM> may also comprise a non-mobile computing device, including, without limitation such things as televisions, desktop computers, a game consoles, set top boxes, home automation components, security system components, and so forth. While examples discussed herein relate to UEs that are IoT devices, implementations are not so limited. For example, mobile computing devices may include, without limitation, a mobile phone (e.g., a smart phone), a tablet computer, a laptop computer, a portable digital assistant (PDA), a wearable computer (e.g., electronic/smart glasses, smart watches, fitness trackers, etc.), a networked digital camera, etc. In this sense, the terms "communication device," "wireless device," "wireline device," "mobile device," "computing device," and "user equipment (UE)" may be used interchangeably herein to describe any communication device capable of performing the techniques described herein.

Furthermore, UE <NUM>, as well as the various network provider components described herein, may be capable of communicating over wired networks, and/or wirelessly using any suitable wireless communications/data technology, protocol, or standard, such as Global System for Mobile Communications (GSM), Time Division Multiple Access (TDMA), Universal Mobile Telecommunications System (UMTS), Evolution-Data Optimized (EVDO), Long Term Evolution (LTE), Advanced LTE (LTE+), Generic Access Network (GAN), Unlicensed Mobile Access (UMA), Code Division Multiple Access (CDMA), Orthogonal Frequency Division Multiple Access (OFDM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Advanced Mobile Phone System (AMPS), High Speed Packet Access (HSPA), evolved HSPA (HSPA+), Voice over IP (VoIP), Voice over LTE (VoLTE), IEEE <NUM>. 1x protocols, WiMAX, Wi-Fi, and/or any future network technology or evolution of an existing network technology (e.g., IP or Non-IP based). These are merely examples and UE <NUM>, as well as the various network provider components described herein, may be capable of communicating via one or more of a <NUM>, <NUM>, <NUM> LTE, and/or <NUM> protocols.

The UE <NUM> may communicate with the MME <NUM> using an access network (not shown), which may comprise a cellular communication network or other type of wired or wireless network. Examples of wireless access networks include LTE, WIFI, GSM EDGE Radio Access Network (GERAN), UMTS Terrestrial Radio Access Network (UTRAN), and other cellular access networks.

In the operations illustrated in <FIG>, the UE <NUM>, MME <NUM>, HSS <NUM>, SCEF server <NUM>, and AS <NUM> may operate to provide connection establishment between UE <NUM> and AS <NUM> and routing to and from the SCEF server(s) <NUM> utilizing a pseudo ID as a SCEF Identifier (SCEF-ID) during connection establishment. Following receipt of a message indicating successful connection establishment from a SCEF instance, the MME <NUM> may update the stored SCEF-ID of the session to an identifier of the SCEF instance included in the message indicating successful connection establishment,.

Initially, the UE <NUM> may be configured to generate and send an attach request <NUM> to the MME <NUM>. The attach request may provide identification of the UE <NUM> and indicate the AS <NUM> or service of AS <NUM> the UE <NUM> is requesting to access or utilize. The MME <NUM> may receive the attach request <NUM> and determine the attach request <NUM> relates to establishing a session with AS <NUM> for the UE <NUM> via SCEF. The MME <NUM> may further determine that a SCEF session for the UE <NUM> has not been established. In response, the MME <NUM> may send an update location request (ULR) <NUM> to the HSS <NUM> requesting the HSS <NUM> authorize the SCEF session for the UE <NUM> based on subscription information maintained by the HSS <NUM> and information included the attach request <NUM>. In some examples, the MME <NUM> may communicate with the HSS <NUM> via a Diameter S6a interface.

The HSS <NUM> may receive the ULR <NUM> and, based thereon, determine whether the UE <NUM> is authorized to access or utilize the requested service of the AS <NUM>. If so, the HSS <NUM> may provide an update location answer (ULA) <NUM> to the MME <NUM> that may authorize UE and include a pseudo SCEF-ID. As discussed above, the pseudo SCEF-ID may have been provisioned previously and may be used, in some cases, by the MME <NUM> to establish multiple or all SCEF sessions (e.g., for different sessions and/or different user equipment (UE)).

The MME <NUM> may then generate and send a connection management request (CMR) <NUM> to the SCEF server(s) <NUM>. The CMR <NUM> may be sent via a Diameter T6a interface. The CMR <NUM> may include the pseudo SCEF-ID in a SCEF-ID field. Though not shown for simplicity of illustration and explanation, a Diameter Routing Agent (DRA) may operate to route the CMR <NUM> to a SCEF instance operating on the SCEF server(s) <NUM> based on the SCEF-ID field containing the pseudo SCEF-ID and/or other factors such as load balancing or routing metrics.

A SCEF instance operating on the SCEF server(s) <NUM> may receive the CMR <NUM> from the MME <NUM>. The SCEF instance may determine the CMR <NUM> requests establishment of a session associated with an application server (e.g., AS <NUM>). The SCEF instance may determine the CMR <NUM> is valid and return a connection management answer (CMA) <NUM> to the MME <NUM> including an "Origin-Host" ID field identifying the SCEF instance. Generally, the "Origin-Host" ID field of the CMA <NUM> may have the same value as the SCEF-ID of the SCEF instance that originated the CMA <NUM> towards the MME <NUM>. As mentioned above, the SCEF-ID may be an identifier of the SCEF instance. In some examples, the CMA <NUM> may include the pseudo SCEF-ID as the value of the SCEF-ID field. In other examples, rather than using the pseudo SCEF-ID as the value of the SCEF-ID field of the CMA <NUM>, the SCEF instance may utilize the SCEF-ID of the SCEF instance as the value of the SCEF-ID field of the CMA <NUM>.

The MME <NUM> may receive the CMA <NUM> including the "Origin-Host" ID identifying the SCEF instance. The MME <NUM> may verify the success of the connection establishment. The MME <NUM> may then extract the "Origin-Host" ID from the CMA <NUM> (e.g., which may be the same as the SCEF-ID of the SCEF instance). The MME <NUM> may then update the stored SCEF-ID for the SCEF session for the UE <NUM> to the value of the "Origin-Host" ID field of the CMA <NUM>. In this manner, the information stored at the MME <NUM> for the session of the UE <NUM> associated with the attach request <NUM> includes the identifier of the SCEF instance handling the session. As will be discussed below, the MME <NUM> may utilize the updated SCEF-ID stored for the session in generating future requests to the AS <NUM> via SCEF.

In particular, when the UE <NUM> subsequently generates and sends a UE request <NUM> to the AS <NUM> via the MME <NUM>, the MME <NUM> may utilize the session information including the updated SCEF-ID to send a mobile-originating data request (ODR) <NUM> to the SCEF instance operating on the SCEF server(s) <NUM>. More particularly, the ODR <NUM> may include the updated SCEF-ID in the SCEF-ID field of the ODR <NUM>. As mentioned above, the updated SCEF-ID stored at the MME may be the same as the value of the "Origin-Host" ID field of the CMA <NUM>. As such, the ODR <NUM> may be delivered to and received by the same SCEF instance that sent the CMA <NUM>.

The SCEF instance may receive the ODR <NUM>, and, based thereon, may generate and send a request <NUM> to the AS <NUM>. The AS <NUM> may receive and process the request <NUM> and send an answer <NUM> to the SCEF instance. In some examples, the SCEF server(s) <NUM> may communicate with the AS <NUM> via a Diameter T8 interface.

The SCEF instance may receive the answer <NUM> from the AS <NUM>. The SCEF instance may then return a mobile-originating data answer (ODA) <NUM> to the MME <NUM> including the answer from the AS <NUM>. In some examples, the value of the SCEF-ID field of the ODA <NUM> may be set to the updated SCEF-ID (e.g., the identifier of the SCEF instance).

In turn, the MME <NUM> may receive the ODA <NUM> from the SCEF instance. Based on the answer from the AS <NUM> and the SCEF-ID field and/or other fields of the ODA <NUM>, the MME <NUM> may provide the UE <NUM> an answer <NUM> to the UE request <NUM>.

While <FIG> illustrates a simplified and generalized example system and communications flow for providing connection establishment and routing for a SCEF utilizing a pseudo ID as a SCEF-ID during connection establishment, implementations are not limited to the specifics of <FIG>. Rather, details may vary from implementation to implementation and are not limited to NB-IoT NIDD via SCEF. Further, while the illustrated as operating one or more SCEF instances, in some implementations, the SCEF server(s) may operate a single respective SCEF instance. <FIG> and <FIG> may illustrate particular example communication flows in example implementations.

<FIG> illustrates an example communication flow <NUM> for providing connection establishment and routing for a SCEF utilizing a pseudo ID as a SCEF Identifier (SCEF-ID) during connection establishment, according to some implementations. In the illustrated example, the system includes user equipment (UE) <NUM>, MME <NUM>, a HSS <NUM>, SCEF server(s) <NUM>, and application server(s) <NUM>. In the illustrated example, the data flow may relate to an implementation of the disclosed systems and methods in a carrier network utilizing a SCEF to provide NIDD for IoT devices.

In the operations illustrated in <FIG>, the HSS <NUM> may operate to provision a pseudo SCEF-ID <NUM> for NIDD. More particularly, the HSS <NUM> may provision a pseudo SCEF-ID once and provide the pseudo SCEF-ID to the MME <NUM> in ULAs as a SCEF-ID for a plurality of ULRs (e.g., for different sessions and/or different user equipment (UE)).

The UE <NUM> may generate and send an attach request <NUM> to the MME <NUM>. As discussed above, the attach request <NUM> may provide identification of the UE <NUM> and indicate the AS <NUM> or service or the AS <NUM> the UE <NUM> is requesting to access or utilize.

The MME <NUM> may receive the attach request <NUM> and determine the attach request <NUM> relates to establishing a session with AS <NUM> for the UE <NUM> via SCEF. The MME <NUM> may further determine that a SCEF session for the UE <NUM> has not been established. In response, the MME <NUM> may send a ULR <NUM> to the HSS <NUM> requesting the HSS <NUM> authorize the SCEF session for the UE <NUM> based on subscription information maintained by the HSS <NUM> and information included the attach request <NUM>.

The HSS <NUM> may receive the ULR <NUM> and, based thereon, determine whether the UE <NUM> is authorized to access or utilize the AS <NUM> or requested service of the AS <NUM>. If so, the HSS <NUM> may provide an ULA <NUM> to the MME <NUM> that may authorize the session and which may include the pseudo SCEF-ID <NUM>. As discussed above, the pseudo SCEF-ID <NUM> may have been provisioned previously and may be used, in some cases, by the MME <NUM> for multiple or all SCEF sessions.

The MME <NUM> may then generate and send a connection management request (CMR) <NUM> to the SCEF server(s) <NUM>. The CMR <NUM> may include the pseudo SCEF-ID in a SCEF-ID field of the CMR <NUM>. Though not shown for simplicity of illustration and explanation, a Diameter Routing Agent (DRA) may operate to route the CMR <NUM> to a SCEF instance operating on the SCEF server(s) <NUM> based on the SCEF-ID field containing the pseudo SCEF-ID and/or other factors such as load balancing or routing metrics.

A SCEF instance operating on the SCEF server(s) <NUM> may receive the CMR <NUM> from the MME <NUM>. The SCEF instance may determine the CMR <NUM> requests establishment of a session for the UE <NUM> associated with an application server (e.g., AS <NUM>). The SCEF instance may determine the request is valid and then return a connection management answer (CMA) <NUM> to the MME <NUM> including an "Origin-Host" ID field identifying the SCEF instance. Generally, the "Origin-Host" ID field of the CMA <NUM> may have the same value as the SCEF-ID of the SCEF instance which has originated the CMA <NUM> towards the MME <NUM>. As mentioned above, the SCEF-ID may be an identifier of the SCEF instance. In some examples, the SCEF instance may include the pseudo SCEF-ID as the value of the SCEF-ID field in the CMA <NUM>. In other examples, rather than using the pseudo SCEF-ID as the value of the SCEF-ID field of the CMA <NUM>, the SCEF instance may utilize the SCEF-ID of the SCEF instance as the value of the SCEF-ID field of the CMA <NUM>.

The MME <NUM> may receive the CMA <NUM> including the "Origin-Host" ID field identifying the SCEF instance. The MME <NUM> may verify the success of the connection establishment. The MME <NUM> may then extract the "Origin Host" ID field from the CMA <NUM>. The MME <NUM> may then update the stored SCEF-ID <NUM> for the SCEF session of the UE <NUM> to the value of the "Origin-Host" ID field of the CMA <NUM>. In this manner, the information stored at the MME for the session of the UE <NUM> associated with the attach request <NUM> includes the identifier of the SCEF instance handling the session. As will be discussed below, the MME <NUM> may utilize the updated SCEF-ID stored for the session in generating future requests to the AS <NUM> via the SCEF instance.

In particular, when the UE <NUM> subsequently generates and sends a UE request <NUM> to the AS <NUM> via the MME <NUM>, the MME <NUM> may utilize the session information including the updated SCEF-ID to send a mobile-originating data request (ODR) <NUM> to the SCEF instance operating on the SCEF server(s) <NUM> that includes the updated SCEF-ID (e.g., the value of the "Origin-Host" ID field of the CMA <NUM>) as the SCEF-ID of the ODR <NUM>. As such, the ODR <NUM> may be delivered to and received by the same SCEF instance that sent the CMA <NUM>.

The SCEF instance may receive the ODR <NUM>, and, based thereon, generate and send a request <NUM> to the AS <NUM> associated with the SCEF instance and the requested service. The AS <NUM> may receive and process the request <NUM>. Based thereon, the AS <NUM> may send an answer <NUM> to the SCEF instance.

In turn, the MME <NUM> may receive the ODA <NUM> from the SCEF instance. Based on the answer of the AS <NUM> and the SCEF-ID field and/or other field(s) of the ODA <NUM>, the MME <NUM> may provide an answer <NUM> the UE <NUM>.

<FIG> illustrates a method <NUM> for providing connection establishment and routing for a SCEF utilizing a pseudo ID as a SCEF Identifier (SCEF-ID) during connection establishment, according to the claimed invention. More particularly, <FIG> illustrates operations of a MME (e.g., MMEs <NUM> and <NUM>) that provides connection establishment and routing for a SCEF utilizing a pseudo ID as a SCEF-ID during connection establishment.

At <NUM>, the MME receives a NIDD attach request from a UE. At <NUM>, the MME may send a ULR to the HSS to authorize the UE. At <NUM>, the MME may receive an update location answer from the HSS that may include a pseudo SCEF-ID provisioned by the MME for NIDD via SCEF.

At <NUM>, the MME sends a CMR to the SCEF server(s) using the pseudo SCEF-ID as the value of the SCEF-ID field of the CMR. In response, at <NUM>, the MME receives a CMA from a SCEF instance operating on the SCEF server(s) including a "origin-host" ID field including an identifier of the SCEF instance originating the CMA.

At <NUM>, the MME may update a stored SCEF-ID value of the session being established from the pseudo SCEF-ID to the value of the "origin-host" ID field of the CMA. As mentioned above, the "origin-host" identifier of the SCEF instance may be the same as the SCEF-ID of the SCEF instance.

At <NUM>, the MME utilizes the updated SCEF-ID (e.g., the "Origin-Host" ID of the CMA) as the value of the SCEF-ID field in subsequent request(s) and/or responses associated with session being established.

Additional details of the operations shown in <FIG> are provided above with regard to <FIG> and <FIG> and are not repeated here to avoid unnecessary verbosity.

<FIG> illustrates a component level view of a telecommunication network device <NUM> capable of implementing the UEs <NUM> and <NUM>, MMEs <NUM> and <NUM>, HSSs <NUM> and <NUM>, SCEF Server(s) <NUM> and <NUM>, and/or AS(s) <NUM> and <NUM> of <FIG> and <FIG>. The network device <NUM> may, as an example, comprise a physical or virtual device. The network device <NUM> may comprise a system memory <NUM> storing various executable components and data for implementing the systems and methods <NUM>-<NUM> of <FIG>. The network device <NUM> may further comprise processor(s) <NUM>, a removable storage <NUM>, a non-removable storage <NUM>, transceivers <NUM>, output device(s) <NUM>, and input device(s) <NUM>, any or all of which can be communicatively connected via a communications bus (not shown).

In various examples, the system memory <NUM> is volatile (such as RAM), nonvolatile (such as ROM, flash memory, etc.) or some combination of the two. In some examples, the processor(s) <NUM> is a central processing unit (CPU), a graphics processing unit (GPU), or both CPU and GPU, or any other sort of processing unit.

The network device <NUM> also includes additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by removable storage <NUM> and non-removable storage <NUM>. The system memory <NUM>, removable storage <NUM> and non-removable storage <NUM> are all examples of non-transitory computer-readable storage media.

In some examples, the transceivers <NUM> include any sort of transceivers known in the art. For example, transceivers <NUM> may include a radio transceiver that performs the function of transmitting and receiving radio frequency communications. Also, or instead, the transceivers <NUM> may include other wireless or wired connectors, such as Ethernet connectors or near-field antennas. The transceivers <NUM> may facilitate connectivity between a public network, such as a packet-switched access network (not shown), and one or more other devices of a telecommunication network.

In some examples, the output devices <NUM> include any sort of output devices known in the art, such as a display, speakers, a vibrating mechanism, or a tactile feedback mechanism. Output devices <NUM> also include ports for one or more peripheral devices, such as headphones, peripheral speakers, or a peripheral display.

Claim 1:
A method comprising:
receiving (<NUM>), by a Mobility Management Entity, MME (<NUM>, <NUM>), of a carrier network, a request associated with a user equipment, UE (<NUM>, <NUM>), for a Non-IP Data Delivery, NIDD, connection via a service capability exposure function, SCEF (<NUM>, <NUM>);
transmitting (<NUM>), by the MME (<NUM>, <NUM>) and to the SCEF (<NUM>, <NUM>), a connection management request to establish a session, the connection management request using a first SCEF identifier, ID, provisioned for NIDD via the SCEF (<NUM>, <NUM>);
receiving (<NUM>), by the MME (<NUM>, <NUM>) and from a particular SCEF instance of the SCEF (<NUM>, <NUM>), a connection management answer for the session, the connection management answer including an identifier that is different from the first SCEF-ID, the identifier associated with the particular SCEF instance; and
transmitting, by the MME (<NUM>, <NUM>) and to the particular SCEF instance, a subsequent message for the session, wherein a second SCEF-ID of the subsequent message is associated with the identifier and is different from the first SCEF-ID.