Patent Description:
A Global System for Mobile communications (GSM) or a Universal Mobile Telecommunications System (UMTS) or a Long-Term Evolution (LTE) network or similar is, like most other cellular networks, basically a network of individual cells each covering a small geographical area. Each cell is associated with a radio access node (e.g. a base station or similar) for communicating wirelessly with a WCD located within the cell. By combining the coverage of all cells of a cellular network and their corresponding radio access nodes extends the coverage of the cellular network over a much wider area than a single cell.

In GSM EDGE Radio Access Network (GERAN) / UMTS Terrestrial Radio Access Network (UTRAN) a number of adjacent or neighbouring cells can be grouped into a so-called Routing Area (RA), and into a so-called Tracking Area (TA) in Evolved UTRAN (E-UTRAN). A mobility procedure in the form of a Tracking Area Update (TAU) or a Routing Area Update (RAU) is initiated when a UE enters a new TA or RA respectively. The mobility procedure may e.g. be initiated by moving UE.

Another mobility procedure in cellular networks is the so-called handover procedure, which is the process of transferring an ongoing session such as a call or data session or similar from one radio access node to another radio access node without loss or interruption of service. Typically, handover occurs when a UE moves away from the area covered by one cell and entering the area covered by another cell, whereupon the ongoing session is transferred to the second cell in order to avoid service termination Handover may occur in other situations, e.g. handover from a first cell to second cell when the UE is located in an area overlapped by both cell and the capacity of the first cell is exhausted, or handover from a macro cell to a nearby micro cell to off load the macro cell etc..

The above mentioned and exemplifying mobility procedures TAU, RAU and handover are well known to those skilled in the art and they need no detailed description as such.

<FIG> shows a schematic block diagram illustrating a known communication network 10a wherein embodiments of the present solution may be implemented. The wireless communication network 10a comprises a Radio Access Network (RAN) <NUM> in turn comprising a RAN node <NUM> connected to a Mobility Management Entity (MME) <NUM> and to a Serving Gateway (SGW) <NUM>, in turn connected to the MME <NUM>, and a Packet Data Network Gateway (PGW) <NUM>, which in turn is connected to a Policy and Charging Rules Function (PCRF) <NUM>. The RAN node <NUM> is a radio access node that interfaces with a wireless communication device (WCD).

The WCD, as exemplified by an UE <NUM> in <FIG>, is a device by which a subscriber accesses services offered by an operator's network and services outside operator's network to which the operators radio access network and core network provide access, e.g. access to the Internet (c. the Packet Data Network (PDN) <NUM> in <FIG>). The UE <NUM> in <FIG> may be any device, mobile or stationary, enabled to communicate in the communications network, for instance but not limited to e.g. user equipment, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) device, Device to Device (D2D) device, Internet of Things (IoT) device or any type of consumer electronic, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop or Personal Computer (PC). The UE <NUM> may be portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another UE or a server.

The RAN <NUM> in <FIG> is represented by an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) and the RAN node <NUM> in the E-UTRAN is represented by an evolved NodeB (eNode B, eNB). However, the RAN node may for example be a base station (in the GSM EDGE Radio Access Network (GERAN) <NUM>), a NodeB (in the Universal Terrestrial Radio Access Network (UTRAN) <NUM>), Radio Network Controller (RNC) (in the UTRAN <NUM>) or any other element capable of wireless communication with the UE <NUM> or similar at one end and a Core Network (CN) serving the UE <NUM> at the other end. The reference point between the UE <NUM> and the E-UTRAN <NUM> may be referred to as Long Term Evolution-Uu (LTE-Uu). GSM is short for Global System for Mobile Communications and EDGE is short for Enhanced Data Rates for GSM Evolution.

The MME <NUM> is connected to the E-UTRAN <NUM> via the reference point S1-MME, also known as the S1-interface for the MME. The S1 Application Protocol (S1AP) supports the functions of S1 interface by signalling procedures, e.g. as defined in the specification 3GPP TS <NUM> V14. <NUM> (<NUM>-<NUM>) 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) (Release <NUM>). The MME <NUM> is an element having functions such as e.g. Non-Access Stratum (NAS) signalling, Inter Core Network (CN) node signalling for mobility between 3rd Generation Partnership Project (3GPP) access networks, UE reachability, Tracking Area (TA) list management, PGW and SGW selection, MME selection for handover with MME change etc. S10 is the reference point between MMEs <NUM> for MME relocation and MME to MME information transfer.

The SGW <NUM> routes and forwards user data packets for the UE <NUM> over the S1-U interface, whilst also acting as the mobility anchor for the user plane of the UE <NUM> during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between <NUM>/<NUM> systems and the PGW 110a). For idle state UEs, the SGW terminates the downlink (DL) data path and triggers paging when DL data arrives for the UE <NUM> and further manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception. The SGW communicates with the MME <NUM> via the S11 interface and with the PGW 110a via the S5 interface. Further, the SGW may communicate with the UTRAN <NUM> and with the GERAN <NUM> via the S12 interface.

The PGW 110a is the gateway which terminates the SGi interface towards the Packet Data Network (PDN) <NUM>. The PDN <NUM> is illustrated in <FIG> by the Operator's IP Services (e.g. IMS, PSS etc.). IMS is short for IP Multimedia Subsystem or IM Multimedia core network Subsystem and PSS is short for Packet Switched Streaming. If the UE <NUM> is accessing multiple PDNs, there may be more than one PGW 110a for that UE <NUM>. Functions of the PGW 110a are e.g. providing connectivity from the UE <NUM> to external PDNs by being the point of exit and entry of traffic for the UE <NUM> with respect to the Core Network (CN) of the communications network 10a, performing policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening etc. S5 is the reference point which provides user plane tunnelling and tunnel management between the SGW <NUM> and the PGW 110a.

The SGSN <NUM> is responsible for the delivery of data packets from and to the UE's <NUM> within its geographical service area. One of the SGSN's <NUM> functions is to provide signaling for mobility between <NUM>/<NUM> and E-UTRAN <NUM> access networks. <NUM>/<NUM> access network are exemplified with GERAN <NUM> and UTRAN <NUM> in <FIG>. Some further functions of the SGSN <NUM> are to handle packet routing and transfer, mobility management (attach/detach and location management), logical link management, and authentication and charging functions etc. S3 is the interface between the SGSN <NUM> and the MME <NUM>. S4 is a reference point between the SGSN <NUM> and the SGW <NUM>. S12 is the reference point between the SGW <NUM> and the UTRAN <NUM>. In some embodiments, the SGSN <NUM> and the MME <NUM> are co-located in one node. In this text, the term MME/SGSN will refer to any one of a standalone MME <NUM> or a standalone SGSN <NUM> or a combined MME <NUM> and SGSN <NUM> node. The SGSN <NUM> may also be referred to as a S4-SGSN. In the following, when the term MME is used, it refers to any of the standalone MME, a combined MME/SGSN or a combined MME/S4-SGSN. The term MME is used for the sake of simplicity.

The Home Subscriber Server (HSS) <NUM> is a subscriber server node similar to the GSM Home Location Register (HLR) and Authentication Centre (AuC). The HSS <NUM> comprises subscriber-related information (subscriber profiles), performs authentication and authorization of the user, and may provide information about the subscriber's location and IP information. The reference point S6a enables transfer of subscription and authentication data for authenticating/authorizing user access to the evolved system between the MME <NUM> and the HSS <NUM>.

The PCRF <NUM> is a policy and charging control element. The PCRF <NUM> encompasses policy control decision and flow based charging control functionalities, it provides network control regarding the service data flow detection, gating, Quality of Service (QoS) and flow based charging etc. The PCRF <NUM> may be described as a functional entity which may be a standalone node or a function implemented in another node. The reference point Gx provides transfer of (QoS) policy and charging rules from the PCRF <NUM> to a Policy and Charging Enforcement Function (PCEF) in the PGW 110a or similar. Rx is the reference point which resides between the PCRF <NUM> and the Operator's IP Services represented by the PDN <NUM> in <FIG>. The Rx reference point is used to exchange application level session information between the PCRF <NUM> and one or more Application Functions (AF) (not shown).

In some embodiments, a communications network may be divided into a RAN and a Core Network (CN). Thus, the UE <NUM> reaches the CN using a suitable RAN technology, for example the E-UTRAN <NUM> as exemplified in <FIG>. Note that <FIG> uses E-UTRAN <NUM> as an example, and that the UE <NUM> may reach the CN using any other suitable access technology, both 3GPP technologies and non-3GPP technologies.

As described above, the E-UTRAN <NUM> may comprise a RAN node such as e.g. an eNB <NUM>. Using <FIG> as an example, the CN may comprise several or even all of the MME <NUM>, the SGWs <NUM>, the PGW 110a, the SGSN <NUM>, the HSS <NUM> and the PCRF <NUM>. The RAN and the CN may each comprises additional entities not shown in <FIG>. The CN may be a Packet Switched (PS) core network or a Circuit Switched (CS) core network. In other embodiments, the communications network 10a is not divided into a RAN and a CN. Instead, the communications network 10a may comprise a virtualized CN, and the control and user planes may be split. Terms such as Software Defined Network (SDN), Network Functions Virtualization (NFV) and Network Virtualization (NV) may be used in a scenario with a virtualized CN where the control and user planes are split. The user plane (sometimes known as the data plane, forwarding plane, carrier plane or bearer plane) carries the network user traffic and that the control plane carries signalling traffic. As the SDN may decouple the user and control planes, it removes the control plane from network hardware and implements it in software instead, which enables programmatic access and, as a result, makes network administration much more flexible. The control plane signalling may be routed to the virtualized CN and the user plane signalling is bypassed the virtualized CN. A virtualized CN may comprise virtual network services enabled by a virtualized MME (vMME), virtualized SGSN (vSGSN), virtualized PGW (vPGW), virtualized SGW (vSGW), virtualized Gateway GPRS Support Node (vGGSN), virtualized PCRF (vPCRF), virtualized Deep Packet Inspection (vDPI), vProbe, virtualized Evolved Packet Data Gateway (vePDG) and virtualized Trusted Wireless Local Area Network Access Gateway (vTWAG) etc..

It should be noted that the communication links in the communications systems seen in <FIG> may be of any suitable kind including either a wired or wireless link. The link may use any suitable protocol depending on type and level of layer (e.g. as indicated by the Open Systems Interconnection (OSI) model) as understood by the person skilled in the art.

<FIG> shows a schematic block diagram illustrating a known communication network 10b wherein embodiments of the present solution may be implemented. In particular, <FIG> shows an architecture for a User Equipment (UE) used for non-roaming Machine Type Communication (MTC) connecting to the 3GPP network (UTRAN, E-UTRAN, GERAN, etc.) via the Um/Uu/LTE-Uu interfaces. <FIG> also shows the 3GPP network service capability exposure to Service Capability Server (SCS) and Application Server (AS).

<FIG> shows a schematic block diagram illustrating a known communication network 10b wherein embodiments of the present solution may be implemented. In particular, <FIG> shows an architecture for a User Equipment (UE) used for roaming Machine Type Communication (MTC) connecting to the 3GPP network (UTRAN, E-UTRAN, GERAN, etc.) via the Um/Uu/LTE-Uu interfaces. <FIG> also shows the 3GPP network service capability exposure to Service Capability Server (SCS) and Application Server (AS).

Figures 10b and 10c are copied from the above mentioned specification 3GPP TS <NUM> V14. <NUM> (<NUM>-<NUM>), which specifies architecture enhancements to facilitate communications with packet data networks and applications (e.g. Machine Type Communication (MTC) applications on the (external) network/MTC servers. Both roaming and non-roaming scenarios are covered. The specification TS <NUM> also specifies transmission of non-IP data via Service Capability Exposure Function (SCEF) and Interworking SCEF (IWK-SCEF) for the Cellular Internet of Things (CIoT) Evolved Packet Core (EPS) Optimization.

Reference points (interfaces) shown in Figures 10b-10c are:.

The Service Capability Exposure Function (SCEF) <NUM> shown in Figures 10b-10c is the key entity within the 3GPP architecture for service capability exposure that provides a means to securely expose the services and capabilities provided by 3GPP network interfaces. MTC-IWF may be co-located with SCEF in which case Tsp functionality would be exposed via API, functions provided by the MME/SGSN (e.g. NIDD and Event Monitoring) would be exposed to the MTC-IWF by the SCEF and functions provided by the MTC-IWF (e.g. T4 Triggering) would be available to the SCEF. When they are not co-located, the SCEF may access MTC-IWF functionality via the Tsp interface. Defining interfaces that permit the SCEF to access services or capabilities at either a new or an existing 3GPP Network Element lies within 3GPP scope. The choice of which protocols to specify for such new 3GPP interfaces (e.g. DIAMETER, RESTful APIs, XML over HTTP, etc.) will depend on multiple factors including but not limited to the needs of that specific interface or ease of exposure of requested information. A capability of the SCEF is to monitor and provide notifications of desired events to the AS (Application Server) regarding a UE. For example, the SCEF can be the interface for small data transfers and control messaging between Enterprises and the Operators Core Network (CN). The Interworking SCEF (IWK-SCEF) <NUM> shown in Figures 10b-10c is optional. When deployed, the IWK-SCEF is located in the Visited PLMN (VPLMN) as shown in <FIG>.

Service Capability Server (SCS) <NUM> shown in Figures 10b-10c enables applications to access and use functionality provided by service components over standardized interfaces (APIs). An SCS hosts one or several service components. For example, in the 3GPP IP Multimedia Subsystem (IMS) architecture, the SCS may be a gateway device which translates Session Initiation Protocol (SIP) signalling into an Open Service Access (OSA) Application Programming Interface (API) and vice versa. As such, the SCS may be positioned between the Serving Call Session Control Function (S-CSCF) and the OSA service environment.

Application Server (AS) <NUM> shown in Figures 10b-10c may be seen as a type of server designed to install, operate and host applications and associated services for end users, IT services and organizations. It facilitates the hosting and delivery of high-end consumer or business applications, which are used by multiple and simultaneously connected local or remote users. An AS may consists of a server operating system (OS) and server hardware that work together to provide computing-intensive operations and services to the residing application. An AS may execute and provide user and/or other application access when utilizing the installed application's business/functional logic. Key required features of an AS may include data redundancy, high availability, load balancing, user management, data/application security and a centralized management interface. An AS may be connected by enterprise systems, networks or intranet and remotely accessed via the Internet. Depending on the installed application, an AS may be classified in a variety of ways, e.g. as a Web server, database application server, general purpose application server or enterprise application (EA) server.

The Third Generation Partnership Project (3GPP) specifications have recently provided support for Non-Internet Protocol (IP) (Non-IP) Data Delivery (NIDD) as part of the Cellular Internet of Things (CIoT) Evolved Packet System (EPS) optimizations, see e.g. the specification 3GPP TS <NUM> V14. <NUM> (<NUM>-<NUM>) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements to facilitate communications with packet data networks and applications (Release <NUM>). For example, the Non-Access Stratum (NAS) protocol has been extended to allow small amounts of data to be transferred over the control plane using NIDD.

For the data delivery over NAS (e.g. DoNAS or "Control Plane CIoT Optimization") which was introduced in 3GPP Relase-<NUM>, there is a problem with reliable delivery that has been studied in a Release-<NUM> study, see key issue #<NUM> (clause <NUM>) and solution #<NUM> (clause <NUM>) in the technical report 3GPP TR <NUM> V1. <NUM> (<NUM>-<NUM>) Technical Report 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on extended architecture support for Cellular Internet of Things (Release <NUM>).

The technical report 3GPP TR <NUM> discusses alternative delivery of data over NAS in alternative 5c "Based on hop by hop acknowledgment" in clause <NUM>. <NUM> and in alternative 5d in clause <NUM>. Alternative 5c builds on 5d, such that 5d provides a Negative acknowledgement (unsuccessful delivery) and 5c provides both a Positive acknowledgement (successful delivery) and a Negative acknowledgement (based on 5d).

However, the eNB or similar in the serving Public Land Mobile Network (PLMN), e.g. in a Visited PLMN, may or may not be upgraded to support the Rel-<NUM> reliability hop-by-hop feature (alternative 5c in TR <NUM> above). It is important that the SCEF knows if a reliable delivery was used or not. For example, the SCEF or the AS may decide to switch to application level acknowledgements i.e. UE-AS, if the reliability hop-by-hop feature is not supported by the 3GPP access in the cell where the device is camping.

D1) The document <NPL> disclose some related art as alternatives 5a, 5b, 5c and 5d.

Alternative 5a relies on defining new UE-SCEF transport protocol that provide acknowledgement of data send between UE and SCEF. For MO data SCEF will send acknowledgment and for MT data UE sends acknowledgment. SDT PDU is used between UE and SCEF for reliable delivery of MO/MT data.

Alternative 5b is based on principle of reliable delivery between UE and MME coupled with reliable delivery between MME and SCEF.

T6a is Diameter based and Diameter provide reliable delivery but it cannot guarantee successful processing at the data receiving node. This issue is mitigated by adding acknowledgement of each non- IP data delivery (NIDD) message. Given this we can assume that T6a protocol between MME and SCEF currently provides reliable data delivery.

In Rel-<NUM> new NAS message - Control Plane Service Request is defined for UE using Control Plane CloT EPS optimization for initial NAS PDU data delivery between UE and MME. MME also sends acknowledgement in Service Accept message. This provide reliable delivery for first MO data packet. However subsequent data packet while UE is in ECM_CONNECTED is not guaranteed. Subsequent message for Control Plane EPS optimizations while UE is in connected mode are carried in ESM Data Transport Message which is not acknowledged.

For this alternative, some NAS messages (e.g. ESM Data Transport) would need to be enhanced to provide acknowledgment of data delivery between UE and MME.

Alternative 5c is based on principle of hop by hop reliable delivery that is reliable delivery between UE and eNB, coupled with reliable delivery between eNB and MME, coupled with reliable delivery between MME and SCEF.

As we discussed in alternative 5b, we can we can assume that T6a protocol between MME and SCEF currently provides reliable data delivery.

Between UE and eNB, RLC acknowledged mode is could be used between UE and eNB for reliable delivery of data.

Between eNB and MME, Sl-AP would needs to be enhanced to provide acknowledgement of Sl-AP messages carrying NAS PDU with data. The internal eNB functionality to e.g. determine RLF and support such an S1-AP procedure is provided as described in alternative 5d, below.

Between the MME and SCEF, T6a needs to be enhanced to carry the acknowledgements from the MME to the SCEF.

Alternative 5d discloses that, as per legacy specification TS <NUM>, downlink NAS message delivery is supervised by the eNodeB. If eNodeB is unable to deliver a NAS message to the UE it uses the SlAP NAS NON DELIVERY INDICATION procedure (see TS <NUM>) whereby it sends the non-delivered NAS message back to the MME.

It is proposed to use that procedure when NAS message that contains data sent from the SCEF to the UE can't be delivered over the radio link e.g. due to UE experiencing a RLF (no handover supported for EPS CP CIOT Optimization). Subsequent to reception of the S lAP NAS NON DELIVERY INDICATION message that carries the non-delivered data, the MME stores that data for a configurable period of time. If, as a result of the RLF, the UE performs a TAU, then the MME can re-attempt to deliver that data to the UE. If the UE does not do a TAU, the MME informs the SCEF that that PDU has not been delivered.

D2) Also the document "<NPL>" discloses some related art is. The document specifies architecture enhancements to facilitate communications with packet data networks and applications (e.g. Machine Type Communication (MTC) applications on the (external) network/MTC servers) according to the use cases and service requirements defined in the 3GPP specification TS <NUM> [<NUM>], TS <NUM>, and related 3GPP requirements specifications. Both roaming and non-roaming scenarios are covered. The document also specifies transmission of non-IP data via SCEF for the CloT EPS Optimization.

D3) Similarly, the document "<NPL>" also discloses some related art. The document studies and evaluates the architecture enhancement to support Cellular Internet of Things (CloT). The scope includes NB-IoT, eMTC, and EC-GSM-IoT. The study considers architecture enhancements and/or simplifications in the following areas:
Support of authorization of use of Coverage Enhancement functionality;.

An object of the present invention is to solve, or at least mitigate, the problem(s) mentioned or indicated above. acknowledged mode on application level instead. However it is preferred not to use application layer acknowledgements since these consumes more battery in the device and more resources in the network, but is an alternative method for guarantee reliable delivery.

The above indicated embodiments and further embodiments of the invention will be discussed in more detail in the detailed description hereinbelow with reference made to the accompanying drawings.

The invention will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

Embodiments described herein may comprise one or more of the following properties:.

<FIG> shows a signalling diagram illustrating a delivery of user data to a UE (WCD <NUM>) sent by a SCEF <NUM> according to an embodiment of the present solution. <FIG> illustrates a procedure in which the SCS <NUM> / AS <NUM> sends non-IP data to a given UE as identified via External Identifier or a Mobile Station International Subscriber Directory Number (MSISDN) or similar.

Action <NUM>. If the SCS <NUM> / AS <NUM> has already activated the NIDD service for a given UE (WCD <NUM>), and has downlink non-IP data to send to the UE, the SCS/AS sends a NIDD Submit Request (External Identifier or MSISDN, SCS/AS Reference ID, non-IP data) message to the SCEF.

Action <NUM>. If an SCEF EPS bearer context corresponding to the External Identifier or MSISDN included in step <NUM> is found, then the SCEF <NUM> checks whether the SCS <NUM> / AS <NUM> is authorised to send NIDD requests and that the SCS <NUM> has not exceeded its quota (e.g. <NUM> bytes in 24hrs) or rate (e.g. <NUM> bytes / hour) of data submission. If this check fails, the SCEF <NUM> sends a NIDD Submit Response (action <NUM>) with a cause value indicating the reason for the failure condition and the flow stops at this step. Otherwise, the flow continues with action <NUM>.

If no SCEF EPS bearer context is found, then the SCEF <NUM>, depending on configuration, may either:.

Action <NUM>. If an SCEF EPS bearer context corresponding to the External Identifier or MSISDN included in step <NUM> is found, then the SCEF <NUM> sends a NIDD Submit Request (User Identity, EPS Bearer ID, SCEF ID, non-IP data, SCEF Wait Time, Maximum Re-transmission time) message toward the MME <NUM>. The SCEF Wait Time indicates how long the SCEF <NUM> is prepared to wait for MME <NUM> response. Maximum Re-transmission indicates how long the SCEF <NUM> is prepared to re-transmit the message. If the IWK-SCEF <NUM> receives a NIDD Submit Request message from the SCEF <NUM>, it relays the message to the MME <NUM>.

Action <NUM>. If the MME <NUM> can immediately deliver the non-IP data to the UE e.g. when UE is already in ECM_CONNECTED mode, or UE is in ECM_IDLE and the MME <NUM> can initiate paging procedure, the procedure proceeds at action <NUM>.

If the MME <NUM> is aware of the UE being temporarily unreachable, or if the MME <NUM> that the UE is not scheduled to be reachable within the SCEF Wait Time, while using power saving functions e.g. UE Power Saving Mode or extended idle mode DRX, then the MME <NUM> may send a NIDD Submit Response (Cause, Requested Re-Transmission Time) message towards the SCEF <NUM>. The Cause parameter indicates that Non-IP data was not delivered to the UE, as the UE is temporarily not reachable due to power saving but the MME <NUM> will notify the SCEF <NUM> when the MME <NUM> determines that the UE is reachable. The MME <NUM> sets the Not Reachable for NIDD flag in the EMM context for this UE and stores the corresponding SCEF address. If the Maximum Re-transmission Time was included in the Request, the MME <NUM> may indicate in Requested Re-Transmission time IE the time when the SCEF <NUM> is expected to re-transmit the DL data to the currently unreachable UE.

Action <NUM>. The SCEF <NUM> may send a NIDD Submit Response to the SCS <NUM> /AS <NUM> informing of the received results from the MME <NUM>. If the SCEF <NUM> receives from the MME <NUM> a Cause value indicating that UE is temporarily not reachable due to power saving, the SCEF <NUM> can buffer the non-IP data requested at action <NUM> based on the configuration.

Action <NUM>. When the MME <NUM> detects that the UE is reachable (e.g. when coming out of PSM mode by performing TAU/RAU, when initiating MO communication etc), or when the UE is about to become reachable (e.g. extended idle mode DRX cycle expiring, MME <NUM> anticipating MO communication pattern for the UE etc), and the MME <NUM> has the Not Reachable for NIDD flag set, then the MME <NUM> sends a NIDD Submit Indication (User Identity) message towards the SCEF <NUM>. The MME105 clears the Not Reachable for NIDD flag from its EMM context.

If the MME <NUM> included the Requested Re-transmission-Time in the NIDD Submit Response, the MME <NUM> sends a NIDD Submit Indication (User Identity) message towards the SCEF <NUM> only if the UE becomes reachable before the Requested Re-transmission Time. The MME <NUM> shall clear the Not Reachable for NIDD flag when the Requested Re-transmission Time expires and the UE has not become reachable yet.

Action <NUM>. The SCEF <NUM> sends a NIDD Submit Request (User Identity, EPS Bearer ID, SCEF ID, non-IP data, SCEF Wait Time, Maximum Re-transmission time) message toward the MME <NUM>.

Action <NUM>. If required, the MME <NUM> pages the UE and delivers the non-IP data to the UE using data transfer via the MME procedure, e.g. as described below with reference to <FIG> or <FIG>, see e.g. Actions <NUM>-<NUM> and Actions <NUM>-<NUM>. Depending on operator configuration, the MME <NUM> may generate the necessary accounting information required for charging.

Action <NUM>. If the MME <NUM> was able to initiate action <NUM>, then the MME <NUM> sends a NIDD Submit Response (cause) message towards the SCEF <NUM> acknowledging the NIDD Submit Request from SCEF <NUM> received in action <NUM> or <NUM> above. If the eNodeB supported reliably hop-by-hop delivery, the cause is 'Success Acknowledged Delivery' otherwise 'Success Unacknowledged Delivery'. If the delivery failed, the cause is 'Unsuccessful delivery'. The SCEF <NUM> confirms the non-IP data transfer towards the SCS <NUM> / AS <NUM> and may include the success reliability level.

The 'Success Acknowledged Delivery' implies reliable delivery to the UE, e.g. using RLC acknowledged mode. The 'Success Unacknowledged Delivery'successful result does not imply the data is successfully received at the UE, but just the MME <NUM> has sent the non-IP data in NAS signalling to the UE.

<FIG> shows a signalling diagram illustrating some details of the delivery of data to a UE (WCD <NUM>) sent by the SCEF <NUM> according to an embodiment of the present solution.

Action <NUM>. The UE is EPS attached and in ECM-Idle mode.

Action <NUM>. When the S-GW <NUM> receives a downlink data packet/control signalling for a UE, if the S- GW context data indicates no downlink user plane TEID towards the MME <NUM>, it buffers the downlink data packet and identifies which MME <NUM> is serving that UE.

If that MME <NUM> has requested the S-GW to throttle downlink low priority traffic and if the downlink data packet is received on a low priority bearer to be throttled, the S-GW drops the downlink data. The actions below are not executed.

If that MME <NUM> has requested the S-GW to delay sending the Downlink Data Notification, the S-GW buffers the downlink data and waits until the timer expires before continuing with action <NUM>. If the DL-TEID and MME address for that UE is received before the expiry of the timer, the timer shall be cancelled and the Mobile Terminated Data transport procedure is progressed from step <NUM> as Downlink data are sent to the UE.

If the S-GW receives additional downlink data packets/control signalling for this UE before the expiry of the timer, the S-GW does not restart this timer.

Action <NUM>. If the S-GW <NUM> is buffering data in action <NUM>, the S-GW sends a Downlink Data Notification message (ARP, EPS Bearer ID) to the MME <NUM> for which it has control plane connectivity for the given UE. The ARP and EPS Bearer ID are always set in Downlink Data Notification. The MME <NUM> responds to the S-GW <NUM> with a Downlink Data Notification Ack message.

An MME <NUM> detecting that the UE is in a power saving state (e.g. Power Saving Mode) and cannot be reached by paging at the time of receiving Downlink data notification, shall invoke extended buffering depending on operator configuration, except for cases described in next paragraphs. The MME <NUM> derives the expected time before radio bearers can be established to the UE. The MME <NUM> then indicates Downlink Buffering Requested to the S-GW in the Downlink Data Notification Ack message and includes a Downlink Buffering Duration time and optionally a Downlink Buffering Suggested Packet Count. The MME <NUM> stores a new value for the Downlink Data Buffer Expiration Time in the MM context for the UE based on the Downlink Buffering Duration time and skips the remaining steps of this procedure. The Downlink Data Buffer Expiration Time is used for UEs using power saving state and indicates that there are buffered data in the S-GW <NUM> and that the user plane setup procedure is needed when the UE makes signalling with the network. When the Downlink Data Buffer Expiration Time has expired, the MME <NUM> considers no Downlink data to be buffered and no indications of Buffered Downlink Data Waiting are sent during context transfers at TAU procedures.

If there is an "Availability after DDN Failure" monitoring event configured for the UE in the MME <NUM>, the MME does not invoke extended buffering. Instead, the MME <NUM> sets the Notify-on-available-after-DDN-failure flag to remember to send an "Availability after DDN Failure" notification when the UE becomes available. If there is a "UE Reachability" monitoring event configured for the UE in the MME <NUM>, the MME does not invoke extended buffering.

When "Availability after DDN failure" and "UE reachability" monitoring events are used for a UE, the application server is assumed to send data only when the UE is reachable, hence no extended buffering is needed. If there are multiple application servers, the event notifications and extended buffering may be needed simultaneously. It is assumed this is handled through additional information based on SLA as described in the next paragraph.

The MME <NUM> may use additional information based on a SLA with the MTC user for when to invoke extended buffering, e.g. only invoke it for a certain APN, do not invoke it for certain subscribers, invoke extended buffering in conjunction with "Availability after DDN failure" and "UE reachability" monitoring events, etc..

A S-GW <NUM> that receives a Downlink Buffering Requested indication in a Downlink Data Notification Ack message stores a new value for the Downlink Data Buffer Expiration Time based on the Downlink Buffering Duration time and does not send any additional Downlink Data Notification if subsequent downlink data packets are received in the Serving GW before the buffer time Downlink Data Buffer Expiration Time has expired for the UE.

If the S-GW <NUM>, while waiting for the user plane to be established, is triggered to send a second Downlink Data Notification for a bearer with higher priority (i.e. ARP priority level) than that of the bearer for which the first Downlink Data Notification was sent, the S-GW sends a new Downlink Data Notification message indicating the higher priority to the MME <NUM>. If the S-GW receives additional downlink data packets for a bearer with same or lower priority than the first Downlink Data Notification was sent for or if the S-GW has sent the second Downlink Data Notification message indicating the higher priority and receives additional downlink data packets for this UE, the S-GW buffers these downlink data packets and does not send a new Downlink Data Notification.

If the S-GW <NUM>, while waiting for the user plane to be established, receives a Modify Bearer Request message from an MME other than the one it sent a Downlink Data Notification message to, the S-GW re-sends the Downlink Data Notification message but only to the new MME from which it received the Modify Bearer Request message.

Upon reception of a Downlink Data Notification Ack message with an indication that the Downlink Data Notification message has been temporarily rejected and if the Downlink Data Notification is triggered by the arrival of downlink data packets at the S-GW <NUM>, the S-GW may start a locally configured guard timer and buffers all downlink user packets received to the given UE and waits for a Modify Bearer Request message to come. Upon reception of a Modify Bearer Request message, the S-GW re-sends the Downlink Data Notification message but only to the new MME from which it received the Modify Bearer Request message. Otherwise the S-GW releases buffered downlink user packets upon expiry of the guard timer or upon receiving the Delete Session Request message from MME <NUM>. If the S11-U is already established (buffering is in the MME <NUM>), action <NUM> is not executed and actin <NUM> is immediately executed. Actions <NUM>, <NUM>, <NUM>, <NUM> are executed only if conditions are met when the NAS service request is received at action <NUM>, as outlined below in the respective clauses.

An MME <NUM> detecting that the UE is in a power saving state (e.g. Power Saving Mode) and cannot be reached by paging at the time of receiving Downlink data, shall start extended buffering depending on operator configuration, except for cases described in next paragraphs. The MME derives the expected time before radio bearers can be established to the UE, stores a new value for the Downlink Data Buffer Expiration Time in the MM context for the UE and skips the remaining steps of this procedure. When the Downlink Data Buffer Expiration Time has expired, the MME considers no Downlink data to be buffered.

Also for the case of buffering in the MME <NUM> the "Availability after DDN Failure" monitoring event can be configured for the UE, even though the actual DDN is not received and the Downlink data is received. The "UE Reachability" monitoring event can be configured also. The extended buffering can also be configured as per what is described above in this step of the procedure for the case of buffering in S-GW <NUM>.

Action <NUM>. If the UE is registered in the MME <NUM> and considered reachable, the MME <NUM> sends a Paging message (NAS ID for paging, TAI(s), UE identity based DRX index, Paging DRX length, list of CSG IDs for paging, Paging Priority indication) to each eNodeB <NUM> belonging to the tracking area(s) in which the UE is registered.

Paging priority indication is included only:.

When implementing such optimisations/strategies, the MME <NUM> shall take into account any PSM active timer and the DRX interval for the UE.

If the UE Radio Capability for Paging Information is available in the MME <NUM>, the MME adds the UE Radio Capability for Paging Information in the S1 Paging message to the eNB <NUM>.

If the Information on Recommended Cells And ENBs For Paging is available in the MME <NUM>, the MME shall take that information into account to determine the eNBs for paging and, when paging an eNB <NUM>, the MME may transparently convey the information on recommended cells to the eNB.

The MME <NUM> may include in the S1AP Paging message(s) the paging attempt count information. The paging attempt count information shall be the same for all eNBs selected by the MME for paging.

If the MME <NUM> has Information for Enhanced Coverage stored, the MME shall include it in the Paging message for all eNBs selected by the MME for paging.

Action <NUM>. If eNodeBs receive paging messages from the MME <NUM>, the UE is paged by the eNodeBs.

Action <NUM>-<NUM>. As the UE is in the ECM-IDLE state, upon reception of paging indication, the UE sends a UE triggered Service Request NAS message over RRC Connection request and an S1-AP initial message or similar. The eNodeB <NUM> indicates in the S1-AP Initial UE message or similar if the eNodeB <NUM> supports acknowledgments for downlink NAS data Packet Data Units (PDUs) (including e.g. non-IP data units), e.g. based on RLC acknowledged mode. The Service Request NAS message, when C-IoT Control Plane optimisation applies, does not trigger Data radio bearer establishment by the MME <NUM> and the MME can immediately send Downlink Data it receives using a NAS PDU to the eNodeB <NUM>. The MME <NUM> supervises the paging procedure with a timer. If the MME <NUM> receives no response from the UE to the Paging Request message, it may repeat the paging according to any applicable paging strategy described in action <NUM>.

If the MME <NUM> receives no response from the UE after this paging repetition procedure, it shall use the Downlink Data Notification Reject message to notify the S-GW <NUM> about the paging failure (or, equivalently, if the buffering is in the MME, the MME simply discards data for the UE locally), unless the MME is aware of an ongoing MM procedure that prevents the UE from responding, i.e. the MME received a Context Request message indicating that the UE performs TAU with another MME. When a Downlink Data Notification Reject message is received, the S-GW <NUM> deletes the buffered packet(s). The S-GW <NUM> may invoke the procedure P-GW Pause of Charging if UE is in ECM IDLE and the PDN GW has enabled "PDN charging pause" feature. If buffering is in the MME, Pause Charging is triggered by the MME <NUM> via a Release Access Bearer Request to the S-GW(not shown in <FIG>) including a "Abnormal Release of Radio Link" cause , which releases the S11-U.

To assist the MME <NUM> in any NAS PDU retransmission strategies, the eNB <NUM> indicates the UE's Coverage Level to the MME <NUM>.

The MME <NUM> performs (and the UE responds to) any EMM or ESM procedures if necessary, e.g. the security related procedures. Actions <NUM> to <NUM> can continue in parallel to this, however, steps <NUM> and <NUM> shall await completion of all the EMM and ESM procedures.

Action <NUM>. If the S11-U is not established, the MME <NUM> sends a Modify Bearer Request message (MME address, MME TEID DL, Delay Downlink Packet Notification Request, RAT Type) for each PDN connection to the S-GW <NUM>. The S-GW <NUM> is now able to transmit downlink data towards the UE. The usage of the Delay Downlink Packet Notification Request Information Element is specified with reference to the UE initiated service request procedure, but it equally applies in this case. The MME <NUM> shall indicate S11-U tunnelling of NAS user data and send its own S11-U IP address and MME DL TEID for DL data forwarding by the S-GW <NUM>. Also, regardless of whether the S11-U was already established:.

If the Radio Access Technology (RAT) currently used is NB-IOT this shall be reported as different from other -E-UTRA flavors.

Action <NUM>. If the RAT Type has changed compared to the last reported RAT Type or if the UE's Location and/or Info IEs and/or UE Time Zone and Serving Network id are present in action <NUM>, the S-GW shall send the Modify Bearer Request message (RAT Type) to the P-GW <NUM>. User Location Information IE and/or User CSG Information IE and/or Serving Network IE and/or UE Time Zone are also included if they are present in action <NUM>.

If the Modify Bearer Request message is not sent because of above reasons and the P-GW charging is paused, then the S-GW <NUM> shall send a Modify Bearer Request message with PDN Charging Pause Stop Indication to inform the P-GW <NUM> that the charging is no longer paused. Other IEs are not included in this message.

Action <NUM>. The P-GW <NUM> sends the Modify Bearer Response to the S-GW <NUM>.

Action <NUM>. If a Modify Bearer Request message was sent at action <NUM>, the S-GW <NUM> shall return a Modify Bearer Response (Serving GW address and TEID for uplink traffic) to the MME <NUM> as a response to a Modify Bearer Request message. The S-GW address for S11-U User Plane and S-GW TEID are used by the MME <NUM> to forward UL data to the S-GW <NUM>.

Action <NUM>. Buffered (if S11-U was not established) Downlink data (e.g. such as non-IP data) is sent by the S-GW <NUM> to the MME <NUM>.

Actions <NUM>-<NUM>. The MME <NUM> encrypts and integrity protects the Downlink data received in action <NUM> above and sends it to the eNodeB <NUM>, preferably using a NAS PDU preferably carried by a Downlink S1-AP message or similar. If the eNodeB <NUM> supports acknowledgements of downlink NAS data PDUs, the MME <NUM> indicates in the Downlink S1-AP message or similar that an acknowledgment of the data delivery is requested (positive and negative depending on result) from the eNodeB <NUM>. This parameter makes possible to avoid unnecessary acknowledgement signaling from eNB <NUM> to MME <NUM> when not required. For IP PDN type PDN connections configured to support Header Compression, the MME <NUM> shall apply header compression before encapsulating data into the NAS message.

If the eNodeB <NUM> reports an unsuccessful delivery of the data, e.g. using a S1-AP NAS Non Delivery Indication, (the MME <NUM> may e.g. decide that it may have been because of a cell change) the MME should wait for some time, e.g. until the UE has changed cell and re-established contact with the MME <NUM>, and then resend the Downlink S1-AP message to the eNodeB <NUM>. If the eNodeB <NUM> still reports an unsuccessful delivery the the MME <NUM> should report an unsuccessful delivery to the SCEF. This should also preferably be don in case of a T6a procedure. If the eNodeB <NUM> reports a successful delivery, e.g. with a S1-AP NAS Delivery Indication and if the Downlink data was received over the T6a interface, the MME <NUM> should respond to the SCEF <NUM>, see e.g. action <NUM> described above referring to <FIG>. If the eNodeB <NUM> doesn't support acknowledgement of a successful delivery of the data to the UE, e.g. supports a S1-AP NAS Delivery Indications, the MME <NUM> indicates a cause code 'Success Unacknowledged Delivery' to the SCEF <NUM>. If the eNodeB <NUM> supports acknowledgement of a successful delivery of the data to the UE then the MME <NUM> indicates a cause code 'Success acknowledged Delivery' to the SCEF <NUM>.

Action <NUM>. The NAS PDU with data is delivered to the UE via a Downlink RRC message. This is taken by the UE as implicit acknowledgment of the Service Request message sent in action <NUM>. If header compression was applied, to the PDN, the UE shall perform header decompression to rebuild the IP header.

Action <NUM>. While the RRC connection is still up, further Uplink and Downlink data can be transferred using NAS PDUs. In action <NUM> an Uplink data transfer is shown using an Uplink RRC message encapsulating a NAS PDU with data. At any time the UE has no user plane bearers established, the UE may provide a Release Assistance Information with Uplink data in the NAS PDU.

For IP PDN type PDN connections configured to support Header Compression, the UE shall apply header compression before encapsulating it into the NAS message.

Action <NUM>. The NAS PDU with data is send to the MME <NUM> in an Uplink S1-AP message.

Action <NUM>. The data is checked for integrity and decrypted. If header compression was applied to the PDN, the MME <NUM> shall perform header decompression to rebuild the IP header.

Action <NUM>. The MME <NUM> sends Uplink data to the PGW <NUM> via the S-GW <NUM> and preferably executes any action related to the presence of Release Assistance Information as follows:.

Action <NUM>. If no NAS activity exists for a while the eNB <NUM> detects inactivity and executes action <NUM>.

Action <NUM>. The eNB <NUM> starts an eNodeB initiated S1 release procedure or a Connection Suspend Procedure.

Action <NUM>. The UE is in ECM-Idle mode.

Action <NUM>. The UE establishes a RRC connection and sends as part of it an integrity protected NASPDU. The NAS PDU carries the EPS Bearer ID and encrypted Uplink Data. The UE may also indicate in a Release Assistance Information in the NAS PDU whether no further Uplink or Downlink Data transmissions are expected, or only a single Downlink data transmission (e.g. Acknowledgement or response to Uplink data) subsequent to this Uplink Data transmission is expected. If a cell change happens before the UE has received acknowledgement of successful uplink transmission, the UE shall retransmit the NAS PDU when connectivity has been established in the new cell.

Action <NUM>. The NAS PDU sent in action <NUM> is relayed to the MME <NUM> by the eNodeB <NUM>, preferably using a S1-AP Initial UE message or similar. The eNodeB <NUM> indicates in the S1-AP Initial UE message or similar if the eNodeB <NUM> supports acknowledgments for downlink NAS data Packet Data Units (PDUs) (including e.g. non-IP data units), e.g. based on RLC acknowledged mode.

To assist the MME <NUM> in any NAS PDU retransmission strategies, the eNB <NUM> may indicate the UE's Coverage Level to the MME <NUM>.

Action <NUM>. The MME <NUM> checks the integrity of the incoming NAS PDU and decrypts the data it contains. The MME <NUM> shall decompress the IP header if header compression applies to the PDN connection.

The MME <NUM> performs (and the UE responds to) any EMM or ESM procedures if necessary, e.g. the security related procedures. Action <NUM> to <NUM> can continue in parallel to this, however, actions <NUM> and <NUM> shall await completion of all the EMM and ESM procedures.

If the S11-U connection is not established, the MME <NUM> sends a Modify Bearer Request message (MME address, MME TEID DL, Delay Downlink Packet Notification Request, RAT Type, MO Exception data counter) for each PDN connection to the S-GW <NUM>. The S-GW <NUM> is now able to transmit downlink data towards the UE. The usage of the Delay Downlink Packet Notification Request Information Element is specified with reference to the UE initiated service request procedure, but it equally applies in this case. The MME <NUM> shall indicate S11-U tunnelling of NAS user data and send its own S11-U IP address and MME DL TEID for DL data forwarding by the S-GW <NUM>. Also, regardless of whether the S11-U was already established:.

If the RAT currently used is NB-IOT this shall be reported as different from other E-UTRA flavors.

The MME <NUM> only includes MO Exception data counter if the RRC establishment cause is set to "MO exception data" and the UE is accessing via the NB-IoT RAT. The S-GW <NUM> indicates each use of this RRC establishment cause by the related counter on its CDR. The MME maintains the MO Exception Data Counter and sends it to the S-GW <NUM>.

If the S11-U connection is established and the UE is accessing via the NB-IoT RAT with the RRC establishment cause set to "MO exception data", the MME <NUM> should notify the S-GW <NUM>. The MME <NUM> maintains the MO Exception Data Counter and sends it to the S-GW <NUM>.

Action <NUM>. If the RAT Type has changed compared to the last reported RAT Type or if the UE's Location and/or Info IEs and/or UE Time Zone and Serving Network id are present in action <NUM>, the S-GW <NUM> shall send the Modify Bearer Request message (RAT Type, RRC establishment cause) to the P-GW <NUM>. User Location Information IE and/or User CSG Information IE and/or Serving Network IE and/or UE Time Zone are also included if they are present in action <NUM>.

If the Modify Bearer Request message is not sent because of above reasons and the P-GW charging is paused, then the SGWS-GW shall send a Modify Bearer Request message with PDN Charging Pause Stop Indication to inform the P-GW <NUM> that the charging is no longer paused. Other IEs are not included in this message.

If the Modify Bearer Request message is not sent because of above reasons but the MME <NUM> indicated MO Exception data counter, then the S-GW <NUM> should notify the P-GW <NUM> that this RRC establishment cause has been used by the indication of the MO Exception Data Counter. The S-GW <NUM> indicates each use of this RRC establishment cause by the related counter on its CDR.

The P-GW <NUM> indicates each use of the RRC establishment cause "MO Exception Data" by the related counter on its CDR.

Action <NUM>. If a Modify Bearer Request message was sent at actin <NUM> the S-GW <NUM> shall return a Modify Bearer Response (Serving GW address and TEID for uplink traffic) to the MME <NUM> as a response to a Modify Bearer Request message. The Serving GW address for S11-U User Plane and Serving GW TEID are used by the MME to forward UL data to the S-GW.

Action <NUM>. The MME <NUM> sends Uplink data to the P-GW <NUM> via the S-GW <NUM>.

Action <NUM>. If no Downlink Data are expected based on the Release Assistance Information from the UE in action <NUM>, this means that all application layer data exchanges have completed with the UL data transfer, and therefore, unless the MME <NUM> is aware of pending MT traffic and unless S1-U bearers are established, the MME immediately releases the connection and therefore actin <NUM> is executed.

Otherwise, Downlink data may arrive at the P-GW <NUM> and the P-GW sends them to the MME <NUM> via the S-GW <NUM>. If no data is received actions <NUM>-<NUM> are skipped and the eNB <NUM> may trigger actin <NUM> after action <NUM> detects no activity. While the RRC connection is active, the UE may still send Uplink data and may receive Downlink data in NAS PDUs that are carried in a S1AP Uplink or (respectively) Downlink messages (not shown in the figure). At any time the UE has no user plane bearers established it may provide Release Assistance Information with the Uplink data.

Action <NUM>. If Downlink data are received in action <NUM>, the MME <NUM> encrypts and integrity protects the Downlink data.

Action <NUM>. If action <NUM> is executed then Downlink data are encapsulated in a NAS PDU and sent to the eNB <NUM>, preferably in a Downlink S1-AP Message or similar. If the eNodeB <NUM> supports acknowledgements of downlink NAS data PDUs, the MME <NUM> indicates in the Downlink S1-AP message or similar that an acknowledgment of the data delivery is requested (positive or negative depending on result) from the eNodeB <NUM>. This parameter makes possible to avoid unnecessary acknowledgement signaling from eNB <NUM> to MME <NUM> when not required. For IP PDN type PDN connections configured to support Header Compression, the MME shall apply header compression before encapsulating data into the NAS message. If action <NUM> is not executed, the MME <NUM> sends Connection Establishment Indication message to the eNB <NUM>. The UE Radio Capability may be provided from the MME to the eNB in the Connection Establishment Indication message, and the eNB shall store the received UE Radio Capability information. If the Release Assistance Information was received with Uplink data and it indicated that Downlink data was expected, it means that the next downlink packet following the sending of the Release Assistance Information is the last packet of the application layer data exchange, then for this case, unless the MME is aware of additional pending MT traffic and unless S1-U bearers are established, the MME sends a S1 UE Context Release Command immediately after the S1-AP message including the Downlink data encapsulated in NAS PDU so that the an indication that the eNodeB <NUM> shall release the RRC connection after successfully sending data to the UE.

Action <NUM>. The eNB <NUM> sends a RRC Downlink data message including the Downlink data encapsulated in NAS PDU. If in action <NUM> the S1-AP message with the NAS DATA PDU was followed by a S1 UE Context Release Command action <NUM> is completed promptly after the Downlink Data transmission of the NAS PDU to the UE is complete at the eNB <NUM> and the eNB does not need to enter action <NUM>. If header compression was applied to the PDN, the UE would perform header decompression to rebuild the IP header.

Action <NUM>. If no NAS PDU activity exists for a while, the eNB <NUM> starts an S1 release in action <NUM>.

Action <NUM>. An S1 release procedure triggered by the eNodeB <NUM> or the MME <NUM>. Alternatively, if the MME <NUM> in action <NUM> sent S1 UE Context Release Command then the procedure starts with a Connection Suspend Procedure or similar.

<FIG> shows a schematic signalling diagram illustrating the delivering of data to a WCD sent by a NE according to an embodiment of the present solution.

The delivery method shown in figure is preferably performed in a MME <NUM> for delivering data to a WCD <NUM> that is served by the MME <NUM>. While performing the method it is preferred that the operates in a communication network 10b, 10c comprising a Network Entity (NE), e.g. a SGW <NUM>, a PGW <NUM>, a SCEF <NUM> or an IWK-SCEF <NUM>, and a RAN node <NUM> serving the WCD <NUM>.

The delivery method comprises the following actions, which may be performed in any suitable order:.

Alternatively, when the RAN node <NUM> supports acknowledgement of data delivery to the WCD <NUM>, then an acknowledgement may be received from the RAN node <NUM> indicating that the user data sent in action <NUM> was successfully delivered to the WCD <NUM>. This action corresponds to actions or steps <NUM>, <NUM> discussed above.

Alternatively, when the RAN node <NUM> does not support said acknowledgement of data delivery to the WCD <NUM>, then no acknowledgement will be received from the RAN node <NUM> indicating that the user data sent in action <NUM> was successfully delivered to the WCD <NUM>. This has been illustrated by a dashed line in <FIG>. This action corresponds to actions or steps <NUM>, <NUM> discussed above.

Action <NUM>. Sending a response to the NE. This action corresponds to actions or steps <NUM> discussed above.

Action <NUM>. Sending, the RAN node <NUM> supports acknowledgement of data delivery to the WCD <NUM>, a reliability message intended for the WCD <NUM> indicating that control plane communication of user data between the RAN node <NUM> and the mobility management node <NUM> is reliable. This actions is optional, which has been indicated by a dashed line in <FIG>.

<FIG> shows a flowchart illustrating a method according to an embodiment of the present solution.

The method is preferably performed in a MME <NUM> for delivering data to a WCD <NUM> that is served by the MME <NUM>. While performing the method it is preferred that the operates in a communication network 10b, 10c comprising a Network Entity (NE), e.g. a SGW <NUM>, a PGW <NUM>, a SCEF <NUM> or an IWK-SCEF <NUM>, and a RAN node <NUM> serving the WCD <NUM>.

The method comprises the following steps, which may be performed in any suitable order:.

<FIG> is a schematic block diagram of a mobility management node according to some embodiments of the present disclosure. Here, the mobility management node may be a core network node such as, for example, the MME <NUM> or an SGSN <NUM>. As illustrated, the n mobility management node includes one or more processors <NUM> (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory <NUM>, and a network interface <NUM>. In some embodiments, the functionality of the mobility management node (e.g., the functionality of the MME <NUM>) described above may be fully or partially implemented in software that is, e.g., stored in the memory <NUM> and executed by the processor(s) <NUM>.

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of a network node according to any of the embodiments described herein is provided. In some embodiments, a carrier containing the aforementioned computer program product is provided.

<FIG> is a schematic block diagram of the mobility management node <NUM> according to some other embodiments of the present disclosure. The mobility management node includes one or more modules <NUM>, each of which is implemented in software. The module(s) <NUM> provide the functionality of the mobility management node described herein. As an example, if the mobility management node <NUM> is the MME <NUM>, then the module(s) <NUM> may include: an obtaining module operable to obtain capability information indicating whether the RAN node <NUM> supports acknowledgement of a successful delivery of data to the WCD <NUM>; a receiving module operable to receive a data message sent by the NE (<NUM>, <NUM>, <NUM>, <NUM>) comprising user data intended for the WCD <NUM>; and a sending module operable to send a control plane message comprising the user data to the RAN node <NUM> for further delivery to the WCD <NUM>, and operable to send a response to the NE (<NUM>, <NUM>, <NUM>, <NUM>) indicating the status of the user data delivery to the WCD <NUM>, as described above.

Claim 1:
A method in a mobility management node (<NUM>) for delivering data to a User Equipment, UE, (<NUM>) served by the mobility management node (<NUM>), operating in a communication network (10b, 10c) comprising a network entity, NE, (<NUM>, <NUM>, <NUM>, <NUM>) and a radio access network, RAN, node (<NUM>) serving the UE (<NUM>), the method comprises:
- obtaining (<NUM>, <NUM>, <NUM>, <NUM>) by the mobility management node (<NUM>) capability information indicating whether the RAN node supports acknowledgement of a successful delivery of data to the UE;
- receiving (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) by the mobility management node (<NUM>) a data message sent by the NE comprising user data intended for the UE;
- sending (<NUM>, <NUM>, <NUM>, <NUM>) by the mobility management node (<NUM>) a control plane message comprising the user data to the RAN node for further delivery to the UE;
- sending (<NUM>, <NUM>, <NUM>) by the mobility management node (<NUM>) a response to the NE:
a) indicating an unsuccessful delivery of the user data to the UE when a report is received (<NUM>, <NUM>, <NUM>) from the RAN node indicating that the user data was not successfully delivered to the UE; otherwise;
b) indicating an acknowledged delivery of the user data to the UE when the RAN node supports said acknowledgement and an acknowledgement is received (<NUM>, <NUM>, <NUM>) from the RAN node indicating that the user data was successfully delivered to the UE;
c) indicating an unacknowledged delivery of user data to the UE when the RAN node does not support said acknowledgement.