Patent Description:
Service capability exposure function (SCEF) or equivalent functional entity in the 5th generation (<NUM>) core called as network exposure function (NEF) is the key entity within the 3rd generation partnership project (3GPP) architecture for service capability exposure that provides a means to securely expose the services and capabilities provided by 3GPP network interfaces through application programming interfaces (APIs) to application servers. SCEF or NEF provides small data delivery or network Internet of things (IoT) message function (especially non-Internet protocol (non-IP) data delivery) from user equipment (UE) to application server (AS).

Document <CIT> discloses a method for communicating network capability information, involves receiving network capability request, and sending indication of network capabilities determined in accordance with obtained network capability information to server. Document <CIT> discloses a data transmission method for a network device of a data transmission system. The data transmission system includes a user equipment, a server, and a network device. The server stores target context information of the user equipment. When receiving the target data, the target context information is acquired from the server, and the target data is associated with the user equipment; the target data is forwarded according to the target context information; and the target context information is deleted.

Document "<NPL>], discloses, in chapter chapter <NUM>. <NUM>, the NIDD interface Configuration.

One of the objects of the disclosure is to provide an improved solution for data communication between terminal device and application server.

According to a first aspect of the disclosure, there is provided a method implemented at a network exposure node. The method comprises receiving, from a first application server in operator trust domain, configuration information that can be used for data delivery for a terminal device. The method further comprises receiving data from one of the terminal device and the first application server. The method further comprises forwarding the data to the other of the terminal device and the first application server based on the configuration information.

In an embodiment of the disclosure, the first application server may be deployed in operator mobile edge.

In an embodiment of the disclosure, the configuration information may comprise identity (ID) information of the terminal device, network address information of the first application server and an access point name (APN). The data may be received from the terminal device and forwarded to the first application server based on the network address information of the first application server corresponding to the ID information of the terminal device and the APN.

In an embodiment of the disclosure, the configuration information may comprise ID information of the terminal device, ID information of the first application server and an APN. The method may further comprise obtaining, from a packet gateway node, the ID information and corresponding current network address information of the first application server. The data may be received from the terminal device and forwarded to the first application server based on the current address information of the first application server corresponding to the ID information of the terminal device and the APN.

In an embodiment of the disclosure, the configuration information may comprise network address or ID information of at least one additional destination to which data is to be delivered from the terminal device. The method may further comprise forwarding the data received from the terminal device to the at least one additional destination based on the configuration information.

In an embodiment of the disclosure, one of the at least one additional destination may be a second application server in Internet domain.

The data is received from the terminal device in a form of Internet protocol (IP) data or non-IP data. The IP data may be forwarded through a same interface as that used for the non-IP data.

In an embodiment of the disclosure, the data may be received from the first application server in a form of non-IP data or IP data. The IP data may be received from the first application server through a same interface as that used for the non-IP data.

In an embodiment of the disclosure, the configuration information may comprise ID information of the terminal device, network address or ID information of the first application server and an APN. The data may be received from the first application server in a form of IP data. The method may further comprise obtaining, from a packet gateway node, the ID information and corresponding current network address information of the terminal device. The IP data may be forwarded to the terminal device based on the current network address information of the terminal device corresponding to the ID information of the terminal device.

In an embodiment of the disclosure, the network exposure node may be an SCEF or NEF The same interface is T8 non-IP data delivery (NIDD) interface.

In an embodiment of the disclosure, the ID information may be an external ID or a mobile subscriber international integrated service digital network (ISDN) number (MSISDN) and the network address information may be a uniform resource identifier (URI).

According to a second aspect of the disclosure, there is provided a method implemented at an application server in operator trust domain. The method comprises sending, to a network exposure node, configuration information that can be used for data delivery for a terminal device. The method comprises receiving data from the terminal device via the network exposure node or sending data to the terminal device via the network exposure node.

In an embodiment of the disclosure, the application server may be deployed in operator mobile edge.

In an embodiment of the disclosure, the configuration information may comprise network address or ID information of the application server and at least one additional destination to which data is to be delivered from the terminal device via the network exposure node.

The data is received via the network exposure node in a form of IP data or non-IP data. The IP data is received through a same interface of the network exposure node as that used for the non-IP data.

In an embodiment of the disclosure, the data may be sent via the network exposure node in a form of IP data or non-IP data. The IP data may be sent through a same interface of the network exposure node as that used for the non-IP data.

In an embodiment of the disclosure, the network exposure node may be an SCEF or NEF and the same interface is T8 NIDD interface.

According to a third aspect of the disclosure, there is provided a network exposure node. The network exposure node may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the network exposure node may be operative to receive, from a first application server in operator trust domain, configuration information that can be used for data delivery for a terminal device. The network exposure node may be further operative to receive data from one of the terminal device and the first application server. The network exposure node may be further operative to forward the data to the other of the terminal device and the first application server based on the configuration information.

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

According to a fourth aspect of the disclosure, there is provided an application server in operator trust domain. The application server may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the application server may be operative to send, to a network exposure node, configuration information that can be used for data delivery for a terminal device. The application server may be further operative to receive data from the terminal device via the network exposure node or send data to the terminal device via the network exposure node.

In an embodiment of the disclosure, the application server may be operative to perform the method according to the above second aspect.

According to some embodiment(s) of the disclosure, the data communication between a terminal device and an application server in operator trust domain can be facilitated.

There may be use cases that data communication from UE to application server (AS) on mobile edge communication and then to AS on the cloud is required. One example for such use cases may be environmental monitoring and management. It is becoming more important, as managing the environment and understanding its impacts drives increasing amounts of regulation and activities to reduce pollution. Internet of things (IoT) sensors are able to give accurate real-time data on the environment around us to help us understand how we affect the environment and take actions to improve quality of life in cities.

Environmental sensors have been reduced in size and cost. They are now readily available and can be installed at many points across a city. Mobile technology has also advanced to provide a robust connectivity solution, cellular IoT (CIoT), that enables these sensors to be deployed efficiently and effectively by city authorities and other bodies.

Cities can measure many parameters as part of an environmental monitoring deployment that utilizes connected IoT sensors, including air and water quality, weather, noise, smoke and other attributes that may affect quality of life in a city including those related to disaster management, such as the earthquake and flood sensors.

In order to control these emissions, the city first needs to know both where the pollution hotspots are and how the pollution is generated. With this information, cities can plan for cleaner air by incentivizing the drivers of polluting vehicles to stay away or changing road layouts to direct traffic away from sensitive area. More information related to environmental monitoring use case and solution may refer to global system for mobile communications (GSM) association (GSMA) "Environmental Monitoring: A Guide to Ensuring a Successful Mobile IoT Deployment".

The following table shows an example CIoT SCEF or NEF technology as the mobile data delivery for network IoT message function in environment monitoring business scenario to bridge among UEs, application sever on mobile edge and application server on the cloud.

<FIG> is a diagram showing an existing communication system for environment monitoring use case. As shown, the communication system comprises an operator trust domain and an Internet domain. In the operator trust domain, there are UEs (e.g. IoT sensors) supporting non-IP data delivery (NIDD), UEs (e.g. IoT sensors) supporting IP data delivery (IPDD), an application server on mobile edge (e.g. an environment monitoring local station), radio access networks (RANs), a home subscriber server (HSS), a mobility management entity (MME), a packet data network (PDN) gateway (PGW), and a network exposure function (NEF)/service capability exposure function (SCEF). The term "on mobile edge" may refer to "at the edge of a cellular network". In the Internet domain, there is an application server such as an environment monitoring and management system on the cloud.

Small data communication includes infrequent and frequent small data transmission aiming to support efficient small data transmissions for CIoT, e.g. tracking devices for both mobile originated (MO) and mobile terminated (MT) use cases. It is expected that the number of such devices can increase exponentially, but the data size per device will remain small. For the small data communication, there is no UE to UE communication defined in 3GPP technical specification (TS) <NUM>. UE will always communicate with the application server first (especially the application server on the cloud) via the internet connection outside the operator trust domain before communicating with other UEs. For example, in the existing system shown in <FIG>, the application server on the cloud is the main routing node for UEs' communications and all UEs communicate with the application server on the cloud. This is not efficient when massive UEs need to communicate with the application server on mobile edge which may be considered as a parent UE. In addition, CIoT UE normally will go for sleep mode and thus need network IoT message function in the operator trust domain.

The present disclosure proposes improved solutions for data communication between terminal device and application server. Hereinafter, the solutions will be described in detail with reference to <FIG>.

<FIG> is a diagram showing an exemplary communication system according to an embodiment of the disclosure. Compared with the existing system shown in <FIG>, the SCEF or NEF is used to play as network IoT message function for routing UE to UE communication within the operator trust domain in this embodiment. For example, a child UE can send data to the application server on mobile edge via non-IP PDN. The child UE's non-IP data can be routed to the application server on mobile edge via the NEF/SCEF. Similarly, a child UE can send data to the application server on mobile edge via IP PDN. The child UE's IP data can be routed to the application server on mobile edge via the NEF/SCEF. The application server on mobile edge can send child UEs' aggregate data to the application server on the cloud.

It should be noted that RANs are omitted in <FIG> for brevity and the number of each entity shown in <FIG> may be more than one. Although environment monitoring use case is shown in <FIG>, it is merely an exemplary example for illustration purpose. Those skilled in the art will understand that the principle of the present disclosure may also be applicable to any other case in which data communication between a terminal device and an application server in operator trust domain is required. It should also be noted that the HSS, the MME and the PGW are merely exemplary examples of the components in the communication system and may be replaced by components with similar functionalities. For example, in the fifth generation (<NUM>) core network (CN), the HSS may be replaced by a unified data management (UDM), the MME may be replaced by an access and mobility management function (AMF), and the PGW may be replaced by a user plane function (UPF). That is, the principle of the present disclosure may be reused for data delivery in both <NUM> and <NUM> networks.

The term 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.

<FIG> is a flowchart illustrating a method implemented at a network exposure node according to an embodiment of the disclosure. 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 receives, from a first application server in operator trust domain, configuration information that can be used for data delivery for a terminal device. For example, the first application server may be deployed on operator mobile edge. In environment monitoring use case, it may act as an environment monitoring local station. For a terminal device supporting NIDD, the configuration information may be received in an NIDD configuration request message. For a terminal device supporting IPDD, the configuration information may be received in an IPDD configuration request message. In a case that the network exposure node is an SCEF or NEF, NIDD configuration interface (e.g. API) such as that defined in 3GPP TS <NUM> may be reused for IPDD configuration.

Depending on whether the first application server has a static or dynamic IP address and the direction of data delivery between the terminal device and the first application server, there may be three options. In the first option, the first application server has a static IP address and data is delivered from the terminal device to the first application server. In the second option, the first application server has a dynamic IP address and data is delivered from the terminal device to the first application server. In the third option, the first application server has a static or dynamic IP address and data is delivered from the first application server to the terminal device. For example, block <NUM> may implemented as block <NUM> in the first option, as block <NUM> in the second option, and as block <NUM> in the third option, which will be described later.

At block <NUM>, the network exposure node receives data from one of the terminal device and the first application server. For example, block <NUM> may implemented as block <NUM> in the first option, as block <NUM> in the second option, and as block <NUM> in the third option, which will be described later. At block <NUM>, the network exposure node forwards the data to the other of the terminal device and the first application server based on the configuration information. For example, block <NUM> may be implemented as block <NUM> in the first option, as block <NUM> in the second option, and as block <NUM> in the third option, which will be described later. In this way, since the network exposure node instead of the application server on the cloud is used as the routing node, a more easy way can be provided to route the communication between the terminal device and the application server within the operator trust domain.

<FIG> is a flowchart illustrating a method implemented at a network exposure node according to another embodiment of the disclosure. The method corresponds to the first option described above. At block <NUM>, the network exposure node receives, from a first application server in operator trust domain, configuration information that contains identity (ID) information of the terminal device, network address information of the first application server and an APN. Since the first application server has a static IP address in this option, the configuration information contains the network address information of the first application server. For example, this network address information may be a URI of the first application server, which may be translated to a corresponding IP address. The ID information of the terminal device may be an external ID or an MSISDN of the terminal device. The APN refers to an access point name via which the network address information of the first application server is reachable.

At block <NUM>, the network exposure node receives data from the terminal device. For the terminal device supporting NIDD, the data may be received through NIDD procedure such as that defined in 3GPP TS <NUM>. For the terminal device supporting IPDD, the data may be received via a packet gateway node such as a PGW. At block <NUM>, the network exposure node forwards the data to the first application server based on the network address information of the first application server corresponding to the ID information of the terminal device and the APN. For example, due to the reception of the data from the terminal device, the ID information of the terminal device and the APN may be known by the network exposure node. Based on this combination of the ID information and the APN, the network address information of the first application server corresponding to this combination may be determined from the configuration information received at block <NUM>. Then, the determined network address information may be used for forwarding the data to the first application server. For the terminal device supporting NIDD, the data may be forwarded through T8 NIDD interface such as that defined in 3GPP TS <NUM>. For the terminal device supporting IPDD, the T8 NIDD interface may be reused for forwarding the data.

Optionally, the configuration information received at block <NUM> may further contain network address information of at least one additional destination to which data is to be delivered from the terminal device. Accordingly, optionally, at block <NUM>, the network exposure node may forward the data to the at least one additional destination based on the configuration information. For example, one of the at least one additional destination may be a second application server in Internet domain.

<FIG> is a flowchart illustrating a method implemented at a network exposure node according to another embodiment of the disclosure. The method corresponds to the second option described above. At block <NUM>, the network exposure node receives, from a first application server in operator trust domain, configuration information that contains ID information of the terminal device, ID information of the first application server and an APN. Since the first application server has a dynamic IP address in this option, the configuration information contains ID information instead of network address information of the first application server. For example, the ID information of the first application server may be an external ID or an MSISDN of the first application server which may also be considered as a parent UE. At block <NUM>, the network exposure node obtains, from a packet gateway node, the ID information and corresponding current network address information of the first application server. The packet gateway node may be a PGW or any other entity having similar functionality. For example, the packet gateway node may send the information actively or the network exposure node may inquire the packet gateway node about the information.

At block <NUM>, the network exposure node receives data from the terminal device. Block <NUM> may be the same as block <NUM> and its details are omitted here. At block <NUM>, the network exposure node forwards the data to the first application server based on the current address information of the first application server corresponding to the ID information of the terminal device and the APN. For example, due to the reception of the data from the terminal device, the ID information of the terminal device and the APN may be known by the network exposure node. Based on this combination of the ID information and the APN, the ID information of the first application server corresponding to this combination may be determined from the configuration information received at block <NUM>. Then, the current network address information of the first application server corresponding to its ID information may be determined from the information obtained at block <NUM>. Then, the determined current network address information may be used for forwarding the data to the first application server.

Optionally, the configuration information received at block <NUM> may further contain ID information of at least one additional destination to which data is to be delivered from the terminal device. Accordingly, at block <NUM>, the network exposure node may forward the data to the at least one additional destination based at least on the configuration information. Specifically, the current network address information of the at least one additional destination may be determined in a way similar to blocks <NUM> and <NUM>. Then, the data may be forwarded based on the determined current network address information.

<FIG> is a flowchart illustrating a method implemented at a network exposure node according to another embodiment of the disclosure. The method corresponds to the third option described above. At block <NUM>, the network exposure node receives, from a first application server in operator trust domain, configuration information that contains ID information of the terminal device, network address or ID information of the first application server and an APN. For example, block <NUM> may be implemented as block <NUM> or <NUM>. At block <NUM>, the network exposure node obtains, from a packet gateway node, the ID information and corresponding current network address information of the terminal device. For example, the packet gateway node may send the information actively or the network exposure node may inquire the packet gateway node about the information.

At block <NUM>, the network exposure node receives data from the first application server. The data may be received in the form of non-IP data or IP data. For the case of the non-IP data, it may be received through T8 NIDD interface such as that defined in 3GPP TS <NUM>. For the case of the IP data, the T8 NIDD interface may be reused for receiving the data. At block <NUM>, the network exposure node forwards the data to the terminal device based on the current network address information of the terminal device corresponding to the ID information of the terminal device. For example, due to the reception of the data from the terminal device, the ID information of the terminal device and the APN may be known by the network exposure node. The current network address information of the terminal device corresponding to its ID information may be determined from the information obtained at block <NUM>. Then, the determined network address information may be used for forwarding the data to the terminal device. For the case of the non-IP data, it may be forwarded through T8 NIDD procedure such as that defined in 3GPP TS <NUM>. For the case of the IP data, it may be forwarded via a packet gateway node such as a PGW.

<FIG> is a flowchart illustrating a method implemented at an application server in operator trust domain according to an embodiment of the disclosure. For example, the application server may be deployed in operator mobile edge. At block <NUM>, the application server sends, to a network exposure node, configuration information that can be used for data delivery for a terminal device. Block <NUM> may correspond to block <NUM>, <NUM> or <NUM> and its details are omitted here. Optionally, the configuration information may contain network address or ID information of the application server and at least one additional destination to which data is to be delivered from the terminal device via the network exposure node.

At block <NUM>, the application server receives data from the terminal device via the network exposure node or sends data to the terminal device via the network exposure node. Corresponding to block <NUM> and <NUM>, in the first and second options described above, the data may be received via the network exposure node in the form of IP data or non-IP data. The IP data may be received through a same interface of the network exposure node as that used for the non-IP data, as shown in block <NUM>-<NUM>. Corresponding to block <NUM>, in the third option described above, the data may be sent via the network exposure node in a form of IP data or non-IP data. The IP data may be sent through a same interface of the network exposure node as that used for the non-IP data, as shown in block <NUM>-<NUM>.

<FIG> are flowcharts each illustrating an exemplary process according to an embodiment of the disclosure. In these exemplary processes, SCEF or NEF is used as network IoT message function for routing UE to UE communication within operator trust domain, instead of UE always communicating with AS on the cloud via 3GPP T8 APIs. Thus, a more easy way can be provided to route UE to AS on mobile edge communication within operator trust domain. The process of <FIG> is about the small data delivery from UE to mobile edge when the parent UE has static IP allocation. It covers both NIDD and IPDD for UE to AS on mobile edge.

At block <NUM>, the AS on mobile edge attaches the network and requests packet data network (PDN) connection, thereby getting an static IP address. For example, details of this block may be obtained from 3GPP TS <NUM>, chapter <NUM>. At block <NUM>, the AS on cloud provisions UE onboarding information (e.g. child UE external ID, etc.) to the AS on mobile edge via an interface defined between the application servers. At block <NUM>, the AS on mobile edge sends a request to the SCEF for NIDD Configuration. The request includes External ID/MSISDN of Non-IP UE, AS on mobile edge Destination IP and APN. The request may be sent via an interface such that defined in 3GPP T8 TS <NUM>.

Optionally, the cardinality of 'notificationDestination' in the NIDD Configuration request may be changed from <NUM> to <NUM>. N in order to support multiple notification destination, as shown below.

At block <NUM>, in additional to the AS on mobile edge destination, the AS on the cloud destination may also be also added as NIDD MO destination address. In this way, the SCEF can support multiple destination data delivery in T8 Data Delivery API so that both the AS on mobile edge and the AS on the cloud can receive the child UE MO data.

At block <NUM>, the SCEF sends the NIDD configuration to the HSS in terms of TS <NUM>, chapter <NUM>. At block <NUM>, the child Non-IP UE sends NIDD Mobile Originated data to the SCEF in terms of TS <NUM>, chapter <NUM>. At block <NUM>, the SCEF sends NIDD MO data to the AS on mobile edge via 3GPP T8 TS <NUM> NIDD API. Optionally, at block <NUM>, the SCEF duplicates the child UE's data payload and sends it to the AS on the cloud. The AS on the cloud address used for sending the data is defined in block <NUM> for NIDD Configuration. Blocks <NUM> to <NUM> may be repeated for all child Non-IP UEs.

At block <NUM>, the AS on mobile edge sends IP Data Delivery Configuration Request (including External ID/MISDIN of UE IP, AS on mobile edge Destination IP, APN) via 3GPP T8 extension. In this way, the NIDD Configuration API (such as that defined in 3GPP TS <NUM>) can be reused for IP Data Delivery Configuration. Optionally, the above 'notificationUEDestination' indicating multiple notification destinations may be used for the UE communication routing address. The IPDD configuration may also be sent from the SCEF to the HSS.

At block <NUM>, the IP UE attaches the network and creates IP PDN connectivity. The details of this block may be obtained from TS <NUM>, chapter <NUM>. <NUM> and <NUM>. At block <NUM>, the UE on IP PDN sends data to the SCEF via PGW SGi interface and the UE traffic end point is the SCEF IP address. At block <NUM>, the SCEF embeds IP UE MO data payload (typically is UDP based) in T8 NIDD MO API to the AS on mobile edge (based on the NIDD configuration notification destination) via 3GPP T8 extension. In this way, the 3GPP T8 NIDD API can be reused for IP data delivery to make common APIs for small data delivery in both Non-IP and IP connection. That is, T8 interface is reused for IP based small data delivery that typically is UDP based data. Optionally, at block <NUM>, the SCEF duplicates the child UE's data payload and sends it to the AS on the cloud. The AS on the cloud address used for sending the data is defined in block <NUM> for NIDD Configuration. Blocks <NUM> to blocks <NUM> may be repeated for all Child IP UEs.

The process of <FIG> is about small data delivery from UE to mobile edge and the parent UE has dynamic IP allocation. At block <NUM>, the AS on mobile edge attaches the network and requests PDN connection, thereby getting a dynamic IP address. For example, details of this block may be obtained from 3GPP TS <NUM>, chapter <NUM>. <NUM> and <NUM>. At block <NUM>, the PGW sends IMSI, UE IP and APN to the SCEF via Radius or other pre-defined interface between the SCEF and the PGW. Alternatively, the SCEF may inquire the PGW about IMSI, UE IP and APN via Radius or other pre-defined interface. At block <NUM>, the AS on cloud provisions the UE onboarding information (e.g. child UE external ID, etc.) to the AS on mobile edge , which interface define by Application Server.

At block <NUM>, the AS on mobile edge sends NIDD Configuration Request to the SCEF (including External ID/MISDIN of Non-IP UE, AS on mobile edge Destination such as Parent UE External ID, APN) via 3GPP T8 API such as that defined in 3GPP TS <NUM>. For example, the following attribute may be added in the definition of type 'NiddConfiguration' for UE communication route address, instead of the 3GPP defined 'notificationDestination' that is URI.

Optionally, this NIDD Configuration may also reuse block <NUM> for changing the cardinality of 'notificationDestination' from <NUM> to <NUM>. N in order to support the multiple notification destination.

At block <NUM>, the SCEF sends NIDD Configuration to the HSS in terms of TS <NUM>, chapter <NUM>. At block <NUM>, the Non-IP Child UE sends NIDD Mobile Originated data to the SCEF. The details of this block may be obtained from TS <NUM>, chapter <NUM>. At block <NUM>, the SCEF uses NIDD configuration 'notificationUEdestination' to get the AS on mobile edge IP address, and send NIDD MO data to the AS on mobile edge via 3GPP T8 (see, for example, TS <NUM>). Optionally, at block <NUM>, the SCEF duplicates the child UE's data payload and sends it to the AS on the cloud. The AS on the cloud address used for sending the data is defined in block <NUM> for NIDD Configuration. Blocks <NUM> to <NUM> may be repeated for all Child Non-IP UEs.

At block <NUM>, the AS on mobile edge sends IP Data Delivery Configuration Request (External ID/MISDIN of UE IP, AS on mobile edge Destination such as Parent UE External ID, APN) via 3GPP T8 extension. In this way, NIDD Configuration API such as that defined in 3GPP TS <NUM> can be reused for IP Data Delivery Configuration. Optionally, this IPDD Configuration may also reuse block <NUM> for changing the cardinality of 'notificationDestination' from <NUM> to <NUM>. N in order to support the multiple notification destination.

At block <NUM>, the IP UE attaches the network and create IP PDN connectivity. The details of this block may be obtained from TS <NUM>, chapter <NUM>. <NUM> and <NUM>. At block <NUM>, the PGW sends IMSI, UE IP and APN to the SCEF via Radius or other pre-defined interface between SCEF and PGW. Alternatively, the SCEF may inquire the PGW about IMSI, UE IP and APN via Radius or other pre-defined interface. At block <NUM>, the UE on IP PDN sends data to the SCEF via PGW and the UE traffic end point is the SCEF IP address. At block <NUM>, the SCEF sends MO data to the AS on mobile edge (based on the AS address mapped with the UE ID and APN) via 3GPP T8 extension. Optionally, at block <NUM>, the SCEF duplicates the child UE's data payload and sends it to the AS on the cloud. The AS on the cloud address used for sending the data is defined in 'notificationDestination' in the definition of 'NiddConfiguration' API in 3GPP TS <NUM> T8 APIs (see, for example, chapter <NUM>. Blocks <NUM> to <NUM> may be repeated for all Child IP UEs.

In the process of <FIG>, 3GPP T8 API NIDD Configuration is proposed to add Parent UE External ID or MSISDN, so that the SCEF can map the Parent UE External ID or MSISDN to Parent UE IP address (thus supporting dynamic IP allocation) for providing the way to route UE data towards AS on mobile edge. The exemplary processes shown in <FIG> and <FIG> can be applied to the communication from UE to AS on mobile edge so that a number of child UEs' data can be aggregated in one parent UE that located in mobile edge in operator trust domain. Thereafter the mobile edge may send the aggregated data to the AS on the internet cloud.

The process of <FIG> is about small data delivery from mobile edge (Parent UE) to UE (Child UE). At block <NUM>, the AS on mobile edge attaches the network and creates PDN connection, thereby getting an IP address. The details of this block may be obtained from 3GPP TS <NUM>, chapter <NUM>. <NUM> and <NUM>. At block <NUM>, the AS on cloud provisions the UE onboarding information (e.g. Child UE external ID, etc.) to the AS on mobile edge that interface defined by AS. At block <NUM>, the AS on Mobile Edge sends NIDD Configuration Request (including External ID/MISDIN of Non-IP UE, AS on mobile edge Destination IP, APN) via 3GPP T8 (see, for example, TS <NUM>). At block <NUM>, the SCEF sends the NIDD configuration to the HSS in terms of TS <NUM>, chapter <NUM>.

At block <NUM>, the AS on the cloud sends data to the AS on mobile edge. At block <NUM>, the AS on mobile edge sends NIDD MT data to the SCEF via 3GPP T8 (see, for example, TS <NUM>). At block <NUM>, the NIDD MT data is sent from the SCEF to the Non-IP Child UE (see, for example, TS <NUM>, chapter <NUM>. Blocks <NUM> to <NUM> may be repeated for all Non-IP Child UEs.

At block <NUM>, the AS on mobile edge sends IP Data Delivery Configuration Request (including External ID/MISDIN of UE IP, AS on mobile edge Destination IP, APN) via 3GPP T8 extension. Optionally, the above 'notificationUEDestination' indicating multiple notification destinations may be used for the UE communication routing address. The IPDD configuration may also be sent from the SCEF to the HSS. At block <NUM>, the IP UE attaches the network and creates IP PDN connection (see, for example, TS <NUM>, chapter <NUM>. <NUM> and <NUM>. At block <NUM>, the PGW sends IMSI, UE IP and APN to the SCEF via Radius or other pre-defined interface between SCEF and PGW. Alternatively, the SCEF may inquire the PGW about IMSI, UE IP and APN via Radius or other pre-defined interface.

At block <NUM>, the AS on mobile edge sends MT data to the Child UE ID via SCEF 3GPP T8 API. In this way, NIDD API of the SCEF may be reused for IP Data Delivery which is small data delivery typically based on UDP protocol. At block <NUM>, the SCEF maps UE ID to UE IP, creates UDP packet and sends it to the Child UE via PGW SGi Interface. At block <NUM>, the UE on IP PDN gets data from the SCEF via PGW. Blocks <NUM> to <NUM> may be repeated for all IP Child UEs. 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 and the application server 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 first reception module <NUM>, a second reception module <NUM> and a forwarding module <NUM>. The first reception module <NUM> may be configured to receive, from a first application server in operator trust domain, configuration information that can be used for data delivery for a terminal device, as described above with respect to block <NUM>. The second reception module <NUM> may be configured to receive data from one of the terminal device and the first application server, as described above with respect to block <NUM>. The forwarding module <NUM> may be configured to forward the data to the other of the terminal device and the first application server based on the configuration information, as described above with respect to block <NUM>.

<FIG> is a block diagram showing an application server in operator trust domain according to an embodiment of the disclosure. As shown, the application server <NUM> comprises a sending module <NUM> and a transceiving module <NUM>. The sending module <NUM> may be configured to send, to a network exposure node, configuration information that can be used for data delivery for a terminal device, as described above with respect to block <NUM>. The transceiving module <NUM> may be configured to receive data from the terminal device via the network exposure node or send data to the terminal device via the network exposure node, as described above with respect to block <NUM>. 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, wherein the network exposure node is a service capability exposure function, SCEF, or network exposure function, NEF, the method comprising:
receiving (<NUM>), from a first application server in operator trust domain, configuration information that can be used for data delivery for a terminal device;
receiving (<NUM>) data from one of the terminal device and the first application server; and
forwarding (<NUM>) the data to the other of the terminal device and the first application server based on the configuration information;
the method being characterized in that the data received from the terminal device is in a form of Internet protocol, IP, data or non-IP data; and
wherein the IP data is forwarded through a same interface as is used for the non-IP data;
and wherein the same interface is T8 non-IP data delivery, NIDD, interface.