Patent Description:
In a typical communication network, User equipments (UE), also known as wireless communication devices, mobile stations, stations (STA) and/or wireless devices, communicate via a Radio Access Network (RAN) to one or more core networks (CN). The RAN covers a geographical area which is divided into service areas or cell areas, with each service area or cell area being served by a radio network node such as a radio access node e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a NodeB, an eNodeB, or a gNodeB. A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the UE within range of the radio network node.

The ETSI Network Function Virtualization (NFV) framework is one of the foremost Orchestration and Management frameworks for Virtualized Network Function (VNF) lifecycle management with a widespread acceptance and support in the Telecom Industry.

In the ETSI NFV Lifecycle Management and Orchestration (ETSI NFV-MANO) architecture (se <FIG>) for orchestration and life-cycle management of virtualized networks and virtualized network function (VNF) applications, the NFV Orchestrator (NFVO) interacts with the virtualization infrastructure manager (VIM) of a cloud to set up and manage networking resources such as data storage, processor capacity and similar (except those that are internal to the VNF, i.e. used for communication among VNF components), while it delegates to a VNF Manager (VNFM) to interact with the VIM in order to orchestrate and manage the compute and storage resources and networking interfaces needed in the cloud for a VNF instance.

On the higher level, Network Service (NS) Descriptors (NSD) (i.e. templates) exist that contain amongst others several VNFs and virtual links (VL). The NSDs are orchestrated by the NFVO which in its turn delegates the orchestration of the individual VNFs to the relevant VNFM or VNFMs.

The <FIG> is from "https://www. org/technologies/nfv" and shows the NFV-MANO architectural components and what ETSI specifications that relates to the different components and interfaces.

The VNFM bases the interactions with the Virtual Infrastructure Manager (VIM) of a cloud infrastructure on a combination of:.

With regards to computer networking, an application comprises of one or more deployment units, e.g. VMs, Containers, central processing unit (CPU) boards, that in the VNFD is modelled by a concept called Virtual Deployment Unit (VDU). These deployments have network interfaces to connect to a virtual link (VL) representing the underlying network transport technology, such as virtual local area network (VLAN), Virtual Extensible LAN (VXLAN), generic routing encapsulation (GRE), etc., through which they can communicate with other application units, via internal VLs, and/or with the outside world, via external VLs. These network interfaces are modelled in the VNFD with a concept called Connection Point Descriptors (CPD). A CPD normally models an Ethernet interface, on a VDU, that connects the VDU to a network, such network interfaces are often referred to as access ports, or it may represent a network interface via which the VDU connects to multiple networks (such network interfaces are commonly referred to as trunk ports). A CPD may also represent a port in a router (this is the case when a VnfExtCp is connected to an internal VL rather than being a re-exposure of a VduCp). A CPD may also represent a virtual connection point allowing to access a set of VNFComponent instances (e.g. used to model access to services provided by containerized environments such as Kubernetes).

A CPD can be of a VduCpd type and describes network connectivity between a VNF instance (based on a VDU) and an internal VL (or external VL if the VduCp is re-exposed as a VnfExtCp), or it can be of a VipCpd type where it is used to model the allocation of virtual IP addresses that can be shared by other CPs, or it can be of a VnfExtCpd type, enabling this VNF to connect with an external VL, i.e. connecting an internal VL to an external VL.

A CP of VnfExtCp type enables the VNF to connect with an external VL. This can be achieved as a re-exposure of a VduCp, VipCp, etc. as a VnfExtCp, or by connecting an internal VL to an external VL. In the latter case, the VnfExtCp typically represents a port in a router.

Data to configure VnfExtCp instances is received in Or-Vnfm (NFVO->VNF) e.g. at VNF instantiation.

Addtional background art is represented by the United States patent application publication number <CIT> and by technical standard document <NPL>).

For many use-cases it is important that several VDUs connect inside a VNF to the same external network, as represented by an external virtual link. In other words, that certain CPs (VduCps or VipCps or VnfExtCps), that are exposed externally, get connected to the same NsVirtualLink. This is information known by the designer of the VNFD, which is also the decision maker, and is of no concern to the NSD designer. This is a VNF design decision, due to service coordination, or isolation or any other purposes.

Moreover, a VNF vendor may need to be able to create a set of VNF types that can be used in the NSD without requiring to change the NSD topology when we change the VNFs internal implementation. With the current modelling, if a new VDU descriptor that has a VnfExtCp is added, a new VnfExtCp is added. Thus, a new requirement to the VNF TOSCA type is needed to be added, thus impacting the NSD topology design too. With the current modelling it is not possible for the VNF designer to specify that he wants to connect several connection points (CP) within the VNF to the same external virtual link (VL). As of now, the only options are:.

An object of embodiments herein is to provide a mechanism for improving management and configurability and/or usability, of a communication network in an efficient manner when handling VNFs.

Thus modelling a VNF and/or configuring managing function e.g. a VNFM using the aggregating node is performed efficiently and leading to an improved management and usability, of the communication network when handling VNFs.

Embodiments herein relate to communication networks in general. <FIG> is a schematic overview depicting a communication network <NUM>. The communication network <NUM> comprises one or more access networks, such as radio access networks (RAN) e.g. a first RAN (RAN1), connected to one or more core networks (CN). The communication network <NUM> may use a number of different technologies, such as Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, <NUM>, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/Enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations. Embodiments herein relate to recent technology trends that are of particular interest in a <NUM> context, however, embodiments are applicable also in further development of the existing communication systems such as e.g. <NUM> and LTE.

In the communication network <NUM>, user equipments (UE) e.g. a UE <NUM> such as a mobile station, a non-access point (non-AP) station (STA), a STA, a wireless device and/or a wireless terminal, are connected via the one or more RANs, to the one or more CNs. It should be understood by those skilled in the art that "UE" is a non-limiting term which means any terminal, wireless communication terminal, user equipment, Machine Type Communication (MTC) device, Internet of Things (IoT) operable device, Device to Device (D2D) terminal, mobile device e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or any device communicating within a cell or service area.

The communication network <NUM> comprises a radio network node <NUM> providing radio coverage over a geographical area, a service area <NUM> or a cell, of a first radio access technology (RAT), such as New Radio (NR), LTE, UMTS, Wi-Fi or similar. The radio network node <NUM> may be a radio access network node such as radio network controller or an access point such as a wireless local area network (WLAN) access point or an Access Point Station (AP STA), an access controller, a base station, e.g. a radio base station such as a NodeB, an evolved Node B (eNB, eNodeB), a gNodeB, a base transceiver station, Access Point Base Station, base station router, a transmission arrangement of a radio base station, a stand-alone access point or any other network unit capable of serving a UE within the service area served by the radio network node <NUM> depending e.g. on the first radio access technology and terminology used.

The communication network <NUM> further comprises a network node <NUM> such as a RAN node and/or a core network node e.g. Radio Software Defined Networking (SDN) node, an Access and Mobility Management Function (AMF) node, an mobility management entity (MME), a serving gateway (S-GW), a Serving GPRS Support Nodes (SGSN) node, or corresponding node in e.g. a <NUM> network or similar. The GPRS meaning General Packet Radio Services.

Embodiments herein relate to VNFs and the implementation of a NFV-MANO architecture for virtualization of using network resources of the RAN, IP Multimedia Subsystem (IMS) and/or the CN, e.g. resources of the radio network node <NUM> and the network node <NUM>. Embodiments herein extends capabilities of the NFV-MANO standard framework to, from an orchestration and management point of view, model trunk port attachments to multiple networks for e.g. "virtual machines" and "operating system containers" that are the software deployment units of a Virtual Network Function (VNF) product.

The NFV-MANO instructs what and where the resources, such as processing capacity and memory storage, are localized and used for a virtual network. The NFV-MANO architecture comprises a controlling network node <NUM> that may comprise a NFVO that delegates the orchestration of the individual VNFs to a managing function such as a VNFM. The controlling network node <NUM> may further comprise the managing function. The NFVO provides deployment specific parameters such as e.g. IP addresses, what deployment level to use, how many deployment units e.g. VMs or Containers to instantiate, etc. to the managing function for a VNF instance to be created by the managing function. It should be noted that the controlling network node <NUM> may be a standalone node or a distributed network node comprising functions distributed over several network nodes.

According to embodiments herein the NFVO of the controlling network node <NUM> configures setup of a VNF in the communication network. Hence, the controlling network node <NUM> initiates a setup of virtual resources wherein an aggregating CP indicates a set of CPs to be connected to a same external VL, thus, a connection point (type) aggregating and connecting a set of CPs to the same external virtual link is modelled and/or executed.

According to embodiments herein a method and the controlling network node <NUM> are provided for specifying and using a special connection point (CP), i.e. the aggregating CP, in the context of NFV-MANO network modelling that allows to expose the set of CPs with a requirement to connect to a same external virtual link. Thus, providing the set of CPs with the requirement to connect to the same external virtual link. The aggregating CP denoted as aggregatorExtCp is there for modelling, basically saying that the set of CPs "covered" by the aggregating CP connects to the particular external virtual link to which the aggregating CP is connected. A VNFD can indicate that certain CPS such as VduCps, or VipCps, or VnfExtCps, are connected to the aggregating CP. Thus, the connectivity of this aggregating CP to an external VL may be defined in an NSD. The logical representation of the involved entities is shown in <FIG>, i.e. a representation of the external connectivity of a VNF using the novel entity. In <FIG> VIP1 and VIP2 are IP addresses for services that for high availability reasons or for capacity scaling reasons are supported on several VM instances. Vip1 for example addresses a service that is supported by all VM instances of the VM-<NUM> type, and VIP2 addresses a service that is supported by all VM instances both of VM-<NUM> type and VM-<NUM> type.

In the VNFD an indication such as a new aggregatorExtCpd Information Element may indicate the references to the internal CPs, e.g. VduCps or VipCps, that are aggregated as shown in Table <NUM>.

In TOSCA terms, i.e. in a TOSCA based VNFD, this is expressed by:.

This is shown in <FIG>, which shows use of the aggregatorExtCp in the TOSCA VNFD.

The TOSCA node type definition of the new node is:
tosca. aggregatorExtCp:
derived_from: tosca. Cp
description: Describes a connection point to aggregate one or more
connection points and expose them as one single external connection
point. requirements:
- virtual_link:
capability: tosca. capabilities. VirtualLinkable
relationship: tosca. relationships. AggregatorVirtualLinksTo
occurrences: [<NUM>, <NUM>]
capabilities:
virtual _linkable:
type: tosca. capabilities. VirtualLinkable.

It is herein proposed a usage of a novel CP node type, denoted also as a aggregating CP, aggregatorExtCp or special CP, to connect several CPs, to an external virtual link e.g. a NsVirtualLink. It can be noted that the aggregatorExtCp may use a specific relationship "AggregateVirtualLinksTo" when matching the requirement to a VirtualLinkable capability provided by a NsVirtualLink node. This allows the NSD designer to easily distinguish at a glimpse the requirement of this external CP from other external CPs, since this requirement (together with the relationship) is visible in the VNF node template.

Note that the aggregatorExtCp does not represent any real resource in the VIM, it is there to model the bridge from the CPs that are aggregated to the external virtual link.

As part of the NSD design it is determined to which NsVirtualLink the VnfExtCps are connected, in particular, the aggregatorExtCp that, as said, always acts as a VnfExtCp.

This may be done with the NsVirtualLinkConnectivity construct in the NSD that associates a certain CP, identifier of the CP Descriptor, to a certain NsVirtualLink, e.g. by means of a VirtualLinkProfile that points to a particular NsVirtualLink Descriptor.

The logical representation is shown in <FIG> shows an illustration of the connectivity of the aggregating CP i.e. aggregatorExtCp using the existing NSD NsVirtualLinkConnectivity Information Element.

The NsVirtualLinkConnectivity Information Element in the NSD will be populated as follows:
NsVirtualLinkConnectivity.

Note that the existing NsVirtualLinkConnectivity IE is not modified. It will simply point to the aggregatorExtCp instance.

If a new version of the VNFD changes the number of Cps aggregated by the aggregatorExtCp the NSD design would not be impacted: the NsVirtualLinkConnectivity will continue showing just one occurrence, i.e. one association between the aggregatorExtCp and the virtual link descriptor, being a benefit of embodiments herein.

It is herein shown a system and method at modelling time where the novel aggregatorExtCp node type is introduced.

<FIG> shows an illustration of a novel template design method. <FIG> presents the change in the template design method as the CPs are not connected (via TOSCA requirements) to the external link(s) but to the aggregatorExtCp. In turn the aggregatorExtCp is connecting towards the external link via a single TOSCA requirement.

Note that this process may be used in different embodiments:.

The design tool and the VnfTemplate configure by adding all VNF content a-priori such as VDUs, VduCps, VipCps, VnfExtCps, VLs. The design tool then adds a node denoted as netConn1 of type AggregatorExtCp to the VnfTemplate. The design tool further connects all relevant Cps (e.g. VduCp, VipCps, etc. ) to netConn1 in the VnfTemplate.

Then the system and methods shown here are used to introduce the aggregatorExtCp into the model.

System and method at runtime, where the example below describes an ETSI NFV orchestration embodiment:
Today NFVO configures the CP instances that are defined as VnfExtCps in the VNFD and sends this configuration to the VNFM via the Or-Vnfm reference point when instantiating the VNF as well as in cases of change of connectivity requests.

With embodiments disclosed herein, this behaviour in the NFVO is enhanced. The NFVO will configure all CP instances aggregated by an aggregatorExtCp and send the configuration data to the VNFM as part of the extVirtualLinkData of the specific virtual link instance to which the aggregatorExtCp is connected. The runtime system is shown in <FIG> and the method is shown in <FIG>.

<FIG> presents a system and method at runtime, where the examples describe an ETSI NFV orchestration embodiment of the controlling network node <NUM>. The controlling network node <NUM> may comprise a normal NFVO to VNFM interaction via the Or-Vnfm interface. The difference is that the configuration data is enhanced by the presence of the aggregatorExtCp in the VNFD model. The aggregatorExtCp is not a real CP, it has no VIM resource associated, so no configuration data will be sent for the aggregatorExtCp in the configuration data.

<FIG> presents a method, by the controlling network node, which the configuration data for an external VL is built in the NFVO before a Vnflcm operation is sent from the NFVO to the VNFM (e.g. an instantiate, scale, or ChangeExtVnfConnectivity requests). Precondition <NUM>: The VNFD of a VNF denoted as VNF1 contains an extCpAggregator denoted as extCpAggregator1 that aggregates a number of CPs (e.g. VduCpds, VipCpds, etc.). Precondition <NUM>: The NSD indicates that extCpAggregator1 is connected to an external virtual link denoted as extVL1. The NFVO populates the InstantiateVnfRequestData to instantiate VNF1. NFVO adds configuration for all the CPs aggregated by extCpAggregator1 to the extCps fields in ExtVirtualLinkData for extVL1. Furthermore, extVirtualLinkData for extVL1 is added to extVirtualLinks. The NFVO then sends the InstantiateVnfRequest for VNF1 to the VNFM. It should be emphasized that all aggregated Cps are connected to the same external VL, extVL1 in this case, as a result of a formal specification in the VNFD.

The method actions performed by the controlling network node <NUM> which may be a distributed node comprising an orchestrator and a VIM or VNFM for handling one or more VNFs in the communication network <NUM> according to the claimed invention will now be described with reference to a flowchart depicted in <FIG>. The actions do not have to be taken in the order stated below, but may be taken in any suitable order. Actions performed in some embodiments are marked with dashed boxes.

Action <NUM>. The controlling network node <NUM> initiates the setup of virtual resources for the VNF wherein the special CP, i.e. the aggregating CP indicates the set of CPs to be connected to the same external virtual link or network, thus, the aggregating CP is configured for connecting the set of CPs to the same external virtual link.

the controlling network node <NUM> may use a model of the VNF with the aggregating CP for connecting the set of CPs to the same external virtual link, for example in addition to the VNFs network interfaces, its storage needs, its compute resource needs, its supported instantiation levels, supported deployment variations, and lifecycle management operations. The set of CPs may comprise a respective requirement of a virtual linkable capability matching a requirement for a virtual linkable capability of the aggregating CP.

Action <NUM>. The controlling network node <NUM> for example the orchestrator, transmits configuration data to the managing function wherein the configuration data comprises the indication to connect the set of CPs, grouped by the aggregating CP, to the same external virtual link, e.g. may transmit indications on how to connect the set of CPs to the same external virtual link. The controlling network node <NUM> initiates the setup by configuring all CPs aggregated by the aggregating CP and the configuration data may be transmitted to the managing function as part of an external link data of an external link to which the aggregating CP is connected.

<FIG> is a block diagram depicting the controlling network node <NUM> for handling one or more VNFs in the communication network according to the claimed invention.

The controlling network node <NUM> may comprise processing circuitry <NUM>, such as one or more processors, configured to perform methods herein.

The controlling network node <NUM> may comprise a initiating unit <NUM>, e.g. a transmitter or transceiver. The controlling network node <NUM>, the processing circuitry <NUM>, and/or the initiating unit <NUM> is configured to initiate the setup of virtual resources for a VNF wherein a special connection point type, i.e. the aggregating CP, indicates the set of CPs to be connected to the same external virtual link or network, thus, the aggregating CP may be configured for connecting the set of CPs to the same external virtual link. The set of CPs may comprise a respective requirement of a virtual linkable capability matching a requirement for a virtual linkable capability of the aggregating CP. Thus, the controlling network node <NUM>, the processing circuitry <NUM>, and/or the initiating unit <NUM> is configured to use the model of the VNF with the aggregating CP for connecting the set of CPs to the same external virtual link, and may further use the model in addition to e.g. the VNFs network interfaces, its storage needs, its compute resource needs, its supported instantiation levels, supported deployment variations, and lifecycle management operations. The controlling network node <NUM>, the processing circuitry <NUM>, and/or the initiating unit <NUM> is configured to transmit configuration data, e. from the orchestrator <NUM>, to the managing function unit <NUM> wherein the configuration data comprises indication to connect the set of CPs, grouped by the aggregating CP, to the same external virtual link, e.g. may transmit indications on how to connect the set of CPs to the same external virtual link. The controlling network node <NUM>, the processing circuitry <NUM>, and/or the initiating unit <NUM> may be configured to initiate the setup by configuring all CPs aggregated by the aggregating CP and the configuration data may be transmitted to the managing function as part of an external link data of an external link to which the aggregating CP is connected.

The controlling network node <NUM> further comprises a memory <NUM>. The memory comprises one or more units to be used to store data on, such as requests, models, CPs, set of CPs, aggregated Cps, virtual linkable capability of CPs, templates, applications to perform the methods disclosed herein when being executed, and similar. The controlling network node <NUM> may comprise a communication interface comprising e.g. a receiver, a transmitter, and/or a transceiver. Thus, it is herein provided the controlling network node <NUM> for handling communication in the communication network, wherein the controlling network node comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said controlling network node is operative to perform any of the methods herein.

The methods according to the embodiments described herein for the controlling network node <NUM> are respectively implemented by means of e.g. a computer program product <NUM> or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the controlling network node <NUM>. The computer program product <NUM> may be stored on a computer-readable storage medium <NUM>, e.g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium <NUM>, having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the controlling network node <NUM>. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium.

It is herein further disclosed a method performed by a design tool that either automatically creates or assists a designer to model the VNF with the aggregating connection point type for aggregating and connecting the set of CPs to a same external virtual link, in addition to the VNFs network interfaces, its storage needs, its compute resource needs, its supported instantiation levels, supported deployment variations, and lifecycle management operations.

In some embodiments a more general term "radio network node" is used and it can correspond to any type of radio-network node or any network node, which communicates with a wireless device and/or with another network node. Examples of network nodes are NodeB, MeNB, SeNB, a network node belonging to Master cell group (MCG) or Secondary cell group (SCG), base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB, network controller, radio-network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, Remote radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), etc..

In some embodiments the non-limiting term wireless device or user equipment (UE) is used and it refers to any type of wireless device communicating with a network node and/or with another wireless device in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, proximity capable UE (aka ProSe UE), machine type UE or UE capable of machine to machine (M2M) communication, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles etc..

Embodiments are applicable to any RAT or multi-RAT systems, where the wireless device receives and/or transmit signals (e.g. data) e.g. New Radio (NR), Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

<FIG>: Telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments.

With reference to <FIG>, in accordance with an embodiment, a communication system includes telecommunication network QQ410, such as a 3GPP-type cellular network, which comprises access network QQ411, such as a radio access network, and core network QQ414. Access network QQ411 comprises a plurality of base stations QQ412a, QQ412b, QQ412c, such as NBs, eNBs, gNBs or other types of wireless access points being examples of the radio network node <NUM> above, each defining a corresponding coverage area QQ413a, QQ413b, QQ413c. Each base station QQ412a, QQ412b, QQ412c is connectable to core network QQ414 over a wired or wireless connection QQ415. A first UE QQ491 located in coverage area QQ413c is configured to wirelessly connect to, or be paged by, the corresponding base station QQ412c. A second UE QQ492 in coverage area QQ413a is wirelessly connectable to the corresponding base station QQ412a. While a plurality of UEs QQ491, QQ492 are illustrated in this example being examples of the wireless device <NUM> above, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station QQ412.

The communication system of <FIG> as a whole enables connectivity between the connected UEs QQ491, QQ492 and host computer QQ430. The connectivity may be described as an over-the-top (OTT) connection QQ450. Host computer QQ430 and the connected UEs QQ491, QQ492 are configured to communicate data and/or signalling via OTT connection QQ450, using access network QQ411, core network QQ414, any intermediate network QQ420 and possible further infrastructure (not shown) as intermediaries. OTT connection QQ450 may be transparent in the sense that the participating communication devices through which OTT connection QQ450 passes are unaware of routing of uplink and downlink communications. For example, base station QQ412 may not or need not be informed about the past routing of an incoming downlink communication with data originating from host computer QQ430 to be forwarded (e.g., handed over) to a connected UE QQ491. Similarly, base station QQ412 need not be aware of the future routing of an outgoing uplink communication originating from the UE QQ491 towards the host computer QQ430.

<FIG>: Host computer communicating via a base station with a user equipment over a partially wireless connection in accordance with some embodiments.

In communication system QQ500, host computer QQ510 comprises hardware QQ515 including communication interface QQ516 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of communication system QQ500. Host computer QQ510 further comprises processing circuitry QQ518, which may have storage and/or processing capabilities. In particular, processing circuitry QQ518 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. Host computer QQ510 further comprises software QQ511, which is stored in or accessible by host computer QQ510 and executable by processing circuitry QQ518. Software QQ511 includes host application QQ512. Host application QQ512 may be operable to provide a service to a remote user, such as UE QQ530 connecting via OTT connection QQ550 terminating at UE QQ530 and host computer QQ510. In providing the service to the remote user, host application QQ512 may provide user data which is transmitted using OTT connection QQ550.

Communication system QQ500 further includes base station QQ520 provided in a telecommunication system and comprising hardware QQ525 enabling it to communicate with host computer QQ510 and with UE QQ530. Hardware QQ525 may include communication interface QQ526 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of communication system QQ500, as well as radio interface QQ527 for setting up and maintaining at least wireless connection QQ570 with UE QQ530 located in a coverage area (not shown in <FIG>) served by base station QQ520. Communication interface QQ526 may be configured to facilitate connection QQ560 to host computer QQ510. Connection QQ560 may be direct or it may pass through a core network (not shown in <FIG>) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, hardware QQ525 of base station QQ520 further includes processing circuitry QQ528, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. Base station QQ520 further has software QQ521 stored internally or accessible via an external connection.

Communication system QQ500 further includes UE QQ530 already referred to. It's hardware QQ535 may include radio interface QQ537 configured to set up and maintain wireless connection QQ570 with a base station serving a coverage area in which UE QQ530 is currently located. Hardware QQ535 of UE QQ530 further includes processing circuitry QQ538, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. UE QQ530 further comprises software QQ531, which is stored in or accessible by UE QQ530 and executable by processing circuitry QQ538. Software QQ531 includes client application QQ532. Client application QQ532 may be operable to provide a service to a human or non-human user via UE QQ530, with the support of host computer QQ510. In host computer QQ510, an executing host application QQ512 may communicate with the executing client application QQ532 via OTT connection QQ550 terminating at UE QQ530 and host computer QQ510. In providing the service to the user, client application QQ532 may receive request data from host application QQ512 and provide user data in response to the request data. OTT connection QQ550 may transfer both the request data and the user data. Client application QQ532 may interact with the user to generate the user data that it provides.

It is noted that host computer QQ510, base station QQ520 and UE QQ530 illustrated in <FIG> may be similar or identical to host computer QQ430, one of base stations QQ412a, QQ412b, QQ412c and one of UEs QQ491, QQ492 of <FIG>, respectively.

In <FIG>, OTT connection QQ550 has been drawn abstractly to illustrate the communication between host computer QQ510 and UE QQ530 via base station QQ520, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from UE QQ530 or from the service provider operating host computer QQ510, or both. While OTT connection QQ550 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

Wireless connection QQ570 between UE QQ530 and base station QQ520 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE QQ530 using OTT connection QQ550, in which wireless connection QQ570 forms the last segment. More precisely, the teachings of these embodiments may improve the latency since modelling a VNF and/or configuring managing function e.g. VNFM is performed efficiently and leading to an improved performance of the communication network when handling VNFs and thereby provide benefits such as reduced waiting time and better responsiveness.

In certain embodiments, measurements may involve proprietary UE signalling facilitating host computer QQ510's measurements of throughput, propagation times, latency and the like.

<FIG>: Methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.

In step QQ610, the host computer provides user data. In substep QQ611 (which may be optional) of step QQ610, the host computer provides the user data by executing a host application. In step QQ620, the host computer initiates a transmission carrying the user data to the UE. In step QQ630 (which may be optional), the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step QQ640 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

In step QQ710 of the method, the host computer provides user data. In step QQ720, the host computer initiates a transmission carrying the user data to the UE. In step QQ730 (which may be optional), the UE receives the user data carried in the transmission.

<FIG>: Methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.

In step QQ810 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step QQ820, the UE provides user data. In substep QQ821 (which may be optional) of step QQ820, the UE provides the user data by executing a client application. In substep QQ811 (which may be optional) of step QQ810, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. Regardless of the specific manner in which the user data was provided, the UE initiates, in substep QQ830 (which may be optional), transmission of the user data to the host computer. In step QQ840 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

In step QQ910 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step QQ920 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step QQ930 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

Claim 1:
A method performed by a controlling network node for handling one or more virtual network functions, VNF, in a communication network, the method comprising:
- initiating (<NUM>) a setup of virtual resources for a VNF, wherein an aggregating connection point , CP, indicates a set of CPs to be connected to a same external virtual link; and
- transmitting (<NUM>) configuration data to a managing function wherein the configuration data comprises an indication to connect the set of CPs, grouped by the aggregating CP, to the same external virtual link,
wherein intiating the setup comprises
- using a model of the VNF with the aggregating connection point for aggregating and connecting the set of CPs to a same external virtual link.