TECHNICAL FIELD The present invention relates to the technical field of telecommunication networks.

Particularly, the invention relates to a network function hosting node and to a

telecommunication network, wherein the telecommunication network is configured for hosting virtualized network function entities, VNFEs. BACKGROUND

Current telecommunication networks are built upon hardware based appliances which need specific planning and provisioning; specific skills are necessary to design, integrate and operate them.

"Network Functions Virtualisation - An Introduction, Benefits, Enablers, Challenges & Call for Action issued by the ETSI Network Functions Virtualization (NFV) Industry Specification Group (ISG) generally describes the need for virtualization of network functions. It is particularly stated that networks are populated with a large and increasing variety of proprietary hardware appliances. To launch a new network service often requires yet another variety and finding the space and power to accommodate these boxes is becoming increasingly difficult; compounded by the increasing costs of energy, capital investment challenges and the rarity of skills necessary to design, integrate and operate increasingly complex hardware-based appliances. Network Functions Virtualisation aims to address these problems by leveraging standard IT virtualisation technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage, which could be located in Data Centers, Network Nodes and in the end user premises.

The NFV paradigm drives in particular the architectural design of 5G telecommunication networks, which will involve a Management and Orchestration Plane to instantiate configurable architectures implemented by virtual network functions. For instance, in the architectural framework proposed by the ETSI NFV ISG ("Network Functions virtualization (NFV); architectural framework") the traditional functions operated by the O&M (Operation & Management) sub-system are transferred into a Management and Orchestration Plane. The definition of this Management and Orchestration plane is driven by the following principles: Former monolithic network elements are expected to be implemented by virtualized network functions (VNFs); The VNFs shall be embedded in a virtual substrate, based on "cloud" and "Software Defined Networking (SDN)" techniques; The Orchestrator shall dynamically allocate compute, storage and network resource of the virtual substrate to the VNFs in order to fulfill quality of service requirements while optimizing the utilization of the substrate. In "Network Functions virtualization (NFV), Management and Orchestration" the ETSI NFV ISG introduces the framework for a NFV Management and Orchestration (MANO) Plane. The NFV MANO architectural framework involves the following main components:

NFVO (NFV Orchestrator):

- NFVI (NFV Infrastructure) resource management across operator's Infrastructure

Domains including the distribution, reservation and allocation of NFVI resources to Network Service instances and VNF instances by using an NFVI resources repository, as well as locating and/or accessing one or more VI Ms as needed and providing the location of the appropriate VIM to the VNFM, when required.

- Supporting the management of the relationship between the VNF instances and the

NFVI resources allocated to those VNF instances by using NFVI Resources repository and information received from the VI Ms.

VNFM (Virtual Network Function Manager):

- VNF instantiation, including VNF configuration if required by the VNF deployment template

VIM (Virtualized Infrastructure Manager):

- Managing the allocation/upgrade/release/reclamation of NFVI resources

- Supporting the management of VNF Forwarding Graphs (create, query, update, delete), e.g., by creating and maintaining Virtual Links, virtual networks, etc.

WO 2014/131462 A1 describes virtualization and split of EPC network functions in different virtual machines and the separation between application part, flow forwarding control part and forwarding part. The application part is implemented by Apps embedded in a Cloud Infrastructure. The flow forwarding control functions are instantiated in SDN Controllers, the forwarding part in forwarding elements.

US 2014/0226467 A1 describes a method for performing Software Defined Network (SDN)- based network sharing by a controller to support multiple operators.

US 2014/0078988 A1 describes the implementation of the data plane in 3G/4G networks by means of APIs for flow control; moreover it describes pro-active configuration of flow forwarding tables in SDN enabled switches to implement control function requirements. Some control functions are referred to: attach/detach, bearer management, mobility management, policy processing and flow tracking.

WO 2014/125486 A1 describes an SDN layer managing connectivity among virtualized network functions. The localization of these virtualized network functions is determined by an Orchestrator.

WO 2014/055912 A1 describes architecture to implement a Provider Network Controller leveraging on SDN network elements based on OpenFlow or GMPLS. An application stratum requests the Physical Network Control to implement paths in the substrate.

WO 2014/085207 A1 describes the implementation of EPC on top of a SDN layer. It describes a modified LTE EPC network, in which a typical LTE EPC network has been modified to support a software-defined overlay network. Forwarding Elements are configured to communicate via a modified OpenFlow interface.

SUMMARY

It may be seen as an object of the invention to increase the flexibility and reconfigurability of a telecommunication network.

This object is achieved by the features of the independent claim. Further implementation forms are apparent from the dependent claims, the description and the figures. The invention is based on the following findings and drawbacks recognized in the prior art:

In the prior art, the orchestration modules involved in the instantiation of control and data plane may not be defined, as well as the interfaces and procedure to perform the

instantiation. The data plane may still be based on traditional 4G approach, implemented on top of an SDN infrastructure.

The prior art may not specify how to implement control and data plane of a

telecommunication network on the SDN-based infrastructure. In some of the prior art, the concept of orchestration may refer only to the orchestration of virtual machines, so that it is actually cloud orchestration. This prior art may not distinguish between data plane and control plane flow forwarding functions. In some other prior art, the proposed approach is limited to the implementation of the forwarding functions in the data plane.

For this reason, current telecommunication systems may lack of the flexibility and

reconfigurability, both required to support efficiently next generation services and devices, which will pose a wide set of heterogeneous functional and performance requirements. In this description, an telecommunication network is proposed implemented by control and data planes that can be autonomously provisioned, for example by means of an ETSI NFV compliant Management and Orchestration plane, giving telecommunication network systems (in particular 5G systems) high flexibility in the control and data plane instantiation.

Based on these findings, this description relates to a telecommunication network, particularly to a telecommunication network architecture, and functional components to implement control and data plane in mobile and fixed telecommunication networks. The

telecommunication network comprises virtualized network function entities (VNFEs), which implement elementary components of a telecommunication network, which functionality and communication with other VNFEs may be specified by standard bodies, such as 3GPP, IETF, I RTF, etc. The telecommunication network may further comprise virtualized

connections (VCs), which implement communication among VNFEs according to interface specifications defined by standard bodies, such as 3GPP, IETF, I RTF, etc. Further, the telecommunication network may comprise forwarding elements, which implement control and data plane messages forwarding.

According to an aspect of the invention, a network function hosting node for a

telecommunication network is provided, wherein the network function hosting node is configured to host at least one virtualized network function entity, VNFE, wherein the at least one VNFE is configured to perform a function for operating the telecommunication network, wherein at least one virtual connection, VC, is configured to establish a connection to a second VNFE of a second network function hosting node and wherein the at least one VC is configured to implement a data transmission interface between the at least one VNFE and the second VNFE, wherein the network function hosting node is configured to receive a first type message and a second type message, wherein the first type message is a control plane message and the second type message is a data plane message, wherein the network function hosting node is configured to forward the first type message to the at least one VNFE and to configure the at least one VNFE, and wherein the network function hosting node is configured to forward the second type message via the at least one VC to the second VNFE. The network function hosting node may, in one embodiment, comprise a control module with a processor, a receiving module, and a transmitting module. The receiving module may be configured to receive the incoming messages and the transmitting module may be configured to transmit outgoing messages, i.e. messages directed to the second VNFE, to the intended recipient. The control module may be configured to carry out the at least some or all of the functions of the network function hosting node by means of the processor.

The network function hosting node as described herein may be a last hop routing element, LHRE, or a network end point, NEP. The configuration of the hosted VNFE defines the role of a network function hosting node. It may be seen as one aspect of the network function hosting node that it is configured to distinguish between control and data plane messages in order to enable a separation of the functions of a network function hosting node from its physical structure.

A control plane message may particularly be a message that is to be forwarded to the VNFE in order to configure it and/or network function hosting node in order to configure VNFEs or VCs whereas a data plane message may particularly relate to end-to-end communication and is to be forwarded by the network function hosting node and/or a VNFE to another VNFE, i.e. the data plane message does not relate to the configuration of the VNFE but is forwarded by a VNFE. Thus, it is possible to decouple logical functional blocks of control and data plane from the physical infrastructure.

By hosting VNFEs and VCs, an easy to be reconfigured infrastructure is provided without the necessity to adapt the physical configuration and infrastructure of the network. The network function hosting node can be configured by adapting VNFEs and VCs such that a virtual network structure is provided which can be adapted to varying needs and requirements. The network function hosting node will be described in more detail below with reference to the telecommunication network.

According to an embodiment of the invention, the network function hosting node is configured to receive a VNFE configuration request and to configure the at least one VNFE according to the received VNFE configuration request. The network function hosting node may thus be reconfigured dynamically and its function or a functional module of the network function hosting node can be adapted to changing functional requirements. According to an embodiment of the invention, the network function hosting node is configured to receive a VC configuration request and to configure the at least one VC according to the received VC configuration request.

The network function hosting node may be a modular component which can be

communicatively connected with a plurality of other network function hosting nodes in order to build up a telecommunication network. Each one of the plurality of network function hosting nodes can receive a VNFE configuration and a VC configuration such that a virtual network can be established between VNFEs hosted by the network function hosting nodes and interconnected by the VCs.

According to an embodiment of the invention, the network function hosting node is configured to receive a message forwarding configuration request and to forward received messages according to the received message forwarding configuration request.

The message forwarding configuration may define the message flow between the VNFEs via the VCs. In other words, the network function hosting node may be configured to receive a message forwarding configuration request (this may be a control plane message) and configure a forwarding rule which is used to forward incoming messages (which may particularly be a data plane or control plane message).

In the following, a telecommunication network is described. The following description at least partially relates to the functioning and configuration of the network function hosting node, where applicable.

According to a further aspect of the invention, a telecommunication network is provided, comprising a physical infrastructure. The physical infrastructure comprises at least one network node configured for data transmission through the telecommunication network, at least one software defined networking, SDN, controller which is adapted to configure the at least one network node, and at least one network function hosting node which is configured to host at least one virtualized network function entity, VNFE. The telecommunication network is configured to provide a set of virtualized network function entities, VNFEs, and a set of virtualized connections, VCs. At least one VNFE of the set of VNFEs is configured to perform a function of the telecommunication network, wherein a VC of the set of VCs is configured to implement a data transmission interface according to interface specifications of the physical infrastructure. In other words, a virtual control plane and a virtual data plane are provided on a physical network structure. In case of reconfiguration or if new functions are required, one or both of the control plane and data plane can be amended without carrying out amendments to the physical network structure. Thus, the telecommunication network as described herein enables flexibility and reconfigurability with minimal effort.

In one embodiment, the telecommunication network described herein comprises at least two network nodes which can be referred to as a first network node and a second network node. In another embodiment, the telecommunication network can comprise more than two network nodes. The network node can be a data center or an edge computing node of the telecommunication network.

It is one aspect of the telecommunication network that the functions are implemented by using virtualization and that the implemented functions are separated in a control plane and a data plane. The set of VNFEs may for example comprise two or more VNFEs.

The telecommunication network as described herein can be any kind of data transmission network, particularly a telecommunication network used for interconnecting stationary and/or mobile communication devices. The physical infrastructure may particularly relate to the physical hardware components of the telecommunication network. A network node may be a physical forwarding element establishing the infrastructure of the physical network. When referring to virtualized components, reference is made to the components virtualized network function entity, VNFE, and virtual connection, VC, which may be provided and supplied by virtually implemented function blocks on existing physical infrastructure components. A virtual function can be adapted and adjusted without necessarily affecting the underlying physical structure.

By virtualization of the VNFE and VC, the functions of a telecommunication network are split into two layers; the functions of a network element are implemented in the VNFE and the communication/data exchange between different VNFE is implemented in the VC; thus, the functions of a telecommunication network can be implemented and updated by adapting and adjusting the VNFE and VC and no need for updating the physical components and physical infrastructure of the telecommunication network comes up. Such a telecommunication network enables flexibility of tailoring it to network engineering requirements, device and application performance requirements. It may be described as one aspect of the telecommunication network that it is distinguished between data plane and control plane flow forwarding functions, which may require different performance, by matching quality of service, QoS, requirements of VNFEs and VCs to the appropriate resources in the virtual substrate.

According to an embodiment, the at least one network node of the telecommunication network is a network function hosting node as described above.

According to an embodiment of the invention, the set of VNFEs is configured to perform at least one of the following functions:

radio access, RA, configured to perform access network selection and radio connection management;

wireline access, WA, configured to perform access multiplexing on wired connections to the telecommunication network;

Authentication and Authorization, AA, configured to perform authentication and authorization of a user equipment;

Admission Control, AC, configured to perform admission control of the services requested to the telecommunication network by user equipments and external networks;

Charging, configured to perform policy and charging management;

Flow Management, FM, configured to perform packet routing configuration;

Mobility Management, MM, configured to perform subscriber reachability, tracking area management, paging and handover management, relaying;

Security Management, Sec, performing Access Stratum security management;

Connectivity Management, CM, configured to perform radio connection management, forwarding path management, domain name system, DNS, address resolution, address allocation to user equipments, relaying;

Location and Proximity, configured to perform proximity discovery and direct communication management;

Mutual authentication, MA, configured to perform mutual authentication among user equipments.

In this embodiment, the set of VNFE may comprise at least a Connectivity Management, CM, function configured to perform radio connection management, forwarding path management, domain name system, DNS, address resolution, address allocation to user equipments, relaying; and additionally at least one of the following functions:

Radio Access, RA, configured to perform access network selection and radio connection management; Wireline Access, WA, configured to perform DSL, digital subscriber line, access multiplexing.

A wired connection may be any connection to the telecommunication network mentioned above and hereinafter by wire.

According to an embodiment of the invention, the telecommunication network is configured to provide a control plane by the VNFEs and the VCs and a data plane by SDN controllers and network nodes.

The control plane relates to a set of functions of the telecommunication network and contains control functions to manage access stratum and non access stratum connectivity as well as identity, mobility, security, charging and location of the end user devices; moreover, the control plane involves functions to establish data plane flows between end user devices or between devices and other public data networks. For example, firewall or load balancing functions, which may be part of a user plane, can be dynamically placed as VNFE, for instance according to orchestration principles of the telecommunication network.

As a result of this configuration, a flexible configurable implementation of the control plane as a virtual network and a clean slate implementation of the data plane is provided, which relies on the capabilities provided by an SDN infrastructure.

According to a further embodiment of the invention, the telecommunication network comprises a flow management virtual network function, FM VNFE, which is configured to handle user data flows of user equipments connected to the telecommunication network, to determine a forwarding path for each user data flow and to dispatch the determined forwarding path to the SDN controllers and to the network nodes. Particularly, the SDN controller is configured to dispatch the configuration to the network nodes, i.e. these components are configured consecutively.

According to a further embodiment of the invention, the telecommunication network as described herein further comprises a first forwarding element which is configured to connect a network access point to at least one of the set of VNFEs. The first forwarding element may be the so called Last Hop Routing Element, LHRE; in the telecommunication network. The LHRE may particularly be part of the SDN infrastructure, namely a forwarding element connected to one or more access nodes. The SDN infrastructure includes the forwarding elements and the SDN controllers, which scope is to configure the forwarding elements. A LHRE may for example be a forwarding element that connects a network access point (e.g. a wireline access node, a wireless access node ...) to the SDN infrastructure. It represents a soft mobility anchoring point for the devices connected to the network access point. As a forwarding element, the LHRE has the specificity of being configured to handle the messages coming from the access points connected to it. The LHRE may be configured to forward the following messages: control plane messages to the appropriate control plane VNFE that will handle them; control plane messages that cannot be resolved to its SDN Controller that shall forward them to a default TM-VC in charge of handling them; data plane messages to the appropriate edge forwarding element (LHRE or network end point, NEP), according to a configuration determined by a Flow Management (FM) VNFE; data plane messages that cannot be resolved to its SDN Controller that shall forward them to a default Flow Management (FM) VNF in charge of handling them.

The first forwarding element can handle the messages coming from the access points connected to it both for the control plane (messages that the devices exchange with the VNFE) and the data plane (data messages exchanged between subscriber devices or between subscriber devices and other public data networks) implementation.

According to a further embodiment of the invention, the first forwarding element is configured to forward control plane messages to a VNFE, such that the respective control plane messages can be handled by said VNFE.

The forwarded control plane message may be sent by devices connected to the access nodes, for example as attach request or device originated service request, or it may originate from external networks, for example as network originated service request.

According to a further embodiment of the invention, the first forwarding element is configured to forward a control plane message to a default topology management virtual connection, default TM-VC, if the control plane message cannot be resolved to a specific VNFE. The SDN controller may manage the configuration of the forwarding elements. Particularly, the SDN controller may not be a VNFE as referred to above. If a forwarding element cannot handle a message, it shall forward the message to the SDN controller. The SDN controller then shall invoke applications to interpret the message. These applications may be, for example either the TM-VC if the message is a control plane message or the FM VNFE if the message is a data plane message. Not being able to resolve a control plane message to a specific VNFE may particularly relate to a scenario where an intended recipient or addressee, i.e. the specific VNFE, of a control plane message cannot be identified or is not accessible, i.e. cannot be resolved. In this case, the control plane message is forwarded to the default TM-VC.

According to a further embodiment of the invention, the VNFE selected by the default TM-VC to handle the message, is configured to determine which VNFE will handle the following control plane messages involving the device that originally sent the first control plane message, and request the TM VC to configure the virtual connections to forward the following control plane messages to the appropriate VNFE. Thus, configurability of the control plane is enabled and the control plane can be adapted to changing requirements.

According to a further embodiment of the invention, the first forwarding element is configured to forward a data plane message to a second forwarding element according to a path determined by the FM VNFE and configured by the SDN controller.

In this embodiment, the second forwarding element may be another LHRE or network end point, NEP. A NEP may be a forwarding element that identifies the bound of the physical infrastructure controlled by the Orchestrator with other networks. As a forwarding element, the NEP has the specificity of being configured to handle the messages coming from the external network connected to it. The NEP may be configured to forward the following messages: control plane messages to the appropriate control plane VNFE that will handle them; control plane messages that cannot be resolved to its SDN Controller that shall forward them to a default TM-VC in charge of handling them; data plane messages to the appropriate edge forwarding element (LHRE or NEP), according to a configuration determined by a Flow Management (FM) VNF; data plane messages that cannot be resolved to its SDN Controller that shall forward them to a default Flow Management (FM) VNF in charge of handling them. In one embodiment, the same forwarding element may perform both the role of LHRE and NEP.

The path determined by the FM VNFE can be previously determined or alternatively be determined on demand. The FM VNFE is particularly adapted to configure the SDN Controlling Platform (SDN-C) to handle user data flows. It may be co-located with the SDN Controller or located in a separate Cloud Infrastructure. In any case, the role of the FM VNF may be to determine the forwarding path to be allocated to incoming service requests and dispatch the forwarding path configuration to the SDN-C.

According to a further embodiment of the invention, the first forwarding element is configured to forward a data plane message to a default flow management, FM, virtual network function entity, VNFE, if the data plane message cannot be resolved by the first forwarding element and forwarded to a second forwarding element.

In other words, the forwarding of a data plane message that cannot be resolved by the forwarding element is enabled. The forwarding element forwards it to the SDN controller which invokes the FM VNFE to interpret it.

According to a further embodiment of the invention, the telecommunication network as described above and hereinafter further comprises a third forwarding element which constitutes a bound of the physical infrastructure and which is configured to connect the telecommunication network with an external network and to handle messages sent to or received from the external network.

The third forwarding element may be the network end point, NEP. The third forwarding element is configured to handle the messages coming from external networks.

According to a further embodiment of the invention, the third forwarding element is configured to forward control plane messages to a VNFE, such that the respective control plane messages can be handled by said VNFE. In this embodiment, the control plane messages forwarded by the third forwarding element are originated from an external network.

According to a further embodiment of the invention, the third forwarding element is configured to forward a control plane message to a default topology management, TM, virtual connection, VC, if the control plane message cannot be resolved to a specific VNFE. According to a further embodiment of the invention, the third forwarding element is configured to forward a data plane message to a second forwarding element according to a path previously determined by the FM VNFE and configured by the SDN controller. In this embodiment, the second forwarding element may be another LHRE or NEP.

According to a further embodiment of the invention, the third forwarding element is configured to forward a data plane message to a default flow management, FM, virtual network function entity, VNFE, if the data plane message cannot be resolved by the first forwarding element and forwarded to a second forwarding element.

Summing up, the telecommunication network may be described in alternative words as follows: it can be autonomously provisioned by means of an ETSI NFV compliant

Management and Orchestration plane and may be implemented by virtualized network appliances, realized by virtual network functions interconnected by an SDN infrastructure.

The telecommunication network may include at least one of the following functional components:

- virtualized network function entities (VNFEs), which implement elementary components of a telecommunication network, which functionality and communication with other VNFs are specified by standard bodies, such as 3GPP, IETF, I RTF;

- virtualized connections (VCs), which implement communication among VNFEs according to interface specifications defined by standard bodies, such as 3GPP, IETF, IRTF;

- Forwarding elements, which implement control and data plane messages forwarding.

The VNFEs and/or the network function hosting nodes may include at least one of the following set of key VNFEs:

- Radio Access (RA), performing access network selection and radio connection

management;

- Authentication and Authorization (AA), performing authentication and authorization of the user equipment;

- Admission Control (AC), performing admission control of the services requested to the 5G telecommunication network by user equipments and external networks;

- Charging, performing policy and charging management;

- Flow Management (FM), performing packet routing configuration for the data plane;

- Mobility Management (MM), performing user reachability, tracking area management, paging and handover management, relaying; - Security Management (Sec), performing Access Stratum security management;

- Connectivity Management (CM), performing radio connection management, forwarding path management, DNS address resolution, address allocation to the user equipments, relaying;

- Location and Proximity, performing proximity discovery and direct communication management;

- Mutual authentication (MA), performing mutual authentication among user equipments.

The forwarding elements or network function hosting nodes may include at least one of the following specific forwarding elements:

- Last hop routing elements (LHRE), connected to network access points and managing control and data plane messages' forwarding according to SDN principles;

- Network end points (NEP), connected to external networks and managing control and data plane messages' forwarding according to SDN principles. BRIEF DESCRIPTION OF THE FIGURES

Embodiments of the invention will be described with respect to the following figures, in which:

Fig. 1 schematically shows a telecommunication network according to an embodiment of the invention;

Fig. 2 schematically shows the relations for management and orchestration of the telecommunication network according to a further embodiment of the invention; Fig. 3 schematically shows the forwarding components of a telecommunication network according to a further embodiment of the invention;

Fig. 4 schematically shows control and data plane instantiation procedures of a

telecommunication network according to a further embodiment of the invention;

Fig. 5 schematically shows an SDN infrastructure implementation of a telecommunication network according to a further embodiment of the invention;

Fig. 6 schematically shows a control plane signalling procedure of a telecommunication network according to a further embodiment of the invention. DETAILED DESCRIPTION OF EMBODIMENTS

Fig. 1 shows a telecommunication network 10. The telecommunication network 10 is communicatively connected to a subscriber 20, for example a user equipment, UE. The connection between the telecommunication network 10 and the subscriber 20 may be a wireless connection 25 via which a virtual connection 24 is established between virtualized network function entities 22A, 22B (functional modules indicated by a rectangle with rounded corners) and virtualized network function entities (rectangle with rounded corners) of the telecommunication network 10.

The telecommunication network 10 comprises a physical infrastructure having functional components such as cloud infrastructure 140, forwarding elements 1 10, 120, Ί 30, and links 15 (solid lines) interconnecting these functional components. On top of this physical infrastructure, control and data planes are implemented using virtualized network function entities, VNFE, and virtual connections, VC (dashed lines).

The VNFEs of the subscriber can be adapted together with adaptation of the VNFEs and the VCs of the telecommunication network 10 without the necessity of adapting the physical infrastructure because the control and data plane can be adapted without the necessity of adapting the underlying physical infrastructure.

The telecommunication network 10 schematically shown in Fig. 1 may be further described as follows: Fig. 1 aims at describing a telecommunication network architecture and functional components to implement control and data plane in mobile and fixed telecommunication networks. The shown architecture may particularly be used in connection with a 5G telecommunication network and comprises: virtualized network function entities (VNFEs) 22A, 22B, 142, which implement functional modules or components of a telecommunication network, which functionality and communication with other VNFEs may be specified by standard bodies, such as 3GPP, IETF, IRTF; virtualized connections, VCs 14, 24 which implement communication among VNFEs according to interface specifications defined by the standard bodies mentioned above; and forwarding elements 1 10, 120, 130 which implement control and data plane messages forwarding.

The forwarding element 120 comprises a functional module 190 which can include at least one of a control module with a processor, a receiving module, and a transmitting module referred to above when describing the network function hosting node. The functional module 190 may be an integral part of the forwarding element 120 or may be an optional (internal or external) module. It should be understood that the remaining forwarding elements of the telecommunication network may also comprise such a functional module 190.

The architecture shown in Fig. 1 can be provisioned into a virtual substrate in compliance with Management and Orchestration principles of the telecommunication network 10, particularly those Management and Orchestration principles proposed by the ETSI NFV ISG. The virtualized substrate may comprise: cloud infrastructures adapted to implement at least one virtual machine adapted to host VNFEs and/or at least one link adapted to host virtualized connections, Software Defined Networking (SDN) based infrastructures adapted to implement at least one SDN Controlling Platform adapted to configure the elements of the SDN-based infrastructure, at least one link adapted to host virtualized connections and/or at least one forwarding element adapted to forward messages between links.

The embodiment shown in Fig. 1 may involve a key set of VNFEs. Table 1 shows a non limitative example of a basic set of VNFEs implementing functionality and device to device (D2D) communication with the proposed architecture:

- Radio Access (RA), performing access network selection (e.g. according to 3GPP TS 23.401 Section 4.3.2.2)

- Authentication and Authorization (AA), performing authentication and authorization of the user equipment (e.g. according to 3GPP TS 23.401 Section 4.3.2.3)

- Admission Control (AC), performing admission control of the services requested to the telecommunication network by user equipments and external networks (e.g. according to 3GPP TS 23.401 Section 4.3.2.4)

- Charging, performing policy and charging management (e.g. according to 3GPP TS 23.401 Section 4.3.2.5)

- Flow Management (FM), performing packet routing configuration for the data plane

- Mobility Management (MM), performing user reachability (e.g. according to 3GPP TS 23.401 Section 4.3.5.2), tracking area management (e.g. according to 3GPP TS 23.401 Section 4.3.5.3), paging (e.g. according to 3GPP TS 36.300 Annex 1 ) and roaming (e.g. according to 3GPP TS 36.300 Section 4.1 ), relaying (e.g. according to 3GPP TS 36.300) Security Management (Sec), performing Access Stratum security management (e.g.

according to 3GPP TS 36.300 Section 4.1 )

- Connectivity Management (CM), performing radio bearer management (e.g. according to 3GPP TS 23.401 Section 4.3.6), DNS address resolution (e.g. according to 3GPP TS 23.401

Section 4.3.9.1 ), address allocation to the user equipments (e.g. according to 3GPP TS 23.401 Section 4.3.9.2), relaying (e.g. according to 3GPP TS 36.300 and TS 22.278 Section 7A.2)

- Location and Proximity, performing proximity discovery and direct communication management (e.g. according to 3GPP TS 23.401 Section 4.3.14)

- Mutual authentication (MA), performing mutual authentication among user equipments (e.g. according to 3GPP TS 22.278 Section 7A.2)

- Different sets of VNFEs might be possible, still covering the same 4G and D2D

communication functionalities. Control and Data Plane forwarding components are implemented by specific forwarding elements (LHRE and NEP), which will be described below.

Table 1- Virtual Network Functions

For the sake of completeness, Table 2 maps to Management and Orchestration modules the O&M functions currently implemented by 4G network elements. Table 2 - Management and Orchestration functions

The Resource Orchestration (RO) Module determines the allocation of resources to the VNFEs and VCs. The RO may have abstract knowledge of the underlying infrastructure, mediated by Topology Management (TM) modules that manage the virtualized substrate. Additionally, the RO module may run embedding algorithms to match the resource and quality of service requirements of VNFEs and VCs with the resources and performance offered by the virtual substrate components. The Topology Management modules may handle provisioning and monitoring within a single domain and single technology. The TM-VNFE modules control the cloud infrastructure resources provisioned by Cloud Infrastructure Managers and the TM-VC modules control the virtual links maintained by SDN Control Platforms (SDN-C). The TM modules report resource state and availability to the RO Module, which runs algorithms to find embedding solutions for virtual infrastructure into networking and cloud resources.

TMs interact with the corresponding virtual substrate components (Cloud Infrastructure Managers and SDN Control Platforms) via technology specific interfaces. Fig. 2 shows the implementation of the SDN-based infrastructure mentioned above with reference to the telecommunication network 10 shown in Fig. 1 . Details of the

telecommunication network 10 are not repeated here. Fig. 2 shows an example of a telecommunication network 10 implementing some of the key set of VNFEs mentioned above.

The orchestrator modules (double lined rectangles, for example TM-VNF 150) are interconnected via orchestrator interfaces (dashed double lines) 152 while some of the modules 150 are assigned to cloud infrastructure modules 140 by means of virtual substrate interfaces 170. The SDN-controller 160 is communicatively connected to the forwarding elements 1 10, 120, 130 of the telecommunication network 10 via SDN-based infrastructure configuration interfaces 162, respectively.

Fig. 3 shows control and data plane forwarding components of the telecommunication network 10. Details described with reference to Fig. 1 and Fig. 2 are not repeated here.

The TM-VC 304 is adapted to configure the Control-Plane (c-plane) VCs in the SDN infrastructure and may act as a default application on top of the SDN controller to determine the control plane forwarding configuration according to the path calculated by the Resource Orchestrator, RO.

The Resource Orchestrator RO 302 is configured to calculate the location of the c-plane VNFEs and the c-plane VCs according to network planning requirements and infrastructure availability.

The flow management VNFE 308 is adapted to configure the data plane paths in the SDN infrastructure and may act as a default VNFE to implement data plane forwarding

configuration according to user service requests. The LHRE and NEP 310 are specific forwarding elements, handling respectively the interface to access points and external networks.

As indicated in Fig. 1 , some forwarding elements in the SDN infrastructure may have specific roles for the implementation of control and data planes. These forwarding elements are the Last Hop Routing Elements (LHREs) and the Network End Points (NEPs). The role of the Flow Management (FM) VNFE in relation with these forwarding elements is described in the following paragraphs.

In this embodiment, the LHRE is a forwarding element that connects a network access point (e.g. a wireline access node or a wireless access node) to the SDN infrastructure. It represents a soft mobility anchoring point for the devices connected to the network access point. As a forwarding element, the LHRE may have the specificity of being configured to handle the messages coming from the access points connected to it. The LHRE may be configured to forward the following messages:

- control plane messages to the appropriate control plane VNFE that will handle them;

- control plane messages that cannot be resolved to its SDN controller that shall forward them to a default TM-VC in charge of handling them; - data plane messages to the appropriate edge forwarding element (LHRE or NEP), according to a configuration determined by a Flow Management (FM) VNF;

- data plane messages that cannot be resolved to its SDN Controller that shall forward them to a default Flow Management (FM) VNF in charge of handling them.

A NEP is a forwarding element that identifies the bound of the physical infrastructure controlled by the Orchestrator with other networks. As a forwarding element, the NEP has the specificity of being configured to handle the messages coming from the external network connected to it. The NEP may be configured to forward the following messages:

- control plane messages to the appropriate Control Plane VNF that will handle them;

- control plane messages that cannot be resolved to its SDN Controller that shall forward them to a default TM-VC in charge of handling them;

- data plane messages to the appropriate edge forwarding element (LHRE or NEP), according to a configuration determined by a Flow Management (FM) VNF;

- data plane messages that cannot be resolved to its SDN Controller that shall forward them to a default Flow Management (FM) VNF in charge of handling them.

The flow management virtual network function entity, FM VNFE, is adapted to configure the SDN Controlling Platform (SDN-C) to handle user data flows and may be co-located with the SDN Controller or located in a separate cloud infrastructure. The role of the FM VNFE is to determine the forwarding path to be allocated to incoming service requests and to dispatch the forwarding path configuration to the SDN-C.

In one embodiment, the forwarding elements in the SDN infrastructure (including the LHREs and NEPs) can be OpenFlow enabled switches and the SDN-C an OpenFlow Controller. The FM VNFE can be an application running on top of the OpenFlow Controller. The procedure to handle an incoming data flow originated by a user equipment (UE) connected to an access node can be implemented as follows: 1 . The LHRE connected to the access node receives the first packet of the data flow;

2. As the LHRE cannot match the packet to any configured forwarding rule, the LHRE generates a control packet (so called packet-in) to the SDN-C encapsulating the original first packet of the data flow;

3. The SDN-C receives the packet and forwards it to the FM VNF;

4. The FM VNFE parses the original packet and determines the source (the user equipment) and the destination (e.g. an application server) and the Quality of Service requirements; 5. The FM VNFE, invoking other Control Plane VNFEs, determines a path across the SDN infrastructure to implement the requested service;

6. The FM VNFE dispatches to the SDN-C the forwarding path configuration;

7. The SDN-C configures the OpenFlow switches in the path (including the LHRE that originated the packet-in) and forwards the original packet to the originating LHRE;

8. The LHRE and all the switches involved in the forwarding path will forward any

subsequent packet related to the data flow according to the forwarding rules.

Fig. 4 shows the procedure for the instantiation and re-instantiation of control and data planes of a telecommunication network as described with reference to Figs. 1 to 3. The TM Modules 402 periodically update the RO Module 404 about availability and state of the substrate resources. In step 1 , a network engineering (NE) requirement message triggers a function or embedding algorithm (step 2) in the RO Module 404. The implementation of the NE requirements may result in instantiating (or de-instantiating) VNFEs in the cloud infrastructure 406 controlled by TM-VNF modules 402 (steps 3. a VNFE configuration request, 4. a VNFE configuration, 5. a VNF configuration acknowledge), new VCs in the SDN- based infrastructure controlled by TM-VC modules on top of SDN Platforms (steps 3.b VC configuration request, 4.b VC configuration, 5.b VC configuration acknowledge) and configuring forwarding elements (steps 3. c forwarding configuration request, 4. c forwarding configuration, 5. c forwarding configuration acknowledge).

Fig. 4 particularly shows the configuration of the network function hosting nodes. A network function hosting node may be a LHRE, a NEP or any other forwarding component of the telecommunication network 10. The configuration of each of the network function hosting nodes contributes to providing the desired telecommunication network functions. It should be understood that the description relating to the embodiments shown in Figs. 1 to 3 relates to the network function hosting nodes, i.e. the network function hosting nodes are configured such that they meet the demands referred to in Figs. 1 to 3 when referring to the forwarding elements like LHRE and NEP, for example.

The instantiation of the Control Plane may consist of:

- Embedding the VNFEs while fulfilling network engineering requirements (e.g. network planning requirements, energy consumption constraints, operational cost constraints, geographical distribution of the devices, etc) and service performance requirements;

- Configuring VCs with appropriate latency and bandwidth to interconnect VNFEs;

- Configuring the forwarding elements connected to the network access points, the LHREs, and external networks, the NEPs, to handle Control Plane messages. The instantiation of the Data Plane may consist of:

- Configuring specific forwarding elements connected to the network access points, i.e. the LHREs, and to external networks, i.e. the NEPs, to handle Data Plane messages.

The architecture described above may particularly have the following characteristics. The described structure of the network function hosting nodes and the architecture of the telecommunication network enable full flexibility in the instantiation of control and data plane. Flexibility consists of tailoring the control plane and data plane according to network engineering requirements, device and application performance requirements. In particular, a clean-slate design approach for the data plane has been followed, so that neither dedicated data plane network elements, nor unique logical elements for the whole attached device population (like gateways or mobility anchor points) are defined. Low latency and ultra-high reliability requirements can be addressed by means of this approach. The flexibility in the instantiation of control/data-plane will generate service/device tailored logical architectures, e.g. targeting 5G key performance indicators (KPIs).

Fig. 5 shows the implementation of a public land mobile network (PLMN) involving radio access nodes and a core network fully implemented by applications running on top of an SDN infrastructure. The access nodes are implemented by radiating points and virtual network functions (RA: Radio Access) deployed in edge computing nodes.

The SDN infrastructure is implemented by:

- Forwarding elements (a1 , a2, c1 to c7, e1 , e2), for example Open Flow enabled switches; some forwarding elements (a1 , a2) may have the characteristic of being connected to the access nodes and perform the role of LHREs, some (e1 , e2) of being connected to external packet data networks (PDNs) perform the role of NEPs.

- SDN Controller: this component could be implemented by an OpenFlow Controller (e.g. OpenDayLight, Floodlight) or a distributed OpenFlow Controlling platform (e.g. ONOS, Onyx).

The core network control and data plane are implemented by:

- The SDN infrastructure;

- The applications running on top of the SDN Controller of the SDN infrastructure; these applications implement some of the VNFEs described above. Fig. 6 shows, as an example of control plane signalling procedure, a subscriber (UE) 20 triggered service request to the telecommunication network 10, wherein the subscriber 20 and the telecommunication network 10 implement several VNFEs 22, 142. The VNFEs correspond to the functions of network elements involved in the procedure of the telecommunication network 10 and are implemented as applications running on top of the SDN controller. The establishment of GPRS tunnelling protocol (GTP) tunnels for

establishing the user plane connectivity is replaced by the configuration of flow forwarding rules in the SDN infrastructure (step 13).

The procedure to handle a UE triggered service request is the following (the numbering of the steps corresponds to the numbering in the drawing):

0. An App Client triggers a Service Request to a CM Client. The CM Client formats the message and sends it to a RA App, including the Identity Info and the Application Id and, optionally, the identifier of the destination CM App (see steps 0.1 and 0.2);

1 . The UE RA App forwards the Service Request to the RA App in the Edge Controller (i). The RA App forwards the Service Request to the appropriate App (including Cell ID and TAID), in this case a CM App, by dispatching the message to the Edge Switch the serves as forwarding switch for the RA App. If the Edge Switch cannot resolve the message, it shall forward it to the OF Controller as shown in the Service Request Forwarding procedure. If the RA App can't handle the message it will reject it. If the CM App can't handle the Service Request it will reject it.

2. The CM App verifies the identity of UE and Application with the AA App. The message contains: Cell ID, TAID, LHRE, CM App ID. The CM App may require the AA App to resolve the Identity Info provided by the UE in additional identities (i.e. IMSI). The database of the AA App is configured according to the received Cell ID, TAID, LHRE, CM App ID, e.g. by inserting or updating.

3. The AA App authorizes the service request. The message may contain UE additional identities, if required.

4. Optionally, the authentication procedure is performed by UE, CM App and AA App to further encrypt NAS messages.

5. The CM App sends an Initial Context Setup request to the RA App(s) (which may be different from the one that received the Service Request), including the QoS requirements for the radio bearer, the Security Context and the Handover Restriction List.

6. The RA App and the UE RA App perform the radio bearer establishment procedure.

7. The RA App sends an Initial Context Setup response (list of accepted bearers, list of rejected bearers) to the CM App. 8. The CM App requests the FM Mod to configure the transport layer for the requested service. The "Flow configuration request" includes the LHRE and the identifier(s) of the endpoint(s) involved in the service; for instance: IMSI(s), the device Application Id, the Application Id, the endpoint(s) identifiers for the Application or the IP address(es).

9. FM App shall define specific SW/routers configuration based on Critical Level parameter.

10. The FM Module resolves the endpoint location(s) and requests the AC Module to calculate the abstract path(s) for the data flow(s) of the requested service.

1 1. The AC App determines how to realize the requested path based on the knowledge of physical infrastructure topology and utilization.

12. The AC Module sends the abstract path(s) to the FM Module. If the service cannot be admitted, the AC Module rejects the request.

13. The FM Module configures the OFC and, as a consequence, the forwarding switches involved in the data flow(s).

14. The FM acknowledges the forwarding flow(s) configuration.

15. The CM App acknowledges the Service Request to the CM Client. The user plane is now established.

16. The uplink data generated by the App Client can now be forwarded by the UE RA App to the RA App and from the RA App to the Edge Switch. The forwarding switches forward the uplink data through the SDN-based transport layer to the relevant destination(s) (other devices, Application Servers).