Patent Description:
<CIT> relates to a method for establishing a connection for a small data transmission. <CIT> relates to a method for managing connection of small data transmission. <CIT> relates to methods and apparatus for use in selecting a mobile network route for data communications for a user equipment (UE) in a mobile network. <NPL>" specifies architecture enhancements to facilitate communications with packet data network applications. <NPL>" describes the protocol for the T8 reference point between the SCEF and the SCS/AS. <NPL>" relates to the protocol for the NEF Northbound interface between the NEF and the AF. <NPL>" relates to the Diameter-based interfaces between the HSS and other network elements involved in the architecture for interworking with packet data networks and applications.

Many cellular Internet of things (CloT) applications need to run for years over batteries and reduce overall energy consumption. To improve their power consumption efficiency, 3rd generation partnership project (3GPP) provides two ways for small data communication between CloT user equipment (UE) and service capability server (SCS)/application server (AS): IP data delivery (IPDD) and non-IP data delivery (NIDD).

<FIG> is a diagram illustrating IPDD and NIDD in CloT. As shown, between a UE and an SCS/AS, there are an evolved node B (eNB), a serving general packet radio service (GPRS) support node (SGSN)/mobility management entity (MME), a serving gateway (SGW), a packet data network (PDN) gateway (PGW) and a service capability exposure function (SCEF). As used in <FIG>, the term "CP" refers to control plane, the term "DoNAS" refers to data over non-access stratum (NAS), the term "UP" refers to user plane, and the term "RRC" refers to radio resource control. The IP data to the SCS/AS is accomplished by the delivery using the PGW. The non-IP data delivery to the SCS/AS is accomplished by one of two mechanisms. In case of NIDD, the UE is unaware that a particular non-IP PDN connection is provided via the SCEF or via the PGW.

For one of the two mechanisms, a point-to-point (PtP) SGi tunnel based on user datagram protocol (UDP)/IP may be used to deliver non-IP data to the SCS/AS via the PGW. The PGW acts as a transparent forwarding node for the payload between the UE and the SCS/AS. For uplink non-IP data, the PGW forwards the received data to the SCS/AS over the SGi PtP tunnel using UDP/IP encapsulation. For downlink non-IP data, the SCS/AS sends the data using UDP/IP encapsulation with the IP address of the UE and the 3GPP defined UDP port for "non-IP" data. The PGW decapsulates the received data (i.e. removes the UDP/IP headers) and forwards the data to the SGW on the GPRS tunnelling protocol (GTP)-U tunnel identified by the IP address of the UE (i.e. PDN connection) for delivery to the UE.

For the other of the two mechanisms, the SCEF is used via T8 interface. For example, T8 representational state transfer (Restful) application programming interface (API) is defined by 3GPP for the SCS/AS to use NIDD capability from the operator network. NIDD via the SCEF is handled using a PDN connection to the SCEF. The UE may obtain a non-IP PDN connection to the SCEF either during Attach procedure or via UE requested PDN connectivity or via packet data protocol (PDP) Context Activation procedure. There are three major T8 interfaces defined in 3GPP for the SCS/AS to support NIDD via the SCEF. The first interface is NIDD Configuration, which is used by the SCS/AS to configure necessary information at the SCEF and a home subscriber server (HSS). The second interface is Mobile Originated (MO) NIDD, which is used by the SCS/AS to receive non-IP data from the UE. The third interface is Mobile Terminated (MT) NIDD, which is used by the SCS/AS to send non-IP data to UE(s).

Further features are defined in dependent claims. In the following description only the combination of the subject-matter of <FIG> and its description with the subject-matter of <FIG> and its description is according to the invention as defined in the claims. The rest of the following description and figures (even if named embodiment(s)) does not or does not fully correspond to the invention as defined in the claims and is therefore not according to the invention as defined in the claims but is considered as useful for understanding the invention.

One of the objects of the disclosure is to provide an improved solution for IP and non-IP data communication.

According to one aspect of the disclosure, there is provided a method implemented at a network exposure node. The method comprises performing a configuration procedure such that both IPDD and NIDD can be supported through a unified interface between the network exposure node and a server. The method further comprises performing IPDD or NIDD through the unified interface.

In an embodiment of the disclosure, the performing the configuration procedure comprises receiving, from the server, a first request for configuring data delivery for a terminal device. The performing the configuration procedure further comprises generating a second request for authorizing IPDD/NIDD between the terminal device and the server, based on the first request. The performing the configuration procedure further comprises sending the second request to a subscriber management node. The performing the configuration procedure further comprises receiving, from the subscriber management node, a reply in response to the second request.

In an embodiment of the disclosure, the first request includes an identifier (ID) of the terminal device and an ID of the server. The generating the second request comprises determining an access point name (APN) for IPDD/NIDD between the terminal device and the server, based on the ID of the terminal device and the ID of the server. The second request includes the determined APN for IPDD/NIDD and the ID of the terminal device.

In an embodiment of the disclosure, the first request indicates a port of the server. Alternatively, the port of the server is pre-configured in the network exposure node.

In an embodiment of the disclosure, the server is an SCS or an AS, and the port of the server is an SCS/AS port. The second request is an IPDD/NIDD Information Request message, and the reply in response to the second request is an IPDD/NIDD Information Answer message.

In an embodiment of the disclosure, the performing IPDD through the unified interface comprises obtaining, from a packet gateway node, connection information about a connection between a terminal device and the packet gateway node. The performing IPDD through the unified interface further comprises, in response to receiving a data packet from the terminal device via the packet gateway node, determining an IP address of the server based on the data packet, the obtained connection information and a result of the configuration procedure. The performing IPDD through the unified interface further comprises sending data from the data packet to the server through the unified interface based on the determined IP address of the server.

In an embodiment of the disclosure, the connection information includes an IP address of the terminal device, an international mobile subscriber identity (IMSI) of the terminal device, and an APN for IPDD. The result of the configuration procedure includes the IMSI of the terminal device, the APN for IPDD, and an IP address of the server. The determining the IP address of the server comprises determining a combination of the IMSI of the terminal device and the APN for IPDD from the connection information, based on an IP address of the terminal device included in the data packet. The determining the IP address of the server further comprises determining the IP address of the server from the result of the configuration procedure, based on the determined combination.

In an embodiment of the disclosure, the connection information is received via Radius or Diameter protocol. The data from the data packet is sent in an Uplink Data Notification Request message.

In an embodiment of the disclosure, the performing IPDD or NIDD through the unified interface comprises receiving, from the server through the unified interface, a first request for data delivery to a terminal device. The first request includes data to be delivered to the terminal device. The performing IPDD or NIDD through the unified interface further comprises sending, to a subscriber management node, a second request for monitoring reachability status of the terminal device. The performing IPDD or NIDD through the unified interface further comprises receiving, from the subscriber management node, at least one monitoring report about reachability status of the terminal device. The performing IPDD or NIDD through the unified interface further comprises sending the data to the terminal device based on the received at least one monitoring report.

In an embodiment of the disclosure, the first request indicates an IP protocol of the terminal device. Alternatively, the IP protocol the terminal device is pre-configured in the network exposure node.

In an embodiment of the disclosure, the first request further indicates an application port of the terminal device. Alternatively, the application port of the terminal device is pre-configured in the network exposure node.

In an embodiment of the disclosure, the receiving the at least one monitoring report comprises receiving a monitoring report indicating that the terminal device is reachable via an APN for NIDD. The sending the data to the terminal device comprises: in response to the monitoring report, sending the data to the terminal device through NIDD.

In an embodiment of the disclosure, the receiving the at least one monitoring report comprises receiving a monitoring report indicating that the terminal device is not reachable. The receiving the at least one monitoring report further comprises receiving a subsequent monitoring report indicating that the terminal device is reachable via an APN for NIDD. The sending the data to the terminal device comprises, in response to the subsequent monitoring report, sending the data to the terminal device through NIDD.

In an embodiment of the disclosure, the receiving the at least one monitoring report comprises: receiving a monitoring report indicating that the terminal device is reachable via an APN for IPDD and has an IP address. The sending the data to the terminal device comprises, in response to the monitoring report, generating a data packet including the data from the first request, based on the IP address and the IP protocol of the terminal device. The sending the data to the terminal device further comprises sending the data packet to a packet gateway node based on the APN for IPDD.

In an embodiment of the disclosure, the receiving the at least one monitoring report comprises receiving a monitoring report indicating that the terminal device is not reachable. The receiving the at least one monitoring report further comprises receiving a subsequent monitoring report indicating that the terminal device is reachable via an APN for IPDD and has an IP address. The sending the data to the terminal device comprises, in response to the subsequent monitoring report, generating a data packet including the data from the first request, based on the IP address and the IP protocol of the terminal device. The sending the data to the terminal device further comprises sending the data packet to a packet gateway node based on the APN for IPDD.

In an embodiment of the disclosure, the first request is a Downlink Data Delivery Request message, the second request is a Configuration Information Request message, and the at least one monitoring report is received in a Configuration Information Response message or a Reporting Information Request message.

According to another aspect of the disclosure, there is provided a method implemented at a server. The method comprises initiating a configuration procedure towards a network exposure node such that both IPDD and NIDD can be supported through a unified interface between the network exposure node and the server. The method further comprises performing IPDD or NIDD through the unified interface.

In an embodiment of the disclosure, the initiating the configuration procedure comprises sending, to the network exposure node, a first request for configuring data delivery for a terminal device. The first request indicates a port of the server.

In an embodiment of the disclosure, the performing IPDD or NIDD through the unified interface comprises sending, to the network exposure node through the unified interface, a second request for data delivery to a terminal device. The second request includes data to be delivered to the terminal device and indicates an IP protocol of the terminal device.

In an embodiment of the disclosure, the second request further indicates an application port of the terminal device.

According to another aspect of the disclosure, there is provided a method implemented at a subscriber management node. The method comprises receiving, from a network exposure node, a request for authorizing IPDD between a terminal device and a server. The method further comprises sending, to the network exposure node, a reply in response to the request.

In an embodiment of the disclosure, the request includes an APN for IPDD between the terminal device and the server and an ID of the terminal device. The reply in response to the request includes an IMSI of the terminal device.

According to another aspect of the disclosure, there is provided a method implemented at a packet gateway node. The method comprises performing a connection establishment procedure such that a connection is established between a terminal device and the packet gateway node. The method further comprises sending connection information about the connection to a network exposure node. The method further comprises receiving, from the terminal device, a first data packet including data to be delivered to a server. The first data packet indicates an IP address of the network exposure node. The method further comprises sending, to the network exposure node, a second data packet including the data, based on the IP address of the network exposure node.

In an embodiment of the disclosure, each of the first and second data packets further indicates a port of the server.

In an embodiment of the disclosure, the connection information includes an IP address of the terminal device, an IMSI of the terminal device, and an APN for IPDD.

According to another aspect of the disclosure, there is provided a method implemented at a terminal device. The method comprises initiating a connection establishment procedure such that a connection is established between the terminal device and a packet gateway node. The method further comprises sending, to the packet gateway node, a data packet including data to be delivered to a server. The data packet indicates an IP address of the network exposure node.

In an embodiment of the disclosure, the data packet further indicates a port of the server.

According to another aspect of the disclosure, there is provided a network exposure node. The network exposure node comprises at least one processor and at least one memory. The at least one memory contains instructions executable by the at least one processor, whereby the network exposure node is operative to perform a configuration procedure such that both IPDD and NIDD can be supported through a unified interface between the network exposure node and a server. The network exposure node is further operative to perform IPDD or NIDD through the unified interface.

In an embodiment of the disclosure, the network exposure node is operative to perform the method according to the above aspect.

According to another aspect of the disclosure, there is provided a server. The server comprises at least one processor and at least one memory. The at least one memory contains instructions executable by the at least one processor, whereby the server is operative to initiate a configuration procedure towards a network exposure node such that both IPDD and NIDD can be supported through a unified interface between the network exposure node and the server. The server is further operative to perform IPDD or NIDD through the unified interface.

In an embodiment of the disclosure, the subscriber management node is operative to perform the method according to the above aspect.

According to another aspect of the disclosure, there is provided a subscriber management node. The subscriber management node comprises at least one processor and at least one memory. The at least one memory contains instructions executable by the at least one processor, whereby the subscriber management node is operative to receive, from a network exposure node, a request for authorizing IPDD between a terminal device and a server. The subscriber management node is further operative to send, to the network exposure node, a reply in response to the request.

According to another aspect of the disclosure, there is provided a packet gateway node. The packet gateway node comprises at least one processor and at least one memory. The at least one memory contains instructions executable by the at least one processor, whereby the packet gateway node is operative to perform a connection establishment procedure such that a connection is established between a terminal device and the packet gateway node. The packet gateway node is further operative to send connection information about the connection to a network exposure node. The packet gateway node is further operative to receive, from the terminal device, a first data packet including data to be delivered to a server. The first data packet indicates an IP address of the network exposure node. The packet gateway node is further operative to send, to the network exposure node, a second data packet including the data, based on the IP address of the network exposure node.

In an embodiment of the disclosure, the packet gateway node is operative to perform the method according to the above aspect.

According to another aspect of the disclosure, there is provided a terminal device. The terminal device comprises at least one processor and at least one memory. The at least one memory contains instructions executable by the at least one processor, whereby the terminal device is operative to initiate a connection establishment procedure such that a connection is established between the terminal device and a packet gateway node. The terminal device is further operative to send, to the packet gateway node, a data packet including data to be delivered to a server. The data packet indicates an IP address of the network exposure node.

In an embodiment of the disclosure, the terminal device is operative to perform the method according to the above aspect.

According to another aspect of the disclosure, there is provided a computer program product. The computer program product comprises instructions which when executed by at least one processor, cause the at least one processor to perform the method according to the above aspect.

According to another aspect of the disclosure, there is provided a computer readable storage medium. The computer readable storage medium comprises instructions which when executed by at least one processor, cause the at least one processor to perform the method according to the above aspect.

According to another aspect of the disclosure, there is provided a network exposure node. The network exposure node comprises a configuration module for performing a configuration procedure such that both IPDD and NIDD can be supported through a unified interface between the network exposure node and a server. The network exposure node further comprises a data delivery module for performing IPDD or NIDD through the unified interface.

According to another aspect of the disclosure, there is provided a server. The server comprises an initiation module for initiating a configuration procedure towards a network exposure node such that both IPDD and NIDD can be supported through a unified interface between the network exposure node and the server. The server further comprises a data delivery module for performing IPDD or NIDD through the unified interface.

According to another aspect of the disclosure, there is provided a subscriber management node. The subscriber management node comprises a reception module for receiving, from a network exposure node, a request for authorizing IPDD between a terminal device and a server. The subscriber management node further comprises a sending module for sending, to the network exposure node, a reply in response to the request.

According to another aspect of the disclosure, there is provided a packet gateway node. The packet gateway node comprises a connection module for performing a connection establishment procedure such that a connection is established between a terminal device and the packet gateway node. The packet gateway node further comprises a sending module for sending connection information about the connection to a network exposure node. The packet gateway node further comprises a reception module for receiving, from the terminal device, a first data packet including data to be delivered to a server. The first data packet indicates an IP address of the network exposure node. The sending module further sends, to the network exposure node, a second data packet including the data, based on the IP address of the network exposure node.

According to another aspect of the disclosure, there is provided a terminal device. The terminal device comprises an initiation module for initiating a connection establishment procedure such that a connection is established between the terminal device and a packet gateway node. The terminal device further comprises a sending module for sending, to the packet gateway node, a data packet including data to be delivered to a server. The data packet indicates an IP address of the network exposure node.

According to some embodiment(s) of the disclosure, the data delivery procedure for the server can be simplified.

In CIoT domain, an enterprise may need to manage millions of UEs. Some UEs may use narrow band (NB) IoT network and other UEs may use category (Cat)-M1 network. In addition, some UEs may use IPDD only, some UEs may use NIDD only, and other UEs use both. It is difficult for the enterprise to manage UEs using different network and different data delivery channels (IP, non-IP, or both).

When the operator selects to use PGW to support IPDD and use SCEF to support NIDD for small data delivery, SCS/AS needs different ways to handle IPDD and NIDD. However, it would be desirable to expose a unified way for SCS/AS to handle both IPDD and NIDD. For example, SCS/AS can get below benefits for combined IP and non-IP data delivery.

Firstly, SCS/AS does not need to take care that a UE is a Cat-M1 device or an NB IoT device, since SCEF can detect this information from the operator network and use this information to enhance the data delivery efficiency. For example, when a UE is attached without a PDN connection and downlink data delivery is required, SCEF can based on the device type (Cat-M1 or NB IoT) to decide if IP PDN or non-IP PDN is preferred. Then SCEF can use device triggering to trigger the preferred PDN connection setup.

Secondly, SCS/AS does not need to take care that a UE can support IPDD only, NIDD only, or both. SCEF can detect the UE is attached to the operator network via IP PDN or non-IP PDN. Then SCEF can smartly select the proper PDN to deliver downlink data to customer.

Thirdly, in case a UE can support both IPDD and NIDD, when the UE is attached to the operator network with either non-IP APN or IP APN, SCS/AS does not need to take care what APN the UE is attached to. SCEF will smartly detect the attached PDN for the UE and use the proper PDN to deliver a downlink message for SCS/AS.

Fourthly, Cat-M1 and NB IoT UEs' mobile originated (MO) IP data and non-IP data can be sent to SCEF first. SCEF will always forward the data to SCS/AS via T8 interface. So SCS/AS does not care the MO data is from IP PDN or non-IP PDN. Nor does it care the data is from a Cat-M1 device or an NB IoT device.

In addition, from the operator's view, it would be desirable that the additional benefits and features on NIDD provided by SCEF can also be applied on IPDD. For example, the operator can be allowed to have unified security control such that a CIoT UE can only communicate with allowed SCS/AS. Without permission, SCS/AS cannot send a mobile terminated (MT) message to a particular CIoT UE via either IPDD or NIDD or both. The operator can also be allowed to provide unified buffering strategy for MT IP and non-IP data until a UE wakes up from power saving state. It can also be allowed to protect the radio and core network from message flooding and bandwidth over-usage from SCS/AS, since SCEF can apply SCS/AS level throttling. For example, SCEF may throttle the IP traffic of an SCS/AS dynamically when SCEF detects the SCS/AS violates the throttling rule. Group-based message delivery can also be supported even if some UEs use IPDD and some UEs use NIDD. In particular, it can be allowed that SCS/AS sends one message to SCEF and SCEF forwards the message to multiple UEs, no matter the UE can support NIDD only, IPDD only or both. In addition, unified SCS/AS level dynamic service level agreement (SLA) can be enforced on both IPDD and NIDD, such as throttling and quota control. For example, SCEF can limit a UE to send and receive <NUM> messages per hour no matter the UE use IPDD, NIDD or both.

The present disclosure proposes improved solutions for IP and non-IP data communication. The basic idea is to expose a unified interface (e.g. T8) to a server (e.g. SCS/AS) for handling both IPDD and NIDD. Hereinafter, the solutions will be described in detail with reference to <FIG>.

<FIG> is a diagram showing an exemplary wireless communication system according to an embodiment of the disclosure. As shown, the wireless communication system comprises a user equipment (UE) <NUM>, an evolved node B (eNB) <NUM>, a serving general packet radio service (GPRS) support node (SGSN)/mobility management entity (MME) <NUM>, a serving gateway (SGW) <NUM>, a packet data network (PDN) gateway (PGW) <NUM>, a service capability exposure function (SCEF) <NUM>, a service capability server (SCS)/application server (AS) <NUM>, and a home subscriber server (HSS) <NUM>. Note that the number of each entity mentioned above may be more than one.

The UE <NUM> can communicate through a radio access communication link with the eNB <NUM>. The UE may also be referred to as, for example, terminal device, access terminal, mobile station, mobile unit, subscriber station, or the like. It may refer to any end device that can access a wireless communication network and receive services therefrom. By way of example and not limitation, the UE may include a portable computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and playback appliance, a mobile phone, a cellular phone, a smart phone, a tablet, a wearable device, a personal digital assistant (PDA), or the like.

In an Internet of things (IoT) scenario, a UE may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another UE and/or a network equipment. In this case, the UE may be a machine-to-machine (M2M) device, which may, in a 3GPP context, be referred to as a machine-type communication (MTC) device. Particular examples of such machines or devices may include sensors, metering devices such as power meters, industrial machineries, bikes, vehicles, or home or personal appliances, e.g. refrigerators, televisions, personal wearables such as watches, and so on.

The eNB <NUM> is an element in an evolved universal terrestrial radio access network (E-UTRAN). The eNB <NUM> can provide radio access communication links to UEs that are within its communication service cell and control communications therebetween. It is also possible that the eNB <NUM> may be replaced by a radio network controller (RNC) node and a base station in an universal mobile telecommunications system (UMTS) terrestrial RAN (UTRAN) or a global system for mobile communication (GSM) enhanced data rate for GSM evolution (EDGE) RAN (GERAN).

The SGSN/MME <NUM> means either the SGSN or the MME or both. The SGSN is a core network node in the UMTS and has a user-plane function and a control-plane function. The user-plane function of the SGSN can transfer user data packets of the UE <NUM> between the eNB <NUM> and the PGW <NUM>. The control-plane function of the SGSN can carry out mobility management of the UE <NUM>, bearer management and the like. The MME is a core network node in evolved packet system (EPS) and can carry out the mobility management of the UE <NUM>, the bearer management, and the like. The SGW <NUM> is a packet transfer node in the core network of the EPS. The SGW <NUM> can transfer user data packets of the UE <NUM> between the eNB <NUM> and the PGW <NUM>. The PGW <NUM> is a core network node in the EPS. The PGW <NUM> is a user-plane packet transfer node in the core network and can transfer user data packets of the UE <NUM>. The PGW <NUM> can serve as a gateway to an external PDN and provide the UE <NUM> with the connectivity to the external PDN.

The SCEF <NUM> can securely expose the services and capabilities provided by 3GPP networks by providing access to the services and capabilities through homogenous network application programming interfaces (APIs) defined by open mobile alliance (OMA), GSM alliance (GSMA) and possibly other standardization bodies. The SCEF <NUM> may communicate with the SGSN/MME <NUM> via T6a/T6b interface, and with the PGW <NUM> via IP tunnel, PtP tunnel, or the like.

The SCS/AS <NUM> means either the SCS or the AS or both. The SCS can make open service access (OSA) standard interfaces accessible by application and provide an abstraction of network protocol for application developers. As a gateway between applications and the network, the SCS can accomplish mapping of OSA interfaces onto network protocols and vice versa. The AS may be a type of server designed to install, operate and host applications and associated services for users. The SCS/AS <NUM> may communicate with the SCEF <NUM> via T8 interface (e.g. Restful interface). The HSS <NUM> is a control-plane node in the core network of 3GPP public land mobile network (PLMN) and can manage subscriber information of the UE <NUM>. The HSS <NUM> may communicate with the SCEF <NUM> via S6t interface.

It should be noted that the SGSN/MME <NUM>, the PGW <NUM>, the SCEF <NUM>, and the HSS <NUM> are merely exemplary examples of the components in the wireless communication system and may be replaced by components with similar functionalities. For example, in fifth generation (<NUM>) core network (CN), the SGSN/MME may be replaced by an access and mobility management function (AMF), the PGW may be replaced by a user plane function (UPF), the SCEF may be replaced by a network exposure function (NEF), and the HSS may be replaced by a unified data management (UDM).

<FIG> is a flowchart illustrating a method implemented at a network exposure node according to an embodiment of the disclosure. For example, the network exposure node may take the form of an SCEF, an NEF, or any other entity having similar functionality. At block <NUM>, the network exposure node performs a configuration procedure such that both IPDD and NIDD can be supported through a unified interface between the network exposure node and a server. For example, the server may be an SCS or an AS. The unified interface may be T8 interface. Block <NUM> may be implemented as blocks <NUM>-<NUM> of <FIG>, which will be described later. At block <NUM>, the network exposure node performs IPDD or NIDD through the unified interface. Block <NUM> may be implemented as blocks <NUM>-<NUM> of <FIG> or blocks <NUM>-<NUM> of <FIG>, which will be described later.

Since a unified interface is exposed by the network exposure node for the server, the data delivery procedure for the server can be simplified. The operator can also have a unified way to manage the data delivery for both IPDD and NIDD. In addition, the additional features supported by the network exposure node for NIDD can be applied on IPDD as well.

<FIG> is a flowchart for explaining the method of <FIG>. At block <NUM>, the network exposure node receives, from the server, a first request for configuring data delivery for a terminal device. The first request may include an identifier (ID) of the server, an IP address of the server and an ID of the terminal device. Optionally, the first request may further indicate a port of the server. It is also possible that the port of the server may be pre-configured in the network exposure node. For example, a default port may be configured for all terminal devices. In this case, the first request does not need to indicate the port of the server. The port may correspond to an application which needs to communicate with the terminal device. Different port may correspond to different application. As an exemplary example, the request may be a Data Delivery Configuration Request message, the ID of the server may be an SCS/AS ID, the ID of the terminal device may be an external ID, and the port of the server may be an number used to identify an SCS/AS.

At block <NUM>, the network exposure node generates a second request for authorizing IPDD/NIDD between the terminal device and the server, based on the first request. For IPDD, the second request may include an APN for IPDD between the terminal device and the server, and the ID of the terminal device. For NIDD, the second request may include an APN for NIDD between the terminal device and the server, and the ID of the terminal device. The APN for IPDD/NIDD may be determined based on the IDs of the terminal device and the server which are included in the first request. As an example, there may be a predetermined correspondence between the APN for IPDD/NIDD and a combination of the IDs of the terminal device and the server. The APN for IPDD/NIDD may be derived by a lookup operation on a table reflecting the correspondence. Note that depending on the actual application scenario, various other ways may be used instead to derive the APN for IPDD/NIDD. As an exemplary example, for IPDD, the second request may be an IPDD Information Request message, which is a new message added into the current technical specifications. For NIDD, the second request may be an NIDD Information Request message.

At block <NUM>, the network exposure node sends the second request to a subscriber management node. The subscriber management node may take the form of an HSS, a UDM, or any other entity having similar functionality. At block <NUM>, the network exposure node receives, from the subscriber management node, a reply in response to the second request. Since the subscriber management node maintains the subscription information of the terminal device, the subscriber management node can verify whether the APN for IPDD/NIDD can be used by the terminal device for IPDD/NIDD. If the APN for IPDD/NIDD can be used by the terminal device for IPDD/NIDD, the reply may include an international mobile subscriber identity (IMSI) of the terminal device. As an exemplary example, for IPDD, the reply may be an IPDD Information Answer message, which is a new message added into the current technical specifications. For NIDD, the second request may be an NIDD Information Answer message.

<FIG> is a flowchart illustrating an exemplary process according to an embodiment of the disclosure. In this process, the server is an SCS/AS, the network exposure node is an SCEF, and the subscriber management node is an HSS. This process may be used for combined data delivery configuration such that the SCS/AS can configure necessary information in the HSS and the SCEF for IPDD and NIDD. At block <NUM>, the SCS/AS sends, to the SCEF, a Data Delivery Configuration Request message including a User-Identifier, an SCS/AS Identifier, a T8 Destination Address, a TLTRI, and an SCS/AS Port. The term "TLTRI" refers to T8 long term transaction reference ID. The User-Identifier may be an external identifier of a UE. The T8 Destination Address corresponds to the IP address of the server as mentioned above. Thus, current T8 interface can be enhanced to support both NIDD Configuration and IPDD Configuration. Compared with the existing NIDD Configuration, a new parameter, SCS/AS Port, is added to T8 interface for IPDD Configuration. Alternatively, a default SCS/AS port may be configured in the SCEF for all UEs. Then the SCS/AS does not need to provide the SCS/AS Port in the Data Delivery Configuration Request message.

At block <NUM>, the SCEF performing authentication/authorization (A/A) handling by authenticating the SCS/AS and validating the Data Delivery Configuration Request parameters. At block <NUM>, the SCEF performs service level agreement (SLA) handling by checking the SLA to verify whether the SCS/AS is allowed for this procedure. In this way, unified data communication management for both IP and non-IP between the SCS/AS and the UE can be introduced for the operator. At block <NUM>, the SCEF generates and sends an NIDD Information Request message to the HSS to authorize the NIDD configuration procedure for the received User-Identifier. The NIDD Information Request message includes the User-Identifier (from the Data Delivery Configuration Request message) and an APN-NIDD. The SCEF may use the SCS/AS Identifier and the User-Identifier (which are obtained in block <NUM>) to determine what APN-NIDD and APN-IPDD will be used to enable transfer of data between the UE and the SCS/AS. This determination may be based on local policies. The HSS may authorize the UE having the User-Identifier if the UE can use the APN-NIDD for NIDD. At block <NUM>, the SCEF receives, from the HSS, necessary information for NIDD from an NIDD Information Answer message, if required. In the NIDD Information Answer message, the SCEF can get an IMSI of the User-Identifier. The IMSI may be used by the SCEF to communicate with an MME for NIDD MT and MO data delivery procedure.

At block <NUM>, the SCEF sends an IPDD Information Request message to the HSS to authorize the IPDD configuration request for the received User-Identifier. The IPDD Information Request message includes the User-Identifier and the APN-IPDD. At block <NUM>, the SCEF receives, from the HSS, necessary information for IPDD from an IPDD Information Answer message, if required. Thus, the current S6t interface is extended by adding two new commands (IPDD-Information-Request and IPDD-Information-Answer) to support IP data delivery management, which can improve the security control on IP data delivery. At block <NUM>, the SCEF stores the Data Delivery Configuration data including the User Identifier, the APN-IPDD, the APN-NIDD, the SCS/AS Port, the T8 Destination Address, and the SCS/AS Identifier. These data may be used for later MO and MT data delivery procedure. At block <NUM>, the SCEF sends a Data Delivery Configuration Response message to the SCS/AS to acknowledge acceptance of the Data Delivery Configuration. The Data Delivery Configuration Response message includes TLTRI and Cause.

<FIG> is a flowchart for explaining the method of <FIG>. The flowchart of <FIG> corresponds to MO IP data delivery. At block <NUM>, the network exposure node obtains, from a packet gateway node, connection information about a connection between a terminal device and the packet gateway node. For example, the packet gateway node may take the form of a PGW, a UPF, or any other entity having similar functionality. The connection may be established between the terminal device and the packet gateway node during Attach procedure or via UE requested PDN connectivity or via PDP Context Activation procedure. The connection information may include an IP address of the terminal device, an IMSI of the terminal device, and an APN for IPDD. The connection information may be received (e.g. pushed) from the packet gateway node via Radius or Diameter protocol.

At block <NUM>, in response to receiving a data packet from the terminal device via the packet gateway node, the network exposure node determines an IP address of the server based on the data packet, the obtained connection information and a result of the configuration procedure. As an example, block <NUM> may be implemented as blocks <NUM>-<NUM> of <FIG>. As described above, the result of the configuration procedure may include the IMSI of the terminal device, the APN for IPDD, and an IP address of the server. At block <NUM>, the network exposure node determines a combination of the IMSI of the terminal device and the APN for IPDD from the connection information, based on an IP address of the terminal device included in the data packet. At block <NUM>, the network exposure node determines the IP address of the server from the result of the configuration procedure, based on the determined combination.

As another example of block <NUM>, in case the first request indicates a port of the server, the result of the configuration procedure may include the IMSI of the terminal device, the APN for IPDD, the port of the server, and the IP address of the server. In this case, the network exposure node may determine the combination of the IMSI of the terminal device and the APN for IPDD as described with respect to block <NUM>. Then, the network exposure node may determine the IP address of the server from the result of the configuration procedure, based on the determined combination and a port of the server indicated in the data packet. At block <NUM>, the network exposure node sends data from the data packet to the server through the unified interface based on the determined IP address of the server.

<FIG> is a flowchart illustrating an exemplary process according to another embodiment of the disclosure. In this process, the server is an SCS/AS, the network exposure node is an SCEF, the subscriber management node is an HSS, and the packet gateway node is a PGW. This process may be used for MO IP data delivery such that the SCS/AS receives MO IP data from a UE via the SCEF. At block <NUM>, the UE performs E-UTRAN Initial Attach procedure or UE requested PDN Connectivity procedure or PDP Context Activation Procedure such that the PGW assigns an IP address for the UE based on the value of an APN-IPDD. At block <NUM>, the SCEF gets connection information for the UE from the PGW. The connection information includes the UE's IMSI, the APN-IPDD and the UE IP address. For example, the PGW may push the connection information via Radius or Diameter protocol. According to 3GPP technical specification (TS) <NUM>, the SCEF may be a Radius server or Diameter application, which receives the connection information. Thus, the connection information may be sent to the SCEF without update on the PGW. At block <NUM>, the SCEF caches the mapping between the UE IP address and a combination of the UE's IMSI and the APN-IPDD.

At block <NUM>, the PGW receives MO IP data from the UE. The destination address in the MO IP data is the IP address of the SCEF, and the destination port in the MO IP data is the SCS/AS port, which is the value from the Data Delivery Configuration Request message shown in <FIG>. In this way, the PGW can forward the data to the SCEF. Note that in the protocol stack, the term "LWM2M" refers to light weight machine-to-machine, the term "CoAP" refers to constrained application protocol, and the term "UDP" refers to user datagram protocol. At block <NUM>, the SCEF receives the MO IP data from the UE via the PGW. At block <NUM>, the SCEF decapsulates the received data (e.g. removes the UDP/IP headers) to get the UE IP address and the SCS/AS Port from the data. Based on the UE IP address, the SCEF finds the combination of the corresponding IMSI and APN-IPDD. At block <NUM>, based on the IMSI, the APN-IPDD and the SCS/AS Port, the SCEF finds the Data Delivery Configuration. From the Data Delivery Configuration, the SCEF gets the T8 Destination Address of the SCS/AS and the SCS/AS Identifier.

At block <NUM>, the SCEF validates the SLA if the UE's data can be delivered to the SCS/AS. At block <NUM>, the SCEF sends an Uplink Data Notification Request message with the decapsulated data to the SCS/AS. Thus, T8 Uplink Data Notification interface (which is defined to deliver MO non-IP data to the SCS/AS) is reused to deliver IP data to the SCS/AS. In the protocol stack of the data, the term "HTTP" refers to hypertext transfer protocol and the term "TCP" refers to transmission control protocol. At block <NUM>, the SCS/AS sends an Uplink Data Notification Response message to the SCEF. INote that for MO non-IP data delivery where SCS/AS receives MO non-IP data from UE via SCEF, the current MO NIDD procedure such as that defined in clause <NUM>. <NUM> of 3GPP TS23. <NUM> may be reused.

<FIG> is a flowchart for explaining the method of <FIG>. The flowchart of <FIG> corresponds to MT non-IP and IP data delivery. At block <NUM>, the network exposure node receives, from the server through the unified interface, a first request for data delivery to a terminal device that includes data to be delivered to the terminal device. For example, the first request may include an ID of the server and an ID of the terminal device, and may indicate an IP protocol of the terminal device. It is also possible that the IP protocol of the terminal device may be pre-configured in the network exposure node. Optionally, the first request may further indicate an application port of the terminal device. It is also possible that the application port of the terminal device may be pre-configured in the network exposure node. For example, if the server can only send an MT message to a single protocol (and optionally a single port) in the terminal device, a default IP protocol (and optionally a default application port) may be pre-configured in the network exposure node. In this case, the first request does not need to indicate the IP protocol (and optionally the application port). As an exemplary example, the first request may be a Downlink Data Delivery Request message.

At block <NUM>, the network exposure node sends, to a subscriber management node, a second request for monitoring reachability status of the terminal device. As described above, the subscriber management node may take the form of an HSS, a UDM, or any other entity having similar functionality. The second request may include an ID of the terminal device (e.g. an external ID) and indicate the monitoring type is UE reachability. As an exemplary example, the second request may be a Configuration Information Request message. At block <NUM>, the network exposure node receives, from the subscriber management node, at least one monitoring report about reachability status of the terminal device. At block <NUM>, the network exposure node sends the data to the terminal device based on the received at least one monitoring report. Blocks <NUM>-<NUM> may be implemented as blocks <NUM>-<NUM> of <FIG>, or blocks <NUM>-<NUM> of <FIG>, or blocks <NUM>-<NUM> of <FIG>, or blocks <NUM>-<NUM> of <FIG>, which will be described later.

<FIG> is a flowchart for explaining the method of <FIG>. The flowchart of <FIG> corresponds to MT non-IP data delivery. At block <NUM>, the network exposure node receives a monitoring report indicating that the terminal device is reachable via an APN for NIDD. As an exemplary example, the monitoring report may be received in a Configuration Information Response message. At block <NUM>, in response to the monitoring report, the network exposure node sends the data to the terminal device through NIDD. For example, steps <NUM>, <NUM>, <NUM> and <NUM> defined in clause <NUM>. <NUM> of 3GPP TS23. <NUM> may be used to perform block <NUM>.

<FIG> is a flowchart for explaining the method of <FIG>. The flowchart of <FIG> also corresponds to MT non-IP data delivery. At block <NUM>, the network exposure node receives a monitoring report indicating that the terminal device is not reachable. As an exemplary example, the monitoring report may be received in a Configuration Information Response message. At block <NUM>, the network exposure node receives a subsequent monitoring report indicating that the terminal device is reachable via an APN for NIDD. As an exemplary example, the monitoring report may be received in a Reporting Information Request message. At block <NUM>, in response to the subsequent monitoring report, the network exposure node sends the data to the terminal device through NIDD. For example, steps <NUM>, <NUM>, <NUM> and <NUM> defined in clause <NUM>. <NUM> of 3GPP TS23. <NUM> may be used to perform block <NUM>.

<FIG> is a flowchart illustrating an exemplary process according to another embodiment of the disclosure. In this process, the server is an SCS/AS, the network exposure node is an SCEF, the subscriber management node is an HSS, and the packet gateway node is a PGW. This process may be used for MT non-IP data delivery such that the SCS/AS sends MT non-IP data to the UE via the SCEF. It is assumed that at block <NUM>, the UE performs E-UTRAN Initial Attach procedure or UE requested PDN Connectivity procedure or PDP Context Activation Procedure such that the PGW assigns an IP address for the UE based on the value of an APN-NIDD. At block <NUM>, the SCS/AS sends a Downlink Data Delivery Request message to the SCEF. The Downlink Data Delivery Request message includes a User-Identifier, a TLTRI, an SCS/AS Identifier, an IP Protocol and a UE-Application-Port. Alternatively, if the SCS/AS can only send an MT message to a single port and a single protocol in the UE, a default IP Protocol and a default UE-Application-Port may be pre-configured in the SCEF. In such scenario, the SCS/AS does not need to provide the IP Protocol and the UE-Application-Port in the request.

At block <NUM>, the SCEF sends a Configuration Information Request message to the HSS to monitor the UE's reachability status. Since the UE is already connected to the network, the HSS provides the UE reachability report in a Configuration Information Response message at block <NUM>. This may follow the procedure defined in clause <NUM>. <NUM> of 3GPP TS23. Thus, the details of the interaction between the HSS and the MME are omitted here. The UE reachability report contains the IMSI of the UE, the APN of the established PDN, the PDN type (IP or non-IP) and the IP address assigned to the UE if the PDN type is IP. Optionally, the SCEF may determine whether the Data Delivery Configuration including the same ISMI and the APN can be found. If it can be found, the SCEF may validate this non-IP data delivery. At block <NUM>, the SCEF performs steps <NUM>, <NUM>, <NUM> and <NUM> defined in clause <NUM>. <NUM> of 3GPP TS23. <NUM>, such that the downlink non-IP data is delivered to the UE. At block <NUM>, the SCEF sends a Downlink Data Delivery Response message to the SCS/AS to acknowledge the result of the Downlink Data Delivery. The Downlink Data Delivery Response message includes TLTRI and Cause.

<FIG> is a flowchart illustrating an exemplary process according to another embodiment of the disclosure. This process is similar to that shown in <FIG> except that when the SCEF tries to deliver the non-IP data for the first time, the UE is connected to the network in <FIG> but is not connected to the network in <FIG>. At block <NUM>, the SCS/AS sends a Downlink Data Delivery Request message to the SCEF. The Downlink Data Delivery Request message includes a User-Identifier, a TLTRI, an SCS/AS Identifier, an IP Protocol and a UE-Application-Port. At block <NUM>, the SCEF sends a Configuration Information Request message to the HSS to monitor the UE's reachability status. The Configuration Information Request message includes the User-Identifier and a Monitoring Type which is UE Reachability. Since the UE is not connected to the network, the HSS sends to the SCEF a Configuration Information Response message including Cause at block <NUM>. The Cause value indicates acceptance of the Configuration Information Request. This may follow the procedure defined in clause <NUM>. <NUM> of 3GPP TS23. Thus, the details of the interaction between the HSS and the MME are omitted here. At block <NUM>, the SCEF caches the mobile terminated data, waiting for the UE to wake up and connect to the network. At block <NUM>, the SCEF sends a Downlink Data Delivery Response message to the SCS/AS informing that the UE is not reachable.

It is assumed that the UE performs E-UTRAN Initial Attach procedure or UE requested PDN Connectivity procedure or PDP Context Activation Procedure such that the PGW assigns an IP address for the UE based on the value of an APN-NIDD at block <NUM>. Since the UE wakes up and connects to the network, the MME sends a UE reachability report to the SCEF in a Reporting-Information-Request message at block <NUM>. At block <NUM>, based on the UE reachability report, the SCEF decides to use non-IP PDN channel to deliver the MT data to the UE. At block <NUM>, the SCEF finds the buffered MT data and prepares to deliver the data. At block <NUM>, the SCEF performs steps <NUM>, <NUM>, <NUM> and <NUM> defined in clause <NUM>. <NUM> of 3GPP TS23. <NUM>, such that the downlink non-IP data is delivered to the UE. At block <NUM>, the SCEF sends a Downlink Data Delivery Indication message to the SCS/AS to acknowledge the result of the Downlink Data Delivery. The Downlink Data Delivery Indication message includes TLTRI and Cause.

<FIG> is a flowchart for explaining the method of <FIG>. The flowchart of <FIG> corresponds to MT IP data delivery. At block <NUM>, the network exposure node receives a monitoring report indicating that the terminal device is reachable via an APN for IPDD and has an IP address. As an exemplary example, the monitoring report may be received in a Configuration Information Response message. At block <NUM>, in response to the monitoring report, the network exposure node generates a data packet including the data from the first request, based on the IP address and the IP protocol of the terminal device. The IP address of the terminal device may be included in the monitoring report. The IP protocol of the terminal device may be indicated in the first request or pre-configured in the network exposure node. Optionally, in case the application port of the terminal device is indicated in the first request, the generated data packet is generated based further on the application port of the terminal device. At block <NUM>, the network exposure node sends the data packet to a packet gateway node based on the APN for IPDD. As described above, the packet gateway node may take the form of a PGW, a UPF, or any other entity having similar functionality.

<FIG> is a flowchart for explaining the method of <FIG>. The flowchart of <FIG> also corresponds to MT IP data delivery. At block <NUM>, the network exposure node receives a monitoring report indicating that the terminal device is not reachable. As an exemplary example, the monitoring report may be received in a Configuration Information Response message. At block <NUM>, the network exposure node receives a subsequent monitoring report indicating that the terminal device is reachable via an APN for IPDD and has an IP address. As an exemplary example, the monitoring report may be received in a Reporting Information Request message. At block <NUM>, in response to the subsequent monitoring report, the network exposure node generates a data packet including the data from the first request, based on the IP address and the IP protocol of the terminal device. The generation of the data packet may be similar to block <NUM>. At block <NUM>, the network exposure node sends the data packet to a packet gateway node based on the APN for IPDD.

<FIG> is a flowchart illustrating an exemplary process according to another embodiment of the disclosure. In this process, the server is an SCS/AS, the network exposure node is an SCEF, the subscriber management node is an HSS, and the packet gateway node is a PGW. This process may be used for MT IP data delivery such that the SCS/AS sends MT IP data to the UE via the SCEF. It is assumed that at block <NUM>, the UE performs E-UTRAN Initial Attach procedure or UE requested PDN Connectivity procedure or PDP Context Activation Procedure such that the PGW assigns an IP address for the UE based on the value of an APN-IPDD. At block <NUM>, the SCS/AS sends a Downlink Data Delivery Request message to the SCEF. The Downlink Data Delivery Request message includes a User-Identifier, a TLTRI, an SCS/AS Identifier, an IP Protocol and a UE-Application-Port. At block <NUM>, the SCEF sends a Configuration Information Request message to the HSS to monitor the UE's reachability status. Since the UE is already connected to the network, the HSS provides the UE reachability report in a Configuration Information Response message at block <NUM>. This may follow the procedure defined in clause <NUM>. <NUM> of 3GPP TS23. Thus, the details of the interaction between the HSS and the MME are omitted here. The UE reachability report contains the IMSI of the UE, the APN of the established PDN, the PDN type (IP or non-IP) and the IP address assigned to the UE if the PDN type is IP. Optionally, the SCEF may determine whether the Data Delivery Configuration including the same ISMI and the APN can be found. If it can be found, the SCEF may validate this IP data delivery.

At block <NUM>, based on the UE reachability report, the SCEF decides to use an IP PDN channel to deliver the MT data to the UE. At block <NUM>, the SCEF gets the UE IP address from the UE reachability report and finds the UE application port from the Downlink Data Delivery Request message received at block <NUM>. At block <NUM>, the SCEF prepares an UDP/IP packet to deliver the MT data. At block <NUM>, the SCEF sends the MT Data to the PGW. At block <NUM>, the PGW delivers the data to the UE. At block <NUM>, the SCEF sends a Downlink Data Delivery Response message to the SCS/AS to acknowledge the result of the Downlink Data Delivery. The Downlink Data Delivery Response message includes TLTRI and Cause.

<FIG> is a flowchart illustrating an exemplary process according to another embodiment of the disclosure. This process is similar to that shown in <FIG> except that when the SCEF tries to deliver the IP data for the first time, the UE is connected to the network in <FIG> but is not connected to the network in <FIG>. At block <NUM>, the SCS/AS sends a Downlink Data Delivery Request message to the SCEF. The Downlink Data Delivery Request message includes a User-Identifier, a TLTRI, an SCS/AS Identifier, an IP Protocol and a UE-Application-Port. At block <NUM>, the SCEF sends a Configuration Information Request message to the HSS to monitor the UE's reachability status. The Configuration Information Request message includes the User-Identifier and a Monitoring Type which is UE Reachability. Since the UE is not connected to the network, the HSS sends to the SCEF a Configuration Information Response message including Cause at block <NUM>. The Cause value indicates acceptance of the Configuration Information Request. This may follow the procedure defined in clause <NUM>. <NUM> of 3GPP TS23. Thus, the details of the interaction between the HSS and the MME are omitted here. At block <NUM>, the SCEF caches the MT data, waiting for the UE to wake up and connect to the network. At block <NUM>, the SCEF sends a Downlink Data Delivery Response message to the SCS/AS informing that UE is not reachable.

It is assumed that the UE performs E-UTRAN Initial Attach procedure or UE requested PDN Connectivity procedure or PDP Context Activation Procedure such that the PGW assigns an IP address for the UE based on the value of an APN-IPDD at block <NUM>. Since the UE wakes up and connects to the network, the MME sends a UE reachability report to the SCEF in a Reporting-Information-Request message at block <NUM>. At block <NUM>, the SCEF sends a Reporting-Information-Response message to the MME. At block <NUM>, based on the UE reachability report, the SCEF decides to use an IP PDN channel to deliver the MT data to the UE. At block <NUM>, the SCEF gets the UE IP address from the UE reachability report and finds the UE application port from the Downlink Data Delivery Request message received at block <NUM>. At block <NUM>, the SCEF finds the cached MT data and prepares an UDP/IP packet to deliver the MT data. At block <NUM>, the SCEF sends the MT Data to the PGW. At block <NUM>, the PGW delivers the data to UE. At block <NUM>, the SCEF sends a Downlink Data Delivery Indication message to the SCS/AS to acknowledge the result of the Downlink Data Delivery. The Downlink Data Delivery Indication message includes TLTRI and Cause. Note that when the UE is attached to both IP APN and non-IP APN, it may be up to the operator policies to select the process shown in <FIG>/<FIG> or the process shown in <FIG>/<FIG> for MT data delivery.

<FIG> is a flowchart illustrating a method implemented at a server according to an embodiment of the disclosure. As mentioned above, the server may be an SCS or an AS. At block <NUM>, the server initiates a configuration procedure towards a network exposure node such that both IPDD and NIDD can be supported through a unified interface between the network exposure node and the server. The configuration procedure may be initiated by sending, to the network exposure node, a first request for configuring data delivery for a terminal device. The details of the first request may be similar to those provided for block <NUM>. At block <NUM>, the server performs IPDD or NIDD through the unified interface. Since a unified interface is exposed by the network exposure node for the server, the data delivery procedure for the server can be simplified. For MT data delivery, the server may send, to the network exposure node through the unified interface, a second request for data delivery to a terminal device that includes data to be delivered to the terminal device. The details of the second request may be similar to those of the first request described for block <NUM>.

<FIG> is a flowchart illustrating a method implemented at a subscriber management node according to an embodiment of the disclosure. As mentioned above, the subscriber management node may take the form of an HSS, a UDM, or any other entity having similar functionality. At block <NUM>, the subscriber management node receives, from a network exposure node, a request for authorizing IPDD between a terminal device and a server. Block <NUM> corresponds to block <NUM> and its details are omitted here. At block <NUM>, the subscriber management node sends, to the network exposure node, a reply in response to the request. Block <NUM> corresponds to block <NUM> and its details are omitted here.

<FIG> is a flowchart illustrating a method implemented at a packet gateway node according to an embodiment of the disclosure. As mentioned above, the packet gateway node may take the form of a PGW, a UPF, or any other entity having similar functionality. At block <NUM>, the packet gateway node performs a connection establishment procedure such that a connection is established between a terminal device and the packet gateway node. For example, the connection establishment procedure may be E-UTRAN Initial Attach procedure or UE requested PDN Connectivity procedure or PDP Context Activation Procedure. At block <NUM>, the packet gateway node sends connection information about the connection to a network exposure node. Block <NUM> corresponds to block <NUM> and its details are omitted here. At block <NUM>, the packet gateway node receives, from the terminal device, a first data packet including data to be delivered to a server. The first data packet indicates an IP address of the network exposure node. Optionally, the first data packet may further indicate a port of the server. At block <NUM>, the packet gateway node sends, to the network exposure node, a second data packet including the data, based on the IP address of the network exposure node. Optionally, the second data packet may further indicate the port of the server.

<FIG> is a flowchart illustrating a method implemented at a terminal device according to an embodiment of the disclosure. At block <NUM>, the terminal device initiates a connection establishment procedure such that a connection is established between the terminal device and a packet gateway node. Block <NUM> corresponds to block <NUM> and its details are omitted here. At block <NUM>, the terminal device sends, to the packet gateway node, a data packet including data to be delivered to a server. The data packet indicates an IP address of the network exposure node. Optionally, the data packet may further indicate a port of the server. It should be noted that two blocks shown in succession in the above figures may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

<FIG> is a block diagram showing an apparatus suitable for use in practicing some embodiments of the disclosure. For example, any one of the network exposure node, the server, the subscriber management node, the packet gateway node and the terminal device described above may be implemented through the apparatus <NUM>. As shown, the apparatus <NUM> may include a processor <NUM>, a memory <NUM> that stores a program, and a communication interface <NUM> for communicating data with other external devices through wired and/or wireless communication.

The memory <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memories, magnetic memory devices and systems, optical memory devices and systems, fixed memories and removable memories. The processor <NUM> may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multi-core processor architectures, as non-limiting examples.

<FIG> is a block diagram showing a network exposure node according to an embodiment of the disclosure. As shown, the network exposure node <NUM> comprises a configuration module <NUM> and a data delivery module <NUM>. The configuration module <NUM> may be configured to perform a configuration procedure such that both IPDD and NIDD can be supported through a unified interface between the network exposure node and a server, as described above with respect to block <NUM>. The data delivery module <NUM> may be configured to perform IPDD or NIDD through the unified interface, as described above with respect to block <NUM>.

<FIG> is a block diagram showing a server according to an embodiment of the disclosure. As shown, the server <NUM> comprises an initiation module <NUM> and a data delivery module <NUM>. The initiation module <NUM> may be configured to initiate a configuration procedure towards a network exposure node such that both IPDD and NIDD can be supported through a unified interface between the network exposure node and the server, as described above with respect to block <NUM>. The data delivery module <NUM> may be configured to perform IPDD or NIDD through the unified interface, as described above with respect to block <NUM>.

<FIG> is a block diagram showing a subscriber management node according to an embodiment of the disclosure. As shown, the subscriber management node <NUM> comprises a reception module <NUM> and a sending module <NUM>. The reception module <NUM> may be configured to receive, from a network exposure node, a request for authorizing IPDD between a terminal device and a server, as described above with respect to block <NUM>. The sending module <NUM> may be configured to send, to the network exposure node, a reply in response to the request, as described above with respect to block <NUM>.

<FIG> is a block diagram showing a packet gateway node according to an embodiment of the disclosure. As shown, the packet gateway node <NUM> comprises a connection module <NUM>, a sending module <NUM> and a reception module <NUM>. The connection module <NUM> may be configured to perform a connection establishment procedure such that a connection is established between a terminal device and the packet gateway node, as described above with respect to block <NUM>. The sending module <NUM> may be configured to send connection information about the connection to a network exposure node, as described above with respect to block <NUM>. The reception module <NUM> may be configured to receive, from the terminal device, a first data packet including data to be delivered to a server, as described above with respect to block <NUM>. The first data packet indicates an IP address of the network exposure node. The sending module <NUM> may be further configured to send, to the network exposure node, a second data packet including the data, based on the IP address of the network exposure node, as described above with respect to block <NUM>.

<FIG> is a block diagram showing a terminal device according to an embodiment of the disclosure. As shown, the terminal device <NUM> comprises an initiation module <NUM> and a sending module <NUM>. The initiation module <NUM> may be configured to initiate a connection establishment procedure such that a connection is established between the terminal device and a packet gateway node, as described above with respect to block <NUM>. The sending module <NUM> may be configured to send, to the packet gateway node, a data packet including data to be delivered to a server, as described above with respect to block <NUM>. The data packet indicates an IP address of the network exposure node. The modules described above may be implemented by hardware, or software, or a combination of both.

It should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one of skill in the art, the function of the program modules may be combined or distributed as desired in various embodiments. In addition, the function may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), and the like.

References in the present disclosure to "one embodiment", "an embodiment" and so on, indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the present disclosure. It will be further understood that the terms "comprises", "comprising", "has", "having", "includes" and/or "including", when used herein, specify the presence of stated features, elements, and/or components, but do not preclude the presence or addition of one or more other features, elements, components and/ or combinations thereof. The terms "connect", "connects", "connecting" and/or "connected" used herein cover the direct and/or indirect connection between two elements.

Claim 1:
A method implemented at a network exposure node, the method comprising:
performing (<NUM>) a configuration procedure such that both internet protocol, IP, data delivery, IPDD, and non-IP data delivery, NIDD, can be supported through a unified interface between the network exposure node and a server; and
performing (<NUM>) IPDD or NIDD through the unified interface,
wherein the performing (<NUM>) IPDD or NIDD through the unified interface comprises:
receiving (<NUM>), from the server through the unified interface, a first request for data delivery to a terminal device, the first request including data to be delivered to the terminal device;
sending (<NUM>), to a subscriber management node, a second request for monitoring reachability status of the terminal device;
receiving (<NUM>), from the subscriber management node, at least one monitoring report about reachability status of the terminal device; and
sending (<NUM>) the data to the terminal device based on the received at least one monitoring report.