Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
CORE NETWORK ROUTING OF APPLICATION DATA
Document Type and Number:
WIPO Patent Application WO/2019/092244
Kind Code:
A1
Abstract:
A method of operating a control-plane mobility node (131, 132) of a network (100) includes receiving a registration request message (2032) of a terminal (101) attempting to register with the network (100) via a base station (112) of the network (100); and determining (3034) a device category of the terminal (101); and in response to said receiving of the registration request message (2032) and depending on the device category: selectively creating context information (650) of a user-plane bearer (320), the user-plane bearer (320) being for routing of application data (304) piggybacked to a control message (301, 301A, 2003, 2005, 2011) passing through the base station (112); and transmitting the context information (650) to at least one end point (112, 121, 138) of the user-plane bearer (320).

Inventors:
NORD, Lars (Arkivgatan 25c, Lund, 223 59, SE)
Application Number:
EP2018/080938
Publication Date:
May 16, 2019
Filing Date:
November 12, 2018
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SONY MOBILE COMMUNICATIONS INC. (4-12-3 Higashi-Shinagawa Shinagawa-ku, Tokyo, 〒140-0002, JP)
SONY MOBILE COMMUNICATIONS AB (Mobilvägen 1, LUND, 221 88, SE)
International Classes:
H04W76/22; H04W76/12
Other References:
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 (Release 15)", 3GPP STANDARD ; TECHNICAL SPECIFICATION ; 3GPP TS 24.301, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. CT WG1, no. V15.0.0, 22 September 2017 (2017-09-22), pages 1 - 496, XP051337183
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements to facilitate communications with packet data networks and applications (Release 13)", 24 September 2016 (2016-09-24), XP051168835, Retrieved from the Internet [retrieved on 20160924]
3GPP TS 23.501, VERSION 1.3.0, September 2017 (2017-09-01)
3GPP TS 23.501 VERSION 1.3.0, September 2017 (2017-09-01)
3GPP TS 38.413 V0.3.0, August 2017 (2017-08-01)
3GPP TS 23.003, VERSION 15.0.0, June 2017 (2017-06-01)
Attorney, Agent or Firm:
BERTSCH, Florian (Kraus & Weisert Patentanwälte PartGmbB, Thomas-Wimmer-Ring 15, München, 80539, DE)
Download PDF:
Claims:
CLAIMS

1 . A method of operating a control-plane mobility node (131 , 132) of a network (100), the method comprising:

- receiving a registration request message (2032) of a terminal (101 ) attempting to register with the network (100) via a base station (1 12) of the network (100),

- determining (3034) a device category of the terminal (101 ),

- in response to said receiving of the registration request message (2032) and depending on the device category: selectively creating context information (650) of a user-plane bearer (320), the user-plane bearer (320) being for routing of application data (304) piggybacked to a control message (301 , 301 A, 2003, 2005, 201 1 ) passing through the base station (1 12), and

- transmitting the context information (650) to at least one end point (1 12, 121 , 138) of the user-plane bearer (320).

2. The method of claim 1 , further comprising:

- in response to said receiving of the registration request message (2032): creating an identifier (655) uniquely allocated to the terminal (101 ).

3. The method of claim 2, further comprising:

- receiving a context request message (2022) from the base station (1 12), the context request message (2022) including the identifier (655),

wherein the context information (650) is transmitted to the base station (1 12) in a context response message (2023) and in response to said receiving of the context request message (2022).

4. The method of claims 2 or 3, further comprising:

- receiving a context request message (2022) from a further base station (1 12) of the network (100) which is different from the base station (1 12), the context request message (2022) from the further base station (1 12) including the identifier (655), and

- setting the further base station (1 12) as an end point (1 12, 121 , 138) of the user-plane bearer (320) and adapting (3023) the context information (650)

accordingly, wherein the context information (650) is transmitted to the further base station (1 12) in a context response message (2023) and in response to said receiving of the context request message (2022) from the further base station (1 12). 5. The method of claims 3 or 4,

wherein the context request message (2022) is triggered by a random access procedure (600) of the terminal (101 ) at the respective one of the base station (1 12) and the further base station (1 12). 6. The method of any one of the preceding claims,

wherein the user-plane bearer (320) is a core-network user-plane bearer

(320),

wherein the terminal (101 ) is registered at the network (100) as operating in a non-connected mode (21 1 ), when said transmitting of the context information (650) to the at least one end point (1 12, 121 , 138) of the user-plane bearer (320) is executed.

7. The method of any one of the preceding claims,

wherein the at least one end point (1 12, 121 , 138) of the user-plane bearer (320) comprises the base station (1 12), and/or

wherein the at least one end point (1 12, 121 , 138) of the user-plane bearer

(320) comprises a user-plane node or a gateway node (121 , 138), the application data (304) being directed to a server of a data network (180) connected to the network (100) via the gateway node (121 , 138). 8. The method of any one of the preceding claims,

wherein the context information (650) comprises at least one of the following: a cryptographic key (651 ); a session identity (652); a tunnel information (653); a tunnel identity (654); and an identifier (655) uniquely allocated to the terminal (101 ). 9. The method of any one of the preceding claims,

wherein the registration request message (2032) includes an indicator indicative of the device category, and/or

wherein the device category is determined based on a database entry associated with the terminal (101 ) at a user repository (137).

10. A method of operating a base station (1 12) of a network (100), comprising:

- receiving a control message (301 , 301 A, 2003, 2005, 201 1 ) from a terminal (101 ), the control message (301 , 301 A, 2003, 2005, 201 1 ) including an identifier (655) uniquely associated with the terminal (101 ),

- based on the identifier (655): establishing context information (650) for a user-plane bearer (320), and

- based on the context information (650): routing application data (304) piggybacked to the control message (301 , 301 A, 2003, 2005, 201 1 ) along the user- plane bearer (320).

1 1 . The method of claim 10, further comprising:

- in response to the terminal (101 ) attempting to register with the network (100) via the base station (1 12): transmitting a registration request message (2032) associated with the terminal (101 ) to a control-plane mobility node (131 , 132) of the network (100),

- receiving the identifier (655) from the control-plane mobility node (131 , 132), and

- transmitting the identifier (655) to the terminal (101 ).

12. The method of claims 10 or 1 1 , further comprising:

- transmitting a context request message (2022) to a control-plane mobility node (131 , 132), the context request message (2022) including the identifier (655) and requesting the context information (650), and

- receiving a context response message (2023) from the mobility node (131 , 132), the context response message (2023) including the context information (650).

13. The method of any one of claims 10 - 12, further comprising:

- receiving the context information (650) from a control-plane mobility node (131 , 132),

- storing the context information (650) in a local memory, and

- in response to said receiving the control message (301 , 301 A, 2003, 2005, 201 1 ): loading the stored context information (650) from the local memory.

14. A control-plane mobility node (131 , 132) comprising control circuitry configured to perform:

- receiving a registration request message (2032) of a terminal (101 ) attempting to register with the network (100) via a base station (1 12) of the network

(100) ,

- determining (3034) a device category of the terminal (101 ),

- in response to said receiving of the registration request message (2032) and depending on the device category: selectively creating context information (650) of a user-plane bearer (320), the user-plane bearer (320) being for routing of application data (304) piggybacked to a control message (301 , 301 A, 2003, 2005, 201 1 ) passing through the base station (1 12), and

- transmitting the context information (650) to at least one end point (1 12, 121 , 138) of the user-plane bearer (320).

15. The control-plane mobility node (131 , 132) of claim 14, wherein the control circuitry is configured to perform the method of any one of claims 1 - 9.

16. A base station (1 12) comprising control circuitry configured to perform:

- receiving a control message (301 , 301 A, 2003, 2005, 201 1 ) from a terminal

(101 ) , the control message (301 , 301 A, 2003, 2005, 201 1 ) including an identifier (655) uniquely associated with the terminal (101 ),

- based on the identifier (655): establishing context information (650) for a user-plane bearer (320), and

- based on the context information (650): routing application data (304) piggybacked to the control message (301 , 301 A, 2003, 2005, 201 1 ) along the user- plane bearer (320).

17. The base station of claim 16, wherein the control circuitry is configured to perform the method of any one of claims 10 - 13.

Description:
Core Network Routing of Application Data

TECHNICAL FIELD Various examples generally relate to techniques of piggybacking application data to a control message which passes through a base station of a network. Various examples specifically relate to routing the application data via a user plane of the network.

BACKGROUND

Mobile communication is an integral part of modern life. Connected devices, e.g., in the Internet of Things (IOT) frameworks are proliferated and the number of terminals (user equipment; UE) connecting to networks is, therefore, expected to increase significantly in the near future.

Respectively, in the Third Generation Partnership Project (3GPP) New Radio (NR) or 5G framework, a new study "5G-IOT" will help to provide a framework to support large number of UEs and their respective requirements, e.g., in terms of latency, quality of service, reliability, power consumption, etc..

A reference implementation involves data delivery of application data via the control plane. The application data may be non-Internet Protocol (IP) data. See 3GPP Technical Specification (TS) 23.682 version 14.0.0 (2016-06): section 4.5.14 "Non-IP Data Delivery". The support of application data via the control plane is part of control plane (CP) optimization (CloT), see 3GPP TS 24.301 version 15.0.0 (2017-09). This technique enables support of efficient transport of data, both of non-IP and IP application data, as well as Short Messages (SMS) over the CP without triggering Data Radio Bearer establishment at the radio access network (RAN). Thus, instead of natively communicating the application data via the user plane (UP), the application data is diverted to the CP by encapsulating the application data in a control signaling messages. Therefore, the application data is forwarded via the CP. This helps to reduce latency and control signaling overhead and reducing power consumption. The application data received from upper layers can be included in an information field "dedicated InfoNAS" for an NB-loT UE, see 3GPP TS 36.331 version 14.0.0 (2016-09), section 5.6.2.3. For routing the application data, it is possible to set up a CP bearer, see 3GPP TS 23.682, Version 14.0.0 (2016-06), section 5.13.1 . Here, a CP mobility node, specifically the Mobile Management Entity (MME) in the 3GPP LTE 4G framework is responsible to set-up and maintain the CP bearer. However, such diverting of application data into the CP has certain restrictions and drawbacks. For example, communicating application data via the CP imposes additional traffic on the CP nodes. From the design, CP nodes may not be well suited for supporting a large amount of application data. This, in turn may cause overload/congestion in the CP nodes increasing the latency and affecting the reliable operation of the network.

SUMMARY

Therefore, a need exists for advanced techniques of communicating application data. In particular, a need exists for communicating application data at low latency, and in an energy-efficient manner, and by avoiding congestion in the CP. Further, backwards compatibility may be desirable.

This need is met by the features of the independent claims. The features of the dependent claims define embodiments.

A method of operating a base station of a network includes receiving a message from a terminal. The message includes data in an information field of the message. The information field is for control signaling between the terminal and a CP mobility node of the network. The method further includes selectively routing the data via a UP node of the network depending on a value of an indicator included in the message.

Thereby, it is possible to tailor routing via the CP or the UP, depending on the content of the information field.

It would be possible that the data is routed along a UP bearer associated with the terminal. End points of the UP bearer may include a base station. Alternatively or additionally, end points of the UP bearer may include the UP node or a gateway node.

The method may further include selectively performing proxy functionality to modify the data if the data is routed via the UP node.

It would be possible that the proxy functionality includes decrypting at least a part of the data using a pre-defined cryptographic key. It would be possible that the proxy functionality includes performing header decompression of a header of an IP packet included in the data.

A computer program product or a computer program includes program code that may be executed by control circuitry of a device. Executing the program code may cause the control circuitry to perform a method of operating a base station of a network, which method includes receiving a message from a terminal. The message includes data in an information field of the message. The information field is for control signaling between the terminal and a CP mobility node of the network. The method further includes selectively routing the data via a UP node of the network depending on a value of an indicator included in the message.

A base station of a network includes control circuitry configured to perform: receiving, from a terminal, a message including data in an information field of the message, the information field being for control signaling between the terminal and a CP mobility node of the network; and depending on a value of an indicator included in the message: selectively routing the data via a UP node of the network.

A method of operating a terminal connectable to a network includes setting a value of an indicator depending on whether data is control data or application data. The method also includes transmitting, to a base station of a network, a message. The message includes the indicator. The method further includes the data in an information field of the message. The information field is for control signaling between the terminal and a CP mobility node of the network. The message may be a control message.

This facilitates situation-aware routing of the control data or application data in the core network.

A further message may be included in the information field, the message and the further message being native to different layers of a transmission protocol stack. The indicator may be included in a header of the further message. The indicator may be a 1 -bit flag.

The data may include an Internet Protocol, IP, packet of application data or may include non-IP application data. The application data may be directed to a server of a data network connected to the network via a gateway node.

It would be possible that the message is part of a random access procedure of the terminal.

It would be possible that the message is communicated using a signaling radio bearer established between the terminal and the base station.

It would be possible that the message is a Radio Resource Control, RRC, control message. Alternatively or additionally, the data may be encapsulated in a Network Access Stratum control message piggybacked to the Radio Resource Control message in the information field.

A computer program product or a computer program includes program code that may be executed by control circuitry of a device. Executing the program code may cause the control circuitry to perform a method of operating a terminal connectable to a network, which method includes setting a value of an indicator depending on whether data is control data or application data. The method also includes transmitting, to a base station of a network, a message. The message includes the indicator. The method further includes the data in an information field of the message. The information field is for control signaling between the terminal and a CP mobility node of the network. A terminal including control circuitry configured to perform: setting a value of an indicator depending on whether data is control data or application data; and transmitting, to a base station of a network, a message including the indicator and further including the data in an information field of the message, the information field being for control signaling between the terminal and a CP mobility node of the network.

A method of operating a node of a core of a network is provided. The node is at least one of a UP node and a gateway node of the network. The method includes receiving application data and performing proxy functionality to modify the application data and forwarding the application data.

This may facilitate core network routing of application data.

A computer program product or a computer program includes program code that may be executed by control circuitry of a device. Executing the program code may cause the control circuitry to perform a method of operating a node of a core of a network. The node is at least one of a UP node and a gateway node of the network. The method includes receiving application data and performing proxy functionality to modify the application data and forwarding the application data. A node of a core of a network is provided. The node is at least one of a UP node and a gateway node of the network. The node includes control circuitry configured to perform: receiving application data; and performing proxy functionality to modify the application data; and forwarding the application data. A method of operating a CP mobility node of a network includes receiving a registration request message of a terminal attempting to register with the network via a base station of the network. The method also includes determining a device category of the terminal. The method further includes, in response to said receiving of the registration request message and depending on the device category: selectively creating context information of a UP bearer. The UP bearer is for routing of application data piggybacked to a control message passing through the base station. The method further includes transmitting the context information to at least one end point of the UP bearer.

This may facilitate core network routing of application data. It may be not required to receive a dedicated service request. This reduces latency of routing the application data. The method may optionally include, in response to said receiving of the registration request message: creating an identifier uniquely allocated to the terminal.

The method may optionally include receiving a context request message from the base station. The context request message may include the identifier. The context information may be transmitted to the base station in a context response message and in response to said receiving of the context request message.

The method may optionally include receiving a context request message from a further base station of the network which is different from the base station, the context request message from the further base station including the identifier. The method may also include setting the further base station as an end point of the UP bearer and adapting the context information accordingly. The context information may be transmitted to the further base station in a context response message and in response to said receiving of the context request message from the further base station.

It would be possible that the context request message is triggered by a random access procedure of the terminal at the respective one of the base station and the further base station. It would be possible that the UP bearer is a core-network UP bearer. The terminal may be registered at the network as operating in a non-connected mode, when said transmitting of the context information to the at least one end point of the UP bearer is executed. It would be possible that the at least one end point of the UP bearer includes the base station. Alternatively or additionally, it would be possible that the at least one end point of the UP bearer includes a UP node or a gateway node. The application data may be directed to a server of a data network connected to the network via the gateway node.

It would be possible that the context information includes at least one of the following: a cryptographic key; a session identity; a tunnel information; a tunnel identity; and an identifier uniquely allocated to the terminal. It would be possible that the registration request message includes an indicator indicative of the device category. Alternatively or additionally, the device category may be determined based on a database entry associated with the terminal at a user repository. A computer program product or a computer program includes program code that may be executed by control circuitry of a device. Executing the program code may cause the control circuitry to perform a method of operating a CP mobility node of a network, the method including receiving a registration request message of a terminal attempting to register with the network via a base station of the network. The method also includes determining a device category of the terminal. The method further includes, in response to said receiving of the registration request message and depending on the device category: selectively creating context information of a UP bearer. The UP bearer is for routing of application data piggybacked to a control message passing through the base station. The method further includes transmitting the context information to at least one end point of the UP bearer.

A CP mobility node including control circuitry is configured to perform: receiving a registration request message of a terminal attempting to register with the network via a base station of the network; and determining a device category of the terminal; and in response to said receiving of the registration request message and depending on the device category: selectively creating context information of a UP bearer, the UP bearer being for routing of application data piggybacked to a control message passing through the base station; and transmitting the context information to at least one end point of the UP bearer. A method of operating a base station of a network includes receiving a control message from a terminal. The control message includes an identifier uniquely associated with the terminal. The method also includes establishing context information for a UP bearer based on the identifier. The method also includes routing application data piggybacked to the control message along the UP bearer and based on the context information.

Thereby, UP routing of data along a UP bearer is facilitated. Specifically, the application data may not be forwarded to the CP even though it is included in a control message.

Establishing the context information may correspond to loading the context information or retrieving the context information from another node or searching the context information or selecting the context information from a plurality of candidates.

The method may further include, in response to the terminal attempting to register with the network via the base station: transmitting a registration request message associated with the terminal to a CP mobility node of the network. The method may also include receiving the identifier from the CP mobility node and transmitting the identifier to the terminal.

For example, the registration request message may be received from the terminal and then forwarded. The method may further include transmitting a context request message to a CP mobility node. The context request message may include the identifier and may request the context information. The method may further include receiving a context response message from the mobility node, the context response message including the context information.

The method may further include receiving the context information from a CP mobility node, storing the context information in a local memory, and in response to said receiving the control message: loading the stored context information from the local memory. A computer program product or a computer program includes program code that may be executed by control circuitry of a device. Executing the program code may cause the control circuitry to perform a method of operating a base station of a network, which method includes receiving a control message from a terminal. The control message includes an identifier uniquely associated with the terminal. The method also includes establishing context information for a UP bearer based on the identifier. The method also includes routing application data piggybacked to the control message along the UP bearer and based on the context information.

A base station including control circuitry configured to perform: receiving a control message from a terminal, the control message including an identifier uniquely associated with the terminal; and based on the identifier: establishing context information for a UP bearer; and based on the context information: routing application data piggybacked to the control message along the UP bearer.

It is to be understood that the features mentioned above and those yet to be explained below may be used not only in the respective combinations indicated, but also in other combinations or in isolation without departing from the scope of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 schematically illustrates the architecture of a network according to various examples.

FIG. 2 schematically illustrates the architecture of the network according to various examples.

FIG. 3 schematically illustrates a transmission protocol stack used at a RAN of the network according to various examples. FIG. 4 schematically illustrations various modes in which a UE connected to the network may be operated according to various examples.

FIG. 5 is a signaling diagram of a random access procedure according to various examples.

FIG. 6A schematically illustrates a control message to which application data may be piggybacked according to various examples. FIG. 6B schematically illustrates a control message to which application data may be piggybacked according to various examples.

FIG. 7 schematically illustrated UP and CP routing of application data according to various examples and further illustrates a UP bearer according to various examples.

FIG. 8 is a signaling diagram schematically illustrating UP routing of application data according to various examples.

FIG. 9 is a signaling diagram schematically illustrating UP routing of application data according to various examples, wherein FIG. 9 further schematically illustrates the various layers of the transmission protocol stack.

FIG. 10 is a signaling diagram schematically illustrating establishing context information for a UP bearer according to various examples.

FIG. 1 1 schematically illustrates the context information according to various examples.

FIG. 12 is a signaling diagram schematically illustrating creating context information for a UP bearer according to various examples.

FIG. 13 schematically illustrates a UE according to various examples.

FIG. 14 schematically illustrates a BS according to various examples. FIG. 15 schematically illustrates a CP mobility node according to various examples. FIG. 16 schematically illustrates a gateway node according to various examples.

FIG. 17 is a flowchart of a method according to various examples. FIG. 18 is a flowchart of a method according to various examples. FIG. 19 is a flowchart of a method according to various examples. FIG. 20 is a flowchart of a method according to various examples. FIG. 21 is a flowchart of a method according to various examples.

DETAILED DESCRIPTION OF EMBODIMENTS In the following, embodiments of the invention will be described in detail with reference to the accompanying drawings. It is to be understood that the following description of embodiments is not to be taken in a limiting sense. The scope of the invention is not intended to be limited by the embodiments described hereinafter or by the drawings, which are taken to be illustrative only.

The drawings are to be regarded as being schematic representations and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose become apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components, or other physical or functional units shown in the drawings or described herein may also be implemented by an indirect connection or coupling. A coupling between components may also be established over a wireless connection. Functional blocks may be implemented in hardware, firmware, software, or a combination thereof. Hereinafter, techniques are described which facilitate communication of application data and control data in a network to which UEs can wirelessly connect. Typically, application data originates from higher layers of a transmission protocol stack. For example, application data may be associated with applications or services implemented by the UE, e.g., executed in a runtime environment of an operating system of the UE or supported by the firmware of the UE in another manner. Typical applications may include: actuator control; sensor readout including measurements of physical observables such as temperature, pressure, brightness, volume, flow, acceleration, velocity, position, etc.; web browsing; graphical user interface (GUI); location-aware services; Internet access; HTTP; etc.. Differently, control data may originate from lower layers of the transmission protocol stack, e.g., from layer 1 , layer 2, or layer 3 of the transmission protocol stack according to the Open Systems Interface (OSI) framework. Such control data may be required to set up and maintain or release a connection between the UE and the network.

The techniques described hereinafter may be applied to, both, uplink (UL) data and downlink (PL) data. UL data is transmitted by the UE and received by the network; while PL data is transmitted by the network and received by the UE. For sake of simplicity, hereinafter, various examples are described with reference to UL data; however, it should be understood that respective techniques may be readily applied for PL data, as well. Pepending on whether UL data or PL date is routed, the routing may take place in different nodes. For example, UL data may be routed in the RAN, specifically a base station (BS) of the RAN; while PL data may be routed by a gateway node.

The techniques described herein may find application in various use cases. For example, the techniques described herein may be employed in connection with IOT devices. IOT devices may be configured to execute IOT applications such as measurement reporting, actuator control, etc.. Typically, application data of IOT devices may be characterized by being limited in size (e.g., each measurement report of an IOT device may not be larger than 500 kB, optionally may not be larger than 50 kB). On the other hand, reliability in the communication of application data of IOT devices is typically required to be high. For example, in application fields such as actuator control and/or sensor readout, it can be decisive that the respective application data is delivered timely and uncorrupted. Specifically, the techniques described herein may find application in a CloT framework. Hence, an example framework that may benefit from the techniques described herein is 3GPP NB-IOT, e.g., in connection with 3GPP 5G. However, the techniques described herein may be readily applied to other communication protocols. One example includes Machine Type Communication (MTC). A further example includes Transmission Control Protocol / Internet Protocol (TCP/IP) which could be used to transport the application data, and still the lower layers could utilize the techniques described herein for delivering/receiving the IP packets.

According to the techniques described herein, it may be possible to reliably communicate application data at low latency and reduced power consumption. According to some examples, the application data may be piggybacked to a control message which, e.g., may be communicated on a wireless link between a BS and a UE. For example, the control message may be a Layer 3 control message, sometimes also referred to as Radio Resource Control (RRC) control message. For example, the control message may be communicated on a control channel implemented on the wireless link between the UE and the BS. For example, the control message may be communicated via a Signaling Radio Bearer (SRB) established between the UE and the BS. With respect to the 3GPP Long Term Evolution (LTE) 4G protocol, details of the RRC layer are described in 3GPP TS 36.331 version 14.0.0.

Generally, Layer 3 according to the OSI model may provide for functionality selected from the group including: establishment of radio bearers; release of radio bearers; reconfiguration of radio bearers; broadcast of system information; mobility procedures including paging and wake up; etc.

Piggybacking application data to a control message may refer to: including the application data in an information field of the control message. For example, the application data may be included in a further control message included in the information field. The information field may or may not be reserved exclusively for the purpose of carrying the application data. For example, the same information field may in some instances be used for carrying control data - such as Layer 3 or Layer 2 control data -; while in other instances of communication of the control message, this information field may be used for carrying the application data. For example, it would be possible that the information field is dedicated to including Non-Access Stratum (NAS) control data and the application data is included in this NAS information field. The control message may be sent on a wireless link via a SRB. The Access Stratum (AS) security might not yet be enabled when sending the control message; to protect the application data the NAS message can be encrypted on NAS layer which is situated above AS. In this example, the information field may include application data which is encrypted, e.g., on NAS-layer level. It would be possible that the NAS control message - beyond the application data - also includes NAS control data, e.g., in the same or a different information field which also includes the application data.. Again, it would be possible that such control data - which is included in the control message beyond the application data - is Layer 3 control data. In some scenarios, multiple instances of the control message may be communicated at different times; for example, a first instance of the control message may include control data in the information field, while a second instance of the control message may include the application data in the information field. Thereby, the control message may be flexible used for conveying application data and control data, depending on the particular circumstances.

According to various examples, techniques are provided for efficiently routing such application data - communicated in a control message via the wireless link between the BS and the UE - in the core network (CN). Specifically, according to the techniques described herein, it is possible that the application data is routed via an UP node of the CN. Hence, even though the application data may be piggybacked to the control message in the RAN when communicating the control message via the wireless link between the BS and the UE, it is possible that the application data is then diverted by not forwarding the application data to the CP of the CN, but by rather routing the application data to the UP of the CN. Switch point functionality may be implemented by a BS or another node; the switch point functionality may route control data included in a first instance of the control message to the CP and may route application data included in a second instance of the control message to the UP. In various examples described herein, a CN UP bearer may be established for routing of application data - while a RAN UP bearer is not established. Thus, the UE is not burdened with the task of establishing and maintaining the RAN UP bearer as an endpoint; at the same time, efficient routing of the application data in the CN is provided for.

Thereby, congestion of CP nodes can be avoided and the separation of the CP from the UP can be enforced in the CN. At the same time, at the RAN, establishment of a UP bearer may not be required; simplifying communication of the application data.

FIG. 1 schematically illustrates a network 100. The example of FIG. 1 illustrates the network 100 according to the 3GPP 5G architecture. Details of the fundamental architecture are described in 3GPP TS 23.501 , version 1 .3.0 (2017-09). While FIG. 1 and further parts of the following description illustrate techniques in the 3GPP 5G framework, similar techniques may be readily applied to different communication protocols. Examples include 3GPP LTE 4G and IEEE Wi-Fi technology.

In the scenario of FIG. 1 , a UE 101 is connectable to the network 100. For example, the UE 101 may be one of the following: a cellular phone; a smart phone; and IOT device; a MTC device; a sensor; an actuator; etc..

The UE 101 is connectable to the network 100 via a RAN 1 1 1 , typically formed by one or more BSs (not illustrated in FIG. 1 ). A wireless link 1 14 is established between the RAN 1 1 1 - specifically between one or more of the BSs of the RAN 1 1 1 - and the UE 101 .

The RAN 1 1 1 is connected to a CN 1 15. The CN 1 15 includes a UP 191 and a CP 192. Application data is typically routed via the UP 191 . For this, there is provided a UP function (UPF) 121 . The UPF 121 may implement router functionality. Application data may pass through one or more UPFs 121 . In the scenario of FIG. 1 , the UPF 121 acts as a gateway towards a data network 180, e.g., the Internet or a Local Area Network. Application data can be communicated between the UE 101 and one or more servers on the data network 180. The network 100 also includes an Access and Mobility Managennent Function (AMF) 131 ; a Session Managennent Function (SMF) 132; a Policy Control Function (PCF) 133; an Application Function (AF) 134; a Network Slice Selection Function (NSSF) 134; an Authentication Server Function (AUSF) 136; and a Unified Data Managennent (UDM) 137. FIG. 1 also illustrates the protocol reference points N1 -N22 between these nodes.

The AMF 131 provides one or more of the following functionalities: registration management; NAS termination; connection management; reachability management; mobility management; access authentication; and access authorization. See 3GPP TS 23.501 version 1 .3.0 (2017-09), section 6.2.1 .

The SMF 132 provides one or more of the following functionalities: session management including session establishment, modify and release, including bearers set up of UP bearers between the RAN 1 1 1 and the UPF 121 ; selection and control of UPFs; configuring of traffic steering; roaming functionality; termination of at least parts of NAS messages; etc..

As such, the AMF 131 and the SMF 132 both implement CP mobility aspects needed to support a moving UE.

FIG. 2 schematically illustrates the network 100 according to FIG. 1 in greater detail and as a service-based architecture. In addition to the CP nodes already illustrated in connection with FIG. 1 , FIG. 2 also illustrates the following CP nodes: the Network Exposure Function (NEF) 138 which provides functionality to expose services and capabilities provided by the network 100 to the further data network 180. For example, non-IP application data can be routed to the data network 180 via the NEF 138.

A further node illustrated in FIG. 2 is the NF Repository Function (NRF) 139.

FIG. 3 illustrates aspects with respect to a transmission protocol stack 250 implemented for control signaling between the UE 101 , a BS 1 12 of the RAN 1 1 1 (labelled gNB in FIG. 3, according to the 3GPP 5G terminology), and the AMF 131 . Specifically, FIG. 3 schematically illustrates a control signaling transmission protocol stack 250.

The transmission protocol stack 250 includes a Layer 1 251 , the so-called physical layer. The transmission protocol stack 250 also includes Layer 2 functionality provided by the Medium Access (MAC) layer 252 and the Radio Link Control (RLC) layer 253. The RLC layer 253 provides for one or more of the following functionalities: error correction using an Automatic Repeat Request (ARQ) protocol, segmentation and reordering of protocol data units , scheduling, etc.. The MAC layer 252 provides for one or more of the following functionalities: control of access to the physical transmission medium, framed the limiting and recognition; etc..

Next, Layer 3 is implemented by the Packet Data Convergence Protocol (PDCP) layer 254 which provides one or more of the following functionalities: transfer of application data and control data; header compression such as robust header compression (RoHC); Access Stratum (AS) level encryption. Layer 3 is also implemented by the Radio Resource Control (RRC) layer 255 which provides for control signaling functionality between the UE 101 and the BS 1 12; also, additional Layer 3 functionalities are implemented by the NAS layer 256 which provides for control signaling functionality between the UE 101 and the AMF 131 .

The RRC layer 255 provides one or more of the following functionalities: bearer establishment and release; paging notification; broadcasting of system information. Likewise, also the NAS layer 256 provides for functionality associated with one or more of the following, with respect to signaling towards the core network: bearer establishment and release; mobility control; identity management. In some scenarios, in order to transparently forward any NAS control data via the BS 1 12, and RRC control message may include an information field which has the purpose of including NAS control data. Then, the BS 1 12 may be configured to route the NAS control data included in the respective information field to the AMF 131 . The BS 1 12 would include and forward the information field in a 3GPP NG Application Protocol (NGAP) message. See 3GPP TS 38.413 VO.3.0 (2017-08). It is possible to communicate control messages of the NAS layer 256 and/or the RRC layer 255 on a SRB. A SRB can be associated with certain UE context information such that communication of RRC and/or NAS control messages can be facilitated with limited control signaling overhead. A SRB is used during the RRC establishment in a random access procedure to established radio access bearers or RAN UP bearers. The SRB may also be used for control signaling while the UE 101 is operated in a connected state in which RAN UP bearers are established; here performing handover or reconfiguration or release of the RAN UP bearers may be handled by the SRB. Not illustrated in FIG. 3 is an application layer (e.g., Layer 7), a presentation layer (e.g., Layer 6), a session layer (e.g., Layer 5), and a transport layer (e.g., Layer 4), all stacked upon Layer 3 implemented by the NAS layer 256 and the RRC layer 255.

In the various examples described herein, Layer 3 control messages may be used for piggybacking application data, e.g., originating from Layer 7. Specifically, RRC layer 255 control messages communicated on the wireless link 1 14 may be used for piggybacking the application data. To facilitate such piggybacking, the application data may in some scenarios be included in a NAS control message native to the NAS layer 256, the NAS control message, in turn, being included in a RRC control message native to the RRC layer 255.

FIG. 4 illustrates aspects with respect to different states in which the UE 101 can be operated. In the deregistered state 201 , the UE 101 is not registered with the network. Here, the AMF 131 may not be aware of any valid locational routing information for the UE 101 so that the UE 101 may not be reachable. Some parts of context information associated with the UE 101 may be stored at the CN 1 15. In order to transition from the deregistered state 201 to the registered state 202, the UE 101 can perform an initial registration procedure. In the registered state 202, the UE 101 is registered with the network 100. The UE 101 can then provide location updates in order to account for mobility. If a certain idle timer lapses or if the UE 101 sends a deregistration request, transition into the deregistered state 201 is possible. FIG. 4 also illustrates aspects with respect to connection states 21 1 , 212. These connection states 21 1 , 212 may be applicable where the UE 101 is operated in the registered state 202. In the idle state 21 1 , the UE may be reachable by AMF-triggered paging in accordance with paging occasions defined by a discontinuous reception cycle (DRX). A RAN UP bearer may not be established on the wireless link 1 14. Via paging and a subsequent random access (RACH) procedure and a RRC connection setup procedure, operation of the UE 101 may transition into the connected state 212. Here, a RAN UP bearer is established between the BS 1 12 and the UE 101 on the wireless link 1 14.

Generally, it is possible that multiple connection states such as the connection states 21 1 , 212 are defined, e.g., connection states for the RAN 1 1 1 and further connection states for the CN 1 15. Sometimes, these states are referred to as ECM connected and disconnected (ECM idle) for the CN state, and RRC connected and disconnected (RRCjdle or RRC inactive) for the RAN state.

In the various examples described herein, it would be possible to transmit and/or receive (communicate) application data while the UE 101 is operated in idle state 21 1 , at least for the RAN 1 1 1 . Here, a UP RAN bearer may not be established on the wireless link 1 14.

FIG. 5 illustrates aspects with respect to the RACH procedure 600 that may be used in order to transition from the idle state 21 1 to the connected state 212, or generally from another state to the connected state 212.

At 3001 , the UE 101 transmits a RACH preamble 2001 . This is sometimes also referred to as RACH message 1 . The preamble may be randomly or at least partly randomly selected from a plurality of candidate preambles. The selected preamble helps to temporarily identify the UE 101 and distinguish the UE 101 from one or more other UEs that attempt connect to the network 100 via the BS 1 12 (contention). The BS 1 12 receives the RACH preamble 2001 and responds with a RACH response message 2002, 3002. The RACH response message 2002 may identify the RACH preamble Next, at 3003, the UE 101 transmits a RRC request message 2003, sometimes also referred to as message 3. This is a RRC control message. The RRC request message

2003 serves the purpose of setting up a RAN UP bearer between the UE 101 and the BS 1 12. The size of message 3 is limited, but still it is possible to piggyback application data to this control message 2003. At this point, operation of the UE 101 has not fully transitioned into the connected state 212 (cf. FIG. 4). The RRC request message 2003 may be already associated with a SRB.

Then, at 3004, the BS 1 12 response with a RRC connection setup message 2004, sometimes also referred to as RACH message 4. The RRC connection setup message

2004 includes configuration information and confirms/acknowledges the request in message 3.

Then at 3005, the UE 101 transmits a RRC connection setup complete control message 2005, sometimes also referred to as message 5. The RRC connection setup compete message confirms that the connection is fully established. At the point, the UE 101 may have transitioned into operation in the connected state 212 (cf. FIG. 4).

It would be possible to piggyback application data to this control message 2005.

FIG. 6A schematically illustrates aspects with respect to a control message 301 that can be used for communicating application data 304 between the UE 101 and the BS 1 12. In the example of FIG. 6A, the control message 301 is a RRC control message, i.e., native to the RRC layer 255 (cf. FIG. 3).

The RRC control message 301 could be implemented, according to some examples, by the RRC request message 2003 of the RACH procedure 600 (cf. FIG. 5). However, in other examples, the RRC control message 301 could be implemented by other messages, e.g., an RRC control message transmitted after block 3004 of FIG. 5 such as the RRC complete control message 2005. For example, the RRC control message 301 could be communicated on a SRB.

The RRC control message 301 includes an information field 303. The information field is associated with NAS control data, i.e., is a NAS information field 303. The NAS information field 303 may include a NAS control message or, generally, any NAS-layer data. Thus, the NAS information field 303 and, optionally, the NAS control message, is piggybacked to the RRC control message 301 . The information field is typically used for encapsulating NAS control data, e.g., as part of a NAS control message. As such, the content of the information field 303 is normally directed to the AMF 131 . However, in the scenario FIG. 6A, the information field 303 is re-used for piggybacking the application data 304 to the RRC control message 301 . The application data 304 does not originate from the NAS layer 256, but from a higher layer. For example, the application data 304 may be included in a NAS control message included in the information field 303 or may otherwise be encapsulated in the information field 303.

The NAS control message may have a NAS-specific header.

Thus, a situation is encountered in which - depending on the particular instance of the RRC control message 301 - either application data or NAS control data is included in the information field 303.

The application data 304 may be IP data, i.e., an IP packet including an IP header which may specify an address of a server of the data network 180. Alternatively, it would be possible that the application data 304 is non-IP data. Generally, the data 304 may be directed to a server of the data network 180.

The RRC control message 301 also includes an indicator 302. For example, the indicator 302 may be included in a header of the RRC control message 301 - and hence at a higher hierarchy if compared to the information field 303 - or may be included as a peer to the information field 303, i.e., at the same hierarchy. For example, the indicator 302 may be included in another information field of the RRC control message 301 , different from the information field 303. In some examples (not illustrated in FIG. 6A), it would even be possible that the indicator 302 is included in the information field 303. Generally, the indicator 302 may be included at a position of the control message 301 which is associated with the RRC layer 255. Then detection of the value of the indicator may be RRC-layer functionality of the RRC layer 255. In the example of FIG. 6A, the indicator 302 is implemented as a one-bit flag. Hence, the value of the indicator 302 may be either "1 "/TRUE or "07FALSE. In other examples, other types of indicators may be used, e.g., multi-bit indicators. Based on the indicator 302, it is possible to distinguish between the information field

303 including NAS control data; and the information field 303 including application data

304 (as illustrated in the scenario FIG. 6A). Therefore, the indicator 302 facilitates routing of the content of the information field 303.

In the example of FIG. 6A a scenario is illustrated in which detection of the value of the indicator may be RRC-layer functionality; this is because the indicator 302 is included in a header of the RRC control message 301 . However, other scenarios are possible. Specifically, it would be possible that the detection of the value of the indicator 302 is NAS layer functionality. Such a scenario is illustrated in connection with FIG. 6B.

FIG. 6B schematically illustrates aspects with respect to a control message 301 A that can be used for communicating application data 304 between the UE 101 and the BS 1 12. In the example of FIG. 6B, the control message 301 A is a RRC control message, i.e., native to the RRC layer 255 (cf. FIG. 3).

Generally, the scenario of FIG. 6B corresponds to the scenario of FIG. 6A. However, in the scenario of FIG. 6B, the indicator 302 is included in the NAS information field 303. Generally, there are various options available for including the indicator 302 in the NAS information field. The particular scenario of FIG. 6B is an example in which the information field 303 includes a NAS control message 370. The NAS control message 370, in turn, includes a header section 371 and a payload section 372. Here, the indicator 302 is included in the header section 371 ; while the application data is included in the payload section 372. It should be appreciated that not all fields in the header section 371 will be NAS-layer encoded - e.g., encrypted - and the indicator 302 may be one of the fields that are not encoded. From FIG. 6B in combination with FIG. 3, it will be appreciated that the control messages 301 A and 370 are native to different layers of the transmission protocol stack 250, i.e., the RRC layer 255 for control message 301 A and the NAS layer 256 for the control message 370.

In scenarios in which the indicator 302 is included in the information field 303, detection of the value of the indicator may be NAS-layer proxy functionality (if compared to the RRC-layer functionality according to the example of FIG. 6A). This has the advantage that lower layers - including RRC layer - may operate according to legacy functionality.

In the various examples described herein, it is possible to flexibly arrange the indicator 302 with the control message 301 , 301 A. Irrespective of the particular position of the indicator 302 within the control message 301 , 301 A, it is possible to route the content of the information field 303 along different paths taking into account the value of the indicator 302. Thereby, switch-point functionality may be implemented based on the value of the indicator 302. Respective techniques are described in FIG. 7.

FIG. 7 schematically illustrates aspects with respect to routing of the content of the information field 303. In the scenario FIG. 7, the content of the information field 303 is routed by the BS 1 12. Hence, the BS 1 12 implements switch-point functionality. When routing the content of the information field 303, the BS 1 12 takes into account the value of the indicator 302 of the RRC control message 301 .

Illustrated in FIG. 7 is a scenario in which the BS 1 12 receives the RRC control message 301 from the UE 101 . In a reference implementation, the BS 1 12 would route the information field 303 including the application data 304 along a path 31 1 (dashed line in FIG. 7). In detail, in such a reference implementation, the BS 1 12 would forward the content as part of the information field 303 to the AMF 131 . The AMF 131 could then decrypt the application data, e.g., could decrypt the information field 303 including the application data based on encryption keys associated with the NAS control signaling. Then, the AMF 131 would identify that the decrypted content of the information field 303 corresponds to application data 304 - and not to NAS control data. Specifically, the AMF 131 may identify that the content of the information field 303 corresponds to non-IP application data; then, the AMF 131 would forward the non-IP application data to the NEF 138 which, in turn, would forward the non-IP application data 304 to the data network 180.

As will be appreciated from FIG. 7, the path 31 1 according to the reference implementation extends through the CP 192. Specifically, the AMF 131 is burdened with the task of proxying the application data 304. This may increase latency and cause congestion at the AMF 131 . Further CP-UP separation is breached to some extent, because the application data passes through the AMF 131 as a CP 191 node. According to techniques described herein, it is possible to route the application data 304 via the UPF 121 ; the AMF 131 is circumvented. This relieves the AMF 131 from the task of proxying the application data 304. According to examples, it is possible to selectively route the data 304 for via the UPF 121 to the NEF 138, depending on the value of the indicator 302. Thus, the value of the indicator 302 may change for different instances of the respective message 301 , 301 A. This is explained in greater detail hereinafter:

For example, if the indicator 302 takes a first value in a first instance of the message 301 , 301 A, this may be indicative of the content of the information field 303 corresponding to NAS control data. Then, the content of the information field 303 - i.e., the NAS control data - may be routed to the AMF 131 for further processing of the NAS control data. This corresponds to routing via the CP. Differently, if the indicator 302 takes a second value in a second instance of the message 301 , 301 A, this may be indicative of the content of the information field 303 corresponding to application data 304. Then, the content of the information field 303 - i.e., the application data - may be routed to the UPF 121 . This corresponds to routing via the UP. Thus, selectively routing the data via the UPF 121 may correspond to: routing or not routing the data via the UPF 121 , depending on the value of the indicator 302. The content of the control message 301 e.g., the information field 303 is selectively routed via the CN CP or the CN UP, depending on the value of the indicator.

Hence, the indicator facilitates situation-aware routing of the data encapsulated in the information field 303. This may be achieved even where the content of the data encapsulated in the information field 303 is not transparent to the BS 1 12 or generally the node executing switch-point functionality, e.g., because it is encrypted or coded. By the situation-aware routing of the data encapsulated in the infornnation field 303, the processing load imposed to the AMF 131 can be lowered. While in the scenario of FIG. 7 the application data 304 is routed through the NEF 138 implementing a gateway node towards the data network 180 for non-IP application data 304, in other scenarios it would be possible that the application data 304 is routed through a UPF 121 implementing the gateway node towards the data network 180 for IP application data. Thus, a further selective routing may be implemented depending on whether the application data is IP data or non-IP data.

Generally, it would be possible that the indicator is indicative of whether the application data is IP application data or non-IP application data. In other scenarios, this information may be obtained from data inspection.

FIG. 7 also illustrates aspects with respect to a CN UP bearer 320. For routing of the application data 304, generally, a UP bearer 320 may be employed. Specifically, a CN UP bearer may be employed: the UE 101 may not be aware of the CN UP bearer 320, because it does not extend to the UE 101 . The UP bearer 320 may be set up by the SMF 132 in response to the RRC request message 2003. A characteristic of the UP bearer 320 is that it encompasses one or more UPFs 121 . An endpoint of the UP bearer 320 is the BS 1 12; a further endpoint of the UP bearer 320 as the NEF 138 - this is because in the illustrated scenario non-IP application data is encapsulated in the information field 303. For IP application data, the UPF 121 could implement the endpoint of the UP bearer 320 instead of the NEF 138.

FIG. 8 is a signaling diagram illustrating aspects with respect to routing data included in the information field 303 of the RRC control message 301 . At 301 1 , a control message 201 1 is transmitted by the UE 101 and received by the BS 1 12. For example, the control message 201 1 may be a RRC control message. The control message 201 1 may be communicated on an SRB. The control message 201 1 may include a UE identity. For example, the control message 201 1 could be the control message 301 according to the example of FIG. 6A or the control message 301 A according to the example of FIG. 6B. The control message 201 1 includes the flag 302 and the information field 303 which encapsulates data. The flag 302 is indicative of whether the information field 303 encapsulates control data or application data, e.g., IP application data or non-IP application data.

In more complex scenarios, an indicator included in the control message 201 1 may be indicative of further details of the application data, e.g., it's type such as IP application data or non-IP application data, QoS level, application service code, priority, size, destination, etc..

Accordingly, the BS 1 12, at 3012, checks the value of the indicator 302 and, depending on the value of the indicator, at 3013 either routes the data in a corresponding message 2012 to the UPF 121 implementing a UP node; or at 3015 routes the data in a corresponding message 2014 to the AMF 131 implementing a CP mobility node.

The UPF 121 provides the data in a corresponding message 2013 to the data network 180. The UPF 121 , in the example of FIG. 8, implements gateway functionality and, hence, acts as a gateway node. Instead of the UPF 121 , another gateway node may be generally used, e.g., the NEF 138.

FIG. 9 illustrates aspects with respect to the logic implemented by the various nodes 101 , 1 12, 121 , 138, 181 to facilitate such situation-aware routing of data encapsulated in a control message discussed with respect to the various FIGs. herein.

FIG. 9 is structured according to the transmission protocol stack 250 discussed in connection with FIG. 3; as such, logic functionality depicted higher (lower) in FIG. 9 corresponds to higher (lower) layers. In the scenario of FIG. 9, an application layer 258 provides, at 706, IP application data or non-IP application data to the RRC layer 255, block 701 . Here, an IP header may be added, e.g., including a 5-tuple with source and destination address. In case of non-IP application data some other way is used to address the destination. This differentiation between IP application data and non-IP application data is made at 705. The application data is queued for transmission via the wireless link 1 14.

The UE 101 implements logic for RoHC 704 of a header of IP packets, if IP application data is provided by the application layer 258. For non-IP application data, RoHC may be omitted. Generally, reformatting of the header may be performed, which reformatting may include the RoHC or other techniques.

In any case, at block 703, encryption of the application data received from the application layer 258 is performed. For example, a NAS security context may be used.

At block 702, the UE 101 is configured to set the value of the indicator 302 depending on the layer from which the data originates. Specifically, in the scenario of FIG. 9, the UE 101 is configured to set the value of the indicator 302 such that it reflects encapsulation of the application data in the RRC control message 301 . Generally, the value of the indicator 302 is set at the UE 101 depending on whether the data is control data for the AMF 131 or application data directed to a server 181 of the data network 180. Further decision criteria can be taken into account, e.g., a type of the data, a quality of service associated with the data, etc.. If NAS control data is communicated by the NAS layer 256, the value of the indicator 302 is set appropriately, as illustrated in FIG. 9. Thus, the value of the indicator 302 is generally selected depending on a type of the data to be included in the control message and/or the layer from which the data originates. In the scenario of FIG. 9, the RRC control message 301 is then communicated using the RRC layer 255. The RRC control message 301 is transmitted by the UE 101 and received by the BS 102. This may involve Layer 1 and Layer 2 support.

At block 712, the BS 1 12 checks the value of the indicator 302, block 712. Depending on the value, the data encapsulated in the information field 303 is either transparently forwarded to the NAS layer 256 in the AMF 131 by forwarding along the N2 reference point to the AMF 131 (cf. FIG. 1 ); or proxy functionality is performed at blocks 713, 714 and the application data 304 is forwarded to UPF via N3. The proxy functionality modifies the data. Various options are available for implementing the proxy functionality. The proxy functionality may include encryption/decryption functionality - in other scenarios it would also be possible that encryption/decryption functionality is separate from the proxy functionality. For decrypting, context information of the UE 101 may be used.

Alternatively or additionally, the proxy functionality may include header compression - in particular, when header compressing was performed at the UE 101 , then, subsequently decompressing the header at the BS 102 at block 714 may be performed.

Once the proxy functionality has been performed, the application data 304 is routed to the UPF 121 and subsequently to the NEF 138 and finally provided to the server 181 in the data network 180. This is along the N3 reference point, T6 reference point, and T8 reference point. T6 and T8 reference points may be used in 3GPP LTE 4G framework which is illustrated as an example in FIG. 9; alternative and modification to T6 and T8 are possible.

While in FIG. 9 a scenarios illustrated where the proxy functionality, at blocks 713 and 714 is implemented and the BS 1 12, in other examples, it would also be possible that the proxy functionality - i.e., header compression and/or encryption - is implemented by the UPF 121 , the NEF 138, or generally a gateway node of the network 100 to the data network 180. In such a scenario, the BS 1 12 may transparently forward, based on the indicator 302, the content of the information field 303 and is relieved of the task of performing the proxy functionality.

While in FIG. 9 a scenario of UL data has been illustrated, in other examples DL data may be communicated. Here, the BS 1 12 or another node may perform the proxy functionality 714, 713 for the DL data and may optionally set the value of the indicator. For example, it would be possible that the UPF 121 or the NEF 138 perform the proxy functionality for DL data received from the data network 180 (not illustrated in FIG. 9).

From FIG. 9 it will be appreciated that there are no or only limited modifications of the functionality of the RRC layer 255, the PDCP layer 254, the RLC layer 253, the MAC layer 252, and the PHY layer 251 at the UE 101 and the BS 1 12. This provides for backwards compatibility. Setting and interpretation of the flag 302 may be the main modification.

While in FIG. 9 a scenario has been illustrated in which detection of the value of the indicator 302 is NAS-layer functionality - e.g., because the indicator 302 is included in a header of a NAS control message included in the information field of the RRC control message -, in other examples it would be possible that detection of the value of the indicator 302 is RRC-layer functionality (cf. FIGs. 6A and 6B). Above, various techniques have been described which facilitate CN routing of application data. As described above, it is possible to employ a CN UP bearer 320 for said routing in the CN. Details with respect to said CN routing are described in connection with FIG. 10. FIG. 10 illustrates aspects with respect to routing application data. FIG. 10 is a signaling diagram. FIG. 10 illustrates aspects in connection with routing the application data using a CN UP bearer.

At 3021 , the message 201 1 is transmitted by the UE 101 and received by the BS 1 12. The message 201 1 includes the indicator 302 and the information field 303. UL application data 304 is encapsulated in the information field 303. For example, the message 201 1 may correspond to the message 301 of FIG. 6A or message 301 A of FIG. 6B. For example, the message 201 1 may be implemented by the RRC request message 2003 or the RRC complete message 2005 of the RACH procedure 600 (cf. FIG. 5).

In the scenario of FIG. 10, the message 201 1 also includes an identifier of the UE 101 . Generally, the identifier of the UE 101 may be provided to the BS 1 12 as part of the message 201 1 or separately from the message 201 1 , e.g., in a separate control message. The identifier is uniquely allocated to the UE 101 ; hence, there are no further UEs in the network 100 having the same identifier. For example, an identifier may be used which, in addition to identifying the UE 101 , also identifies the AMF 131 to which the UE 101 is registered. For example, it would be possible to use the Globally Unique Temporary Identity (GUTI) according to the 3GPP TS 23.003, version 15.0.0 (2017- 06), section 2.8; or a shortened / abbreviated version of the GUTI e.g., S-TMSI. In particular, it may be possible to use a CN identifier, i.e., an identifier which is created by a CN node such as the AMF 131 . For example, a CN identifier may be used that also allows to route control messages of control signaling between the UE 101 and the AMF 131 to the correct AMF 131 . In other examples, it would also be possible to use a RAN identifier, e.g., created by the RAN 1 1 1 .

Then, based on the identifier, the BS 1 12 can establish / find the context information for the CN UP bearer 320. It would be possible that the UP bearer 320 has been previously set up, i.e., is ready-to-use when receiving the control message 201 1 . For employing the UP bearer 320 - which may be uniquely allocated to data originating from or being directed to the UE 101 - the context information may be required. Based on the context information, it is hence possible to route application data 304 piggybacked to the control message 201 1 along the CN UP bearer 320. The application data can be forwarded along CN UP bearer 320 as a standalone packet or included in the Information field/NAS message 303.

The context information for the UP bearer 320 may be reserved for use by the UE 101 . As such, the context information is sometimes referred to as context information of the UE 101 .

In the various scenarios described herein, different options are available for establishing, i.e., finding, this context information to be used in connection with routing the application data 304 along the CN UP bearer 320. In a first option, it would be possible that the context information has been previously received by the BS 1 12, e.g., from the AMF 131 . Then, the BS 1 12 may store the context information on the local memory and may load the context information from the local memory in response to receiving the control message 201 1 . Specifically, the context information may be linked with the identifier uniquely allocated to the UE 101 ; then, by receiving the identifier from the UE 101 at 3021 , it is possible to load the correct context information from the local memory based on the identifier. Hence, establishing the context information may correspond to loading the context information from the local memory. Another option for establishing the context infornnation is illustrated in connection with FIG. 10. This option involves retrieving the context infornnation from the AMF 131 . Specifically, in response to receiving the control message 201 1 , the BS 1 12 transmits a context request message 2022 to the AMF 131 . The context request message 2022 may also be referred to as routing request, because it facilitates routing of the application data. The AMF 131 receives the context request message 2022. The context request message also includes the identifier uniquely allocated to the UE 101 . The AMF 131 may locally store or at least be able to retrieve the context information based on the identifier. In this option, establishing the context information may correspond to communicating the context request message 2022.

Typically, the context information is also associated with the endpoints of the CN UP bearer 320. It would be possible that the BS 1 12 from which the context request 2022 is received at 3022 at the AMF 131 is not registered as an endpoint of the CN UP bearer 320. This may occur, e.g., if UE mobility has occurred between set up of the CN UP bearer 320 and communication of the payload data 304 piggybacked to the control message 201 1 at 3021 . Then, the context request message 2022 is received from a further BS if compared to the BS for which the context information of the CN UP bearer 320 has been previously set up, because the serving BS of the UE 101 has changed. If the BS 1 12 from which the context request 2022 is received at 3022 is not registered as an endpoint of the CN UP bearer 320, the AMF 131 , at 3023, may adapt the context information accordingly. Specifically, the context information may be adapted such that it correctly reflects the up-to-date BS 1 12 is an endpoint of the UP bearer 320. Hence, it would be possible that the BS 1 12 via which the UE 101 attempts to connect is set as an endpoint of the CN UP bearer 320 by adapting the context information accordingly, sometimes referred to as path switch, e.g., of the respective N3 tunnel.

Irrespective of whether the context information has been adapted at 3023 or not, at 3024 the AMF 131 transmits a context response message 2023; hence, the context response message 2023 is transmitted in response to receiving of the context request message 2022. The context response message 2023 is received by the BS 1 12. The context response message 2023 includes the context information. Again, the context information may be associated with the identifier of the UE 101 , such that the BS 1 12, based on knowledge of the identifier, may then link the context information included in the context response message 2023 to the UE 101 . The context response message 2023 may or may not include the identifier uniquely allocated to the UE 101 . Then, at 3025, the application data 304 is transmitted by the BS 1 12 and received by the UPF 121 . The application data 304, at 3025, is transmitted using the context information along the CN UP bearer 320.

In the scenario of FIG. 10, the context request message 2022 is triggered by the control message 201 1 which already includes the application data 304 piggybacked thereto. Generally, the context request message 2022 may be transmitted in response to one or more trigger criteria. For example, generally, the context request message 2022 may be triggered by a RACH procedure 600 of the UE 101 at the BS 1 12. As explained above, it is possible that the control message 201 1 including the application data 304 is, itself, part of the RACH procedure 600.

FIG. 1 1 illustrates aspects with respect to the context information 650. The context information may include one or more of the following: a cryptographic key 651 ; a session identity 652; a tunnel information 653; and a tunnel identity 654.

In the scenario FIG. 1 1 , the context information 650 also includes an identifier 655 of the UE 101 , specifically, the GUTI. In other examples, it would be possible that the identifier of the UE 101 is a separate data structure if compared to the context information 650, but in some manner linked to the context information 650 or associated therewith. In some examples, it would be possible that the context information 650 includes the GUTI in order to reliable identify the correct context information from a plurality of candidate context information 650. Thus, the GUTI may help to load the correct context information. It would be possible that the context information includes one or more further identities for routing data. Such example identities are described, e.g., in 3GPP TS 38.413 VO.3.0 (2017-08), Section 9.3.3. In further examples, it would be possible that the context information is associated with the AMF UE NGAP identity meaning that the UE identity, in message 201 1 , points to the context in the RAN node and the AMF UE NGAP identity in the context information points to the AMF end-point for the particular UE. See 3GPP TS 38.413 VO.3.0 (2017- 08), Section 9. The two above identification options could be referred to as explicit identification and implicit identification. Generally, implicit identification or explicit identification of the UE is possible in connection with the context information 650 and the various examples described herein.

Typically, context information 650 regarding the CN UP bearer 320 is provided to the endpoints of the UP bearer 320, as well as, potentially, at least in parts at intermediate nodes - e.g. the UPF 121 - along the path of the CN UP bearer 320. Creation and provisioning of the context information 650, e.g., at the BS 1 12, at the UPF 121 , and/or the NEF 138, may be performed by the AMF 131 and/or the SMF 132 as CP mobility nodes.

FIG. 12 illustrates aspects with respect to creating and provisioning context information 650 according to various examples. For example, the scenario of FIG. 12 may precede the scenario of FIG. 10.

At 3031 , a registration request 2031 is received by the RAN 1 1 1 from the UE 101 . The registration request message 2031 is for transitioning from the deregistered state 201 to the registered state 202 (cf. FIG. 4).

At 3032, the registration request message 2031 is forwarded by the RAN 1 1 1 to the AMF 131 . Instead of purely forwarding the registration request 2031 , it would also be possible that the RAN 1 1 1 generates the registration request to be transmitted at 3032 to the AMF 131 based on certain information received from the UE 101 .

The AMF 131 can perform certain authorization tasks (not illustrated in FIG. 12) such as checking a subscription. The AMF 131 then transmits a registration accept message 2033 at 3033. This may correspond to transitioning the UE 101 from deregistered state 201 to the registered state 202. For example, at this point and in response to receiving the registration request message 2031 , the AMF 131 may also create the identifier 655 such as the GUTI; this identifier 655 may be included in the registration accept message 2031 . At 3034, the AMF 131 determines a device category of the UE 101 . In the various examples described herein, various options are available for determining the device category of the UE 101 . In one option, the registration request message 2031 may include an indicator indicative of the device category. Then, the device category may be determined based on the registration request message 2031 . In a further option, the device category may be determined based on a database entry associated with the UE 101 at a user repository, such as the UDM 137. For example, an indicator indicative of the device category may be retrieved from the UDM 137 based on an identifier, e.g. a subscription identifier, uniquely allocated to the UE 101 and provided with the registration request 2031 - where, generally, this indicator may be different to the identifier 655 associated with the context information 650.

The device category may be selected from the group including: NB-IOT UE; non-NB- IOT UE; MTC UE; non-MTC UE; etc.. The device category may be associated with certain capabilities of the UE 101 when connecting to the network 100. For example, the device category may be associated with whether the UE is capable of supporting endpoint functionality of a RAN UP bearer which is established on the wireless link 1 14 between the UE 101 and the RAN 1 1 1 . For example, the device category may be associated with whether the UE is capable of piggybacking application data - e.g., encapsulated in an information field for NAS control signaling - to a control message, e.g., a RRC control message. In other words, the device category may be associated with whether the UE is capable of supporting CP optimized CloT functionality.

Then, depending on the device category of the UE, the AMF 131 may or may not proceed with creating context information 650 for the UP bearer 320 which is for routing the application data 304 piggybacked to the control message 301 (in FIG. 12 a scenario is illustrated in which the AMF 131 proceeds with creating the context information 650). Hence, the context information 650 may be selectively created. If not already created prior to 3034, it would also be possible that the identifier 655 uniquely associated with the UE 101 is created at this point; hence, it would be generally possible that the identifier 655 is selectively created, depending on the device category. For example, the identifier 655 could be created if the device category indicates a NB-IOT UE or, generally, if the device category prompts creation of the context information 650. Such conditional creation of the identifier 655 depending on the device category is optional. Specifically, in the example of FIG. 12, at 3034, it is checked whether the device category of the UE 101 corresponds to NB-IOT UE or non-NB-IOT UE. If the device category corresponds to NB-IOT UE, then, at 3035, a PDU session establishment request message 2034 is transmitted by the AMF 131 and received by the SMF 132. The SMF 132 then establishes a PDU session as CN UP bearer 320 and creates context information 650 and transmits the latter to the nodes along the CN UP bearer 320, specifically to the UPF 121 ; in this regard, a session modification request message 2035 is transmitted by the SMF 132 and received by the UPF 121 at 3036; and a session modification response message 2036 is transmitted by the UPF 121 and received by the SMF 132 at 3037. Hence, an N3 tunnel may be created as part of the UP bearer.

The SMF 132 then confirms creation of the context information 650 by transmitting a PDU session response message 2037 to the AMF 131 at 3038. This PDU session response message 2037 includes the context information 650 which was previously also distributed to the UPF 121 using the session modification request message 2035.

At 3039, the AMF 131 then transmits a UE create context request message 2038 to the RAN 1 1 1 and, optionally, to the UE 101 . The configuration update message 2038 includes the identifier 655 which has been previously created by the AMF 131 of the SMF 132, e.g., when creating the context information 650 or separately. It would be possible that the configuration update message 2038 also includes the context information 650, e.g., for locally storing of the context information 650 at the BS 1 12 of the RAN 1 1 1 . In other examples, it would also be possible that the context information 650 is provided to the BS 1 12 in a separate control message, e.g., as described in connection with FIG. 10 above.

The UE 101 may then be operated in idle state 21 1 : there may be no RAN UP bearer established between the UE 101 and the BS 1 12 on the wireless link 1 14. Nonetheless, a CN UP bearer may remain established or in suspended state, i.e., in active state. The BS 1 12 may retain locally the context information; or may fetch it on demand. As will be appreciated from the description of FIGs. 10 - 12, it is possible that the context information 650 is provided to the BS 1 12 for routing of the application data 300 for in the UP at a point in time at which a CN UP bearer is not established on the wireless link 1 14 between the UE 101 and the BS 1 12. Hence, the CN UP bearer 320 may be established on the CN 1 15, but may not extend to the UE 101 via the wireless link 1 14. Hence, it is, in other words, possible that the UE 101 is registered as operating in the idle mode 21 1 or, generally, a non-connected mod, as least as a RAN 1 1 1 state. In the non-connected mode, the UE 101 may not be directly reachable using a UP bearer extending all the way to the UE 101 ; rather, paging of the UE may be required in order to reach the UE 101 . Such techniques have the advantage that it is not required to burden the UE 101 with the task of locally setting up the RAN UP bearer, because establishment of the UP bearer is restricted to the CN 1 15. This helps to reduce power consumption at the UE 101 and reduce signaling overhead on the wireless link 1 14.

FIG. 13 schematically illustrates aspects with respect to the UE 101 . The UE 101 includes control circuitry formed by a processor 8001 and a memory 8003. The UE 101 also includes an interface 8002 for wireless communication. The memory 8003 may be a non-volatile memory. Program code may be stored by the memory 8003. The program code may be loaded by the processor 8001 and may then be executed by the processor 8001 . Executing the program code may cause the processor 8001 to perform techniques as described herein, e.g., with respect to: setting the value of an indicator to be included in a control message, e.g., based on the type of data; transmitting the control message; piggybacking application data to a control message; performing header compression and/or encryption; perform a RACH procedure; transmitting a RRC control message; etc..

FIG. 14 schematically illustrates aspects with respect to the BS 1 12. The BS 1 12 includes control circuitry formed by a processor 801 1 and a memory 8013. The BS 1 12 also includes an interface 8012 for wireless communication and CN communication. The memory 8013 may be a non-volatile memory. Program code may be stored by the memory 8013. The program code may be loaded by the processor 801 1 and may then be executed by the processor 801 1 . Executing the program code may cause the processor 801 1 to perform techniques as described herein, e.g., with respect to: receiving a control message; inspecting an information field of the control message; inspecting an indicator associated with the information field and, specifically, associated with data encapsulated in the information field; depending on a value of the indicator, selectively routing the data via a UP node or a CP node; performing proxy functionality on application data; acting as an endpoint of a CN UP bearer; transmitting a context request to a CP mobility node; routing the data based on context information associated with a UP bearer; establishing context information based on an identifier of a UE; etc.. FIG. 15 schematically illustrates aspects with respect to the AMF 131 and the SMF 132. The AMF 131 and the SMF 132 each implement control-network mobility nodes. Generally, the AMF 131 , as well as the SMF 132 may be configured according to the example of FIG. 15. In some scenarios, it would be possible that the AMF 131 and the SMF 132 are co-located at a common device. The AMF 131 /SMF 132 includes control circuitry formed by a processor 8021 and the memory 8023. The AMF 131/SMF 132 also includes an interface 8022 for CN communication, e.g., on NAS layer. The memory 8023 may be a non-volatile memory. Program code may be stored in the memory 8023. The program code may be loaded by the processor 8021 and may then be executed by the processor 8021 . Executing the program code may cause the processor 8021 to perform techniques as described herein, e.g., with respect to: receiving a registration request of a UE attempting to register with the network; based on device category of the UE; selectively creating context information of a UP bearer, specifically a CN UP bearer; transmitting the context information to a least one endpoint of the UP bearer, e.g., in response to receiving a context request; creating an identifier of the UE; performing a path switch of the UP bearer in response to detecting UE mobility, by setting a new endpoint; terminating NAS control messages; etc..

FIG. 16 schematically illustrates aspects with respect to the UPF 121 and the NEF 138. The UPF 121 and the NEF 138 each implement gateway nodes, because they can forward application data between the network and a further data network. Generally, the UPF 121 , as well as the NEF 138 may be configured according to the example of FIG. 16. In some examples, it would be possible that the UPF 121 and the NEF 138 are co-located at a common device. The UPF 121/NEF 138 includes control circuitry formed by a processor 8031 and a memory 8033. The UPF 121/NEF 138 also includes an interface 8032 for CN communication. The memory 8033 may be a nonvolatile memory. Program code may be stored in the memory 8033. The program code may be loaded by the processor 8031 and may then be executed by the processor 8031 . Executing the program code may cause the processor 8031 to perform techniques as described herein, e.g., with respect to routing data along a UP bearer where the data can be application data that has been communicated on a respective wireless link piggyback to a control message; performing proxy functionality; routing data along a CP UP bearer; etc.. FIG. 17 is a flowchart of a method according to various examples. For example, the method according to the example of FIG. 17 could be performed by control circuitry of the BS 1 12. Optional blocks are marked with dashed lines.

In other examples, it would be possible that the method according to the example of FIG. 17 is performed by a CN node, e.g., a gateway node such as the UPF 121 or the NEF 138. This may, in particular, be applicable where DL data is communicated from an application server in a data network 180 towards a UE 101 .

At block 9001 , a message is received. For example, a control message such as an RRC control message may be received (cf. FIG. 6A). The message may be received on an SRB or as part of a RACH procedure of a UE (cf. FIG. 5). The message may be received on a wireless link. For example, the message may be received on a wireless link 1 14 of a network operating according to the 3GPP 5G protocol (cf. FIGs. 1 and 2). The message may include an information field in which data is encapsulated. The information field may be for control signaling. For example, the message may include a further control message in the information field which further control message, in turn, includes the data in a payload section. Further, the message includes an indicator, e.g., a one-bit flag. The indicator may or may not be part of the information field. It is an option to include the indicator of a header of the further control message included in the information of the message.

At block 9002, the value of the indicators checked. Depending on the outcome of that check - i.e., depending on the value - the method either commences at block 9003 or at block 9004 (also cf. FIG. 8). At block 9003, the data encapsulated and the information field is routed via an UP node, e.g., a UPF in the 3GPP 5G framework. Here, a CN UP bearer may be used. The UP node may or may not implement gateway functionality; one-hop or multi-hop routing in the UP are possible. At block 9004 - which is generally an optional step - , the data encapsulated in the information field is routed to a CP node, e.g., a CP mobility node such as the AMF in the 3GPP 5G framework. Here, a CN CP bearer may be used. Since the indicator value is False the information field is a NAS control message. Instead of routing the data via the CP node at block 9004, other implementations are conceivable for the respective branch of the method flow, e.g., discarding the data, etc..

If block 9003 is executed, it is possible that at optional block 9005 proxy functionality - e.g., encryption, including decrypting, and/or header compression, including decompressing - is performed. Block 9005 may be performed by the BS; or may be performed by another node such as the UP node to which the BS routes the data.

FIG. 18 is a flowchart of a method according to various examples. For example, the method according to the example of FIG. 18 could be performed by control circuitry of the UE 101 . Optional blocks are marked using dashed lines.

At block 901 1 - which is an optional block -, data such as higher-layer data or, specifically, application data which is sometimes also referred to as payload data user data is received. The data may be received in a transmit buffer, e.g., on Layer 3. The data may be queued for transmission on a wireless link.

Next, at block 9012 - which is again an optional block -, proxy functionality is performed on the data. The proxy functionality may include encryption, i.e., encrypting and/decrypting depending on the scenario. Alternatively or additionally, the proxy functionality may include header compression, i.e., compressing and/or decompressing depending on the scenario (cf. FIG. 9).

At block 9013, the value of an indicator is set. The value may be set depending on a type of the data received at block 901 1 . For example, if the type of the data corresponds to control data - e.g., NAS control data or, generally, Layer 3 control data -, then a first value may be selected for the indicator; differently, the type of the data corresponds to application data - which generally originates from a layer above the layer of the control data -, then a second value different from the first value may be selected for the indicator. Thus, generally, the value of the indicator may be set depending on a layer of a transmission protocol stack from which the data received at block 901 1 originates from and/or a type of the data.

At block 9014, a message is transmitted. The message includes an information field which encapsulates the data; also, the message includes the indicator having the value set accordingly at block 9013. The information field may be for control signaling; as such, the message may be referred to as control message. Yet, the information field may not be exclusively reserved for control signaling - rather, it would be possible that the information field is re-used for communication of application data. FIG. 19 is a flowchart of a method according to various examples. For example, the method according to the example of FIG. 19 could be performed by control circuitry of the UPF 121 and/or by control circuitry of the NEF 138. Generally, the method according to the example of FIG. 19 could be performed by a CN node, specifically, by a gateway node.

At block 9021 , data is received. The data may be received from a CN node or a BS. The data may be received using CN signaling. The data may be received on a CN UP bearer. The data may be received from a data network. At block 9022, proxy functionality is performed. The proxy functionality may include header compression and/or encryption. Optionally, the value of an indicator associated with the data may be set.

At block 9023, the data is forwarded, e.g., to another CN node or to a data network.

FIG. 20 is a flowchart of a method according to various examples. For example, the method according to the example of FIG. 20 could be performed by the control circuitry of the BS 1 12. In an alternative scenario, the method according to the example of FIG. 20 could also be executed by a gateway node of the network when receiving DL data from a data network different from the network.

At block 9031 , a control message is received. The control message includes an identifier uniquely allocated to a UE from which the control message is received. For example, the identifier may be a CN identifier. For example, the identifier may be the 3GPP 5G GUTI.

There is also application data piggybacked to the control message. For example, the application data could be encapsulated in an information field which is for control signaling between the UE and a CP mobility node such as an AMF or SMF in the 3GPP 5G framework. The application data could be included in a further control message included in the information field of the control message, e.g., in a payload section of the further control message.

Next, at 9032, context information is established for a UP bearer to be used when routing the application data. Establishing the context information may relate to: searching for the pre-created context information and/or retrieving the pre-created context information. In one example, the context information may be retrieved from a CP mobility node such as an AMF or SMF in the 3GPP 5G framework; to this end, respective context request message may be transmitted to the CP mobility node which triggers a context response message including the context information. An alternative option would be to load the pre-provisioned context information from a local memory. The context information may be associated with the identifier.

Once the context information has been established, at block 9033, the application data is routed using the UP bearer based on the context information. For example, the application data may be routed to a UP node such as the UPF or a gateway node. FIG. 21 is a flowchart of a method according to various examples. For example, the method according to the example of FIG. 21 could be performed by the control circuitry of the AMF 131 and/or the SMF 132. First, at block 9041 , a context information request message is received. The registration request message is transmitted by the BS or another node of a RAN. The registration request message is for registering a UE at the network. Hence, prior to receiving a registration request at block 9041 , the UE may be operated in the deregistered state (cf. FIG. 4).

At block 9042, a device category is determined for the UE. This may be based, at least partly, on information included in the registration request message. It would be possible that determining the device category is, at least partly, based on information retrieved from a data repository of the CN. Specifically, at block 9042, can be checked whether the device category indicates that the UE is capable of piggybacking application data to control messages for communication on the wireless link. This may be the case for the device category NB-IOT UE. Alternatively or additionally, it may be checked whether the UE is capable of terminating a RAN UP bearer.

If the device category corresponds to one or more certain predefined target device categories, then, at 9043, context information for a UP bearer is created (cf. FIG. 1 1 ). For example, in a 3GPP 4G scenario, the UP bearer may be implemented by the Evolved Packet System (EPS) bearer; while in the 3GPP 5G scenario, the UP bearer may be implemented by a PDU session. Otherwise, the context information may not be created. Hence, the context information may be selectively created, depending on the device category. The context information may include data required for routing along the UP bearer, e.g., cryptographic keys, tunnel identifiers, etc.. As will be appreciated from FIG. 21 , the creation of the context information is in response to receiving the registration request, subject to the correct device category. Thus, the context information is generated while - or potentially even prior to - transitioning the UE from deregistered state to registered state (cf. FIG. 4). This is different certain reference implementations where a dedicated service request or RRC resume control message may be required to trigger creation of the context information, after operation of the UE has been transitioned into registered state. Thereby, latency may be reduced and the UE may be relieved from the burden of sending the service request or RRC resume control message; specifically, this may be helpful in scenarios where the UE does not have the capability of terminating a RAN UP bearer. At 9044, the context information is transmitted. For example, the context information could be transmitted to a BS via which the registration request message has been received at block 9041 . Alternatively or additionally, the context information could be transmitted to one or more endpoints of the UP bearer, to thereby configure these endpoints appropriately for routing the data. Alternatively or additionally, the context information could be transmitted to one or more intermediate nodes of the UP bearer.

Summarizing, techniques have been described above which facilitate a clear separation of the CP and the UP. This is achieved by selectively routing data included in an information field piggybacked to a control message via the UP or the CP, e.g., depending on the value of an indicator. These techniques, furthermore, facilitate compatibility with the CloT feature according to 3GPP 4G LTE technology, because changes to the UE-behavior are limited.

The techniques described herein facilitate efficient detection of application data included in an information field for control signaling. The application data may even be detected by a node - e.g., a BS - which may not be able to decrypt the content of the information field, e.g., because it is not in possession of the respective cryptographic keys.

Efficient detection of the application data is achieved, in some scenarios, by using an indicator. The indicator may be transparent to the detecting node. Depending on the value of the indicator, it may be judged whether the content of the information field is control data or application data. This helps to route/steer the data appropriately, e.g., via the UP or via the CP. A 1 -bit flag may be used as indicator. The flag may be used, e.g., by the BS, to detect that this is a special control message and the application data can then be extracted and forwarded over a UP node to the destination address, e.g., a gateway node to a further network - e.g., implemented by a NEF or last UPF that has the N6 connection to the data network.

Routing can be along a UP bearer, e.g., a CN UP bearer. The UP bearer may encompass a UP node such as the UPF in 3GPP 5G NR. In some examples, the setup / establishment of this UP bearer is performed at initial registration of the UE, when transitioning operation of the UE from deregistered state to registered state. There may be no need for a dedicated service request. This reduces latency and control-signaling overhead. The UE must not be In some scenarios proxy functionality is provided. This proxy functionality may be provided by the node that provides for the routing - e.g., the BS or the GW node e.g. the NEF; or may be provided by a different node, e.g., an intermediate note along a UP bearer used for said routing. Although the invention has been shown and described with respect to certain preferred embodiments, equivalents and modifications will occur to others skilled in the art upon the reading and understanding of the specification. The present invention includes all such equivalents and modifications and is limited only by the scope of the appended claims.

For illustration, above various examples have been described in which an RRC control message encapsulates application data in an NAS information field. However, in other examples, other kinds and types of control messages may be used in order to piggyback application data, e.g., Layer 2 or Layer 1 control messages.

For further illustration, various examples have been described above in which the indicator is included in the same message in which the application data or control data is included. In other examples, the indicator may be included in another message that may be associated with the message including the application data or control data.

For further illustration, above various examples have been described in which UL application data is encapsulated in the information field of the UL control message. In other examples, DL application data may be encapsulated in a DL control message. Here, proxy and routing functionality may reside at the GW node - e.g., the NEF or the UPF - instead of at the BS.

For still further illustration, while above various scenarios have been described with respect to non-IP application data, similar techniques may be readily applied to IP application data; here, instead of using a NEF GW node, a UP GW node such as a UPF may provide interfacing to the data network, e.g., using the N6 reference point in the 3GPP 5G NR framework.

For still further illustration, above various scenarios have been described in which non- IP application data is routed to a data network via the CP NEF node. This is an example implementation only; in other examples, it would be possible to use a different GW to the data network for non-IP application data, e.g., a UP UPF.

For still further illustration, above various scenarios have been described in which proxy functionality includes encryption. However, encryption is generally optional. Further, if encryption is used, it may not be part of the proxy functionality.