WO2018072811A1

WO2018072811A1 - Mobile network function chaining

Info

Publication number: WO2018072811A1
Application number: PCT/EP2016/074890
Authority: WO
Inventors: Peter Rost; Cinzia Sartori
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2016-10-17
Filing date: 2016-10-17
Publication date: 2018-04-26

Abstract

It is provided a method, comprising identifying a first function, wherein the first function is requested in a received message received from a radio access network; determining, based on the first function, a first resource for providing the first function; forwarding the request for the first function to the first resource.

Description

DESRIPTION TITLE

Mobile network function chaining Field of the invention

The present invention relates to an apparatus, a method, and a computer program product related to mobile network function chaining. More particularly, the present invention relates to an apparatus, a method, and a computer program product of a mobile core network in which functionality may be flexibly allocated and used.

Abbreviations

3GPP Third Generation Partnership Project

5G 5^th Generation

AAA Authentication, Authorization, Accounting

AP Application Protocol

AS Access Stratum

CN Core Network

CNPE Core Network Processing Entity

C-Plane, CP Control Plane

CS Circuit Switched

DPI Deep Packet Inspection

e2e end-to-end

eDECOR Enhancements of Dedicated Core networks

eNodeB, eNB Evolved Node B

EPC Evolved Packet Core

EPS Evolved Packet System

E-RAB E-UTRAN RAB

ETSI European Telecommunications Standards Institute

E-UTRAN Evolved UMTS Terrestrial Radio Access Network

GTP GPRS Tunnelling Protocol

HSS Home Subscriber Server

IMS IP Multimedia Subsystem ΙοΤ Internet of Things

IP Internet Protocol

IPSec IP Security

LTE Long Term Evolution

LUP Location Update

MBB Mobile Broadband

MDD Multi-Dimensional-Descriptor

Mgmt Management

MM Mobility Management

MME Mobility Management Entity

MNO Mobile network Operator

NAS Non-Access Stratum

NFV Network Function Virtualization

NGMN Next Generaton Mobile Network

NW Network

PCRF Policy and Charging Rules Function

PDN-GW, PGW Packet Data Network Gateway

PDU Packet Data Unit

RAB Radio Access Bearer

RAN Radio Access Network

SA System Architecture

SCTP Stream Control Transmission Protocol

SDL Shared Data Layer

SDN Software Defined Networking

SGW Serving Gateway

SM Session Management

TAU Tracking Area Update

TLS Transport Layer Security

TR Technical Report

UE User Equipment

UDP User Datagram Protocol

U-Plane, UP User Plane

Background of the invention The 3GPP Evolved Packet System (EPS) typically refers to the logical architecture, which is composed by the radio access network (RAN) and the evolved packet core (EPC) as defined in [1 ][2] and illustrated inFig. 1 . As shown in Fig. 1 , the eNBs are connected to the core network via S1 interface. In particular, the eNBs are connected to the control layer of the EPC (represented by MME and HSS) via S1 -MME interface, and to the data layer (represented by S-GW, PDN-GW, and PCRF) via S1 -U interface.

The objective of this logical architecture is to enable a flat IP-based network architecture and provide a standardized set of network elements and network interfaces. Standardized elements and interfaces enable operators to integrate implementations from different vendors into one system and to ensure interoperability between these implementations. The design of a logical architecture satisfies requirements originating from use cases that are expected to be of particular interest for 3GPP LTE.

So far, the aim of 3GPP LTE has been mainly the provisioning of mobile broadband for which the system makes very efficient use of available spectrum. The need to support novel and emerging services, possibly services which are not even introduced yet, may require novel architectural concepts within 3GPP LTE. The static assignment of functionality to network elements as it is currently done in 3GPP LTE and the strong functional dependencies within each network element make it difficult to support the required flexibility of future 3GPP LTE deployments.

Due to the partly conflicting requirements of different use cases or deployments, it is necessary to use the right functionality at the right place and time within the network. In order to provide this flexibility, it has recently been discussed whether the Network Functions Virtualization (NFV) paradigm may be adopted in the mobile access network domain, i.e. mobile network functionality is decomposed into smaller function blocks which are flexibly instantiated.

So far, the degrees of freedom for assigning network functionality to network entities is very limited. In current 3GPP LTE networks, EPC entities may be relocated but the functionality of each entity cannot, i.e. each entity always maintains the same set of functions. Therefore, in order to replace a specific functional behaviour either the entity itself must support this adaptation or the complete entity needs to be replaced. In the case of multiple parallel operating logical networks as it is envisioned by Network Slicing [5], an instantiation of many entities in order to adapt individual functionality is not resource efficient.

A network slice, namely "5G slice", supports t e communication service of a particular connection type with a specific way of handling the C- and U-plane for this service. To this end, a 5G slice is composed of a collection of 5G network functions and specific RAT settings that are combined together for the specific use case or business model. Thus, a 5G slice can span all domains of the network: software modules running on cloud nodes, specific configurations of the transport network supporting flexible location of functions, a dedicated radio configuration or even a specific RAT, as well as configuration of the 5G device. Not all slices have to contain the same functions, and some functions that today seem essential for a mobile network might even be missing in some of the slices. The intention of a 5G slice is to provide only the traffic treatment that is necessary for the use case, and avoid all other unnecessary functionality. The flexibility behind the slice concept is a key enabler to both expand existing businesses and create new businesses. Third-party entities can be given permission to control certain aspects of slicing via a suitable API, in order to provide tailored services.

Fig. 2 shows current 3GPP LTE EPS network entities and interfaces [7]. Control interfaces are shown by dashed lines, while interfaces carrying user data are shown by solid lines. In this application, interfaces S1 -MME, S1 -U and S1 1 are particularly relevant. In general, the S1 interface between RAN (represented by eNodeB) and EPC (represented by MME and SGW facing the RAN, and further network entities such as HSS, PDN-GW, and PCRF) is divided into control and user plane protocols. The control plane protocol, S1 -AP which is also used for S1 -MME, is based on Stream Control Transmission Protocol (SCTP) and the Internet Protocol (IP). A connection between eNodeB and core network is always set up in pairs of streams, i.e. one for upstream and one for downstream. Furthermore, one pair of such streams is reserved for common procedures and there are streams reserved for dedicated procedures, i.e. specific to one user equipment (UE).

The user plane protocol, referred to as S1 -U, is based on GPRS Tunnelling Protocol (GTP), the User Datagram Protocol (UDP), and IP. Each transport connection between eNodeB and core network is identified by GTP tunnel endpoints as well as source/destination IP addresses. Then, an eNodeB sends upstream packets to the EPC IP address which is associated with a particular bearer. It is currently under discussion to separate user and control plane in S-GW and PGW. This allows for complete separation of processing of data messages (u-plane chaining) and control messages in the Core Network. The main advantage is to locate parts differently, e.g., local u- plane processing in order to relieve the transport network load and exploiting local break-out points while c-plane is still processed centrally in order to guarantee an efficient network operation. However, the split in u- and c-plane, as discussed currently in literature and 3GPP, does not cover the split of control plane functionality, i.e., mainly MME functionality, at different locations. In other words: although MM and SM messages can already be differentiated, their processing cannot.

While U-plane service chaining is state of the art, S1 C-Plane chaining is not. Today MM piggybacks SM messages. The two functionalities are not decoupled and MME and S/PGW are always involved.

It is currently discussed in the context of ETSI NFV whether novel interfaces may be introduced which enable a relocation of functionality to different places. However, this would imply the standardization of additional non-3GPP interfaces which requires significant efforts and requires synchronization between 3GPP Working Group SA and the body defining the interface between the additional entities.

In the context of Network Slicing, e.g. NGMN, it is also discussed that core network functionality may be processed at different locations depending on the actual use case. In that case, each slice may use a different implementation processed by a different entity. Current implementations do not allow for efficiently distributing S1 messages belonging to different network slices (and different implementations, even per UE).

References:

[1 ] 3GPP, "TS 36.300; Overall description; Stage 2," Technical specification, 2013

[2] 3GPP, "TS 23.401 ; General Packet Radio Service (GPRS) enhancements for Evolved

Universal Terrestrial Radio Access Network (E-UTRAN) access," Technical specification, 2015

[3] P. Rost, C.J. Bernardos, A. De Domenico, M. Di Girolamo, M. Lalam, A. Maeder, D.

Sabella, and D. Wubben, "Cloud technologies for flexible 5G radio access networks," IEEE Communications Magazine, May 2014 [4] A. de la Oliva, X.C. Perez, A. Azcorra, A. Di Giglio, F. Cavaliere, D. Tiegelbekkers, J.

Lessmann, T. Haustein, A. Mourad, and P. lavanna, "Xhaul: Towards an Integrated

Fronthaul/Backhaul Architecture in 5G Networks," accepted for publication in IEEE

Wireless Communications Magazine, July 2015.

[5] NGMN Alliance, "NGMN 5G White Paper," Technical report, February 2015

[6] S. Sesia, I. Toufik, and M. Baker, "LTE - from theory to praxis," Wiley, 2009

[7] 3GPP 23.401 , General Packet Radio Service (GPRS) enhancements for Evolved

Universal Terrestrial Radio Access Network (E-UTRAN) access, Release 13,

December 2015

Summary of the invention

It is an object of the present invention to improve the prior art.

According to a first aspect of the invention, there is provided an apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor, with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform at least identifying a first function, wherein the first function is requested in a received message received from a radio access network; determining, based on the first function, a first resource for providing the first function; forwarding the request for the first function to the first resource.

The at least one processor, together with the at least one memory, may be further configured to perform checking if a second function in addition to the first function is requested in the received message; determining, based on the second function, a second resource for providing the second function if the second function is requested; forwarding the request for the second function to the second resource after a response to the request for the first function is received.

The at least one processor, together with the at least one memory, may be further configured to perform checking if a third function in addition to the first function is requested in the received message; determining, based on the third function, a third resource for providing the third function if the third function is requested; forwarding the request for the third function to the third resource together with the forwarding of the request for the first function to the first resource. The at least one processor, together with the at least one memory, may be further configured to perform monitoring if the received message comprises an indication that a proprietary function is requested; forwarding the request for the proprietary function to a predetermined resource if the received message comprises the indication.

The at least one processor, together with the at least one memory, may be further configured to perform inquiring an indication of the first resource based on the first function; determining the first resource based on the indication received in response to the inquiry.

The received message may comply with a protocol; and the at least one processor, together with the at least one memory, may be further configured to perform composing a sent message for forwarding the request for the first function, wherein the sent message complies with the protocol; wherein the forwarding of the request for the first function may comprise forwarding the sent message to the first resource.

The protocol may be a protocol of an interface between the radio access network and a core network according to a third generation partnership project.

The first function may be a function of at least one of a mobility management and a session management. The first function may belong to a user plane or a control plane.

The determining may be additionally based on at least one of a user equipment to which the received message is related, a user profile of a user of the user equipment, a destination address comprised in the received message, a type of the received message, a computational load on the apparatus, an available transport capacity, a latency, and a slice.

According to a second aspect of the invention, there is provided a method, comprising identifying a first function, wherein the first function is requested in a received message received from a radio access network; determining, based on the first function, a first resource for providing the first function; forwarding the request for the first function to the first resource.

The method may further comprise checking if a second function in addition to the first function is requested in the received message; determining, based on the second function, a second resource for providing the second function if the second function is requested; forwarding the request for t e second function to the second resource after a response to the request for the first function is received.

The method may further comprise checking if a third function in addition to the first function is requested in the received message; determining, based on the third function, a third resource for providing the third function if the third function is requested; forwarding the request for the third function to the third resource together with the forwarding of the request for the first function to the first resource.

The method may further comprise monitoring if the received message comprises an indication that a proprietary function is requested; forwarding the request for the proprietary function to a predetermined resource if the received message comprises the indication.

The method may further comprise inquiring an indication of the first resource based on the first function; determining the first resource based on the indication received in response to the inquiry.

The received message may comply with a protocol; and the method may further comprise composing a sent message for forwarding the request for the first function, wherein the sent message complies with the protocol; wherein the forwarding of the request for the first function may comprise forwarding the sent message to the first resource.

The determining may be additionally based on at least one of a user equipment to which the received message is related, a user profile of a user of the user equipment, a destination address comprised in the received message, a type of the received message, a computational load on the apparatus performing the method, an available transport capacity, a latency, and a slice.

The method of the second aspect may be a method of network function chaining. According to a third aspect of the invention, there is provided a computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to the second aspect. The computer program product may be embodied as a computer-readable medium or directly loadable into a computer.

According to some embodiments of the invention, at least one of the following advantages may be achieved:

• the solution allows for network function chaining of core network entities;

• the network function chaining may be transparent to RAN;

• the solution may be legacy compliant;

• the solution allows for proprietary enhancements;

• the location of a function may be time dependent, e.g. based on load;

• the solution enables a flexible core network function allocation based on standardized 3GPP interfaces;

• the standardization of additional interfaces or even proprietary solutions is avoided;

• Novel functionality can be easily integrated by one or more additional CNPEs without updating or replacing existing deployments. This also enables future-proof deployments because additional functionality may simply be added as CNPE without impacting existing deployments. Existing core network deployments may be placed behind a new CNPE which is then performing novel/additional functionality such as network slicing while all legacy functionality remains. Messages are forwarded accordingly.

• Latency for NAS processing may be reduced (if necessary).

• The solution simplifies NW slicing as the assignment of the correct CNPE may be done based on the actual NW slice that was selected (within the proxy function of the CNPE).

• Co-located optimization of RAN and CN functionality is enabled.

It is to be understood that any of the above modifications can be applied singly or in combination to the respective aspects to which they refer, unless they are explicitly stated as excluding alternatives.

Brief description of the drawings Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein

Fig. 1 shows a 3GPP LTE architecture;

Fig. 2 shows current 3GPP LTE EPS network entities and interfaces (taken from [6], section 2.1 ) ;

Fig. 3 shows a CNPE according to some embodiments of the invention ;

Fig. 4 shows an architecture according to some embodiments of the invention;

Fig. 5 shows an example of network slicing;

Fig. 6 shows an example of network slicing according to some embodiments of the invention; Fig. 7 shows an apparatus according to an embodiment of the invention;

Fig. 8 shows a method according to an embodiment of the invention; and

Fig. 9 shows an apparatus according to an embodiment of the invention.

Detailed description of certain embodiments

Herein below, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.

Moreover, it is to be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.

The decomposition of the mobile network functionality would imply a stronger decoupling of logical and physical architecture than in 3GPP LTE. In this application, it is focused on the decomposition of core network functionality, in particular C-Plane, and the possibility to flexibly place functionality within the network (in terms of place of execution). The major problems and requirements that may arise from this decomposition of functionality are

- The interface complexity between eNodeB and EPC must preferably not increase, i.e. standard communication protocols with only minor extensions shall be used; - The replacement of functionality or relocation of EPC functionality must be transparent to the eNodeB, i.e. if a specific EPC functionality is executed on a different server then the interface between eNodeB and core network should not be affected;

- Adding or removing functionality from the EPC should not affect the interface between eNodeB and EPC except for the addition/removal of the corresponding messages but addressing and alike must not be affected. In the following, we refer to this interface as the S1 interface which may also cover future redesigns and evolutions.

A main objective of the above requirements is to ensure legacy compliance between eNodeB and core network, as well as a simple interface between eNodeB and core network in order to hide possibly complex processes of network function virtualization within the core network. Furthermore, the number of standardized interfaces within the core network should not increase.

A main benefit of the architecture according to some embodiments of the invention is the possibility to exploit centralization gains where possible, to optimize the network operation to the actual network topology and its structural properties, and to use algorithms optimized for particular use cases, i.e. optimize through dedicated implementations instead of parameters.

Some embodiments of this invention are legacy compliant with existing mobile network interfaces (e.g. S1 in 3GPP LTE) while extending their usage to the scope of function virtualization in mobile core networks.

In the following, it is referred to the S1 -AP and S1 -U protocols. According to some embodiments of the invention, use of messages defined for both protocols [7] is made. MM and SM are decoupled and allocated on different parts/processors, e.g. of an e2e slice. In this way, two services (service 1 and service 2) can use different SM functionality and ciphering keys, each per network slice. This is not allowed today since there is one authorization and authentication only.

Some embodiments of the invention are related to a mobile network comprising a radio access network composed of user equipment and eNodeB, and a core network which is communicating through 3GPP LTE S1 interface with the radio access network. The core network according to some embodiments of the invention is organized such that - Functionality is split up into individual control plane functions and user plane functions, and the set of control plane functions may be processed by multiple core network processing entities (CNPEs), which may or may not be physically co-located. Control plane functions include e.g. session management, mobility management, and policy control. User plane functions include policy enforcement functions and network service functions.

- A proxy function which receives S1 messages and pre-processes them, and distributes them to the responsible S1 message processors providing the requested function(s) within the network. The proxy function may either distribute the pre-processed message to the physical location of the processor, or the actual allocation to a physical resource may be done by NFV. That is, in the latter case, the pre-processed message is distributed to a logical address, and NFV provides the physical address based on the logical address. NFV enables Virtual Network Functions (VNF) to execute on top of standard high-volume servers, switches and storage devices, or cloud computing infrastructure, instead of custom hardware. The handling of messages by the proxy function is applied in particular to the set of c-plane messages, not only to u-plane messages. Hence, the S1 interface may be used not only as an interface between RAN and CN but may be rather used to implement the chaining/distribution of network functions, i.e., S1 may be used for a novel, different purpose.

- Alternatively, the distribution of S1 messages to the individual processors may be done by leveraging on the SDN technology where a separate controller distributes S1 messages to the related Core Network Functions. While NFV decouples the CN Functions from the underlying platform, the interface, e.g. point-to-point message, between those Network Functions can be preserved as is; on the other side, in a SDN- based architecture, the single CN Functions, both standardized such as MM, SM, as well as proprietary ones can be plugged in as applications, through an API based Interface of a 'SDN controller'. This is shown in Fig.6.

Each CNPE may connect to additional CNPEs which perform processing of those S1 messages that are not processed by the CNPE. In some embodiments, S1 messages may even be processed by multiple CNPEs in parallel, in which case a corresponding flag should be set. The communication between CNPEs is done based on the S1 interface such that the number of CNPEs and their location is transparent to CNPEs and UEs. Fig. 3 shows an architecture according to some embodiments of the invention. On the left side, a RAN comprising one or more UEs and one or more eNodeBs is shown. The eNodeB(s) are connected to the proxy function of the core network. That is, towards the RAN, the proxy function provides the S1 interface including S1 -MME and S1 -U.

The proxy function identifies which core function(s) (CP function(s) and/or UP function(s)) is/are requested by a message received from RAN on S1 interface. Depending on the identified function(s) the message, or at least the request for the function is forwarded to the respective function.

More in detail, the proxy function identifies the requested function(s). Then, it checks which resources (CNPE, e.g. identified by their logical addresses) may provide the requested function. If a requested function is provided by only one resource, the message (or a request for the requested function based on the received message) is forwarded to this resource. If plural resources may provide one of the requested functions, the proxy function may take into account one or more further criteria (e.g. a default setting, a load, a latency, a geographical location of the proxy and/or of the resource, etc.) to select one of these resources to forward the received message (or a request for the requested function based on the received message) to.

In some embodiments of the invention, where function chaining is implemented, the proxy function may only identify a first requested function and forward the message (or a request for the requested first function based on the received message) to the respective (first) resource. This (first) resource may provide the first requested function and check if a second function is requested. If yes, the (first) resource may forward the message received by the (first) resource (or a request for the requested second function based on the received message) to the respective (second) resource, etc.. The resources in the chain may not know each other. E.g. the second resource may not know whether it receives the request from another CNPE (the first resource) or directly from an eNodeB. Also, the eNB may not know if the requested functionality is provided fully by the first resource or if the request is forwarded to further resources. Correspondingly, the first resource may not know if the requested functionality is provided fully by the second resource or if the request is forwarded to further resources.

The proxy function, together with the CP function(s) and UP function(s) that can be directly addressed by the proxy function (here, logically directly addressed is sufficient, HW addressing may be performed by NFV), are denoted as a CNPE. A CNPE may be implemented on dedicated hardware, or it may be fully or partly implemented in a cloud.

If a message received from RAN on S1 interface requests a function which is not provided or cannot be provided by a CNPE which received the message (or at least the request for the particular function) such as the CNPE facing the RAN, it may forward the message (or at least the request for the particular function) to another CNPE, wherein the forwarding is done based on a CNPE-I protocol which may largely correspond to the S1 protocol. I.e., in this case, the first CNPE plays a role of a RAN towards a subsequent CNPE.

Fig. 4 shows an example implementation according to some embodiments of the invention, where multiple UEs communicate with two eNBs using LTE-Uu. Fig. 4 is based on Fig. 1 , and shows some adaptations due to the introduction of CNPEs. At the right eNB, a CNPE (CNPE 1 ) is co-located and may perform part of the NAS functionality. An example includes processing of AAA in the case of loT network slices (more examples and applications are detailed later). The co-located CNPE 1 is communicating with other CNPEs such as CNPE 2 and CNPE 3 using the interface CNPE-I. The CNPE 2 and CNPE 3 may perform part of the processing which is not performed at CNPE 1 and possibly all of the processing from other eNB(s).

An example for such a setup is that a CNPE may be co-located with a small-cell in order to lower the signalling traffic while all remaining processing is performed at a CNPE co-located with a nearby macro-base-station or in a metro site at regional level, where traffic of different access nodes is aggregated and concentrated. The interface CNPE-I may carry messages of the interfaces S1 and S1 1 (between MME and SGW, see Fig. 1 ) such that core-network processing may be distributed. E.g. part of the processing would be done at a base-station, part at the edge-cloud (at metro site level), and part at central offices. Since all exchanged messages use standard 3GPP interfaces, no additional standardization overhead is necessary. Examples for these message are e.g. Handover Preparation, Handover Resource, Allocation, Handover Notification, Path Switch, Request, Handover Cancellation, E-RAB Setup, ERAB Modify, E-RAB Release, RAB Release, Indication, Initial Context Setup, or Paging.

Once a CNPE receives a NAS messages from a UE, the message is decoded. Based on the UE, destination IP, and message type, the message is then either processed at the CNPE itself or forwarded to a responsible CNPE ("proxy functionality" inherent to a CNPE). The correct CNPE may also be chosen according to a given network slice. Network slicing is currently discussed in 3GPP for the 5G Network Architecture (SA2 and RAN groups). In a UE assisted method, envisaged by eDECOR in LTE as well as its evolution in 5G (e.g. based on MDD=Multi-Dimensional-Descriptor, see 3GPP TR 23.799), the network contains a 'Network Selection Function', both in RAN and in CN (the latter applies to 5G only and not to LTE according to current standards) for routing messages according to services the UE requires (based on e.g. MDD). The actual location where the message is processed is transparent to the UE and may also be transparent to other CNPEs, which allows for including CNPEs of third parties implementing specific functionality (possibly within one network slice) without revealing the network structure. The included CNPE of a third party may even implement only parts of the core network functionality or even only parts of the functionality of an individual core network entity, e.g. Mobility Management Entity (MME). An example includes the implementation of a specific session management algorithm for loT while all remaining functionality is implemented by a "default slice".

The location where NAS messages are processed may change over time and depending on the current computational load, available transport network capacity, or available latency on the transport network. For example, if the latency on the transport network increases, according to some embodiments of the invention functionality may be moved to a CNPE closer to the eNB. The change of CNPE location is transparent to RAN (UE(s) and eNodeB(s)).

In some embodiments of the invention, a single NAS message may be processed by multiple CNPEs, i.e. after processing a NAS message, the same message may be relayed to a second CNPE. An example for such a use case is full redundancy in high-robustness/reliability use cases, such as smart factories, where in the case of failure of the first CNPE, the second CNPE could take over the processing of the first CNPE. Furthermore, a NAS message may only be partly processed (or only a subset of its parameters) by the first CNPE.

Overall, according to some embodiments of the invention, the logical definition of an MME or of any individual 3GPP interfaces does not change but only the message-dependent processing. Hence, additional interface definitions within the core network due to changes of 3GPP interfaces may not be required and additional core network functionality may even be implemented in a separate CNPE which is then added to the core network. This allows for implementing proprietary NAS messages which are indicated as such and may then be forwarded to a responsible CNPE (e.g. using a S1 container for such messages). An example includes the implementation of specific NAS signalling for non-typical use cases such as Industrial loT (one example may be additional maintenance reporting or usage information). In this case, machine manufacturers may introduce additional essential NAS signalling which is then carried by S1 interface and forwarded by the CNPE to a responsible CNPE of machine manufacturer, which could even be closed source (e.g. exchange of sensor signalling). This would require the definition and use of one or more default S1 messages which would be ignored by a standard 3GPP system otherwise (or rather not processed), or transporting this additional signalling as U-plane payload.

Furthermore, a message containing multiple requests may be partly processed locally while the remaining part of the message is processed in more centralized core network instances. Alternatively, the proxy function may send each message to all relevant functions which are then only processing the relevant parts. The advantage is a slightly reduced latency in the processing of the incoming message by the proxy function.

SDN technology is very appropriate for implementing the logic of exchanging messages between CNPEs. This is due to the fact that the interface of network functions (CNPEs) to SDN controller, which implements the connectivity between those network functions, can be realized by means of APIs which makes easier - on one side - the insertion (or removal) of new network functions into the chain and -on the other side - multi vendor implementations.

Impact on Existing Networks and Difference to Prior Art

Currently deployed networks may be easily extended with additional CNPEs because standard 3GPP interfaces are used and due to its inherent proxy functionality, the distribution of functionality is transparent to eNB and UE. One could even introduce CNPE(s) only to parts of the installed base by assigning the appropriate MME IP address. Furthermore, the standardization of 3GPP entity does not need to be changed but existing definition could be used instead. Since the first CNPE decides where the processing is performed, even legacy 3GPP entities could be included behind a CNPE facing the RAN (in which case all NAS signalling is forwarded).

Compared to prior art, some embodiments of the invention

- Utilize existing 3GPP standards; other literature makes use of additional interface which limits the applicability, and increases the standardization effort; - Concatenate multiple CNPEs which each may perform parts of the functionality of a 3GPP entity compared to 3GPP where pre-defined entities are concatenated;

- Includes proprietary NAS signalling for dedicated purpose such as industrial network slicing;

- Enables time-variant location of NAS processing in a transparent way (to eNB and UE).

Potentially, embodiments of the invention may impact 3GPP standardization, such as S1 standardization. For example, the following changes due to some embodiments of the invention could potentially impact 3GPP:

1 . Introduction of a container protocol (as outlined above) which is capable of transporting proprietary or service-specific S1 signalling. In some of these embodiments, a specific CNPE may be deployed to process those proprietary or service-specific messages while all other messages are processed by other CNPEs. E.g., in some embodiments of the invention, the proprietary or service specific messages may be processed first by the specific CNPE, and all other messages are forwarded to subsequent one or more CNPEs.

2. Definition that an arbitrary core network entity may process only part of the S1 messages. This would move the implementation-specific aspects of the invention report into the space of logical architecture, i.e., currently defined functionality could be flexibly grouped instead of statically assigned to individual entities. In that case, the below definition of a common database may be necessary (but has been addressed already).

3. Definition that multiple messages may be processed by more than one entity, e.g., in the case of enterprise deployments where only part of the network functionality is provided by the enterprise deployment while the remaining functionality is provided by MNO. In this case, a message delivered from one CNPE to another one may not be encrypted based on the 3GPP keys but rather based on a separate security context between the CNPEs (which may be common for all connections), e.g., using IPSec/TLS.

4. A common database and database access interface - this has already been mentioned in the context of SDL. The difference is that this invention report would use S1 (or S1 ^* in future releases) as interface between the individual entities while other proposals see pre-defined grouping and interfaces.

Examples and Applications In conventional S1 interface the NAS messages are split into:

EPS Mobility management

- EPS Session Management

EPS Mobility Management includes a vast category of messages. In addition to 'pure' Mobility (e.g. Tracking Area update, Paging), this category includes messages which don't carry 'pure' MM functions, for example Attach/Detach Request, Authentication, Service Request/service, etc. In particular the Attach Request/accept/complete/Reject are MM which piggyback SM messages. Other messages, like (Extended)Service Request/Reject, CS Service Notification are semantically SM messages.

In 3GPP SA2, several 5G network architectures are discussed and most likely MM and SM will be split (for example S2-162264 proposes the split of MM and SM functions); one option sees MM belonging to a central CN Common Control Plane function (shared CN part of a network slice) while SM can be own per dedicated part of a network slice, as shown in Fig. 5. Fig. 5 shows network slices with some shared components ("Common Control Plane", e.g. MM function) and dedicated components ("Control plane", e.g. IUP functions). In this case, UE may camp on multiple network slices provided there is a single MM function for a given UE. In addition, future core network solutions may provide additional functionality which allows for more fine-granular assignment of functionality.

According to some embodiments of the invention, the above scenario (Fig. 5) can be transparently implemented even in a multi-vendor environment and without changes to the S1 interface. This shows that additional interfaces, e.g. developed outside 3GPP, may not be necessary in order to support the flexibility of assigning NAS functions to different network entities.

Another example relates to network slicing with a clear separation of RAN and CN functionality (in terms of interfaces) while the actual functionality implemented by the CN may vary significantly depending on the actual network. According to some embodiments of the invention, the S1 messages from RAN may be forwarded by the proxy in the CNPE facing the RAN dependent on the slice. Network slicing is currently discussed in 3GPP for the 5G Network Architecture (SA2 and RAN groups). In a UE assisted method, envisaged by eDECOR in LTE as well as its evolution in 5G (e.g. based on MDD, see 3GPP TR 23.799), the network contains a 'Network Selection Function', both in RAN and in CN (the latter applies to 5G only and not to LTE, as currently standardized) for routing messages according to services t e UE requires (based on e.g. MDD).

Fig. 6 shows for an embodiment of the invention how the proxy could forward S1 messages based on the current state (UE initial access or not) as well as based on the actual slice. E.g. in the case of an loT slice only parts of the functionality are needed and therefore a slim implementation is possible. Functionality going beyond this set of essential functionality (e.g. mobility management, session management, charging, and lawful interception) would be caught by the proxy function and forwarded to a default implementation (shared slice).

In another example, some embodiments of the invention enable a transparent flexible concatenation of core network functionality between edge cloud resources and central resources, as well as between edge clouds (e.g. during handover or load balancing). Motivation for such a concatenation may be a change of user profile (from static to mobile, e.g. when entering a car; or from MBB to loT, e.g. when going to sports). Furthermore, different users at one access point may require a different allocation of NAS functionality (static users using mobile edge cloud resources compared to mobile users requiring robust and fast mobility). This user dependent selection may be done easily within the proxy function without any need for significant changes of the S1 interface. The required information may be obtained based on the radio bearer setup information (or NAS signalling in general) and information related to the network slices to which the UE is connected to.

Another example according to some embodiments of the invention has been mentioned before: in an Industrial loT scenario, such as smart factories, it may be necessary that parts of the NAS signalling is processed locally due to privacy constraints imposed by the factory operator. This may also imply that parts of AAA is performed locally in the factory. All remaining signalling may be forwarded to a mobile network operator (MNO) owned CNPE which processes this signalling (e.g. charging). In this case, the critical information may not be exposed to a MNO but remains locally at the operator of the smart factory while information critical to the operation of the network or operations that should be performed preferably outside the factory (e.g. paging) may be handled by the MNO. Furthermore, this setup allows for including proprietary signalling which would be handled by a CNPE owned by the factory operator (or even implemented by machine manufacturers) while all remaining messages are forwarded to a 3GPP entity (which may even be a MME). In this case, proprietary solutions could be easily combined with standardized solutions in the Industrial loT environment. Finally, in some embodiments of the invention, co-located (proprietary) optimization of AS and NAS functionality is enabled, e.g. implemented in a mobile edge cloud solution.

Fig. 7 shows an apparatus according to an embodiment of the invention. The apparatus may be a CNPE or an element thereof. In particular, the apparatus may be a proxy function of a CNPE. Fig. 8 shows a method according to an embodiment of the invention. The apparatus according to Fig. 7 may perform the method of Fig. 8 but is not limited to this method. The method of Fig. 8 may be performed by the apparatus of Fig. 7 but is not limited to being performed by this apparatus.

The apparatus comprises identifying means 10, determining means 20, and forwarding means 30. The identifying means 10, determining means 20, and forwarding means 30 may be an identifying processor, determining processor, and forwarding processor, respectively.

The identifying means 10 identifies a function (S10). The function is requested in a received message and the received message is received from a radio access network;

Based on the identified function, the determining means 20 determines a resource for providing the identified function (S20).

The forwarding means 30 forwards the request for the function to the determined resource (S30).

Fig. 9 shows an apparatus according to an embodiment of the invention. The apparatus comprises at least one processor 41 0, at least one memory 420 including computer program code, and the at least one processor 410, with the at least one memory 420 and the computer program code, being arranged to cause the apparatus to at least perform at least the method according to Fig. 8.

Embodiments of the invention may be employed in a 3GPP network such as LTE or LTE-A, or in a 5G network. They may be employed also in other mobile networks such as CDMA, EDGE, UTRAN networks, etc.. A terminal may be a user equipment such as a mobile phone, a smart phone, a PDA, a laptop, a tablet PC, a wearable, a machine-to-machine device, or any other device which may be connected to the respective mobile network.

One piece of information may be transmitted in one or plural messages from one entity to another entity. Each of these messages may comprise further (different) pieces of information.

Names of network elements, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or protocols and/or methods may be different, as long as they provide a corresponding functionality.

If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software.

According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example a proxy function such as a proxy function of a core network processing entity, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

It is to be understood that what is described above is what is presently considered the preferred embodiments of the present invention. However, it should be noted that the description of the preferred embodiments is given by way of example only and that various modifications may be made without departing from the scope of the invention as defined by the appended claims.

Claims

1 . Apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor, with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform at least

identifying a first function, wherein the first function is requested in a received message received from a radio access network;

determining, based on the first function, a first resource for providing the first function ; forwarding the request for the first function to the first resource.

2. The apparatus according to claim 1 , wherein the at least one processor, together with the at least one memory, is further configured to perform

checking if a second function in addition to the first function is requested in the received message;

determining, based on the second function, a second resource for providing the second function if the second function is requested;

forwarding the request for the second function to the second resource after a response to the request for the first function is received.

3. The apparatus according to any of claims 1 and 2, wherein the at least one processor, together with the at least one memory, is further configured to perform

checking if a third function in addition to the first function is requested in the received message;

determining, based on the third function, a third resource for providing the third function if the third function is requested;

forwarding the request for the third function to the third resource together with the forwarding of the request for the first function to the first resource.

4. The apparatus according to any of claims 1 to 3, wherein the at least one processor, together with the at least one memory, is further configured to perform

monitoring if the received message comprises an indication that a proprietary function is requested;

forwarding the request for the proprietary function to a predetermined resource if the received message comprises the indication.

5. The apparatus according to any of claims 1 to 4, wherein the at least one processor, together with the at least one memory, is further configured to perform

inquiring an indication of the first resource based on the first function;

determining the first resource based on the indication received in response to the inquiry.

6. The apparatus according to any of claims 1 to 5, wherein

the received message complies with a protocol; and the at least one processor, together with the at least one memory, is further configured to perform

composing a sent message for forwarding the request for the first function, wherein the sent message complies with the protocol; wherein

the forwarding of the request for the first function comprises forwarding the sent message to the first resource.

7. The apparatus according to claim 6, wherein

the protocol is a protocol of an interface between the radio access network and a core network according to a third generation partnership project.

8. The apparatus according to any of claims 1 to 7, wherein the first function is a function of at least one of a mobility management and a session management, and/or the first function belongs to a user plane or a control plane.

9. The apparatus according to any of claim 1 to 8, wherein

the determining is additionally based on at least one of a user equipment to which the received message is related, a user profile of a user of the user equipment, a destination address comprised in the received message, a type of the received message, a computational load on the apparatus, an available transport capacity, a latency, and a slice.

10. Method, comprising

determining, based on the first function, a first resource for providing the first function; forwarding the request for the first function to the first resource.

1 1 . The method according to claim 10, further comprising checking if a second function in addition to the first function is requested in the received message;

12. The method according to any of claims 10 and 1 1 , further comprising

13. The method according to any of claims 10 to 12, further comprising

14. The method according to any of claims 10 to 13, further comprising

inquiring an indication of the first resource based on the first function;

15. The method according to any of claims 10 to 14, wherein

the received message complies with a protocol; and the method further comprises composing a sent message for forwarding the request for the first function, wherein the sent message complies with the protocol; wherein

16. The method according to claim 15, wherein the protocol is a protocol of an interface between the radio access network and a core network according to a third generation partnership project.

17. The method according to any of claims 10 to 16, wherein the first function is a function of at least one of a mobility management and a session management, and/or the first function belongs to a user plane or a control plane.

18. The method according to any of claim 10 to 17, wherein

the determining is additionally based on at least one of a user equipment to which the received message is related, a user profile of a user of the user equipment, a destination address comprised in the received message, a type of the received message, a computational load on the apparatus performing the method, an available transport capacity, a latency, and a slice.

19. A computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to any of claims 10 to 18.

20. The computer program product according to claim 19, embodied as a computer-readable medium or directly loadable into a computer.