Apparatus and method for deploying intra-network computing in cellular network

Abstract

The invention relates to a device and a method for deploying intra-network computing in a cellular network. A management device for managing a 3GPP network obtains configuration information for enabling a network function to instantiate intra-network computations into application services. And the management equipment sends the configuration information to a network function entity. The network function entity instantiates an intra-network computing service in a 3GPP network domain after receiving the configuration information. The configuration information may be encapsulated as a network service descriptor. By deploying the in-network computing service in the 3GPP network domain, user plane data may be dynamically processed on the way to the data network, and may be reduced. Therefore, traffic can be reduced, time delay is shortened, and network resource utilization rate is improved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology. For example, the present invention relates to a device and method for deploying in-network computing (INC) in a cellular network. Background Art

[0002] Traditionally, network equipment for cellular (or mobile) networks is vendor-specific. The functionality of network equipment (e.g., supported network protocols) is pre-installed. Traditional network equipment is difficult to upgrade after deployment because the onboard hardware chipsets are statically designed and packaged according to predefined specifications. The widely used specifications in the field of mobile communications are developed by a standards organization called the 3rd Generation Partnership Project (3GPP). Mobile networks that comply with 3GPP specifications may also be named 3GPP networks, which may include fifth-generation (5G) mobile networks and 6G mobile networks. 5G mobile networks may also be referred to as 5G new radio (NR) networks. In the present invention, the terms "cellular network", "mobile network" and "3GPP network" may be used interchangeably.

[0003] Edge computing refers to bringing data computing and storage closer to the data source. In order to support edge computing and edge application services (EAS) through 3GPP networks, 3GPP proposed an application architecture that allows application data traffic to be transmitted from UE through the 3GPP core network to the edge data network (E-DN). The edge data network is interoperable with the 3GPP network. The edge data network can host one or more edge application servers for processing application data. In addition, the European Telecommunications Standard Institute (ETSI) has defined a network architecture called "Multi-access edge computing (MEC)" to enable cloud / edge computing capabilities at the edge of the cellular network. Summary of the invention

[0004] Edge computing reduces the distance that data must travel. However, edge application services may bring more and more data traffic through the 3GPP network, especially in the 3GPP core network. This is because some edge application services may cause the UE (or client) to generate a large amount of raw data, which will be processed on the corresponding application server deployed in the edge data network that is interoperable with the 3GPP network. A large amount of raw data needs to be transmitted to the corresponding application server through the 3GPP network. This may cause excessive traffic load in the 3GPP network and may cause network congestion in the 3GPP network. In addition, round-trip delays may also reduce the user experience of application services.

[0005] It should be noted that edge computing is usually an application service or an edge application service. In the present invention, the terms "application service" and "edge application service" can be used interchangeably.

[0006] In view of the above situation, the present invention aims to optimize the data traffic of application services in 3GPP networks. Another object of the present invention is to enable the management plane (MP) of the 3GPP network to support the instantiation of network function instances containing part or all of the application logic defined by the application service provider (ASP) in the 3GPP core network domain. The application logic can be used to implement application services and should be instantiated in the edge application server of the edge data network.

[0007] In addition, it is not clear how to implement in-network computing for application services in mobile networks, especially in the core network of 3GPP networks. According to 3GPP, computing tasks (especially those for user plane purposes) are considered to be application services that should be provided in the data network (DN), which is located outside the 3GPP network domain. In other words, the 3GPP network can only realize the connection from the UE to the data network or the multi-access edge computing system. If an application service provider wants to deploy in-network computing (or in-network application logic (IN-AL)) services for their applications, current cellular networks (such as 5G mobile networks) do not support this operation. More specifically, the management plane of the 3GPP network does not support this operation.

[0008] In other words, the current 3GPP network does not have the support of the management plane and cannot implement network functions including IN-AL deployed in the 3GPP network domain. That is, traditionally, application-specific computing logic can only reside in the edge data network, and only 3GPP standardized and 3GPP defined network functions can be deployed in the 3GPP network domain. Due to this limitation, application services cannot take advantage of in-network computing in mobile networks.

[0009] These and other objects are achieved by the inventive solutions described in the independent claims. Advantageous implementations are further specified in the dependent claims.

[0010] A first aspect of the present invention provides a management device for managing a core network of a cellular network. The management device is used to obtain configuration information of an application service, wherein the application service includes an in-network computing service. In addition, the management device is used to provide the configuration information to a network function (NF) entity of the core network. The configuration information is used to enable the network function entity to instantiate one or more instances for executing the in-network computing service.

[0011] The in-network computing service in the present invention can be understood as directly deploying the application-specific computing logic to the network elements of the forwarding path, such as the network function entity. In other words, the in-network computing service can be referred to as the offload of the (edge) application service running in the core network (such as the 3GPP core network) of the cellular network. In other words, the in-network computing service can be associated with the (edge) application service deployed in the (edge) data network.

[0012] The advantage of this is that processing tasks can start earlier (e.g., in the core network) before reaching the endpoint (e.g., edge data network) where the actual application server is located. Other advantages of supporting in-network computing in the core network of a cellular network can include reducing traffic in the cellular network, reducing service latency (or round-trip latency), and improving resource utilization of the cellular network.

[0013] Optionally, the network function entity may include a programmable network processing unit (NPU). The network function entity may be based on network function virtualization (NFV).

[0014] In an implementation manner of the first aspect, the configuration information may include one or more of the following:

[0015] - the number of the one or more instances required to perform the in-network computing service;

[0016] - Identification information of the application service.

[0017] Optionally, the identification information of the application service may be an identification (identity, ID) value associated with an (edge) application service deployed in an edge data network interoperable with a cellular network.

[0018] In this way, the in-network computing of the network function entity can be identified and linked to the associated (edge) application service. The cellular network can classify the traffic data and redirect the data related to the edge application service to the corresponding network function entity.

[0019] In an implementation manner of the first aspect, the configuration information may also include topology information of two or more instances of the in-network computing service.

[0020] That is, when two or more instances are needed to implement an in-network computing service, the configuration information may also indicate how the two or more instances should be connected to form a specific service graph. The service graph may be a linear path, a tree, or a general graph. Optionally, the topology information may also carry link performance indicators, which may include the minimum bandwidth and minimum link rate between each link in the two or more instances.

[0021] This ensures the quality of service of computing services within the network.

[0022] In an implementation manner of the first aspect, the management device may be configured to obtain the configuration information through the following operations:

[0023] - Receive an instantiation request from an application service provider (ASP);

[0024] - retrieving said configuration information according to said instantiation request.

[0025] Optionally, the application service provider may be a UE.

[0026] Optionally, the instantiation request may indicate which (edge) application service is to be "offloaded" to the network function entity. The management device may then be used to retrieve configuration information according to the indicated (edge) application service.

[0027] In an implementation manner of the first aspect, before instantiating the one or more instances on the network function entity, the management device may also be configured to allocate resources to the network function entity based on the configuration information.

[0028] In this way, when computing services within the network are to be consumed, resources (such as bandwidth, power, computing resources, etc.) can be utilized, thereby improving resource utilization.

[0029] In an implementation manner of the first aspect, the cellular network may include a 3GPP network.

[0030] A 3GPP network may refer to a communication network having a wireless interface defined by the 3GPP technical specifications. A 3GPP network may be, for example, but not limited to, a 5G / 6G mobile network or any variant thereof.

[0031] In an implementation of the first aspect, the management device may include a network functions virtualization management and network orchestration (NFV-MANO) entity. The configuration information may include a network service descriptor (NSD).

[0032] In an implementation of the first aspect, the NFV-MANO entity may include a NFV orchestrator (NFV orchestrator, NFVO) and a directory entity. The NFVO may be used to:

[0033] - receiving the NSD from an operations support system (OSS) and / or a business support system (BSS);

[0034] -Sending said NSD to said directory entity.

[0035] It should be noted that OSS and / or BSS may sometimes be referred to as "OSS / BSS" in the telecommunications field.

[0036] In an implementation manner of the first aspect, the directory entity may be used to:

[0037] - receiving the NSD from the NFVO;

[0038] - Storing said NSD in association with a directory ID.

[0039] In an implementation of the first aspect, the NFV-MANO entity may further include a virtual network function manager (VNFM). The VNFM may be used to:

[0040] - receiving a deployment request from the NFVO, wherein the deployment request includes the catalog ID;

[0041] -Acquire the NSD from the directory entity according to the directory ID;

[0042] -Configuring the one or more instances at the network function entity according to the NSD.

[0043] A second aspect of the present invention provides a network function entity. The network function is used in a core network of a cellular network, and is used to:

[0044] - receiving configuration information of an application service from a management device managing the core network, wherein the application service includes an in-network computing service;

[0045] - Instantiating one or more instances for executing the in-network computing service according to the configuration information.

[0046] In this way, processing tasks can start earlier on the network functional entity before reaching the endpoint where the actual application server is located (such as the edge data network). Other advantages can include reducing traffic in the cellular network, shortening service latency, and improving resource utilization of the cellular network.

[0047] In an implementation manner of the second aspect, the network function entity may be configured to process user plane traffic through the one or more instances.

[0048] In this way, user plane traffic (or user plane data) can be processed “dynamically” and resource utilization can be improved.

[0049] In an implementation manner of the second aspect, the network function entity may be used to:

[0050] -processing the user plane traffic;

[0051] - Send the processed user plane traffic to the application server for further processing.

[0052] Optionally, the user plane traffic can be reduced after being processed by the network function entity. This can reduce the amount of data and avoid traffic congestion between the cellular network and the edge data network where the application server is deployed. In addition, the round-trip delay of the user plane traffic can be shortened.

[0053] In an implementation manner of the second aspect, the network function entity may be used to:

[0054] - Process user-generated data to obtain final results;

[0055] - Sending said final result to the user entity (or UE).

[0056] That is to say, the in-network computing service can be used to fully complete the tasks of the application server. In this way, the full functionality of the application server can be fully integrated into the core network of the cellular network. Therefore, data processing can be closer to the data generator. Therefore, the efficiency of edge computing can be further improved.

[0057] In an implementation manner of the second aspect, the cellular network may include a 3GPP network.

[0058] In an implementation manner of the second aspect, the network function entity includes a user plane function (UPF).

[0059] Optionally, the network function entity may be based on network function virtualization (NFV). Optionally, the network function entity may include one or more programmable network processing units (NPUs). The cellular network (or the operator of the cellular network) may program the network function entity by providing scripts. The scripts may be written, deployed, and executed on the network function entity according to the configuration information. In this way, the network function entity is able to process data packets through user-specific processing logic including in-network computing. Therefore, an opportunity is provided for individually customizing the network infrastructure.

[0060] A third aspect of the present invention provides a method for managing a core network of a cellular network. The method comprises the following steps:

[0061] - the management device obtains configuration information of application services, wherein the application services include in-network computing services;

[0062] - the management device provides the configuration information to a network function entity of the core network, wherein the configuration information is used to enable the network function entity to instantiate one or more instances for executing the in-network computing service.

[0063] In an implementation form of the third aspect, the configuration information may include one or more of the following:

[0064] - the number of the one or more instances required to perform the in-network computing service;

[0065] - Identification information of the application service.

[0066] In an implementation manner of the third aspect, the configuration information may also include topology information of two or more instances of the in-network computing service.

[0067] In an implementation manner of the third aspect, the step of acquiring the configuration information may include:

[0068] - receiving an instantiation request from an application service provider;

[0069] - retrieving said configuration information according to said instantiation request.

[0070] In an implementation manner of the third aspect, before instantiating the one or more instances on the network function entity, the method may further include allocating resources to the network function entity based on the configuration information.

[0071] In an implementation manner of the third aspect, the cellular network may include a 3GPP network.

[0072] In an implementation manner of the third aspect, the management device may include a NFV-MANO entity. The configuration information may include an NSD.

[0073] In an implementation of the third aspect, the NFV-MANO entity may include an NFVO and a directory entity. The method may also include:

[0074] -The NFVO receives the NSD from the OSS / BSS;

[0075] -The NFVO sends the NSD to the directory entity.

[0076] In an implementation manner of the third aspect, the method may further include:

[0077] - the directory entity receives the NSD from the NFVO;

[0078] - The directory entity stores the NSD associated with a directory ID.

[0079] In an implementation manner of the third aspect, the NFV-MANO entity may further include a VNFM. The method may further include:

[0080] - the VNFM receives a deployment request from the NFVO, wherein the deployment request includes the catalog ID;

[0081] -The VNFM obtains the NSD from the directory entity according to the directory ID;

[0082] -The VNFM configures the one or more instances at the network function entity according to the NSD.

[0083] The method of the third aspect and its implementation manner can achieve the same advantages and effects as the management device described in the above first aspect and its implementation manner.

[0084] A fourth aspect of the present invention provides a method for a core network of a cellular network. The method comprises the following steps:

[0085] - A network function entity receives configuration information of an application service from a management device of the core network, wherein the application service includes an in-network computing service;

[0086] -The network function entity instantiates one or more instances for executing the in-network computing service according to the configuration information.

[0087] In an implementation manner of the fourth aspect, the method may further include the network function entity processing user plane traffic through the one or more instances.

[0088] In an implementation of the fourth aspect, the method may further include:

[0089] - the network function entity processes the user plane traffic;

[0090] - The network function entity sends the processed user plane traffic to the application server for further processing.

[0091] In an implementation of the fourth aspect, the method may further include:

[0092] - the network functional entity processes the user-generated data to obtain the final result;

[0093] - The network function entity sends the final result to the user entity.

[0094] In an implementation manner of the fourth aspect, the cellular network may include a 3GPP network.

[0095] In an implementation manner of the fourth aspect, the network function entity includes a UPF.

[0096] The method of the fourth aspect and its implementation manner can achieve the same advantages and effects as the network function entity described in the above second aspect and its implementation manner.

[0097] A fifth aspect of the present invention provides a system, which includes a management device according to the first aspect or any implementation thereof, and at least one network function entity according to the second aspect or any implementation thereof.

[0098] Optionally, when there are two or more network function entities in the system, the two or more network function entities may be cascaded to process user plane traffic.

[0099] A sixth aspect of the present invention provides a computer program comprising instructions, which, when a computer executes the program, cause the computer to perform the method according to the third aspect or any implementation thereof.

[0100] A seventh aspect of the present invention provides another computer program comprising instructions, which, when another computer executes the program, cause the other computer to perform the method according to the fourth aspect or any implementation thereof.

[0101] An eighth aspect of the present invention provides a non-transitory storage medium, which stores executable program code. When a processor executes the executable program code, the method according to the third aspect or any implementation thereof is performed.

[0102] A ninth aspect of the present invention provides a non-transitory storage medium, which stores executable program code. When a processor executes the executable program code, the method according to the fourth aspect or any implementation thereof is performed.

[0103] It should be noted that all devices, elements, units and modules described in this application can be implemented by software or hardware elements or any type of combination thereof. All steps performed by various entities described in this application and the described functions to be performed by various entities are intended to indicate that each entity is used to perform corresponding steps and functions. Although in the description of the following specific embodiments, the specific functions or steps performed by external entities are not reflected in the description of the specific detailed elements of the entity performing the specific steps or functions, it should be clear to the technician that these methods and functions can be implemented in corresponding software or hardware elements or any type of combination thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0104] In conjunction with the accompanying drawings, the following description of specific embodiments will illustrate the above aspects and implementation methods, wherein:

[0105] Figure 1 An example of a management device 100 and at least one network function entity 200 of the present invention is shown;

[0106] Figure 2 An example of the system architecture of the present invention is shown;

[0107] Figure 3 An example of the IN-AL service launch process of the present invention is shown;

[0108] Figure 4 An example of the IN-AL service instantiation process of the present invention is shown;

[0109] Figure 5 A diagram illustrating the method of the present invention;

[0110] Figure 6 A diagram illustrating another method of the present invention. DETAILED DESCRIPTION

[0111] A list of abbreviations used in this disclosure is provided below:

[0112] -INC: In-network computing;

[0113] -IN-AL: In-network application logic;

[0114] -(E-)DN: (Edge) Data Network;

[0115] -MEC: Multi-access edge computing;

[0116] -MP: Management plane;

[0117] -CN: core network;

[0118] -RAN: Radio Access Network;

[0119] -(E)AS: (Edge) Application Services;

[0120] -ASP: Application Service Provider;

[0121] -NS: Network service;

[0122] -NF: Network Function;

[0123] -cNF: Computational Network Function;

[0124] -NSD: Network Service Descriptor;

[0125] -VNF: Virtual Network Function;

[0126] -UPF: User plane function;

[0127] -NFV: Network Function Virtualization;

[0128] -NFVI: NFV infrastructure;

[0129] -NFVO: NFV Orchestrator;

[0130] -VNFM: Virtual Network Function Manager;

[0131] -VIM: Virtual Infrastructure Manager;

[0132] -EM: Element Manager;

[0133] -NFV-MANO: NFV management and orchestration.

[0134] The present invention generally provides an extension to a management plane of a mobile network (eg, a 3GPP network) carrying new information to facilitate new procedures for instantiating an in-network computing service at one or more network functional entities of the mobile network.

[0135] Figure 1 An example of a management device 100 and at least one network function entity 200 of the present invention is shown.

[0136] The management device 100 is used to obtain configuration information 101 of the application service. The application service includes an in-network computing service. In other words, the management device 100 is used to obtain configuration information 101 of the in-network computing service.

[0137] The management device 100 is further configured to provide configuration information 101 to the network function entity 200 of the core network. The configuration information 101 is used to enable the network function entity 200 to instantiate one or more instances for executing in-network computing services in the core network.

[0138] It should be noted that application services including in-network computing services are not standard 3GPP services. More precisely, application services including in-network computing services are defined by corresponding application service providers. Therefore, the configuration information 101 can help instantiate the in-network computing services at the network function entity 200, while the core network itself does not know how to deploy the in-network services without the configuration information 101.

[0139] Optionally, the configuration information 101 may be carried by NSD. NSD is an information model introduced by ETSI, for example since ETSI GR NFV-MAN001v.1.2.1 and other related specifications, to support network function virtualization (NFV). In the present invention, NSD is extended with additional information elements, which can be used to carry the configuration information 101 of the in-network computing service. An example of the NSD of the present invention is specified in Table 1.

[0140] Table 1. NSD for in-network computing

[0141]

[0142] It should be noted that the names of the attributes in Table 1 are only given as examples, and other names may also be used to define the attributes of NSD.

[0143] Optionally, in addition to the extended information element, the in-network computing (or IN-AL) service can share the same attributes of ordinary network services (NS) such as 3GPP services. It should be noted that for cellular networks, network services can be of different types. For example, the network service can be a 3GPP service standardized by 3GPP. Alternatively, the network service can be an application service provided and / or specified by an application service provider. The application service is not a 3GPP service, but user-specific. The in-network computing (or IN-AL) service in the present invention is a specific type of application service. The public attributes of the NSD in the present invention can specify the identifier, version, name, resource requirements, security configuration and image (such as application scripts and / or virtual machine images and / or required software packages) and other meta-information of the IN-AL service. The IN-AL service can be a virtualized instance characterized by an NSD.

[0144] Optionally, unlike conventional network services, IN-AL services may not be standalone, as IN-AL services may be related to existing (edge) application services located in the (edge) data network.

[0145] The EdgeAppId attribute in Table 1 can be used to indicate which (edge) application service the IN-AL service is associated with. Since IN-AL is designed to enhance the experience and performance of existing (edge) application services, the EdgeAppId attribute can be used to inform the core network (or network operator) how the network function entity running the IN-AL service should be linked to the (edge) application service located in the (edge) data network.

[0146] The InstanceNum attribute in Table 1 can be used to indicate the number of instances required to implement the IN-AL service. The InstanceNum attribute is optional and can exist when two or more instances are required. That is, when the (edge) application service of the (edge) data network only requires one instance, this attribute can be omitted. Correspondingly, if InstanceNum is not carried in the NSD, the network function entity can instantiate one instance by default. Optionally, when the (edge) application service of the (edge) data network needs to include two or more instances of application-specific processing logic to implement a specific service, InstanceNum is carried and its value can be greater than 1.

[0147] The InstanceTopo attribute can be used to indicate the topology information of the required number of instances. For example, this attribute can indicate how the instances should be connected to form a specific service graph (linear path, tree, or graph). Network operators must refer to this topology when deploying the required instances.

[0148] The InterNFParams attribute can be used to indicate which intermediate results are to be exchanged between instances. This attribute can include a list of key-value pairs. In each entry in the list, the key can contain the index of the production instance and the consumption instance, and the value can contain the parameters generated from the production instance and sent to the consumption instance.

[0149] Figure 2 An example of the system architecture of the present invention is shown.

[0150] The system architecture exemplarily illustrates a cellular network architecture. The cellular network may include a management plane, a core network, and at least one radio access network. The cellular network may be interoperable with a data network. The data network may be used to deploy one or more application services for executing custom applications. When the data network adopts multi-access edge computing or edge computing, the data network may also be referred to as a multi-access edge computing network or an edge data network.

[0151] The cellular network may be a 3GPP network. Correspondingly, the 3GPP network may include a 3GPP management plane, a 3GPP core network and at least one radio access network. The 3GPP network may be a 5G / 6G communication network. When the 3GPP network is a 5G network, the 3GPP core network may be referred to as a 5G core network (5G core, 5GC) or a 5G evolved packet core network (evolved packet core, EPC). The 3GPP management plane may include an OSS / BSS and an element manager (element manager, EM). The 3GPP core network may include one or more network function entities. A network function entity may also be referred to as a network element (NE), which may be a discrete network entity including a virtualized or non-virtualized network function (NF).

[0152] The system also includes a management device (or management entity) for managing the core network. The management device corresponds to Figure 1management device 100, and can similarly share the same features and functions. 3GPP networks use virtualization technology. For example, some or all of the network function entities of the 3GPP core network can run virtualized network functions to support various 3GPP services. For resource management of virtualized 3GPP networks, the management device can be an NFV management and orchestration (NFV-MANO) element. The NFV-MANO element is a key element of the ETSI NFV architecture. NFV-MANO can be used to coordinate network resources of virtualized applications and lifecycle management of virtual network functions (VNFs) and network services. VNFs can be referred to as network functions based on virtualization technology. NFV-MANO can include the following components: NFV orchestrator (NFV orchestrator, NFVO), VNF manager (VNF manager, VNFM) and virtual infrastructure manager (virtual infrastructure manager, VIM). NFV-MANO can be used to interact with the 3GPP management plane and the 3GPP core network through a dedicated interface.

[0153] Under normal circumstances, user plane traffic (or user plane data) can be generated in the UE or (edge) data network, pass through one or more UPFs of the 3GPP core network, and reach its destination (data network or UE). In the present invention, a management device (such as NFV-MANO) can obtain configuration information of the in-network computing service and provide the configuration information to the UPF. The in-network computing service may include an IN-AL associated with the edge application service of the edge data network. IN-AL can be used to (pre) process user plane traffic at the core network. Therefore, in the present invention, the in-network computing service can be regarded as equivalent to the IN-AL service. The UPF equipped with IN-AL can generally be referred to as a computing network function (cNF). That is, the cNF in the present invention can be regarded as an enhanced version of the UPF for running IN-AL services. The cNF can correspond to Figure 1 The network function entity 200 of the core network can also share the same features and functions. In this way, the edge application service can start processing the user plane traffic in the core network, which is much earlier than processing in the data network. In addition, the user plane traffic can be further reduced after being processed in the core network. Therefore, the amount of data can be significantly reduced and network congestion can be avoided.

[0154] Optionally, multiple cNFs can be used to run in-network computing services. Multiple cNFs can be associated with (edge) application services deployed in a data network (e.g., E-DN / MEC). Optionally, cNFs can operate in two modes: an intermediate processing point, or a termination point for associated application services. For the first mode, the cNF can be responsible for some preparation tasks for the application service. For the second mode, the cNF itself can provide a complete service to the UE. In the second mode, user plane traffic can terminate at the cNF without reaching the final server end of the (edge) data network. The application service provider can decide which mode to use or combine these two modes to design a specific IN-AL by considering the characteristics of the application service, resource availability, and the expected quality of service (QoS) of the application service. When multiple cNFs are used, these two modes can be used in combination. For example, the first cNF can be used as an intermediate processing point, and the second cNF following the first cNF and coupled to the first cNF can be used as a termination point. Alternatively, the second cNF can be used as another intermediate processing point to pass the processing results to the (edge) data network.

[0155] Optionally, deployment of IN-AL in a cellular network may include two phases: the first phase is IN-AL service launch, and the second phase is IN-AL service instantiation.

[0156] Figure 3 An example of the IN-AL service launch process of the present invention is shown.

[0157] It should be noted that, in the present invention, the online process is optional. When deploying IN-AL services in a cellular network, the online process is not necessary and may be performed only once. The online process may include the following steps.

[0158] Step 301: Submit an online request.

[0159] In step 301, the ASP submits a request for an IN-AL service to launch an application service. The NSD information may follow the attributes defined in Table 1. The request may be submitted to the OSS / BSS management entity.

[0160] Step 302: Verify the online request and upload the IN-AL NSD information.

[0161] In step 302, the OSS / BSS management entity receives the online request and verifies its meta information to check whether the ASP can issue such a request. If the verification is successful, the OSS / BSS management entity forwards the request together with the IN-AL NSD information as directory data to the NFVO.

[0162] Optionally, the ASP can be a UE or a third party relative to the network operator. Alternatively, the ASP and the OSS / BSS management entity can also belong to the same operator. In this case, the OSS / BSS management entity can directly submit the online request. This means that the (edge) application service can also be provided by the network operator instead of by a third-party service provider independent of the network operator. In this case, no verification is required.

[0163] Step 303: Send a request to notify the directory entity to store IN-AL NSD information.

[0164] In step 303, the NFVO sends a request message to the directory entity to store the IN-AL NSD information as an IN-AL service directory. The request message contains the IN-AL NSD information specified in Table 1.

[0165] Step 304: Receive a response indicating that the IN-AL service directory has been stored.

[0166] In step 304, the catalog entity stores the IN-AL service catalog and sends a response to the NFVO regarding the status of the rollout event. The response may include an assigned catalog ID that can be used to retrieve the IN-AL NSD, a flag value indicating how the rollout was completed, and other relevant information.

[0167] Step 305: Send a request to upload a service package corresponding to the IN-AL service catalog.

[0168] In step 305, when the go-live is successful, after the NFVO receives the response from the catalog entity, the NFVO sends a service package upload request to the VIM entity. The service package includes the image script required for the IN-AL service. The image script can be composed of multiple parts, which can be instantiated by one or more instances when the deployment request is triggered. Different instances can form a certain IN-AL service topology, in which intermediate parameters and / or results must be exchanged according to the properties specified in Table 1.

[0169] Step 306: Receive a response indicating that the service package has been uploaded.

[0170] In step 306, the NFVO receives a package upload response with the upload status from the VIM. The status may include a flag value indicating how the upload is completed, a package reference identifier, a hash value for subsequent integrity check, and related information.

[0171] Step 307: In response to the online request in steps 301 and 302, an online response is sent.

[0172] In step 307, the NFVO replies to the OSS / BSS with the status of the IN-AL service catalog launch request. The status may include a catalog ID, which may be used when triggering the IN-AL service.

[0173] Step 308: Confirm the online request.

[0174] In step 308, the OSS / BSS sends a confirmation message with the status of the IN-AL directory online request to the ASP.

[0175] Figure 4 An example of the IN-AL service instantiation process of the present invention is shown.

[0176] The instantiation process may include the following steps.

[0177] Step 401: ASP (or OSS / BSS) sends an IN-AL service instantiation request.

[0178] In step 401, the ASP may send an IN-AL service instantiation request to the OSS / BSS, and then to the NFVO. Alternatively, the OSS / BSS itself may initiate the sending of the IN-AL service instantiation request to the NFVO. The request may include an identifier of the IN-AL service catalog referencing the application service (e.g., APP No. 1).

[0179] Optionally, if the IN-AL service catalog is prepared by the UE itself, the ASP may also be the UE. For example, in the online stage, the UE may upload the IN-AL catalog designed and developed according to Table 1.

[0180] The identifier of the IN-AL service directory can be retrieved in a variety of ways, which can be independent of the instantiation request process or dependent on the instantiation request process. In an independent way, the ASP can store the identifier of the IN-AL service directory when the service is online. Alternatively, the ASP can request the identifier of the IN-AL service directory from other parties that store all online directories. For example, if the requested IN-AL service has not been previously online by the ASP itself, the ASP can query the OSS / BSS or other ASP.

[0181] Step 402: NFVO deploys IN-AL service for the identified application service (eg, APP No. 1).

[0182] In step 402, the NFVO may send an IN-AL service deployment request to the VNFM (eg, for APP No. 1). The deployment request may include an identifier of the IN-AL service catalog provided in the request from the OSS / BSS (or originally from the ASP).

[0183] Step 403: VNFM allocates resources for the IN-AL service.

[0184] In step 403, the VNFM receives the deployment request and searches the catalog entity for the identifier of the IN-AL service catalog. The VNFM may retrieve the resource requirements, such as the required number of instances and the resource specifications for each instance listed in Table 1. The VNFM may then reply to the NFVO with a resource allocation profile based on the existing state of the resource pools under the management of the VNFM.

[0185] Step 404: NFVO sends a deployment request with a resource allocation configuration file to VIM.

[0186] In step 404, the NFVO may trigger the IN-AL service instantiation by sending a deployment request with the resource allocation profile provided by the VNFM to the VIM.

[0187] Step 405: VIM allocates resources of NFV infrastructure (NFVI) of the 3GPP domain; VIM attaches each instantiated network function instance to the cellular network (especially the core network).

[0188] In step 405, the VIM receives the IN-AL service instantiation request and implements the specified resource allocation profile to the actual resource pool of the NFVI. The implementation of the specified resource allocation plan may include the following subtasks. The first task may be to implement the topology of the requested instance according to the InstanceTopo attributes defined in Table 1. The task may include allocating resources (such as CPU, memory, and storage resources) in the resource pool for the required instances and the connections between instances according to the topology. The second task may be to configure the instantiated topology through the requested parameters such as link bandwidth, latency, etc. The allocation may be performed based on virtualization technology.

[0189] After step 405 , the network function entity 200 provisioned by the VIM may be considered online or activated.

[0190] Step 406: The VIM sends an instantiation completion response to the NFVO.

[0191] Step 406 is optional, and the VIM may not be used to send an instantiation completion response.

[0192] Alternatively, when instantiation fails, the VIM may be used to send a response to the NFVO with a status of instantiation failure.

[0193] Step 407: NFVO sends a confirmation message to VNFM.

[0194] In step 407, the NFVO sends a confirmation message to the VNFM, indicating that the requested IN-AL service instantiation is completed through the specified resource allocation and the information of the instantiated instance in the NFVI.

[0195] Step 408: The VNFM provides the network function entity 200 with configuration information of the in-network computing service.

[0196] In step 408, the VNFM may configure the instance of the network function entity 200 with the required configuration provided by the configuration information. The configuration information may be application layer specific and may include the attributes of InterNFParams in Table 1. The attribute InterNFParams may include information about which intermediate information is to be exchanged between directly connected instances. The attribute InterNFParams may also indicate the roles of the entry point and exit point of the instance. The configuration information may also include a reference point connected to an associated edge application service with information specified by the attribute EdgeAppId in Table 1. For example, the configuration information may configure access information (e.g., an IP address) of an associated edge application.

[0197] Alternatively, the instantiation in step 405 and the parameter configuration in step 408 can be done by a single entity, rather than in two separate steps by two different entities. If the InterNFParams information is available to the VIM, the VIM can do these two steps directly.

[0198] Generally, since OSS / BSS, NFVO, VNFM, and VIM can be sub-units of the NFV-MANO entity, the NFV-MANO entity can be considered as Figure 1 In the present invention, it can be understood that the instantiation and parameter configuration of the network function entity 200 for running the in-network computing service is completed by the management device 100 as a single entity.

[0199] Step 409: The VNFM notifies the element manager (EM) of the status of the started instance.

[0200] In step 409 , the VNFM may notify the EM of the instantiation and configuration status of the started instance in the NFVI of the IN-AL service (eg, for APP No. 1).

[0201] Step 410: EM enters the instantiation instance.

[0202] In step 410 , the EM may register the instantiation instance of the IN-AL service (eg, for APP No. 1) for management purposes.

[0203] Step 411: The VNFM sends a response indicating that the instantiation is complete.

[0204] In step 411, the VNFM may send a response to the NFVO indicating that the IN-AL service instantiation is complete.

[0205] Step 412: The NFVO sends a response indicating that the instantiation is complete.

[0206] In step 412, the NFVO may forward the instantiation completion response to the OSS / BSS, and optionally, further to the ASP.

[0207] Generally, since NFVO, VNFM and VIM can be sub-units of the NFV-MANO entity as the management device 100, steps 401-407 and 409-411 can be regarded as internal processes of the management device 100. In the present invention, steps 401-407 and 409-411 are optional. Therefore, steps 401-407 and 409-411 may not be necessary for the network function entity 200 to instantiate the in-network computing service. Step 409 only discloses the interaction between the management device 100 and the management plane of the cellular network, while step 410 only discloses the interaction between the network function entity 200 (or the core network) and the management plane of the cellular network. Therefore, steps 409 and 410 are also not necessary for the management device 100 and the network function entity 200 to instantiate the in-network computing service. Step 408 can generally correspond to Figure 1 The interaction between the management device 100 and the network function entity 200 is shown.

[0208] Figure 5 A diagram of a method 500 of the present invention is shown. The method 500 is used to manage a core network of a cellular network, comprising the following steps:

[0209] -Step 501: The management device obtains configuration information of the application service, wherein the application service includes an in-network computing service;

[0210] - Step 502: The management device provides configuration information to a network function entity of the core network, wherein the configuration information is used to enable the network function entity to instantiate one or more instances for executing the in-network computing service;

[0211] From the above Figure 1-4 From the perspective of FIG. 5 , the steps of method 500 may share the same functions and details. Therefore, at this point, the corresponding method implementation will not be described again.

[0212] Figure 6 A diagram of another method 600 of the present invention is shown. The method 600 is used in a core network of a cellular network and comprises the following steps:

[0213] - Step 601: The network function entity receives configuration information of the application service from the management device of the core network, wherein the application service includes an in-network computing service;

[0214] - Step 602: The network function entity instantiates one or more instances for executing the in-network computing service according to the configuration information;

[0215] From the above Figure 1-4 From the perspective of FIG. 6 , the steps of method 600 may share the same functions and details. Therefore, at this point, the corresponding method implementation will not be described again.

[0216] In the present invention, a network function entity may be referred to as a network function element, or simply as a network function. Configuration information used to enable a network function entity to instantiate one or more instances for performing in-network computing services may be referred to as in-network application logic network service descriptor information (IN-AL NSDInfo). IN-AL NSDInfo typically includes an in-network computing service description for edge application services. The in-network computing service description enables a cellular network to support the instantiation of in-network computing in the core network of the cellular network. By using IN-AL NSDInfo to support the launch and instantiation of IN-AL services, the management plane of a cellular network (e.g., a 3GPP network) can directly deploy network function instances that implement in-network computing of edge application services in its core network (e.g., a 3GPP core network). In addition, by including various configurations in IN-AL NSDInfo, the resources of the cellular network can be flexibly and efficiently utilized to deploy in-network computing services for edge application services.

[0217] In the present invention, the management device 100 may be referred to as a collection of management units dedicated to different management and orchestration functions. For example, the management device 100 may include OSS / BSS and / or NFV-MANO. NFV-MANO may include NFVO, VNFM, and VIM. The features and functions disclosed above with respect to any one of OSS / BSS, NFVO, VNFM, and VIM may generally be applied to the management device 100.

[0218] In the present invention, the device (i.e., the management device and the network function entity) may include at least one processor or processing circuit (not shown), which is used to perform, carry out or start various operations of the device described herein. The processing circuit may include hardware and / or the processing circuit may be controlled by software. The hardware may include analog circuits or digital circuits, or both analog circuits and digital circuits. The digital circuit may include components such as an application-specific integrated circuit (ASIC), a field-programmable array (FPGA), a digital signal processor (DSP) or a multi-purpose processor. The device may also include a memory circuit that stores one or more instructions that can be executed by a processor or processing circuit (e.g., executed under the control of software). For example, the memory circuit may include a non-transitory storage medium that stores executable software code, and when the processor or processing circuit executes the executable software code, the executable software code causes the device to perform various operations. In one embodiment, the processing circuit includes one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code that, when executed by one or more processors, causes the apparatus to perform, perform, or initiate the operations or methods described herein.

[0219] The invention has been described in conjunction with various embodiments as examples and implementations. However, from a study of the drawings, the invention and the independent claims, a person skilled in the art will be able to understand and implement other variations when implementing the claimed subject matter. In the claims as well as in the specification, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfil the functions of several entities or items described in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not mean that a combination of these measures cannot be used to advantage.

Claims

1. A management device (100) for managing a core network of a cellular network, characterized in that: The management device (100) is used for: Acquiring configuration information of an application service (101), wherein the application service includes an in-network computing service; The configuration information (101) is provided to a network function entity (200) of the core network, wherein the configuration information (101) is used to enable the network function entity (200) to instantiate one or more instances for executing the in-network computing service.

2. The management device (100) according to claim 1, characterized in that: The configuration information (101) includes one or more of the following: a number of the one or more instances required to perform the in-network computing service; The identification information of the application service.

3. The management device (100) according to claim 1 or 2, characterized in that: The configuration information (101) also includes topology information of two or more instances of the in-network computing service.

4. The management device (100) according to any one of claims 1 to 3, characterized in that: To obtain the configuration information (101), the management device (100) is used to: receiving an instantiation request from an application service provider; The configuration information is retrieved according to the instantiation request (101).

5. The management device (100) according to any one of claims 1 to 4, characterized in that: Before instantiating the one or more instances, the management device (100) is further configured to allocate resources to the network function entity (200) according to the configuration information (101).

6. The management device (100) according to any one of claims 1 to 5, characterized in that: The cellular network includes a 3GPP network.

7. The management device (100) according to claim 6, characterized in that: The management device (100) includes a network function virtualization management and network orchestration NFV-MANO entity, and the configuration information (101) includes a network service descriptor NSD.

8. The management device (100) according to claim 7, characterized in that: The NFV-MANO entity includes a NFV orchestrator NFVO and a directory entity, wherein the NFVO is used to: Receiving the NSD from an operations support system OSS and / or a business support system BSS; The NSD is sent to the directory entity.

9. The management device (100) according to claim 8, characterized in that: The directory entity is used to: receiving the NSD from the NFVO; The NSD is stored in association with the directory identification ID.

10. The management device (100) according to claim 9, characterized in that: The NFV-MANO entity further includes a virtual network function manager VNFM, wherein the VNFM is configured to: receiving a deployment request from the NFVO, wherein the deployment request includes the catalog ID; Obtain the NSD from the directory entity according to the directory ID; The one or more instances are configured at the network function entity (200) according to the NSD.

11. A network function entity (200) for a core network of a cellular network, characterized in that: The network function entity (200) is used for: Receiving configuration information (101) of an application service from a management device (100) that manages the core network, wherein the application service includes an in-network computing service; One or more instances for executing the in-network computing service are instantiated according to the configuration information (101).

12. The network function entity (200) according to claim 11, characterized in that: Used to process user plane traffic through the one or more instances.

13. The network function entity (200) according to claim 12, characterized in that: Used for: Processing the user plane traffic; Send the processed user plane traffic to the application server for further processing.

14. The network function entity (200) according to claim 12 or 13, characterized in that: Used for: Processing user-generated data to obtain final results; The final result is sent to the user entity.

15. The network function entity (200) according to any one of claims 11 to 14, characterized in that: The cellular network includes a 3GPP network.

16. The network function entity (200) according to any one of claims 11 to 15, characterized in that: The network function entity (200) includes a user plane function.

17. A method (500) for managing a core network of a cellular network, characterized in that: The method comprises: The management device (100) obtains (501) configuration information (101) of an application service, wherein the application service comprises an in-network computing service; The management device (100) provides (502) the configuration information (101) to the network function entity (200) of the core network, wherein the configuration information (101) is used to enable the network function entity (200) to instantiate one or more instances for executing the in-network computing service.

18. A method (600) for a core network of a cellular network, characterized in that: The method comprises: The network function entity (200) receives (601) configuration information (101) of an application service from a management device (100) of the core network, wherein the application service includes an in-network computing service; The network function entity (200) instantiates (602) one or more instances for executing the in-network computing service according to the configuration information (101).

19. A computer program, characterized in that The method comprises a program code for executing the method according to claim 17 when the program code is executed on a computer.

20. A computer program, characterized in that The method comprises a program code for executing the method according to claim 18 when the program code is executed on a computer.

Images