Data node, service node, open function node and method for subscribers in a communication network

Abstract

A method for distinguishing non-IP data delivery (NIDD) services in a communication network performed by a subscriber's data node. The communication network includes a subscriber's data node, a service node, and an open function node. The subscriber's data node receives a NIDD authorization request including a first identifier from the open function node. The first identifier includes any one of a service capability server identifier, an application server identifier, and an application function identifier. The subscriber's data node generates a non-IP flow description based on the received first identifier. The non-IP flow description includes an application identifier and a non-IP flow identifier for NIDD authorization. The subscriber's data node sends the non-IP flow description to the service node. The subscriber's data node sends a NIDD authorization response including the non-IP flow identifier to the open function node.

Description

Technical Field

[0001] Embodiments herein relate to a subscriber's data node, a service node, an open function node, and methods therein. In particular, embodiments herein relate to differentiating non-Internet protocol (IP) data delivery (NIDD) traffic in a communication network. Background Art

[0002] In a typical wireless communication network, wireless devices (also referred to as communication devices, mobile stations, stations (STAs), and / or user equipment (UEs)) communicate with one or more core networks (CNs) via a local area network or radio access network (RAN), such as a WiFi network. The RAN covers a geographic area that is divided into service areas or cell areas (which may also be referred to as beams or beam groups), each of which is served by a radio network node, such as a radio access node (e.g., a Wi-Fi access point or radio base station (RBS), which in some networks may also be denoted as, for example, a NodeB, an eNodeB (eNB), or, as in the fifth generation (5G) era, a gNB). A service area or cell area is a geographic area where radio coverage is provided by a radio network node. The radio network node communicates with wireless devices within range of the radio network node over an air interface operating on radio frequencies. The radio network node transmits to wireless devices in the downlink (DL) and receives from wireless devices in the uplink (UL).

[0003] The specification of the Evolved Packet System (EPS), also known as the fourth generation (4G) network, has been completed within the Third Generation Partnership Project (3GPP), and this work continues in upcoming 3GPP releases, for example to specify the fifth generation (5G) network, also known as 5G New Radio (NR). The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as the System Architecture Evolution (SAE) core network. E-UTRAN / LTE is a variant of the 3GPP radio access network in which radio network nodes are directly connected to the EPC core network, rather than to the Radio Network Controller (RNC) used in third generation (3G) networks. Typically, in E-UTRAN / LTE, the functionality of the 3G RNC is distributed between the radio network nodes (e.g., eNodes in LTE) and the core network. Therefore, the RAN of the EPS has a substantially "flat" architecture, comprising radio network nodes directly connected to one or more core networks, i.e., the radio network nodes are not connected to the RNC. To compensate for this, the E-UTRAN specifications define a direct interface between radio network nodes, which is denoted as the X2 interface.

[0004] Multiple antenna technology can significantly increase the data rate and reliability of wireless communication systems. Performance is particularly improved if both the transmitter and receiver are equipped with multiple antennas, forming a multiple-input, multiple-output (MIMO) communication channel. Such systems and / or related technologies are generally referred to as MIMO.

[0005] In addition to faster peak internet connection speeds, 5G plans also aim for higher capacity than current 4G, allowing for a larger number of mobile broadband users per area unit and higher or unlimited data consumption per user per month in gigabytes. This will enable large segments of the population to stream high-definition media on their mobile devices for several hours per day when they cannot access Wi-Fi hotspots. 5G research and development also aims to improve support for machine-to-machine communications (also known as the Internet of Things), aiming to achieve lower costs, lower battery consumption, and lower latency than 4G devices.

[0006] Demand for machine-to-machine (M2M) and Internet of Things (IoT) communications is rapidly growing. The IoT is a network of physical objects, called devices or "things," embedded with electronics, software, sensors, and connectivity, enabling them to deliver greater value and services by exchanging data with manufacturers, carriers, and / or other connected devices. Each "thing" is uniquely identified by its embedded computing system and is capable of interoperating within the existing internet infrastructure. The IoT is generally expected to provide advanced connectivity for devices, systems, and services that goes beyond M2M communication and encompasses a wide range of protocols, domains, and applications. Things in the IoT can refer to a wide variety of devices, such as cardiac monitoring implants, biochip transponders for farm animals, electric clams in coastal waters, cars with built-in sensors, or field equipment assisting firefighters with search and rescue operations. These devices collect useful data with the help of various existing technologies and then autonomously transmit that data between other devices. Current market examples include smart thermostats and washing machines and / or dryers that utilize WiFi for remote monitoring. The IoT is expected to generate vast amounts of data aggregated at very high speeds from diverse locations, increasing the need for better indexing, storage, and processing of this data.

[0007] The Cellular Internet of Things (CIoT) is a technology that involves machine-type communication (MTC) devices, allowing telecom operators to offer their networks to other parties and / or companies for different applications. An example of such an application is the use of smart meter readers, where MTC devices can be placed in different locations and begin to periodically send and receive data (such as electricity usage reports and water levels). This information may require a given MTC provider (such as an electric utility) to exchange information with different devices via the NIDD through the Service Capability Exposure Function (SCEF) in 4G or the Network Exposure Function (NEF) in 5G.

[0008] These MTC providers can utilize service capability servers (SCSs), application servers (ASs), and application functions (AFs) to request, collect, and manage application data (e.g., water temperature levels). To achieve this, software applications (i.e., MTC applications) can be installed on MTC devices (e.g., water temperature meters). Software applications (i.e., MTC applications) can also be installed on the AF and / or AS to request, collect, interpret, and post-process this data.

[0009] Quality of Service (QoS) is something that should be ensured by the AS and / or AF owned by the MTC provider for energy collection from MTC devices installed in a user's home, as applications in the MTC devices may need to prioritize NIDD. For example, in the event of a network overload or disconnection, a request for energy consumption from, for example, an AS or AF owned by MTC provider X may not be as important as a gas level measurement in a user's home requested by the same AF or AS. Therefore, the network should ensure this differentiation of services, such as energy consumption, gas levels, and temperature levels, for each MTC provider and service. Furthermore, the type of application data exchanged may have different requirements in terms of network latency, i.e., gas levels should be read and sent with very little latency (almost real time), while energy reports may be queued in the device and / or network and sent later, as they are less urgent for post-processing by the MTC application in the AF and / or AS owned by the MTC provider.

[0010] As mentioned above, such application data (eg, water levels, temperature levels, and gas levels) are exchanged via the NIDD.

[0011] As described in chapter 4.5.14.1 of TS 23.682, the concept of non-IP data services is not structured in 4G and 5G according to the 3rd Generation Partnership Project (3GPP) packet core network. This means that it may not be possible to identify traffic flows from MTC applications in the AS and / or AF towards MTC devices, and vice versa. Since the identification of traffic flows is done through IP-based services (e.g. based on source-destination IP addresses), serving nodes (such as the Session Management Function (SMF) in 5G and the MME in 4G) may not be able to differentiate traffic for multiple applications in the same MTC device. For example, the priority, importance and quality of data delivered to a smart meter device for reading water temperature levels may not require the same treatment as that for reading cleanliness levels.

[0012] An example of IP-based traffic is described as follows: All IP packets from IP address 1.1.1.1 to IP address 2.2.2.2 are identified by the network as "Service X" because network elements understand IP packets by inspecting structured data (also known as IP datagrams), and the source and / or destination IP addresses in the IP packets (e.g., source IP address 2.2.2.2) can identify MTC provider X and gas-level MTC application. This identification is not possible with non-IP data because there are no identifiable headers, such as the IP addresses of the originator and destination of the data being sent and / or received. Therefore, network elements may not be able to identify the type of data being exchanged and how each node should process the exchanged data. Summary of the Invention

[0013] There is no mechanism to ensure QoS for NIDD traffic, as it is delivered from an open function node (e.g., SCEF) to an MTC device via a serving node (e.g., Mobility Management Entity (MME)). In short, the serving node cannot differentiate between NIDD traffic and MTC applications to ensure the correct QoS, required latency, importance of the data to be exchanged, and traffic priority for the type of data being exchanged.

[0014] An object of embodiments herein is to handle communications of NIDD services in a communication network.

[0015] According to a first aspect of the embodiments of the present invention, the purpose is achieved by a method for distinguishing non-IP data delivery (NIDD) services in a communication network, performed by a subscriber's data node. The communication network includes a subscriber's data node, a service node, and an open function node. The subscriber's data node receives a NIDD authorization request including a first identifier from the open function node. The first identifier includes any one of a service capability server identifier, an application server identifier, and an application function identifier. The subscriber's data node generates a non-IP flow description based on the received first identifier. The non-IP flow description includes an application identifier and a non-IP flow identifier for NIDD authorization. The subscriber's data node sends the non-IP flow description to the service node. The subscriber's data node sends a NIDD authorization response including the non-IP flow identifier to the open function node.

[0016] According to a second aspect of the embodiments of this document, the purpose is achieved by a method for distinguishing non-IP data delivery (NIDD) services in a communication network, performed by a service node. The communication network includes a subscriber's data node, a service node, and an open function node. The service node receives a non-IP flow description from the subscriber's data node. The non-IP flow description includes an application identifier and a non-IP flow identifier. The service node associates the application identifier and the non-IP flow identifier as an authorized non-IP flow description. The service node receives a corresponding NIDD submission request with the non-IP data and the non-IP flow identifier from the open function node. The service node determines the application identifier associated with the non-IP flow identifier. The service node applies the non-IP service policy configured for the application identifier to the non-IP data.

[0017] According to a third aspect of the embodiments of the present invention, the object is achieved by a method for distinguishing non-IP data delivery (NIDD) services in a communication network, performed by an open function node. The communication network includes a subscriber's data node, a service node, and an open function node. The open function node receives a NIDD configuration request including a first identifier from an application node. The first identifier includes any one of a service capability server identifier, an application server identifier, and an application function identifier. The open function node sends a NIDD authorization request including the first identifier to the subscriber's data node. The open function node receives a NIDD authorization response including a non-IP flow identifier from the subscriber's data node. The open function node associates the non-IP flow identifier received in the NIDD authorization response with the first identifier sent in the NIDD authorization request. The open function node receives a NIDD submission request including the non-IP data and the first identifier from the application node. The open function node sends a corresponding NIDD submission request including the non-IP data and the non-IP flow identifier associated with the first identifier to the service node.

[0018] According to a fourth aspect of the embodiments of this document, the purpose is achieved by a data node of a subscriber configured to distinguish non-IP data delivery (NIDD) services in a communication network. The communication network is suitable for including a subscriber's data node, a service node, and an open function node. The subscriber's data node is configured to receive a NIDD authorization request including a first identifier from the open function node. The first identifier is suitable for including any one of a service capability server identifier, an application server identifier, and an application function identifier. The subscriber's data node is configured to generate a non-IP flow description based on the received first identifier. The non-IP flow description is suitable for including an application identifier and a non-IP flow identifier for NIDD authorization. The subscriber's data node is configured to send the non-IP flow description to the service node. The subscriber's data node is configured to send a NIDD authorization response including the non-IP flow identifier to the open function node.

[0019] According to a fifth aspect of the embodiments of this document, the purpose is achieved by a service node configured to distinguish non-IP data delivery NIDD services in a communication network. The communication network is suitable for including a subscriber's data node, a service node and an open function node. The service node is configured to receive a non-IP flow description from the subscriber's data node. The non-IP flow description is suitable for including an application identifier and a non-IP flow identifier. The service node is configured to associate the application identifier and the non-IP flow identifier as an authorized non-IP flow description. The service node is configured to receive a corresponding NIDD submission request with non-IP data and a non-IP flow identifier from the open function node. The service node is configured to determine an application identifier associated with the non-IP flow identifier. The service node is configured to apply the non-IP service policy configured for the application identifier to the non-IP data.

[0020] According to a sixth aspect of the embodiments of the present invention, the object is achieved by an open function node configured to distinguish non-IP data delivery (NIDD) services in a communication network. The communication network is adapted to include a subscriber's data node, a service node, and an open function node. The open function node is configured to receive a NIDD configuration request including a first identifier from an application node. The first identifier may include any one of a service capability server identifier, an application server identifier, and an application function identifier. The open function node is configured to send a NIDD authorization request including the first identifier to the subscriber's data node. The open function node is configured to receive a NIDD authorization response including a non-IP flow identifier from the subscriber's data node. The open function node is configured to associate the non-IP flow identifier received in the NIDD authorization response with the first identifier sent in the NIDD authorization request. The open function node is configured to receive a NIDD submission request including the non-IP data and the first identifier from the application node. The open function node is configured to send a corresponding NIDD submission request including the non-IP data and the non-IP flow identifier associated with the first identifier to the service node.

[0021] By generating a non-IP flow description that includes an application identifier and a non-IP flow identifier and allowing association and identification of data for each specific application in the same communication device (e.g., an MTC device), the service node can differentiate services for multiple applications in the same communication device, thereby achieving the purpose of differentiating NIDD services. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Examples of embodiments herein are described in more detail with reference to the accompanying drawings, in which:

[0023] Figure 1 is a schematic block diagram illustrating an embodiment of a communication network.

[0024] Figure 2 is a combined signaling scheme and flow diagram according to some embodiments herein.

[0025] Figure 3 is a flow chart depicting an embodiment of a method in a data node of a subscriber.

[0026] Figure 4 is a flow chart depicting an embodiment of a method in a service node.

[0027] Figure 5 is a flow chart depicting an embodiment of a method in an open function node.

[0028] Figure 6 is a combined signaling scheme and flow diagram according to some embodiments herein.

[0029] Figure 7a and Figure 7b is a combined signaling scheme and flow diagram according to some embodiments herein.

[0030] Figure 8a and Figure 8b is a schematic block diagram illustrating embodiments of a data node of a subscriber.

[0031] Figure 9a and Figure 9b is a schematic block diagram illustrating an embodiment of a service node.

[0032] Figure 10a and Figure 10b is a schematic block diagram illustrating an embodiment of an open function node.

[0033] Figure 11 A telecommunications network is schematically shown connected to a host computer via an intermediary network.

[0034] Figure 12 is a generalized block diagram of a host computer communicating with a user device via a base station over a partially wireless connection; and

[0035] Figures 13 to 16 is a flow chart illustrating a method implemented in a communication system including a host computer, a base station, and a user equipment. DETAILED DESCRIPTION

[0036] The examples of embodiments herein provide a mechanism for handling NIDD traffic in a communication network, specifically a mechanism for distinguishing MTC applications within the same communication device (e.g., MTC devices such as smart meters, sensors for temperature, air pollution, and water levels). NIDD traffic can be distinguished, for example, by QoS, service priority, and / or classification. By identifying the type of traffic, i.e., by identifying the data of each specific application within the same MTC device, a serving node can apply different processing based on priority and QoS.

[0037] This is achieved by introducing the concept of non-IP flow description, which is used to apply different non-IP service processing in the service node.

[0038] Figure 11 is a schematic overview depicting a communication network 100 in which embodiments of the present invention may be implemented. The communication network 100 includes communication devices, such as communication devices 120, such as mobile stations, UEs, non-access point (non-AP) STAs, STAs, wireless devices, and / or wireless terminals. It should be understood by those skilled in the art that "UE" is a non-limiting term that refers to any terminal, wireless communication terminal, user equipment, machine type communication (MTC) device, Internet of Things (IoT) operable device, device-to-device (D2D) terminal, mobile device (e.g., smartphone), laptop, mobile phone, sensor, repeater, mobile tablet, or any device that communicates within a cell or service area.

[0039] Network nodes, such as a subscriber's data node 131 , a service node 132 , an open function node 133 , and application nodes 134 and 135 , operate in the core network.

[0040] The data node 131 of a subscriber may be, for example, an HSS or a UDM. These functions may store a subscriber profile with identification, security keys and information related to services for each subscriber.

[0041] The service node 132 may be, for example, an MME or an SMF. These network functions will establish, modify, and release data sessions between the communication device 120 and an external data network.

[0042] The open function node 133 may be, for example, an open SCEF or NEF that supports capabilities and events.

[0043] The application nodes 134 and 135 may be, for example, MTC applications in an AS, an AF, or an SCC.

[0044] There are network nodes (not those mentioned above) that provide radio coverage over a geographical area through antenna beams. The geographical area can be referred to as a cell, service area, beam, or beam group. In this case, these network nodes can be sending and receiving points, such as radio access network nodes, which are, for example, base stations (e.g., radio base stations, such as NodeB, evolved NodeB (eNB, eNodeB), NR NodeB (gNB)), base transceiver stations, radio remote units, access point base stations, base station routers, transmission devices of radio base stations, independent access points, wireless local area network (WLAN) access points, access point stations (AP STA), access controllers, UEs acting as access points or peers in device-to-device (D2D) communication, or any other network unit capable of communicating with UEs within the cell 11 served by the radio network node 110, depending on, for example, the radio access technology and terminology used.

[0045] The method according to the embodiments herein is performed by a network node, which may be any one of the data node 131 , the service node 132 , and the open function node 133 of the subscriber.

[0046] The communication network 100 may use 5G NR, but may also use many other different technologies, such as Wi-Fi, (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile Communications / Enhanced Data rates for GSM Evolution (GSM / EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), to mention just a few possible implementations.

[0047] The communication network 100 includes one or more CNs 140 and one or more RANs 150. The communication device 120 is connected to the one or more CNs 140 via the one or more RANs 150.

[0048] Alternatively, distributed nodes (DN) and functions (e.g. included in Figure 1 The cloud 130 shown in FIG can be used to perform or partially perform these methods.

[0049] According to an embodiment of the present invention, an example scenario of a mechanism for distinguishing MTC applications in the same communication device 120 is that the MTC application in the application node 134 requests NIDD authorization for a service to the subscriber's data node 131 via the open function node 133. The NIDD authorization includes a first identifier, and the subscriber's data node 131 identifies the service based on, for example, the first identifier and generates an IP flow description. The IP flow description includes an application identifier and a non-IP flow identifier (e.g., a unique flow ID) and is passed to the service node 132 (e.g., an MME). The service can be, for example, requesting, collecting, interpreting, and post-processing data. The application identifier is derived from an identifier of the application node 134 (e.g., an AF, AS, or SCS) via a new configuration in the subscriber's data node 131 (e.g., an HSS or UDM), while the non-IP flow identifier is globally unique over time.

[0050] In the authorization response, the subscriber's data node 131 returns the non-IP flow identifier to the open function node 133. The non-IP flow identifier is sent to the open function node 133, but is not forwarded to the AF so that the open function node 133 includes it in every non-IP data sent by the MTC application. In this way, the service node 132 can identify the flow (i.e., service) and associate it with the application identifier. The application identifier is then mapped to a set of QoS parameters via a new configuration in the service node. Based on the service, the QoS parameters can be priority and / or importance.

[0051] In short, assuming that non-IP data does not contain any structured data for identifying the flow and applying QoS characteristics, the subscriber's data node 131 (e.g., HSS or UDM) generates appropriate structured data using the non-IP flow identifier and application identifier so that the open function node 133 can add this structured data when sending the non-IP data. This is because the open function node stores the relationship between the first identifier and the non-IP flow identifier. Therefore, NIDD services can be associated with specific MTC applications and the most appropriate processing can be applied.

[0052] First, refer to Figure 2 The method for distinguishing NIDD services in the communication network 100 is described in an overview, and will be referred to separately below. Figures 3 to 5 The method will be described one by one from the perspectives of the subscriber's data node 131, the service node 132, and the open function node 133.

[0053] Figure 2 is a combined signaling scheme and flow chart of an example of a method according to some embodiments of the present invention. The method includes, for example, the following steps:

[0054] Step 1. The subscriber's data node 131 receives a NIDD authorization request with a first identifier from the open function node 133. The first identifier includes any one of a service capability server identifier, an application server identifier, and an application function identifier.

[0055] Step 2. The subscriber's data node 131 then generates a non-IP flow description based on the first identifier. The non-IP flow description includes an application identifier and a unique non-IP flow identifier for NIDD authorization.

[0056] Step 3. The subscriber's data node 131 then sends the non-IP flow description including the application identifier and the non-IP flow identifier to the service node 132 .

[0057] Step 4. The service node 132 associates the application identifier with the non-IP flow identifier as an authorized non-IP flow description. This can be achieved by storing the association between the received non-IP flow identifier and the application identifier so that when NIDD data with the non-IP flow identifier is received, the service node can retrieve the associated application identifier stored during the previous NIDD authorization / configuration process.

[0058] Step 5. The subscriber's data node 131 then sends a NIDD authorization response including the non-IP flow identifier to the open function node 133. Only the non-IP flow identifier is sent in the NIDD authorization response without the application identifier because the open function node 133 needs to store the non-IP flow identifier and associate it with the MTC application, that is, with the first identifier that first initiated the NIDD authorization.

[0059] Step 6. The open function node 133 identifies the previously sent NIDD authorization request corresponding to the NIDD authorization response, and associates the non-IP flow identifier received in the NIDD authorization response with the first identifier previously sent in the NIDD authorization request.

[0060] Step 7. The open function node 133 receives the NIDD request including the non-IP data and the first identifier from the application node 134.

[0061] Step 8. The open function node 133 then sends a corresponding NIDD submission request to the service node 132. The corresponding NIDD submission request includes the non-IP data and the non-IP flow identifier previously associated with the first identifier.

[0062] Step 9. Service node 132 determines the application identifier associated with the non-IP flow identifier.

[0063] Step 10. Finally, the service node 132 applies the non-IP service policy configured for the application identifier to the non-IP data.

[0064] These steps are further described in more detail below.

[0065] Now refer to Figure 3 1 and 2. The flowchart depicted in FIG. 1 is used to describe an example embodiment of a method performed by a subscriber's data node 131 for differentiating NIDD traffic in the communication network 100. The subscriber's data node 131, the service node 132, and the open function node 133 operate in the communication network 100.

[0066] The method comprises the following actions, which may be performed in any suitable order.

[0067] Action 300

[0068] The subscriber's data node 131 receives a NIDD authorization request including a first identifier from the open function node 133. The first identifier includes any one of a service capability server identifier, an application server identifier, and an application function identifier. The first identifier will be used later to generate a non-IP flow description.

[0069] Action 301

[0070] The subscriber's data node 131 generates a non-IP flow description based on the received first identifier. The non-IP flow description includes an application identifier and a non-IP flow identifier for NIDD authorization.

[0071] The non-IP flow identifier may be a globally unique identifier in the communication network 100 .

[0072] The application identifier may be derived from the communication provider information. The communication provider information may be, for example, "Company A" as the MTC provider ID and "TV" as the service ID.

[0073] An application identifier may be configured for each first identifier. This may be the case when no communication provider information is received, which means that the open function node 133 needs to derive the provider information based on the identity of the AF after authenticating the AF.

[0074] Action 302

[0075] The subscriber's data node 131 then sends the non-IP flow description to the service node 132 .

[0076] Action 303

[0077] Subscriber's data node 131 sends a NIDD authorization response including a non-IP flow identifier to open function node 133. In the authorization response, subscriber's data node 131 returns the non-IP flow identifier to open function node 133 because subscriber's data node 131 sent the non-IP flow identifier to open function node 133 in the response, but open function node 133 does not forward this information to application node 134 so that open function node 133 includes this information in each non-IP data sent by application node 134. In this way, service node 132 can identify the flow (i.e., the service) and associate it with the application identifier.

[0078] Now refer to Figure 4 An exemplary embodiment of a method for differentiating NIDD traffic in the communication network 100 performed by the service node 132 is described with reference to the flowchart depicted in FIG. The service node 132, the subscriber's data node 131, and the open function node 133 operate in the communication network 100.

[0079] The method comprises the following actions, which may be performed in any suitable order.

[0080] Action 400

[0081] The service node 132 receives a non-IP flow description from the subscriber's data node 131 , wherein the non-IP flow description includes an application identifier and a non-IP flow identifier.

[0082] Action 401

[0083] Service node 132 associates the application identifier with the non-IP flow identifier as a description of the authorized non-IP flow. This association is later required to perform the determination step in action 404. From this point on, authorization is performed on a per-non-IP flow identifier basis, as the application identifier is stored and associated with the non-IP flow identifier, but is no longer signaled, i.e., no longer sent or received. Therefore, if a non-IP flow identifier is received and there is no association with the application identifier, this means that the flow is not allowed, i.e., there is no default QoS policy for unknown non-IP flow identifiers.

[0084] Action 402

[0085] Service node 132 receives a corresponding NIDD submission request with the non-IP data and non-IP flow identifier from open function node 133. The first identifier is known to the subscriber's data node 131 and open function node 133, but is not received by service node 132 because service node 132 does not need to know the first identifier. This is because service node 132 only needs to identify the flow, i.e., the non-IP flow identifier, and then obtain the associated application identifier, which was stored locally after the previous authorization stage.

[0086] Action 403

[0087] The service node 132 determines an application identifier associated with the non-IP flow identifier. The application identifier is determined by using the received non-IP flow identifier to obtain an application identifier previously associated with the non-IP flow identifier.

[0088] Action 404

[0089] The service node 132 applies the non-IP traffic policy configured for the application identifier to the non-IP data.

[0090] Non-IP traffic policies may be configured at service node 132 for each application identifier.

[0091] The non-IP traffic policy may include any of the following: application priority during normal conditions, application priority during congestion, buffer size in the communication device 120, QoS information, time of day at which communications are allowed or blocked, rate limits for uplink non-IP data, and rate limits for downlink non-IP data.

[0092] Now refer to Figure 5 An exemplary embodiment of a method for differentiating NIDD traffic in the communication network 100 performed by the open function node 133 is described with reference to the flowchart depicted in FIG. A subscriber's data node 131 , a service node 132 , and an open function node 133 operate in the communication network 100 .

[0093] The method comprises the following actions, which may be performed in any suitable order.

[0094] Action 500

[0095] The open function node 133 receives the NIDD configuration request including the first identifier from the application node 134 , the first identifier including any one of a service capability server identifier, an application server identifier, and an application function identifier.

[0096] The application node 134 may be a third-party node that does not belong to the communication network 100 .

[0097] Action 501

[0098] The open function node 133 then sends a NIDD authorization request including the first identifier to the subscriber's data node 131. Optionally, MTC provider information may also be sent to the subscriber's data node 131. The MTC provider may be configured as "trusted" in the open function node 133, ensuring that the MTC provider information (if included) is reliable. If the MTC provider information is not included, the subscriber's data node 132 may derive the provider information from the AF, SCS, or AS identifier (i.e., from the first identifier).

[0099] Action 502

[0100] The open function node 133 receives a NIDD authorization response including a non-IP flow identifier from the subscriber's data node 131 .

[0101] In the NIDD authorization response, the subscriber's data node 131 returns the non-IP flow identifier to the open function node 133 so that it is included in every non-IP data sent by the open function node 133. In this way, the service node 132 can identify the service and associate it with the application identifier.

[0102] Action 503

[0103] The open function node 133 thus associates the non-IP flow identifier received in the NIDD authorization response with the first identifier sent in the NIDD authorization request.

[0104] The open function node 133 may send a NIDD configuration response to the application node 134 .

[0105] Action 504

[0106] The open function node 133 receives a NIDD submission request including non-IP data and a first identifier from the application node 134. The NIDD submission request is used to send the non-IP data to the device 120. For example, the data may be an instruction to the device 120, such as "collect water level".

[0107] Action 505

[0108] In order for the service node 132 to determine the application identifier associated with the non-IP flow identifier and apply the non-IP service policy configured for the application identifier to the non-IP data, the open function node 133 sends a corresponding NIDD submission request with the non-IP data and the non-IP flow identifier associated with the first identifier to the service node 132.

[0109] The embodiments of the present invention as mentioned above will now be further described and illustrated.The following text is applicable to and can be combined with any suitable embodiment above.

[0110] An example of a method according to some embodiments is Figure 6 The combined signaling scheme is shown in the flowchart and comprises the following steps:

[0111] Step 1. The application node 134 requests a NIDD configuration, which includes its first identifier, such as an AF, SCS or AS identifier.

[0112] Step 2. The open function node 133 proxies, ie sends, the NIDD authorization request with the first identifier to the subscriber's data node 131 and stores the first identifier so that the first identifier can be retrieved when a response to the NIDD authorization request arrives.

[0113] Steps 3 to 6. The subscriber's data node 131 can generate a non-IP flow description based on the first identifier by assigning a globally unique non-IP flow identifier. In addition, an application identifier is included as part of the non-IP flow description. The application identifier can be mapped from the first identifier via a configuration in the subscriber's data node 131. The non-IP flow description is passed to the service node 132 so that it knows that the provided non-IP flow identifier is authorized (if received from the open function node 133). The application identifier is also stored by the service node 132 so that different QoS policies or priorities can be associated with the non-IP flow via a configuration in the service node 132. Other information (such as the buffer size in the MTC device 120 supporting the service) can also be associated.

[0114] An example of the configuration of the subscriber's data node 131 for the application identifier is shown in the following table:

[0115] First identifier Application Identifier "Company-B AS-1" "Battery"

[0116] Example of non-IP flow description generated by globally unique non-IP flow identifier = 123456:

[0117] Non-IP flow description = 123456, power consumption.

[0118] In cases where the same first identifier manages multiple applications, the application identifier can be derived from the MTC provider information, as described in Note 7 of Chapter 5.13.2 of 3GPP TS 23.682. The subscriber's data node 131 can configurably derive the application identifier, see the table below, or the subscriber's data node 131 can transparently use the MTC provider information directly. This configurable option makes it easier to group and / or map different MTC provider information to the same services requiring the same QoS. Otherwise, if the information is passed transparently, the service node 132 would need to configure as many QoS local policies as there are applications in the network. This can be inefficient in scenarios with thousands or hundreds of applications.

[0119] First identifier MTC Provider Information Application Identifier "Company-C Brand-1" "Company-C" "Battery" "Company-D" "energy" "Battery" "Company-E" (null) "Battery"

[0120] Steps 7-8. The subscriber's data node 131 returns the allocated non-IP flow identifier to each open function node 133 so that they include such information when sending non-IP data from each application to the communication device 120 (eg, the MTC device 120).

[0121] Step 9. The open function node 133 retrieves the first identifier stored in step 2 and binds it to the non-IP flow identifier received in the response of steps 7 to 8. This association (i.e., first identifier <-> non-IP flow identifier) ​​can be stored by the open function node 133 during the life cycle of NIDD configuration and / or authorization. Therefore, for each NIDD data sent by the application node 134, the open function node 133 will be able to retrieve the non-IP flow identifier associated with the first identifier and add the non-IP flow identifier when forwarding the non-IP data to the service node 132.

[0122] Step 10 . The open function node 133 removes the non-IP flow identifier before sending a response to the application node 134 .

[0123] Another example of this method, according to some embodiments, is Figure 7a and Figure 7b The combined signaling scheme is shown in the flow chart and includes the following steps:

[0124] Step 1. The application node 134 sends non-IP data, which includes a first identifier, such as an SCS, AS or AF identifier.

[0125] Step 2 to Step 3. The open function node 133 retrieves the non-IP flow identifier previously bound to the first identifier received from the application node 134, see Figure 6 and include the non-IP flow identifier and the non-IP flow data in the NIDD request.

[0126] Step 4 to Step 5. Then, the service node 132 retrieves the application identifier associated with the received non-IP flow identifier. The application identifier is in Figure 6 This allows service node 132 to apply different NIDD traffic processing by obtaining the relevant configuration, which is stored locally in service node 132 before sending non-IP data. In this example, the buffer size is checked before sending non-IP data.

[0127] Steps 6 to 8. At the same time, another MTC application (eg, application node 135 ) sends non-IP data to the same MTC device 120 .

[0128] Step 9 to step 10. Since the two transmitted non-IP data cannot be delivered simultaneously, the local policy at the service node 132 for the two application identifiers instructs the service node 132 to apply prioritization to the first transmitted application identifier. The non-IP data from the application node 135 is discarded.

[0129] Steps 11 to 15. After completing the non-IP data exchange for the first sent application identifier, the service node 132 notifies the downlink data notification (DDN) failure. The notification includes the non-IP flow identifier so that Figure 6 Based on the association stored in step 9, the open function node 133 can resolve the application identifier to the appropriate application node.

[0130] An example of the NIDD QoS local policy in service node 132 for the first transmitted application identifier is shown in the following table:

[0131]

[0132] In order to perform the above method actions for differentiating NIDD traffic in the communication network 100, the subscriber's data node 131 may include Figure 8a and Figure 8b As described above, the communication network 100 is adapted to include a subscriber's data node 131 , a service node 132 and an open function node 133 .

[0133] The subscriber's data node 131 may comprise an input and output interface 800 configured to communicate, for example, with the service node 132. The input and output interface 800 may comprise a wireless receiver (not shown) and a wireless transmitter (not shown).

[0134] The subscriber's data node 131 is configured to receive, from the open function node 133, for example, through the receiving unit 810 in the subscriber's data node 131, a NIDD authorization request including a first identifier, where the first identifier is applicable to include any one of a service capability server identifier, an application server identifier, and an application function identifier.

[0135] The subscriber's data node 131 is configured to generate a Non-IP flow description based on the received first identifier, eg by a generating unit 820 in the subscriber's data node 131 , wherein the Non-IP flow description is adapted to include an application identifier and a Non-IP flow identifier for NIDD authorization.

[0136] The non-IP flow identifier may be a globally unique identifier in the communication network 100 .

[0137] The application identifier may be derived from the communication provider information.

[0138] An application identifier may be configured for each first identifier.

[0139] The subscriber's data node 131 is configured to send the non-IP flow description to the service node 132 , for example, via a sending unit 830 in the subscriber's data node 131 .

[0140] The subscriber's data node 131 is configured to send a NIDD authorization response including the non-IP flow identifier to the open function node 133 , for example, via the sending unit 830 in the subscriber's data node 131 .

[0141] The embodiments herein may be implemented by a corresponding processor or one or more processors (e.g., Figure 8a The program code may be implemented as a computer program product, for example, in the form of a data carrier carrying the computer program code, which, when loaded into the subscriber's data node 131, is used to execute the embodiments herein. One such carrier may be in the form of a CD ROM disk. However, other data carriers (e.g., a memory stick) are also feasible. The computer program code may also be provided as pure program code on a server and downloaded to the subscriber's data node 131.

[0142] The subscriber's data node 131 may also include a memory 860 comprising one or more storage units for storing data thereon. The memory includes instructions executable by the processor 850. The memory 860 is arranged to store, for example, application data, thresholds, data packets, events, data, configurations, and applications for performing the methods herein when executed in the subscriber's data node 131.

[0143] Those skilled in the art will also understand that the units in the subscriber's data node 131 described above may refer to a combination of analog and digital circuits, and / or one or more processors configured with, for example, software and / or firmware stored in the subscriber's data node 131, the software and / or firmware being executed by the corresponding one or more processors (e.g., the processors described above). One or more of these processors and other digital hardware may be included in a single application-specific integrated circuit (ASIC), or several processors and various digital hardware may be distributed across several independent components, whether individually packaged or assembled into a system-on-chip (SoC).

[0144] In some embodiments, the computer program 890 includes instructions that, when executed by the corresponding at least one processor 850, cause the at least one processor 850 of the subscriber's data node 131 to perform the actions described above.

[0145] In some embodiments, a carrier 895 includes the computer program 890 , where the carrier 895 is one of: an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

[0146] To perform the above-described method actions for differentiating NIDD traffic in the communication network 100, the service node 132 may include Figure 9a and Figure 9b The communication network 100 is adapted to include a data node 131 , a service node 132 and an open function node 133 of a subscriber.

[0147] The service node 132 may include an input and output interface 900 configured to communicate, for example, with the open function node 133. The input and output interface 900 may include a wireless receiver (not shown) and a wireless transmitter (not shown).

[0148] The service node 132 is configured to receive a non-IP flow description from the subscriber's data node 131 , eg via a receiving unit 910 in the service node 132 , wherein the non-IP flow description is adapted to include an application identifier and a non-IP flow identifier.

[0149] The service node 132 is configured to receive a corresponding NIDD submission request with the non-IP data and the non-IP flow identifier from the open function node 133 , for example, via the receiving unit 910 in the service node 132 .

[0150] The service node 132 is configured to associate the application identifier and the non-IP flow identifier as the authorized non-IP flow description, for example, via an association unit 920 in the service node 132 .

[0151] The service node 132 is configured to determine the application identifier associated with the non-IP flow identifier, for example, via a determination unit 930 in the service node 132 .

[0152] The service node 132 is configured to apply the non-IP service policy configured for the application identifier to the non-IP data, for example, through the application unit 940 in the service node 132 .

[0153] Non-IP traffic policies may be configured at service node 132 for each application identifier.

[0154] The non-IP traffic policy may include any of the following: application priority during normal conditions, application priority during congestion, buffer size in the communication device 120, QoS information, time of day at which communications are allowed or blocked, rate limits for uplink non-IP data, and rate limits for downlink non-IP data.

[0155] The embodiments herein may be implemented by a corresponding processor or one or more processors (e.g., Figure 9a The program code may be implemented as a computer program product, for example, in the form of a data carrier carrying the computer program code, which, when loaded into the service node 132, is used to execute the embodiments described herein. One such carrier may be in the form of a CD ROM disk. However, other data carriers (e.g., a memory stick) are also feasible. The computer program code may also be provided as pure program code on a server and downloaded to the service node 132.

[0156] Service node 132 may also include a memory 960 comprising one or more memory units for storing data thereon. The memory includes instructions executable by processor 950. Memory 960 is arranged to store, for example, application data, thresholds, data packets, events, data, configurations, and applications for performing the methods herein when executed in service node 132.

[0157] Those skilled in the art will also understand that the units in the aforementioned service node 132 may refer to a combination of analog and digital circuits, and / or one or more processors configured with, for example, software and / or firmware stored in the service node 132, the software and / or firmware being executed by the corresponding one or more processors (e.g., the aforementioned processors). One or more of these processors and other digital hardware may be included in a single application-specific integrated circuit (ASIC), or several processors and various digital hardware may be distributed across several independent components, whether individually packaged or assembled into a system-on-chip (SoC).

[0158] In some embodiments, computer program 990 includes instructions that, when executed by the corresponding at least one processor 950 , cause at least one processor 950 of service node 132 to perform the actions described above.

[0159] In some embodiments, carrier 995 includes computer program 990 , where carrier 995 is one of: an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

[0160] In order to perform the above method actions for differentiating NIDD services in the communication network 100, the open function node 133 may include Figure 10a and Figure 10b The communication network 100 is adapted to include a data node 131 , a service node 132 and an open function node 133 of a subscriber.

[0161] The open function node 133 may comprise an input and output interface 1000 configured to communicate, for example, with a subscriber's data node 131. The input and output interface 1000 may comprise a wireless receiver (not shown) and a wireless transmitter (not shown).

[0162] The open function node 133 is configured to receive a NIDD configuration request including a first identifier from the application node 134 , for example, via the receiving unit 1010 in the open function node 133 . The first identifier may include any one of a service capability server identifier, an application server identifier, and an application function identifier.

[0163] The open function node 133 is configured to receive a NIDD authorization response including a non-IP flow identifier from the subscriber's data node 131 , for example, via a receiving unit 1010 in the open function node 133 .

[0164] The open function node 133 is configured to receive the NIDD submission request with the non-IP data and the first identifier from the application node 134 , for example, via the receiving unit 1010 in the open function node 133 .

[0165] The application node 134 may be a third-party node that does not belong to the communication network 100 .

[0166] The open function node 133 is configured to send a NIDD authorization request including the first identifier to the data node 131 of the subscriber, for example, via the sending unit 1020 in the open function node 133 .

[0167] The open function node 133 is configured to send a corresponding NIDD submission request with the non-IP data and the non-IP flow identifier associated with the first identifier to the service node 132 , for example, via the sending unit 1020 in the open function node 133 .

[0168] According to some embodiments, the open function node 133 is further configured to send a NIDD configuration response to the application node 134 , for example, via the sending unit 1020 .

[0169] The open function node 133 is configured to associate the non-IP flow identifier received in the NIDD authorization response with the first identifier sent in the NIDD authorization request, for example, via an association unit 1030 in the open function node 133 .

[0170] The embodiments herein may be implemented by a corresponding processor or one or more processors (e.g., Figure 10a The program code may be implemented as a computer program product, for example, in the form of a data carrier carrying the computer program code, which, when loaded into the open function node 133, is used to execute the embodiments herein. One such carrier may be in the form of a CD ROM disk. However, other data carriers (e.g., a memory stick) are also feasible. The computer program code may also be provided as pure program code on a server and downloaded to the open function node 133.

[0171] The open function node 133 may also include a memory 1060 including one or more memory units for storing data thereon. The memory includes instructions executable by the processor 1050. The memory 1060 is arranged to store, for example, application data, thresholds, data packets, events, data, configurations, and applications for performing the methods herein when executed in the open function node 133.

[0172] Those skilled in the art will also understand that the units in the open function node 133 described above may refer to a combination of analog and digital circuits, and / or one or more processors configured with, for example, software and / or firmware stored in the open function node 133, the software and / or firmware being executed by the corresponding one or more processors (e.g., the processors described above). One or more of these processors and other digital hardware may be included in a single application-specific integrated circuit (ASIC), or several processors and various digital hardware may be distributed across several independent components, whether individually packaged or assembled into a system-on-chip (SoC).

[0173] In some embodiments, the computer program 1090 includes instructions that, when executed by the corresponding at least one processor 1050 , cause the at least one processor 1050 of the open function node 133 to perform the actions described above.

[0174] In some embodiments, carrier 1095 includes computer program 1090 , where carrier 1095 is one of: an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

[0175] Other extensions and variations

[0176] Reference Figure 11 According to an embodiment, a communication system includes a telecommunication network 3210, such as the wireless communication network 100 (e.g., a NR network, such as a 3GPP-type cellular network). The telecommunication network 3210 includes an access network 3211 (e.g., a radio access network) and a core network 3214. The access network 3211 includes a plurality of base stations 3212a, 3212b, and 3212c (e.g., radio network nodes 110, access points, AP STAs, NBs, eNBs, gNBs, or other types of wireless access points), each of which defines a corresponding coverage area 3213a, 3213b, and 3213c. Each base station 3212a, 3212b, and 3212c is connectable to the core network 3214 via a wired or wireless connection 3215. A first user equipment (UE) (e.g., wireless device 120, such as non-AP STA 3291) located in the coverage area 3213c is configured to wirelessly connect to or be paged by the corresponding base station 3212c. A second UE 3292 (e.g., the first radio node 110 or the second radio node 120, or a non-AP STA, for example) in the coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. Although multiple UEs 3291 and 3292 are shown in this example, the disclosed embodiments are equally applicable to situations where only one UE is in the coverage area or is connected to the corresponding base station 3212.

[0177] The telecommunications network 3210 itself is connected to a host computer 3230, which can be implemented as hardware and / or software for a standalone server, a cloud-based server, a distributed server, or as processing resources in a server cluster. The host computer 3230 can be owned or controlled by a service provider, or can be operated by or on behalf of the service provider. The connections 3221, 3222 between the telecommunications network 3210 and the host computer 3230 can extend directly from the core network 3214 to the host computer 3230, or can be made via an optional intermediate network 3220. The intermediate network 3220 can be one or a combination of more than one of a public, private, or carrier network; the intermediate network 3220 (if present) can be a backbone network or the Internet; specifically, the intermediate network 3220 can include two or more subnetworks (not shown).

[0178] Figure 11 The communication system as a whole implements a connection between one of the connected UEs 3291, 3292 and a host computer 3230. This connection can be described as an over-the-top (OTT) connection 3250. The host computer 3230 and the connected UEs 3291, 3292 are configured to communicate data and / or signaling via the OTT connection 3250, using the access network 3211, the core network 3214, any intermediate networks 3220, and possibly other infrastructure (not shown) as intermediaries. The OTT connection 3250 can be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of the routing of uplink and downlink communications. For example, the base station 3212 may not be informed, or may not need to be informed, of the past routing of incoming downlink communications containing data originating from the host computer 3230 to be forwarded (e.g., handed over) to the connected UE 3291. Similarly, base station 3212 need not be aware of the future routing of outgoing uplink communications originating from UE 3291 to host computer 3230.

[0179] Now refer to Figure 12To describe an example implementation of the UE, base station, and host computer discussed in the previous paragraphs according to the embodiment. In the communication system 3300, the host computer 3310 includes hardware 3315, and the hardware 3315 includes a communication interface 3316, which is configured to establish and maintain a wired or wireless connection with the interface of different communication devices of the communication system 3300. The host computer 3310 also includes a processing circuit 3318, which may have storage and / or processing capabilities. Specifically, the processing circuit 3318 may include one or more programmable processors, application-specific integrated circuits, field programmable gate arrays, or a combination thereof (not shown) suitable for executing instructions. The host computer 3310 also includes software 3311, which is stored in the host computer 3310 or can be accessed by the host computer 3310 and can be executed by the processing circuit 3318. The software 3311 includes a host application 3312. The host application 3312 is operable to provide services to a remote user, such as a UE 3330, connected via an OTT connection 3350 terminated at the UE 3330 and the host computer 3310. In providing services to the remote user, the host application 3312 may provide user data sent using the OTT connection 3350.

[0180] The communication system 3300 also includes a base station 3320 provided in the telecommunication system, the base station 3320 including hardware 3325 that enables it to communicate with the host computer 3310 and with the UE 3330. The hardware 3325 may include: a communication interface 3326 for establishing and maintaining a wired or wireless connection with the interface of different communication devices of the communication system 3300; and a radio interface 3327 for establishing and maintaining a connection with at least a network located in the coverage area ( Figure 12 The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct, or it may pass through the core network ( Figure 12 (not shown) and / or through one or more intermediate networks external to the telecommunications system. In the illustrated embodiment, the hardware 3325 of base station 3320 also includes processing circuitry 3328, which may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. Base station 3320 also has software 3321 stored internally or accessible via an external connection.

[0181] The communication system 3300 also includes the UE 3330 already mentioned. Its hardware 3335 may include a radio interface 3337 configured to establish and, for this purpose, establish a wireless connection 3370 with a base station serving the coverage area in which the UE 3330 is currently located. The hardware 3335 of the UE 3330 also includes processing circuitry 3338, which may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or a combination thereof (not shown) adapted to execute instructions. The UE 3330 also includes software 3331, which is stored in the UE 3330 or accessible by the UE 3330 and executable by the processing circuitry 3338. The software 3331 includes a client application 3332. The client application 3332 may be operated to provide services to human or non-human users via the UE 3330 under the support of the host computer 3310. In the host computer 3310, a host application 3312 executing therein can communicate with a client application 3332 executing therein via an OTT connection 3350 terminated between the UE 3330 and the host computer 3310. When providing a service to a user, the client application 3332 can receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 can transmit both the request data and the user data. The client application 3332 can interact with the user to generate the user data it provides.

[0182] Notice, Figure 12 The host computer 3310, base station 3320 and UE 3330 shown can be respectively Figure 11 The host computer 3230, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291, 3292 are the same. That is, the internal workings of these entities can be as follows Figure 12 shown, and independently, the surrounding network topology can be Figure 11 network topology.

[0183] exist Figure 12 , an OTT connection 3350 has been abstractly drawn to illustrate communications between a host computer 3310 and a user device 3330 via a base station 3320, without explicitly mentioning any intermediate devices and the precise routing of messages via these devices. The network infrastructure can determine the routing, which can be configured to be hidden from the UE 3330, or hidden from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure can also make decisions to dynamically change the routing (e.g., based on load balancing considerations or network reconfiguration).

[0184] The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improves the performance of OTT services provided to the UE 3330 using the OTT connection 3350, where the wireless connection 3370 forms the last leg of the OTT connection 3350. More specifically, the teachings of these embodiments can improve data rates, latency, and power consumption, thereby providing benefits such as reduced user latency, relaxed file size restrictions, better responsiveness, and extended battery life.

[0185] A measurement process may be provided for the purpose of monitoring data rates, latency, and other factors improved by one or more embodiments. An optional network function may also be provided for reconfiguring the OTT connection 3350 between the host computer 3310 and the UE 3330 in response to changes in measurement results. The measurement process and / or network function for reconfiguring the OTT connection 3350 may be implemented in software 3311 of the host computer 3310, software 3331 of the UE 3330, or both. In an embodiment, a sensor (not shown) may be deployed in or associated with the communication device through which the OTT connection 3350 passes. The sensor may participate in the measurement process by providing values ​​for the monitored quantities exemplified above or other physical quantities that the software 3311, 3331 may use to calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 3350 may include message formats, retransmission settings, preferred routing, and the like. This reconfiguration need not affect the base station 3320 and may be unknown or imperceptible to the base station 3320. Such processes and functions may be known and practiced in the art. In certain embodiments, the measurements may involve proprietary UE signaling that facilitates the host computer 3310 to measure throughput, propagation time, latency, etc. The measurements may be implemented as follows: the software 3311, 3331 enables the use of the OTT connection 3350 to send messages (specifically, empty messages or "dummy" messages) while it monitors propagation time, errors, etc.

[0186] Figure 13 1 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station (eg, an AP STA) and a UE (eg, a non-AP STA), which may be a reference Figure 11 and Figure 12 For the sake of simplicity of this disclosure, only the host computer, base station and UE described in this section will be included. Figure 13In a first act 3410 of the method, a host computer provides user data. In an optional sub-act 3411 of the first act 3410, the host computer provides the user data by executing a host application. In a second act 3420, the host computer initiates a transmission carrying the user data to the UE. In an optional third act 3430, in accordance with the teachings of the embodiments described throughout this disclosure, the base station sends the user data carried in the host computer-initiated transmission to the UE. In an optional fourth act 3440, the UE executes a client application associated with the host application executed by the host computer.

[0187] Figure 14 1 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station (eg, an AP STA) and a UE (eg, a non-AP STA), which may be a reference Figure 11 and Figure 12 For the sake of simplicity of this disclosure, only the host computer, base station and UE described in this section will be included. Figure 14 In a first act 3510 of the method, a host computer provides user data. In an optional sub-act (not shown), the host computer provides the user data by executing a host application. In a second act 3520, the host computer initiates a transmission carrying the user data to the UE. In accordance with the teachings of the embodiments described throughout this disclosure, the transmission may be via a base station. In an optional third act 3530, the UE receives the user data carried in the transmission.

[0188] Figure 15 1 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station (eg, an AP STA) and a UE (eg, a non-AP STA), which may be a reference Figure 11 and Figure 12 For the sake of simplicity of this disclosure, only the host computer, base station and UE described in this section will be included. Figure 15Reference to the figure. In the optional first action 3610 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in the optional second action 3620, the UE provides user data. In the optional sub-action 3621 of the second action 3620, the UE provides the user data by executing a client application. In another optional sub-action 3611 of the first action 3610, the UE executes a client application, which provides the user data in response to the input data received provided by the host computer. When providing the user data, the executed client application may also take into account the user input received from the user. Regardless of the specific manner in which the user data is provided, the UE initiates sending the user data to the host computer in the optional third sub-action 3630. In the fourth action 3640 of the method, in accordance with the teachings of the embodiments described throughout the present disclosure, the host computer receives the user data sent from the UE.

[0189] Figure 16 1 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station (eg, an AP STA) and a UE (eg, a non-AP STA), which may be a reference Figure 11 and Figure 12 For the sake of simplicity of this disclosure, only the host computer, base station and UE described in this section will be included. Figure 16 In an optional first act 3710 of the method, the base station receives user data from the UE in accordance with the teachings of the embodiments described throughout this disclosure. In an optional second act 3720, the base station initiates a transmission of the received user data to the host computer. In a third act 3730, the host computer receives the user data carried in the transmission initiated by the base station.

[0190] When the word "comprise" or "comprising" is used, it should be interpreted as non-limiting, ie meaning "consisting at least of.

[0191] The embodiments herein are not limited to the preferred embodiments described above, and various replacements, modifications, and equivalents may be used.

Claims

1. A method for distinguishing non-IP data delivery (NIDD) services in a communication network (100) performed by a data node (131) of a subscriber, wherein: The communication network (100) comprises a data node (131), a service node (132) and an open function node (133) of the subscriber, and the method comprises: receiving (300) a NIDD authorization request including a first identifier from the open function node (133), the first identifier including any one of a service capability server identifier, an application server identifier, and an application function identifier; generating (301) a non-IP flow description based on the received first identifier, wherein the non-IP flow description comprises an application identifier and a non-IP flow identifier for NIDD authorization; sending (302) the non-IP flow description to the service node (132); and A NIDD authorization response including the non-IP flow identifier is sent (303) to the open function node (133).

2. The method according to claim 1, wherein: The non-IP flow identifier is a globally unique identifier in the communication network.

3. The method according to claim 1, wherein: The application identifier is configured for each first identifier.

4. The method according to claim 1, wherein: The application identifier is derived from the communication provider information.

5. A carrier (895) comprising a computer program (890), wherein: The carrier is a computer-readable storage medium; the computer program (890) comprises instructions which, when executed by a processor (850), cause the processor (850) to perform actions according to any one of claims 1 to 4.

6. A method for distinguishing non-IP data delivery (NIDD) services in a communication network (100) performed by a service node (132), wherein: The communication network (100) comprises a data node (131) of a subscriber, the service node (132) and an open function node (133), and the method comprises: receiving (400) a non-IP flow description from a data node (131) of the subscriber, wherein the non-IP flow description comprises an application identifier and a non-IP flow identifier; Associating (401) the application identifier and the non-IP flow identifier as an authorized non-IP flow description; receiving (402) a corresponding NIDD submission request having non-IP data and a non-IP flow identifier from the open function node (133); determining (403) an application identifier associated with the non-IP flow identifier; and The non-IP traffic policy configured for the application identifier is applied (404) to the non-IP data.

7. The method according to claim 6, wherein: The non-IP service policy is configured at the service node for each application identifier.

8. The method according to claim 6, wherein: The non-IP service policy includes any of the following: application priority during normal conditions, application priority during congestion, buffer size in the communication device, QoS information, time of day for allowing or preventing communication, rate limit for uplink non-IP data, and rate limit for downlink non-IP data.

9. A carrier (995) comprising a computer program (990), wherein: The carrier is a computer-readable storage medium; the computer program (990) comprises instructions which, when executed by a processor (950), cause the processor (950) to perform actions according to any one of claims 6 to 8.

10. A method for distinguishing non-IP data delivery (NIDD) services in a communication network (100) performed by an open function node (133), wherein: The communication network (100) comprises a data node (131) of a subscriber, a service node (132) and the open function node (133), and the method comprises: receiving (500) a NIDD configuration request including a first identifier from an application node (134), the first identifier including any one of a service capability server identifier, an application server identifier, and an application function identifier; sending (501) a NIDD authorization request including the first identifier to a data node (131) of the subscriber; receiving (502) a NIDD authorization response including a non-IP flow identifier from a data node (131) of the subscriber; associating the non-IP flow identifier received in the NIDD authorization response with the first identifier sent in the NIDD authorization request (503); receiving (504) a NIDD submission request having non-IP data and the first identifier from the application node (134); and A corresponding NIDD submission request is sent (505) to the service node (132) with the non-IP data and a non-IP flow identifier associated with the first identifier.

11. The method according to claim 10, wherein: The method also includes sending a NIDD configuration response to the application node (134).

12. The method according to claim 10, wherein: The application node (134) is a third-party node that does not belong to the communication network (100).

13. A carrier (1095) comprising a computer program (1090), wherein: The carrier is a computer-readable storage medium; the computer program (1090) comprises instructions which, when executed by a processor (1050), cause the processor (1050) to perform actions according to any one of claims 10 to 12.

14. A data node (131) of a subscriber, configured to distinguish non-IP data delivery (NIDD) services in a communication network (100), wherein: The communication network (100) is adapted to include a data node (131), a service node (132) and an open function node (133) of the subscriber, and the data node (131) of the subscriber is further configured to: receiving, from the open function node (133), a NIDD authorization request including a first identifier, the first identifier being adapted to include any one of a service capability server identifier, an application server identifier, and an application function identifier; generating a non-IP flow description based on the received first identifier, wherein the non-IP flow description is adapted to include an application identifier and a non-IP flow identifier for NIDD authorization; sending the non-IP flow description to the service node (132); and A NIDD authorization response including the non-IP flow identifier is sent to the open function node (133).

15. The subscriber's data node according to claim 14, further configured to perform the method according to any one of claims 2 to 4.

16. A service node (132) configured to differentiate non-IP data delivery (NIDD) services in a communication network (100), wherein: The communication network (100) is adapted to include a data node (131) of a subscriber, the service node (132) and an open function node (133), the service node (132) being further configured to: receiving a non-IP flow description from a data node (131) of the subscriber, wherein the non-IP flow description is adapted to include an application identifier and a non-IP flow identifier; Associating the application identifier with the non-IP flow identifier as an authorized non-IP flow description; receiving a corresponding NIDD submission request with non-IP data and a non-IP flow identifier from the open function node (133); determining (403) an application identifier associated with the non-IP flow identifier; and The non-IP service policy configured for the application identifier is applied to the non-IP data.

17. The service node according to claim 16, further configured to perform the method according to any one of claims 7 to 8.

18. An open function node (133) configured to distinguish non-IP data delivery (NIDD) services in a communication network (100), wherein: The communication network (100) is adapted to include a data node (131) of a subscriber, a service node (132) and the open function node (133), the open function node (133) being further configured to: receiving, from an application node (134), a NIDD configuration request including a first identifier, the first identifier being adapted to include any one of a service capability server identifier, an application server identifier, and an application function identifier; sending a NIDD authorization request including the first identifier to a data node (131) of the subscriber; receiving a NIDD authorization response including a non-IP flow identifier from a data node (131) of the subscriber; associating the non-IP flow identifier received in the NIDD authorization response with the first identifier sent in the NIDD authorization request; receiving a NIDD submission request having non-IP data and the first identifier from the application node (134); as well as A corresponding NIDD submission request is sent to the service node (132) with the non-IP data and the non-IP flow identifier associated with the first identifier.

19. The open function node according to claim 18, further configured to perform the method according to any one of claims 11 to 12.

Images