Patent Description:
Non-IP data delivery (NIDD) is specified in clause <NUM>. <NUM> of 3rd generation partnership project (3GPP) technical specification (TS) <NUM>. Functions for NIDD may be used to handle mobile originated (MO) and mobile terminated (MT) communication with user equipments (UEs). The data used for the communication is considered unstructured from the evolved packet system (EPS) standpoint (which may also be referred to as non-IP). The support of non-IP data is part of the cellular Internet of things (CIoT) EPS optimizations. The non-IP data delivery to service capability server (SCS)/application server (AS) may be accomplished by one of two mechanisms: delivery using service capability exposure function (SCEF) and delivery using a point-to-point (PtP) SGi tunnel.

The delivery using a PtP SGi tunnel is further described in 3GPP TS <NUM>. NIDD via the SCEF is handled using a packet data network (PDN) connection to the SCEF. The UE may obtain a non-IP PDN connection to the SCEF either during the Attach procedure (see TS <NUM>, clause <NUM>. <NUM>) or via UE requested PDN connectivity (see TS <NUM>, clause <NUM>. <NUM>) or via packet data protocol (PDP) Context Activation procedure (see TS <NUM>, clause <NUM>. Note that the UE is not made aware that a particular non-IP PDN connection is provided via SCEF or via PDN gateway (PGW). However, the network informs the UE whether a particular non-IP PDN connection uses control plane CIoT optimization (see TS <NUM>).

Document XP051366551 by CONVIDA WIRELESS discloses that the "Reliable Data Service Configuration" in the MT and MO NIDD procedures is used to identify the application on the originator and to identify the application on the receiver.

For NIDD via SCEF, an association between an SCS/AS and a PDN connection to the SCEF needs to be established to enable transfer of non-IP data between the UE and the SCS/AS. When the Reliable Data Service (RDS) is not enabled, the SCEF determines the association based on provisioned policies that may be used to map an SCS/AS identity and user identity to an access point name (APN). When the RDS is enabled, the SCEF determines the association based on port numbers and provisioned policies that may be used to map SCS/AS identities and user identity to an APN (see TS <NUM>, clause <NUM>. Note that when more than one SCS/AS is associated with the same PDN connection, it is permissible for packets to or from one port number to be associated with more than one SCS/AS. Also, any polices that are applied to the PDN connection (e.g. APN rate control), apply to traffic from all of the SCS/AS's that are associated with the PDN connection.

NIDD via SCEF uses the User Identity, APN, and the SCS/AS identity to identify which UE a particular T6a/T6b connection belongs to. The User Identity is the user's international mobile subscriber identification number (IMSI). The user's IMSI shall not be used on the interface between SCEF and SCS/AS. In order to perform NIDD configuration or to send or receive NIDD data, the SCS/AS shall use MSISDN or External Identifier to identify the user. In order to facilitate correlation of SCS/AS requests to T6a/T6b connection for a given UE, the home subscriber server.

(HSS) provides to the SCEF (see NIDD Configuration procedure in clause <NUM>. <NUM> of TS <NUM>) the user's IMSI, and if available, the MSISDN (when NIDD Configuration Request contains an External Identifier) or if available, External Identifier (when NIDD Configuration Request contains an MSISDN). The term MSISDN refers to mobile subscriber international integrated services digital network (ISDN) number.

The EPS system supports multiple PDN connections towards the same APN. In case of non-IP, the multiple PDN connections are anchored in the same SCEF, as shown in <FIG>. The SCEF holds the correlation between EPS bearer identity (ID), UE ID and T8 long term transaction reference ID (TLTRI) in NIDD configuration and determines which EPS bearer the MT NIDD should be delivered to, as mentioned in clause <NUM>. <NUM> of TS <NUM>:
The SCEF sends an NIDD Configuration Response (TLTRI, Maximum Packet Size, Reliable Data Service Indication, and Cause) message to the SCS/AS to acknowledge acceptance of the NIDD Configuration Request and the deletion of the identified NIDD configuration, if it was requested. If the NIDD Configuration was accepted, the SCEF will create an association between the TLTRI, External Group Identifier or External Identifier or MSISDN, IMSI, and EBI of the non-IP PDN connection. In the MT NIDD procedure, the SCEF will use TLTRI and External Group Identifier or External Identifier or MSISDN to determine the IMSI(s) and EBI(s) of the non-IP PDN connection(s). In the MO NIDD procedure, the SCEF will use the IMSI(s) and EBI(s) to obtain the TLTRI, External Identifier or MSISDN.

As shown in <FIG>, if multiple non-IP PDN connections towards the same APN apply, there are multiple EPS bearer IDs (EBIs) for the same UE and the SCEF does not know exactly which EPS bearer the MT NIDD should be delivered to. Consequently, the MT NIDD may be delivered to a wrong application in the UE. Furthermore, the charging data may be recorded for the wrong PDN connection (e.g. see control plane data transfer (CPDT)-service capability exposure (SCE)-charging data record (CDR)/CPDT-serving network name (SNN)-CDR in TS <NUM>).

The same issue also exists in 5th generation core (5GC) as well. In this case, the SCEF is replaced by a network exposure function (NEF), the APN is replaced by a combination of data network name (DNN) and network slice selection assistance information (NSSAI), the PDN connection is replaced by a PDU session, and the SCS/AS is replaced by an AF.

The present disclosure proposes an improved solution for NIDD. Hereinafter, the solution will be described in detail with reference to <FIG>.

As used herein, the term "communication system" refers to a system following any suitable communication standards, such as the first generation (<NUM>), <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> communication protocols, and/or any other protocols either currently known or to be developed in the future. Furthermore, the communications between a terminal device and a network node in the communication system may be performed according to any suitable generation communication protocols, including, but not limited to, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> communication protocols, and/or any other protocols either currently known or to be developed in the future.

In the following, different terms may refer to a same or similar network function or network node with the same or similar functionality in different communication systems. Thus, the specific terms used herein do not limit the present disclosure only to the communication system related to the specific terms, which however can be more generally applied to other communication systems.

<FIG> is a diagram showing an exemplary communication system into which an embodiment of the disclosure is applicable. As shown, the communication system comprises a user equipment (UE) <NUM>, a radio access network (RAN) <NUM>, a serving general packet radio service (GPRS) support node (SGSN) <NUM>, a mobility management entity (MME) <NUM>, a serving gateway (SGW) <NUM>, a gateway GPRS support node (GGSN)/packet data network (PDN) gateway (PGW) <NUM>, a service capability exposure function (SCEF) <NUM>, a service capability server (SCS) <NUM>, an 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 RAN <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 RAN <NUM> may include, for example, a universal mobile telecommunications system (UMTS) terrestrial RAN (UTRAN), a global system for mobile communication (GSM) enhanced data rate for GSM evolution (EDGE) RAN (GERAN), and/or an evolved universal terrestrial RAN (E-UTRAN). The UTRAN and the GERAN can each include radio network controller (RNC) nodes to control communications through radio base stations providing radio access communication links to UEs that are within their respective communication service cells. The E-UTRAN can include radio base station nodes (eNodeBs or eNBs) that can provide the combined functionality of the RNC nodes and base stations of the UTRAN and the GERAN.

The SGSN <NUM> 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 <NUM> can transfer user data packets of the UE <NUM> between the RAN <NUM> and the GGSN/PGW <NUM>. The control-plane function of the SGSN <NUM> can carry out mobility management of the UE <NUM>, bearer management and the like. The MME <NUM> 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 RAN <NUM> and the GGSN/PGW <NUM>.

The GGSN is a core network node in the UMTS. The PGW is a core network node in the EPS. The GGSN/PGW <NUM> means either the GGSN or the PGW or both. The GGSN/PGW <NUM> is a user-plane packet transfer node in the core network and can transfer user data packets of the UE <NUM>. The GGSN/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 SCS <NUM> 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 <NUM> can accomplish mapping of OSA interfaces onto network protocols and vice versa. The AS <NUM> may be a type of server designed to install, operate and host applications and associated services for users. 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>.

As shown in <FIG>, the communication system may further comprise a mobile switching center (MSC) <NUM>, a short message service (SMS)-service center (SC)/gateway mobile switching center (GMSC)/interworking MSC (IWMSC) <NUM>, a short message entity (SME) <NUM>, an IP-short message (SM)-gateway (GW) <NUM>, a machine-type communication (MTC)-interworking function (IWF) <NUM>, a charge data function (CDF)/charge gateway function (CGF) <NUM> and an MTC-authentication, authorization and accounting (AAA) <NUM>. It should be noted that the SCEF <NUM>, the SCS <NUM> and the AS <NUM> are merely exemplary examples of the components in the communication system and may be replaced by components with similar functionalities. For example, in <NUM> system, the SCEF may be replaced by a network exposure function (NEF), and the SCS/AS may be replaced by an application function (AF).

<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 be an SCEF, an NEF, or any other entity having similar functionality. At block <NUM>, the network exposure node obtains associations between multiple non-IP connections between a terminal device and the network exposure node and multiple RDS port configurations configured to the network exposure node by an application related node for multiple applications. For example, the non-IP connection may be a non-IP PDN connection or an unstructured PDU session. Each of the multiple non-IP connections may be identified by an EPS bearer identity (EBI) or a PDU session identifier. The application related node may be an SCS, an AS, an AF, or any other entity having similar functionality. Each of the multiple RDS port configurations may comprise a first RDS port for use by the network exposure node and a second RDS port for use by the terminal device.

Each of the multiple RDS port configurations may be configured to the network exposure node through static RDS configuration or dynamic RDS management. The static RDS configuration may be performed by receiving a request for NIDD configuration from the application related node. That is, if all of the multiple RDS port configurations are configured through static RDS configuration, the request for NIDD configuration may contain the multiple RDS port configurations. Regarding the dynamic RDS management, various port management procedures (similar to the dynamic RDS port procedure as described in clause <NUM>. <NUM> of TS <NUM> V16. <NUM>) may be used by the application related node to request the network exposure node to manage (e.g. reserve) a RDS port configuration, and the network exposure node in turn requests the terminal device to manage (e.g. reserve) a RDS port configuration as described in clause <NUM>. <NUM> of TS <NUM> V16. It is also possible that the multiple RDS port configurations are configured partly through static RDS configuration and partly through dynamic RDS management.

Each of the multiple RDS port configurations may correspond to one of the multiple applications. This correspondence may be preconfigured in a terminal device related to the multiple applications before the terminal device leaves the factory. Alternatively, this correspondence may be configured to the terminal device by the network exposure node through dynamic RDS management as described in clause <NUM>. <NUM> of TS <NUM> V16. It is also possible that this correspondence is configured to the terminal device partly through preconfiguration and partly through dynamic RDS management.

There may be two options for the implementation of block <NUM>. As the first option, an establishment of a non-IP connection among the multiple non-IP connections may be initiated from the terminal device without a trigger sent by the network exposure node to the terminal device. For example, this may be the case that the terminal device has MO NIDD data to send and thus establishes the non-IP connection. In this case, the association between the non-IP connection and at least one RDS port configuration among the multiple RDS port configurations may be obtained by receiving the at least one RDS port configuration from the terminal device through the non-IP connection. If acknowledged mode is to be used between the terminal device and the network exposure node, the at least one RDS port configuration may be received in a RDS command for setting acknowledged mode. If unacknowledged mode is to be used, the at least one RDS port configuration may be received in a RDS message in unacknowledged mode.

As the second option, an establishment of a non-IP connection among the multiple non-IP connections may be initiated from the terminal device with a trigger sent by the network exposure node to the terminal device. For example, this may be the case that the network exposure node receives from the application related node MT NIDD data destined to a terminal device. But there has been not any non-IP connection established between the terminal device and the network exposure node. Thus, the network exposure node may send a trigger (e.g. a short message) to the terminal device. In this case, the association between the non-IP connection and at least one RDS port configuration among the multiple RDS port configurations may be obtained by sending the at least one RDS port configuration to the terminal device through the non-IP connection. If acknowledged mode is to be used between the network exposure node and the terminal device, the at least one RDS port configuration may be sent in a RDS command for setting acknowledged mode and a response for accepting the setting may be received from the terminal device. If unacknowledged mode is to be used, the at least one RDS port configuration may be sent in a RDS message in unacknowledged mode.

At block <NUM>, the network exposure node receives, from the application related node, a message that is destined to the terminal device and includes non-IP data and one of the multiple RDS port configurations. At block <NUM>, the network exposure node transfers the non-IP data to the terminal device through one of the multiple non-IP connections that is associated with the one of the multiple RDS port configurations according to the obtained associations. In this way, the correct non-IP connection can be chosen for MT NIDD in the case of multiple non-IP connections anchored in the same network exposure node.

<FIG> is a flowchart illustrating a method implemented at an application related node according to an embodiment of the disclosure. The application related node may be an SCS, an AS, an AF, or any other entity having similar functionality. At block <NUM>, the application related node configures, for each of multiple applications, a corresponding one of multiple RDS port configurations to a network exposure node. Each of the multiple RDS port configurations may comprise a first RDS port for use by the network exposure node and a second RDS port for use by the terminal device. The network exposure node may be an SCEF, an NEF, or any other entity having similar functionality. Each of the multiple RDS port configurations may be configured to the network exposure node through static RDS configuration or dynamic RDS management. The details about the configuring have been described above with respect to block <NUM> and thus are omitted here.

At block <NUM>, when the application related node needs to send non-IP data for one of the multiple applications to a terminal device, the application related node sends, to the network exposure node, a message including the non-IP data and one of the multiple RDS port configurations that corresponds to the one of the multiple applications. Since the corresponding RDS port configuration is sent to the network exposure node, the correct non-IP connection can be chosen by the network exposure node for MT NIDD in the case of multiple non-IP connections anchored in the same network exposure node.

<FIG> is a flowchart illustrating an exemplary process according to an embodiment of the disclosure. As shown, in this exemplary process, the network exposure node is an SCEF and the application related node is an SCS/AS. The UE has MO NIDD data to send and thus establishes PDN connection <NUM> and PDN connection <NUM>. Since the two PDN connections have the same APN, they are both anchored in the same SCEF. The SCS/AS sends, to the SCEF, NIDD configuration containing multiple RDS port configurations which take the form of a list of RDS ports. Note that the RDS ports may also be dynamically managed via the RDS protocol as described in TS <NUM>. Also note that the NIDD configuration can be done before or after the PDN connection establishment.

Take PDN connection <NUM> as an example. Note that the following description for PDN connection <NUM> may be similarly applicable to PDN connection <NUM>. When PDN connection <NUM> is established at block <NUM> and NIDD configuration is performed, the SCEF maintains the association between PDN connection <NUM> and the NIDD configuration (i.e. TLTRI <NUM> of the T8 NIDD configuration, UE ID <NUM> and EBI of PDN connection <NUM>). At block <NUM>, the UE initiates RDS with acknowledged (ack. ) mode setup by sending a SET_ACK_MODE command which contains RDS source port and destination port. Suppose these two ports are called RDS ports A. At block <NUM>, the SCEF may check if the destination port is defined (either in the static RDS configuration or in the dynamic RDS management). If accepted, at block <NUM>, the SCEF sends a RDS ACCEPT frame and records the association for RDS ports A in the table, together with the EBI of PDN connection <NUM> on which the RDS message was received. That is, the RDS ports is added into the association when the RDS ACCEPT frame is sent. At block <NUM>, the UE initiates MO NIDD to the SCEF by sending a RDS information (I) frame through PDN connection <NUM>. The RDS I frame contains RDS ports A and MO NIDD payload.

<FIG> is a flowchart illustrating an exemplary process according to an embodiment of the disclosure. The difference between the processes shown in <FIG> and <FIG> mainly lies in that unacknowledged mode is used between the UE and the SCEF. Also take PDN connection <NUM> as an example. When PDN connection <NUM> is established at block <NUM> and NIDD configuration is performed, the SCEF maintains the association between PDN connection <NUM> and the NIDD configuration (i.e. TLTRI <NUM> of the T8 NIDD configuration, UE ID <NUM> and EBI of PDN connection <NUM>). At block <NUM>, the UE initiates RDS with unacknowledged (unack. ) mode by sending a RDS unacknowledged information (UI) frame which contains RDS source port and destination port and MO NIDD payload. Suppose these two ports are called RDS ports A. At block <NUM>, the SCEF may check if the destination port is defined (either in the static RDS configuration or in the dynamic RDS management). If accepted, at block <NUM>, the SCEF records the association for RDS ports A in the table, together with the EBI of PDN connection <NUM> on which the RDS message was received. That is, the RDS ports is added into the association when the RDS UI frame with MO NIDD payload is received.

<FIG> is a flowchart illustrating an exemplary process according to an embodiment of the disclosure. As shown, the SCS/AS sends, to the SCEF, NIDD configuration containing multiple RDS port configurations which take the form of a list of RDS ports. Note that the RDS ports may also be dynamically managed via the RDS protocol as described in TS <NUM>. In this exemplary process, no PDN connection exists initially between the UE and the SCEF. The SCS/AS has non-IP data for an application to send to the UE. Suppose the application corresponds to RDS ports C. Then, the SCS/AS initiates MT NIDD to the SCEF. The MT NIDD contains the non-IP data and RDS ports C. Since no PDN connection exists, the SCEF may send a device trigger short message to the UE. In response to the short message, the UE establishes PDN connection <NUM> at block <NUM>.

At block <NUM>, the SCEF initiates RDS with ack. mode setup by sending a SET_ACK_MODE command which contains RDS ports C. At block <NUM>, the UE may check if the destination port is defined (either in the static RDS configuration or in the dynamic RDS management). If accepted, the UE may send a RDS ACCEPT frame to the SCEF at block <NUM>. If accepted, the SCEF may record, at block <NUM>, the association for RDS ports C in the table, together with the EBI of PDN connection <NUM> on which the RDS message was received. That is, when the RDS ACCEPT frame is received, the SCEF maintains the association between the PDN connection and the NIDD configuration (i.e. RDS ports C, TLTRI <NUM> of the T8 NIDD configuration, UE ID <NUM> and EBI of PDN connection <NUM>). At block <NUM>, the SCEF initiates MT NIDD to the UE by sending a RDS I frame through PDN connection <NUM>. The RDS I frame contains RDS ports C and MT NIDD payload.

<FIG> is a flowchart illustrating an exemplary process according to an embodiment of the disclosure. The difference between the processes shown in <FIG> and <FIG> mainly lies in that unacknowledged mode is used between the SCEF and the UE. Similar to <FIG>, in response to a device trigger short message, the UE establishes PDN connection <NUM> at block <NUM>. At block <NUM>, the SCEF initiates RDS with unack. mode by sending a RDS UI frame which contains RDS ports C and MT NIDD payload. At block <NUM>, the SCEF records the association for RDS ports C in the table, together with the EBI of PDN connection <NUM> on which the RDS message was sent. That is, when the RDS UI frame with MT NIDD payload is sent, the SCEF may maintain the association between PDN connection <NUM> and the NIDD configuration (i.e. RDS ports C, TLTRI <NUM> of the T8 NIDD configuration, UE ID <NUM> and EBI of PDN connection <NUM>). It should be noted that two blocks shown in succession in the 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 diagram illustrating an exemplary process according to an embodiment of the disclosure. As shown in the table, the SCEF has maintained the associations between PDN connections and NIDD configurations. In this exemplary process, the SCS/AS has non-IP data for an application to send to the UE. Suppose the application corresponds to RDS ports B. Then, the SCS/AS initiates MT NIDD to the SCEF. The MT NIDD contains the non-IP data and RDS ports B. From the received RDS ports B, the SCEF may determine that the received RDS ports B correspond to PDN connection <NUM>, according to the maintained associations. Thus, the SCEF chooses PDN connection <NUM> to transfer the MT NIDD payload to the UE.

According to the description above, the following changes may be made to the current technical specifications. In evolved packet core (EPC), for the case of multiple PDN connections of an APN, the RDS shall be used. The SCEF will, in addition, use the RDS application ports for the binding correlation between the non-IP PDN connection and NIDD configuration. In 5GC, for the case of multiple PDU sessions of an DNN and NSSAI, the RDS shall be used. The NEF will, in addition, use the RDS application ports for the binding correlation between the unstructured PDU session and NIDD configuration.

<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 LwM2M client, the LwM2M server and the management entity 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 optionally 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 an obtaining module <NUM>, a reception module <NUM> and a transferring module <NUM>. The obtaining module <NUM> may be configured to obtain associations between multiple non-IP connections between a terminal device and the network exposure node and multiple RDS port configurations configured to the network exposure node by an application related node for multiple applications, as described above with respect to block <NUM>. The reception module <NUM> may be configured to receive, from the application related node, a message that is destined to the terminal device and includes non-IP data and one of the multiple RDS port configurations, as described above with respect to block <NUM>. The transferring module <NUM> may be configured to transfer the non-IP data to the terminal device through one of the multiple non-IP connections that is associated with the one of the multiple RDS port configurations according to the obtained associations, as described above with respect to block <NUM>.

<FIG> is a block diagram showing an application related node according to an embodiment of the disclosure. As shown, the application related node <NUM> comprises a configuration module <NUM> and a sending module <NUM>. The configuration module <NUM> may be configured to configure, for each of multiple applications, a corresponding one of multiple RDS port configurations to a network exposure node, as described above with respect to block <NUM>. The sending module <NUM> may be configured to, when the application related node needs to send non-IP data for one of the multiple applications to a terminal device, send, to the network exposure node, a message including the non-IP data and one of the multiple RDS port configurations that corresponds to the one of the multiple applications, 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 in a network exposure node comprising:
obtaining (<NUM>) associations between multiple non-Internet protocol, IP, connections between a terminal device and the network exposure node and multiple reliable data service, RDS, port configurations configured to the network exposure node by an application related node for multiple applications;
receiving (<NUM>), from the application related node, a message that is destined to the terminal device and includes non-IP data and one of the multiple RDS port configurations; and
transferring (<NUM>) the non-IP data to the terminal device through one of the multiple non-IP connections that is associated with the one of the multiple RDS port configurations according to the obtained associations.