System and method for integrating standard and non-standard network services - Patents.com

Abstract

In networks with variable levels of service quality, if a UE connects to an application through a network or network slice whose service characteristics are not optimally defined for the user or application provider, a low level of service may be experienced. This may result from the application being improperly designed, and in fact may be related to the UE and application connecting through a network that is not properly configured for its intended use. To mitigate these problems, applications and UEs may be provided with direct or indirect access to the network configuration environment, enabling them to send standardized QoS requests to network entities between the UE and the application execution environment.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of priority to U.S. Patent Application Serial No. 63 / 231,837, entitled "System and Method of Integrating Standard and Non-Standard Network Services," filed on August 11, 2021, the contents of which are incorporated herein by reference.

[0002] (Technical field) The present application relates generally to a network element for indicating the configuration of a connection, and in particular to a network element for generating, in relation to a request received over a user plane, network configuration instructions associated with a connection between a UE and an application for implementation by a management plane and / or control plane entity. [Background technology]

[0003] The evolution of wireless communication networks has resulted in the deployment of fifth generation (5G) wireless networks. 5G networks offer several improvements over previous generations of wireless networks, notably the ability to support differentiated levels of service throughout the network. This can be done in any of several ways. In the Radio Access Network (RAN), which is typically defined as the part of the network that supports the air interface and is therefore often considered as the network of 5G NodeBs (gNBs), differentiated services are often provided by the provision of different Data Radio Bearers (DRBs) with different Quality of Service (QoS) characteristics. In the network core (also called the core network or packet core), differentiated levels of service can be provided through the use of network slicing. Network slicing allows a common set of network resources to be used as a substrate for many different independent networks, enabling the creation of isolated virtual networks through which various traffic flows can travel. Different network slices can have the ability to support different network topologies, different capacities, latencies, and different types of network traffic. Network slicing allows network operators to support different services that require very different characteristics without having to support each service on the same network by provisioning more resources to each connected device so that the needs of each service are properly supported.

[0004] In some implementations, end-to-end slicing can be provided through the allocation of different sets of DRBs to different network slices. Thus, all traffic received through a given DRB is immediately known to be associated with a particular network slice. Conversely, all traffic received at a gNB from a particular network slice can be transmitted through the associated downlink channel.

[0005] In the network standardization process, network equipment manufacturers, user equipment manufacturers and network operators take care to ensure interoperability between devices. Generally, this has focused on the ability of standard-compliant user equipment to connect to base stations regardless of who manufactured which node. As networks become more advanced, it has also become important to define the interactions between components in the core network and to allow the core network to be a heterogeneous network. However, 5G networks define the role of a User Plane Function (UPF) that is accessed by users and resides in the core network. When a network operator provides an application or a service supported by the UPF, the characteristics of the network slice can be configured to support the needs of the application. However, standardization has not been directed to allowing applications, especially applications outside the core network, to define connectivity requirements (or other application-specific requirements such as network function allocation) to the rest of the network. Similarly, the standardization management and control plane entities lack an interface that allows network applications outside the network core to easily send requests for either configuration modifications or adjustments of network function allocation in terms of application requests or requirements without in-depth knowledge of the network configuration. When a single application provides services to users in different network slices or different networks, there is no standardization mechanism that allows either the user or the application to select the characteristics of the network used to connect the UE to the application.

[0006] It may therefore be advantageous to provide a mechanism for the user or application to provide characteristics that can be used to define the characteristics of the connection between the UE and the application. With respect to Release 17 of the 3GPP 5G standard, there is no standardization mechanism designed to enable a network-accessible application to define or modify any of the QoS network allocations, or other parameters of the intervening network that have an impact on the apparent connectivity between the UE and the network application. There has been discussion of allowing the UE to participate in resource allocation negotiations, but as discussed below, this is insufficient in many situations. The concept of using the UE as a proxy for applications generally stems from the fact that in order to connect to the network, the UE must authenticate the network, and is therefore somewhat known and trusted. In 3GPP Release 17, applications outside the operator network are not considered trusted entities. From the network's perspective, the UE connects to the network using a DRB associated with QoS. The UE accesses the application through this connection. If the connection is under-provisioned, there is no simple mechanism that allows the UE to make this decision automatically. From an application's perspective, there may be several different users, each of which may connect through a different network slice and may use a different access network. Such a scenario means that the user has information associated with the desired QoS, but not information on how to enable such connections. Network operators only see the traffic that flows through a connection to an application or application server, and thus the carrier will not understand the need to tune a given connection. The application itself has information that can be used to identify how to optimally serve several different connections, but this information is currently unavailable unless the application is implemented by the carrier or provided with access to carrier information.Although each different network provider may have information that is useful to an application, this information is opaque to the application. Thus, the ability of an application service provider or network service provider to properly deploy connections is limited under current standardized methods and services.

[0007] This makes it difficult to develop and support applications in a 5G environment; application developers can design applications to run under defined conditions, but the execution environment may not have a way to ensure that a UE accessing the application has a connection that meets the defined conditions. Thus, an application does not have the ability to determine the QoS of a UE connected to the application, nor does it have a mechanism that allows it to specify the QoS to the UE. (Although described in this example as being associated with QoS, it should be understood that this is a simplified example, and other configurable parameters, including application service provider and network operator resource allocations, are opaque to one another.) To further complicate things, if a single application is designed to support connections from multiple different networks, the application may not have a mechanism to determine which network or network slice the UE is connecting through.

[0008] This introduces a tremendous amount of complexity for applications to manage, none of which is transparent to the UE. Thus, a UE that does not have the proper QoS or is communicating with an application through a misclassified DRB will experience an unexplained and inadequate level of service. This results in a poor quality of experience. [Prior art documents] [Patent documents]

[0009] [Patent Document 1] U.S. Patent Application Serial No. 63 / 231,837 Summary of the Invention [Problem to be solved by the invention]

[0010] It is an object of aspects of the present invention to obviate or mitigate the above-mentioned problems of the prior art. [Means for solving the problem]

[0011] In a first aspect of the present invention, a method for generating configuration information associated with a network element is provided, the method comprising the steps of receiving a connection configuration request associated with an application executed on a UE and an application server, a network connecting the UE to the application server, and at least one of a node or a network function in the network, and transmitting configuration information determined according to the received connection configuration request towards the network element associated with the received connection configuration request.

[0012] In an embodiment of the first aspect of the invention, the connection configuration request is sent by one of the UE, the application server, a proxy of the UE, and a proxy of the application server. In another embodiment, the connection configuration request is sent by the application server. In a further embodiment, the sending step towards the network element includes sending a request to configure the network element to a network function in a management plane. In another embodiment, the sending step towards the network element includes sending a request to configure the network element to a management or control plane network function, and optionally the request to configure is sent to a network orchestrator via a management plane entity. In another embodiment, sending the determined UE configuration towards the UE. In another embodiment, the method further includes receiving a connection configuration request from the UE and sending the UE configuration determined according to the configuration request received from the application server towards the UE. In another embodiment, the sending step of the configuration information includes sending to each of the plurality of network elements configuration information associated with a respective element of the plurality of network elements.

[0013] In some embodiments, the method is performed outside the network in which the network element resides. The network in which the network element resides may optionally be a core network of a 3GPP-compliant network. The network in which the network element resides may be a radio access network, which may itself be 3GPP-compliant.

[0014] According to one aspect of the invention, there is provided a method for configuring a connection in a managed network, which can be a newly created connection or an existing connection being reconfigured, comprising the steps of receiving a request associated with a connection between nodes in the managed network from a node via a connection outside the managed network, generating, in an application description function, configuration information associated with the connection according to the received request, and sending a configuration request associated with the generated configuration information towards a network element associated with the connection.

[0015] In an embodiment of this aspect, the request received from a node outside the managed network is formatted according to an outbound application programming interface. In another embodiment, the connection configuration request is received from one of an application server, a user equipment node connected to the managed network, a proxy of the application server, and a proxy of the user equipment node. In another embodiment, the configuration request is formatted according to an application programming interface (API) associated with the network element, optionally the API being different from the outbound API associated with the received request.

[0016] In another embodiment, the request from a node outside the managed network is received through a data plane of a network other than the managed network. In some embodiments, the network element associated with the connection is within one of a control plane of the managed network and a management plane of the managed network. In other embodiments, sending the configuration request toward the network element includes sending the configuration request to a second network element within one of a control plane of the managed network and a management plane of the managed network, and optionally, the configuration request is sent toward the network orchestrator via a network entity of the management plane.

[0017] In some embodiments, the configuration request is sent toward a user equipment (UE) node connected to the managed network, the configuration request being a request for configuration of a connection associated with the UE. Optionally, the received request is received from the UE, the configuration request being determined according to a second request received from an application server outside the managed network. In another embodiment, the received request is associated with a connection between the UE and an application server.

[0018] In another embodiment, generating the configuration information includes generating sets of configuration information data, each set associated with a different network element in the managed network, and sending the configuration request includes sending to each of the different network elements a configuration request associated with a corresponding subset of the configuration information.

[0019] In another embodiment, generating the configuration information further comprises generating a quality of service flow indicator (QFI) associated with the connection. In another embodiment, the managed network is one of a 5G core network, a 5G radio access network, an edge computing network, a 4G core network, a radio access network, and a Wi-Fi network.

[0020] In another embodiment, the connections between nodes in the managed network include a plurality of connections spanning different managed network segments. Optionally, the connections in the plurality of connections include at least one of a connection between a UE and a base station, a connection between a UE and a wireless access point, a connection between a UE and a gNodeB, a connection between a gNodeB and a user plane function (UPF), a connection between a gNodeB and a gateway, a connection between two UPFs, and a connection between a gateway and a UPF.

[0021] In another embodiment, the connections between nodes in the managed network include connections associated with Internet of Things (IoT) devices.

[0022] In another aspect of the present invention, an application description function (ADF) is provided for generating configuration requests associated with connections in a managed network according to requests received from outside the managed network. The ADF includes a processor as well as a first and a second network interface. The first network interface enables the ADF to receive requests from outside the managed network. The second network interface enables the ADF to send requests to network elements in the managed network. The processor can execute instructions stored on a computer-readable medium that, when executed, cause the ADF to perform the above-described methods of each of the embodiments as well as the aforementioned aspects.

[0023] Embodiments of the invention will now be described in detail, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0024] [Figure 1] A diagram showing a model for connecting a UE-based application to a network entity. [Diagram 2] FIG. 2 illustrates another model for connecting applications to network entities. [Diagram 3] FIG. 1 illustrates an embodiment of a network architecture using ADF to enable connectivity. [Figure 4] FIG. 2 illustrates an embodiment of an API stack used to enable an application to negotiate resource allocation with a network control or management entity. [Diagram 5] 1 is a graph showing the relationships between different sets of data and the owners of these data sets. [Figure 6]2 is a network call flow diagram illustrating a messaging method according to an embodiment of the present invention. [Figure 7] FIG. 2 is a block diagram illustrating a connectivity model according to an embodiment of the present invention. [Figure 8] 2 is a network call flow diagram illustrating a messaging method according to an embodiment of the present invention. [Figure 9] 4 is a flow diagram illustrating a method for configuring a network element according to an embodiment of the present invention. [Figure 10] 4 is a flow diagram illustrating a method for requesting a configuration of a network element according to an embodiment of the present invention. [Figure 11] FIG. 2 is a block diagram illustrating a functional diagram of an application-defined function according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] In the above figures, like elements are designated with like numerals wherever possible.

[0026] Reference may be made to parameters in this specification and the accompanying drawings. These parameters are provided for the usability of a single embodiment and should not be considered limiting or essential. It should be understood that the parameters listed below are used to describe the embodiments. It is not intended to convey that a particular parameter is required, nor is the following description intended to be exhaustive when considering parameters on which application-defined functions operate.

[0027] In a dynamic network, such as a 5G network, the network can be configured to serve any of a number of different needs. When a UE connects to a network-based application, there can be several networks through which traffic can flow. Each of these networks has a number of network elements that can be configured to support the connection. Those skilled in the art will appreciate that a wide variety of different configuration parameters can be set for each network element. The following description illustrates both network slicing and QoS. In other embodiments, different configuration parameters can be used. As an example, in some embodiments, power consumption parameters of network elements can be specified when a network connection is to be prioritized for eco-friendly applications. In another embodiment, the configuration parameters can be associated with the processing capacity (also referred to as computer resources) of a given node in the connection path, allowing customized service function chains to be achieved, so that traffic receives appropriate network analysis and treatment. In the following description, the configuration parameters are described with a focus on setting up quality of service guarantees for traffic between the UE and the application server. It should be understood that this description is intended to be exemplary and illustrative. It should be understood that the following description is not limiting.

[0028] In a 5G network, different levels of service may be offered. The radio edge may offer one set of levels of differentiated service, and the core network may offer another set of levels of differentiated service. In some examples, QoS guarantees may be associated with these levels of service. In some networks, different network slices may be associated with different QoS levels.

[0029] The use of network slices can provide differentiated levels of service without requiring the deployment of the highest service level for all connections. For example, a 5G network handset designed to allow users to stream and download content while moving through the network and a fixed device intended for use in a smart grid that guarantees low levels of traffic only intermittently are both UEs. However, they have very different needs in terms of bandwidth and mobility configuration and consumption. Instead of deploying each device consuming the same resources, these devices can be supported using different network slices. Each slice can be designed precisely to support the traffic needs of the intended UE. Similarly, it can be advantageous for a network operator to support two different network configurations for different UEs within the same class of device. For example, two users with the same UE may have different needs regarding latency and bandwidth. A first network slice can be designed to implement low latency traffic associated with real-time communication, and a second slice can be designed for large amounts of data transfer without worrying about latency. An application designed for one of these slices may not perform an acceptable job of supporting UEs connecting through the other slice. In some cases, there may be a third type of slice that is designed for both low latency and high bandwidth, but which may be very expensive for users to access: UEs for which a subscriber has paid for access through this slice will be served fairly when connecting to an application through this slice, but it may be more expensive than necessary.Since standardization bodies such as 3GPP generally focus on standardizing the interaction between UEs and elements in a network operator's network, or between two elements in a network operator's network, the interest in enabling coordination in network resource allocation is generally directed to either a node in the network operator's network (which can generally interact with a control plane network function), or to the UE. Even through communication with a control plane entity such as the AMF or SMF, the UE may request a different QoS or a different allocation of network services, which is an unsatisfactory situation. An application server may request a specific allocation of network resources, but the network may provide such an allocation. If the UE makes the request on behalf of the application, it becomes the node at the center of the negotiation. By allowing the application to interact with the network element without having the UE in place, the application can be properly served to negotiate modified resource allocations and identify other suboptimal network resource allocations that become more accessible through modification of the configuration of the application resources.

[0030] The management and creation of network slices in 5G networks often relies on network virtualization technology, which is considered common in the computer industry. Network Function Virtualization (NFV) allows for the creation of network functions within a network slice. In some embodiments, NFV is used to create fully virtual network entities specific to this slice on general-purpose computing hardware, while in other embodiments, dedicated network functions using specialized hardware resources are used by different slices of network functions that are assigned to different slices of the network. The use of NFV allows for virtualization functions to be configured to meet the needs of a particular network slice. As the needs of the slice grow, new resources can be allocated to the virtualization functions to expand the functionality, or new instances of the functionality can be introduced that allow different network designs and architectures to be implemented.

[0031] Configuration of parameters within the virtual network can also be performed on network connections. Changes in the bandwidth allocated to a connection, or the latency between virtual nodes, can be made via entities in the control plane of the 5G network. Management and Orchestration (MANO) functions can be used in instantiating virtualized functions within the network. However, access to these functions is generally considered off-limits to anyone other than the network operator for both security and reliability reasons.

[0032] The 3rd Generation Partnership Project (3GPP) is the organization responsible for setting the standards under which 5G networks operate. The 3GPP specifications set standards for how UEs connecting to a 5G network are supported to accommodate the different QoS levels that can be provided. The 3GPP specifications also set example QoS assignments that many operators have adopted, with the notion that these QoS assignments must correspond to the required QoS levels. Applications can be designed with these QoS levels in mind, but it can be difficult for an application to determine the QoS levels for different UEs that may connect through different networks and network slices.

[0033] SA2 and SA5 are 3GPP subgroups that respectively define the network functions of the control plane, the user plane connections, topology and functions, and the management plane and how to configure their respective functions. The management plane functions are used by the network operator to define business and charging rules and can be translated into rules and network elements that are generated and enforced by the control plane entities. Typically, these entities are only visible to the network operator. The UE may have limited exposure to the control plane entities and never see the presence of the management plane entities, even if only for short periods of time.

[0034] SA6 is a 3GPP standardization subgroup aimed at enabling support of mission-critical applications and enabling application access to the network. In general, this standardization is directed to supporting mission-critical applications within a network operator's network (or with access to the control plane). The total set of configuration parameters is enormous, since each network element within the network operator's network has a different set of configuration parameters. Application servers outside the operator's network do not have mechanisms to deal with this efficiently or to properly obtain access to sufficient information about the different network operators that may be used by the user for access.

[0035] From a network operator's point of view, it is advantageous to define a relatively small number of QoS levels. This reduces the network complexity and allows for simplified radio management, network engineering and device attachment mechanisms. Applications within the network can be assigned QoS rules by a control plane entity such as an Access and Mobility Management Function (AMF). A core network with reduced complexity allows for easy validation and is reflected by a limited number of Software Defined Function (SDF) templates.

[0036] These configurations and simplifications are designed by 3GPP discussions driven by access and core network equipment vendors and network operators, as mentioned above. UE manufacturers are generally only interested in the parameters of the air interface, which allows them to participate and drive discussions in these areas. UE manufacturers may be interested in how the UE is provided with information related to QoS, but do not tend to be interested in further details. Thus, the rules and modes of operation are generally defined by the network operator without consideration of the developers of the applications that are supposed to be present in the network. This results in a network architecture that makes assumptions about the nature of the network applications that are not based on the capabilities of the 5G network, but instead based on use cases designed for previous generations of networks. Previous generation networks did not consider so-called over-the-top (OTT) applications, which are applications that are simply accessed by the user beyond the top of the network connectivity provided, but 5G networks can realize applications that are present in the network and engage the network operator in the deployment of the service, if configuration is possible. These applications can be tightly coupled to the 5G network, but for this to happen, the applications must be supported by connections with QoS levels that satisfy the needs of the applications. To be sufficiently user friendly, applications must not expose the user to too much technical information that is consistent with the service offerings from the mobile network operator. A mechanism is needed for the application to ensure that the UE is provided with the QoS level it requires. The involvement of the UE or the application in selecting the QoS level is outside the scope of the standards set by SA2 and SA5, which are aimed at the needs of the operator, not the applications to which the operator provides access.

[0037] Although described herein in terms of a 5G network, it should be understood that the core network can be configured according to a number of different standards, including the Long Term Evolution (LTE) standard, and can simultaneously support a number of different radio access technologies, including 5G New Radio, 4G Radio Access (also referred to as LTE), and WiFi. The network resources, either in the core network or in the RAN, can include so-called edge computing networks.

[0038] In order to provide applications with the ability to contribute to or control the service levels provided to UEs already connected to the network, an out-of-band connection management layer is proposed. This connection management function allows applications to provide network requirements, validates these provided network requirements against existing QoS levels (such as QoS levels defined in standards and possibly supplemented by additional QoS levels), and, given an acceptable match, can forward requests for these network requirements to a Software Defined Network (SDN) controller that can provide a UE-to-application network connection that meets (and possibly exceeds) these requirements, or can adjust existing connections to meet (and possibly exceed) these requirements.

[0039] As shown in FIG. 1, this can be accomplished in the network 100 through the use of a network-accessible Application Defined Function (ADF) 102. It should be appreciated that in some embodiments, the ADF 102 can be a function in the 5G core network 104 that is accessible to the UE 106 and the application 108 that reside in the same network as the ADF 102. In other embodiments, the UE 106 and the application 108 can interact with the ADF 102 that is not limited to being embedded in the same network as either the UE 106 or the application 108. In this embodiment, the ADF 102 can request a relationship with the core network 104 so that it can determine the available QoS levels 110. The ADF 102 also requests to be able to determine the network identifier from UE-specific information provided by the application 108 (which may reside in the Internet, but may also have components that reside in the UE 106). It should be appreciated that the different QoS flow identifiers (QFIs) can each terminate at a single point, such as an endpoint of a gNB tunnel. At this point, the packet is transported either via the radio edge or the core network 104 (depending on the particular flow termination). The ADF 102, provided with information about the core network functionality and configuration, enables the configuration of the terminating UPF 112 to automatically attach MPLS labels so that traffic can be routed according to application requirements. Indication of UPF configuration can be accomplished by BGP messages to support integration. It should be understood that the use of MPLS is for purposes of illustration and example. Other routing protocols such as source routing can be used to similar effect. In environments where at least a portion of the network is provided using a metro ring protocol based network, similar directives and procedures can be in place to affect traffic flow and processing, to the extent permitted by the network.This description of alternative protocols is intended to provide examples and should not be taken as an exhaustive description of network architectures and protocols that may be used.

[0040] The ADF 102 can be provided with a full set of QoS levels supported by the network, allowing the ADF 102 to select an appropriate QoS 110. In another embodiment, the ADF 102 can submit a request including an indication of various QoS characteristics for which a connection is required, and receive in response a QoS level selected by the network 110 according to the provided QoS characteristics. In FIG. 1, the ADF 102 is shown communicating with a gNB 114. It should be understood that the ADF 102 can communicate with the gNB 114 to determine which QoS levels 110 are supported by the gNB 114, especially in a network where different segments of the network provide support for different sets of QoS levels. It should also be understood that in some embodiments, the ADF 102 can communicate with another network node and can simply identify either a geographical region or can more precisely identify the region using an identifier of a particular gNB. In this manner, the ADF 102 can have a simplified communication structure, where it communicates with a single network entity (or a small set of network entities) but can obtain information regarding the QoS levels 110 provided by each gNB 114. It should be appreciated that in a RAN sliced ​​network 100, the gNB 114 can be a virtual entity specific to a particular slice. This can be done using an edge computing platform providing the virtualized gNB or by a physical gNB providing the virtualized entity via slicing. It should be appreciated that when a virtual gNB is identified, the original device providing these features can provide some additional QoS levels, but this is not important as they are not provided by the virtual gNB in ​​question. To all devices outside of the control or management plane, the virtual gNB will be indistinguishable from a physical gNB. It should be appreciated that in some embodiments, an LTE compliant eNodeB (eNB) can be connected to the 5G core network 104. The ADF 102 can be used to ensure the configuration of traffic leaving the eNB so that the traffic is formatted and directed to the appropriate 5G core network element.The 5G standardization was designed to make the 5G RAN separate from the 5G core network with the assumption that the 5G RAN may be deployed before the 5G core. However, due to several factors including delays in the allocation of 5G spectrum, the 4G RAN is connected to the 5G core network. Configuring an eNB in ​​a 4G RAN to connect to a dynamic 5G core network is difficult, but through the use of the ADF 102, an entity in the 5G core network can provide the dynamic updates required to the eNB without having to expose interfaces that may have security implications.

[0041] When the ADF 102 identifies and selects the appropriate QoS level for this session between the UE 106 and the network-based portion of the application 108, the ADF 102 can send a request to the SDN controller 116 of the network that can identify at least one of the UE 106 and the application 108. Those skilled in the art will appreciate that some networks can provide a single interface node for the ADF 102 to communicate with. This can allow all requests for gNB information and all requests for connections directed to the SDN controller 116 to be authenticated or verified at a single function. This function can act as an authenticator and proxy for the requests. The function receives, authenticates, and then forwards the requests. The function can generate a response to the request to itself, or can receive responses from other functions in the network and forward the response to the ADF.

[0042] FIG. 2 illustrates a process that may be followed when a requested QoS level is not available or when a more relevant QoS level is available. As previously described, an instance of an application 108 associated with a UE 106 interacts with the ADF 102 to provide network requirements associated with the application 108. The ADF 102 may then send a message to interrogate whether the gNB 114 supports the desired QoS level. Based on the result, the ADF 102 may formulate an alternative QoS request. In some embodiments, this allows a more appropriate QoS level to be selected than the originally requested QoS level. This reformulation request may be sent to the gNB 114 (or to an appropriate proxy as described above) for confirmation and then forwarded to the SDN controller 116 (or to an appropriate proxy). In response to the request sent to the SDN controller 116, the core network entity may send the application network requirements to a node in or associated with the terminating RAN. Those skilled in the art will appreciate that different QoS levels 110 may be associated with radio access connections between the gNB 114 and the UE 106, but also with connections spanning the gNB 114 and the application 118 and far-end devices on the other end of the backhaul. This procedure may result in an end-to-end connection being deployed between the UE 106 and the network portion of the application 108 that satisfies the connectivity requirements of the application 108. If the 5G network 100 can generally provide connectivity that satisfies a reasonable set of requirements, the question of how an application not generated by the network operator can be guaranteed to be deployed in the network is addressed by having the ADF 102 and network entities interact to enable this deployment.

[0043] In some embodiments, the network controller can send a reattach request to the UE 106 instructing the UE 106 to connect to a different network slice or connect via a different DRB. In this manner, the network 100 can ensure that the UE-application connection is satisfied even when the UE 106 is connected to a network slice that cannot support the required connection requirements.

[0044] FIG. 3 illustrates an exemplary embodiment of a network 100 utilizing an ADF 102 as described above. Instances of the ADF 102 are co-located in data centers 122 of a private network 120. Applications 108 are hosted in these data centers 122 and can be accessed both through the private network 120 that connects the data centers 122 to employees 124 at remote locations 126, and through a 5G network service provider 128. This can provide a hybrid environment 100 in which resources of the data centers 122 are accessed through a secure and trusted private network 120 and through a public network 128 where the connection can be secure, but must be deployed such that there is sufficient connectivity and trust to allow access to the applications 108. Both physical and virtual network elements (NEs) 130 can be controlled by an SDN controller with authority over the respective domains. Both control and management planes can be instantiated in this network deployment. The characteristics of access to the applications 108 in the data centers 122 are defined by the ADF 102 associated with the data center 122. When access is obtained from a remote location 126 via known connections, the ADF 102 can send instructions to the SDN controller 116 associated with those connections to ensure that the end-to-end connections between the remote location 126 and the application 108 are properly deployed to provide access through a network connection having characteristics for which the application 108 is designed. When access is initiated through a public network 128, such as a 5G network, the ADF 102 determines network identity information associated with the UE connection in response to the connection with the UE 106, as described above. This network connection information can be associated with the UE 106, the RAN through which the UE 106 is connected, and the core network 104 to which the RAN is connected.The ADF 102 can then determine the available QoS levels 110 and select an appropriate level or can begin the negotiation process outlined above. By setting the QoS 110 for the connection between the UE 106 and the data center 122, the ADF 102 can allow the application 106 to run with the resources it is intended to support.

[0045] FIG. 4 illustrates an architecture 140 in which the ADF 102 responds to the domain level orchestrator 142 for any number of different configuration parameters, including parameters associated with setting the QoS level 110. The ADF 102 can have similar relationships with different orchestrators 142 associated with different mobile networks. In some embodiments, all interactions with the orchestrator 142 are defined through a single API, but the ADF 102 can support different sets of APIs for different orchestrators. The orchestrator 142 is generally a network entity in the management or control plane of the network. The orchestrator 142 communicates with the orchestrator 144 and the SDN controller 116 on smaller segments of the network. The smaller segments can be geographically distinct segments of the network. In other embodiments, these are at least partially overlapping network segments and slices. All of these smaller segments, segments, and slices are supported by the original network infrastructure 146. In some embodiments, this can be a virtualization infrastructure, managed by the orchestrator 144 and the controller 116. At one layer, a physical infrastructure underlies the entire network. This infrastructure may be owned by several different network operators or by a single entity. It should be understood that networks described herein that have a management or control plane are often referred to as managed networks when the connections between nodes or functions in the data plane are managed to provide security and reliable quality of service.

[0046] The ADF 102, sitting on top of the entire network architecture 140, can rely on a set of restful APIs to interact with the applications 108 and a second set of restful APIs for interacting with the orchestrator 142. In this manner, the ADF 102 can respond to any received requests and further send requests to either the applications 108 or the orchestrator 142, if necessary. As mentioned above, the interface with the orchestrator 142 can include communication through a proxy that operates to authenticate communications with the ADF 102 and provide a level of security to the network operator.

[0047] The interaction between the orchestrator 142 and either the instantaneous orchestrator 144 and the controller 116 may be overseen via processes specific to each carrier or network operator. However, this may also require the use of open standards for these communications, including through the use of protocols such as OpenFlow, BGP, OSPF computational requests, and other such requests. In some embodiments, this may include requests for reconfiguration of existing virtual nodes and connections, which may take the form of VNF reconfiguration or instantiation requests, which may be classified as NFV directives. These requests issued to the original controller and orchestrator are determined according to requests received from the ADF 102. This may include authentication of the request (which may be done by another entity as described above) and translation of the received request.

[0048] Requests received by the SDN controller 116 and orchestrator 144 at a domain-specific level can use the origin infrastructure 146 to act on the received domain-specific instructions. By splitting the request into domain-specific instructions at the orchestrator 142, only the domains involved in the connection can be provided with information about the request. This can provide a degree of privacy, reduce overall complexity by only including the relevant network segments, and allow other network segments to operate unobstructed.

[0049] The original infrastructure 146 can be configured only when the domain level controller 116 determines that it has the capability for this request. In a hierarchical orchestrator-SDN controller deployment, each level is generally aware of the overall capabilities of the domain below it, but not necessarily the capabilities of the individual resources within the domain. Two adjacent domains with similar capabilities may have different usage patterns and therefore may respond to implementing different instructions received from a higher level orchestrator.

[0050] This spreads the responsibility for configuration of the network across layers. As shown in FIG. 5, different configuration information 150, 152, 154 can be maintained separately. In a network 156 using network operator configuration of resource availability, part of this configuration information 150 is effectively maintained by hand. An application 108 can contain a portion of configuration data 152 associated with the type of connection and configuration it requests. For example, an application 108 can store information 152 associated with the configuration of a proxy server through which components of the UE-based application 108 access application servers. The ADF 102 can also store configuration information 154 that has been provided by another network entity. In the above example of a proxy server, the ADF 102 can store configuration information 154 that associates a given radio access network with a particular proxy server, such that components of the application 108 running on a UE 106 connecting to a first RAN are directed to the first proxy server and provided with the relevant configuration information 154. When the same UE 106 connects to a different RAN, the ADF 102 can direct the UE 106 to a different proxy server, but can also configure a new proxy server. The specific configuration associated with the ADF-maintained data 154 can be different between the two different proxy servers, but this can be achieved by providing the configuration information to the UE 106 as well. The ADF 102 can also format instructions differently to different proxy servers based on the proxy server's needs. In the event of a network outage, if a connection needs to be reconfigured between the application 108 and the ADF 102, the network orchestrator enabling the connection can be provided with information with knowledge of the network topology and can configure links and virtual nodes to bring the UE-to-application connection back to life.

[0051] 6 illustrates an example call flow 160 in which the ADF 102 helps configure a UE-to-application connection. Upon initialization or boot-up 162, the UE 106 issues an attach request 164 to the gNB 114, causing the UE 106 and the gNB 114 to begin a connection negotiation process as defined by the mobile network standard. This provides the UE 106 with an over-the-air connection with the gNB 114 with a default QoS provided by a default QoS assignment 166. When the UE 106 initiates an application 108 that requests access to a resource accessed via the network with a defined QoS 168, the UE 106 (or the application 108 executing on the UE 106) initiates a connection with the ADF 102 and requests the requested QoS 170. This connection 170 with the ADF 102 provides the ADF 102 with certain information, including the identity of the network or gNB 114 to which the UE 102 is connected, and an indication of the application 108 requesting a connection (or the IP address to which it should connect with connection parameters defining the required QoS).

[0052] The ADF 102 issues a QoS check 172 with a network entity 186 (such as an orchestrator) to determine the available QoS levels. This may include the ADF 102 providing connectivity requirements and receiving a 5G QoS Indicator (5QI), which is similar to the QCI used in earlier network generations including those under the LTE banner. Alternatively, there may be a request for a list of different QoS levels, allowing the ADF 102 to select one of the various QoS levels to use. A similar QoS check 174 may be sent to the gNB 114. This message is optional if the ADF 102 is communicating with an entity capable of both QoS checks.

[0053] A QoS negotiation 176 may begin between the ADF 102, the gNB 114, and a core network function 186, such as a BGP node. In some embodiments, this is a negotiation with a control or management plane entity, such as an orchestrator, which may configure the core network element 186 and the gNB 114 according to the outcome of the negotiation. The ADF 102 or orchestrator may then send endpoint configuration information 178, 180 towards the core network element 186 and the gNB 114 or other RAN elements.

[0054] The QoS response 182 is sent to the UE 106 to enable UE configuration 184. In some embodiments, this may be configured by the ADF 102 and sent to a management or control plane entity, which may cause a node in the core network control plane, such as the AMF or SMF, to send a configuration response to the UE 106. The configuration response from the AMF or SMF may include a reattach instruction that causes the UE 106 to attach to a different network slice that supports the QoS level requested for this connection. It should be understood that the UE 106 does not necessarily need to drop an existing connection with the network if the existing connection can support access to multiple network slices.

[0055] At the end of this process, the UE 106 can connect to the application 108 over a channel that has the necessary characteristics to enable the desired connection.

[0056] The ADF 102 described herein allows several different services to be offered. By acting as an abstraction layer between the applications 108 that perform the services relied upon by the applications and the network functions, the ADF 102 can also insulate both the applications and the network functions from changes in each other. In one example, an application submits a request to the ADF 102, which then maps the request to a specific network function and then sends the request to the network function that is formed according to the received request but formatted for the selected network function. If the original network function is replaced by either an updated version of the network function or by a comparable function from another vendor, this is hidden from the application. Changes in the format of the request accommodated by the network function do not impact the application. This allows network operators to upgrade equipment, use equipment and software from different vendors, and relocate network functions without having to worry about these changes breaking applications that rely on these functions. These changes are only made visible to the ADF 102, and the ADF-to-application interface remains unchanged.

[0057] It should be understood that the interfaces between the ADF 102 and various network functions can use standardized interfaces with the NFs as detailed in 3GPP TS 23 501, and corresponding procedures outlined in TS 23 502. It should also be understood that in cases where the NFs support proprietary interfaces that can provide additional functionality, the ADF 102 can support both standardized and proprietary interfaces.

[0058] The ADF-to-application interface can use a restful interface using standard HTTP messaging between the application 108 and the ADF 102, can use either JavaScript Object Notification (JSON), or some other messaging model. The API can be modified to provide access to new functionality in the original network elements and features without breaking the design of the application. In some embodiments, different versions of the ADF API can be maintained to allow different levels of control or to implement new functionality without breaking the rendering of the application. The ADF network element interface can use both standardized and proprietary interfaces as needed, as described above.

[0059] 7 shows an abstract model of such an interface. A set of applications 108 can interact with the ADF 102 through a publicly defined API, which can take the form of a standardized application API 190. This API 190 can be extended and modified over time, but can provide maximum benefit to application developers by maintaining backward compatibility over time. The network address associated with the ADF 102 can remain constant over time, or the ADF 102 can simply be made discoverable to the application 108. When the application 108 connects to the ADF 102, the application 108 uses ADF function calls. This call interface 192 can also include functionality that allows the ADF 102 to provide API updates to the application 108 or notify application developers of updates to the API 190.

[0060] The ADF 102 can maintain a set of rules 194 and mapping values ​​196 to process application requests to determine how these should be expressed in requests to available network functions 204. This can include both discovery 200 of currently available network functions 204 and execution 198 of rules 194 associated with the discovered network functions to determine whether the application 108 or UE 106 has access to the discovered functions 204 before mapping 196 the received request to a generated request. A variety of network technologies and communication models can be used to interact with the network elements. If the network element in question has a defined 3GPP interface, the 3GPP networking interface can be used by standardized API calls. In some embodiments, a network function 204 can be selected and the ADF 102 can generate a service chain of functions. This service chain can be defined using source routing or Multi-Protocol Label Switching (MPLS), which can help navigate parts of the service chain that are outside the boundaries of the 3GPP network functions (as shown). Other network models and interactions can be supported using different protocols without changing the way applications submit requests or receive responses.

[0061] Much of the above description has described network characteristics such as QoS. It should be understood that this is done for simplicity when describing how one service characteristic is managed. Any request for a network service characterized and supported by the original network element 204 is similarly served by the ADF 102. In one embodiment, a high priority application 108 can interact with the ADF 102 to initiate a new network slice. In one such embodiment, law enforcement or other such emergency services may have an application 108 that provides access to the network slice to a limited number of UEs 106, but only in certain circumstances. Depending on the geographic location of the initiating UE 106, the original network element 204 that generates the new network slice can vary. The ADF 102 can receive a request for a service that must be carried through a new network slice. This service request may not specify that it must be a new network slice, but instead simply indicates a session ID that does not map to a slice. This is treated as an application requesting a new slice. A subsequent application instance 108 in a different UE 106 can provide the same session ID and is then provided with the network slice ID generated for the initial request. This allows the creation of slices and sharing of access to the slices to a limited number of entities without requiring user configuration of the application in the UE.

[0062] As the situation associated with the creation of the network slice evolves, other application requests may be received that will modify the characteristics of the network slice. These may include application calls for more bandwidth, different latency, different encryption or security features, and other such characteristics. The ADF may receive the initial request and provide the requested session to the requesting application without the UE or application being aware that a new network slice is being created or if an existing network slice is being used.

[0063] 8 illustrates a call flow resulting from a method 208 executed or driven by the ADF 102. The ASD 102 receives a message 220 from the US 106 identifying the API or API version (which may be explicitly or implicitly defined) being received along with the resource identifier (e.g., URL and port number) of the application or application server. The ADF 102 authenticates and authorizes the request and provides an authorization message 222 to the UE 102. The UE then sends a message 224 identifying the use case of the connection, which may be an identification of an existing use case in a standard document such as TS29 505. Based on the received use case, the ADF 102 sends a subscription request 226 to the UDR 210, which may be formatted according to TS29 in some embodiments 505. The UDR 210 relays the subscription request information 228 to the UDM 212, which processes the request 503 via a defined procedure, e.g., as defined in TS29. A response 232 is then sent back to the ADF 102, which in some embodiments is done according to a defined procedure. The ADF 102 then provides authentication information 234 to the UE 106 and optionally also sends a policy check 236 to the PCF 214. The PCF 216 can then send a session request 238 to the SMF 216, which then sends a session initiation request 240 to the responsible UPF 218.

[0064] FIG. 9 shows a flow diagram of a method 250 that can be performed by the ADF 102 as described above. In a first step, the ADF 102 receives a request 252 from a UE 106-based application. The request is received through a user plane (also called data plane) connection. The request typically includes information such as the identity of the server to which the UE 106 must connect. This can also be deduced by the ADF 102 according to an application identifier provided by the UE 106. The network through which the UE 106 is connecting can also be explicitly identified or determined by the ADF 102. The ADF 102 can then identify 254 network elements that must be configured for the UE-to-application server connection. Configuration parameters associated with the network elements can then be identified and determined. This determination 254 is made based on the UE 106, the application 108 of the UE 106, the resources available in the network, and the requirements of the application server. The determined configuration, or configuration parameters, can then be transmitted 256 towards the network element, and in some optional embodiments, the corresponding configuration can be sent 258 to the UE 106 (through an existing user plane connection). The transmission 256 of the configuration parameters can be sent to the network element via one or both of a management plane or control plane node or function. In one such embodiment, the ADF 102 can send an instruction to a management plane entity that identifies the network element and the configuration information required. This can be part of a negotiation process, or it can be a strict instruction. The management plane entity can send the instruction to a network orchestrator that can either instantiate the network element or reconfigure the instantiated network element. Alternatively, the ADF 102 can send an instruction to a management plane entity that communicates with a control plane function to implement the determined configuration.In response to receiving the confirmation, the ADF 102 can send an indication to the UE 106 so that the UE 106 can properly use the configured network elements. If the ADF 102 negotiates with a management or control plane entity, the ADF 102 can modify the indication that would otherwise be sent to the UE 106 or a UE-based application.

[0065] Those skilled in the art will understand that in the above flow chart, the ADF 102 can receive a request from an application on the application server 252, and depending on the configuration of the network element, the ADF 102 can store this information, so that any UE 106 can connect a link between the UE 106 and the application server and request this connection configuration without having to perform configuration processing on a per-UE basis, and the established configuration information is immediately provided.

[0066] Similarly, the ADF 102 may use a similar but slightly modified version of the flow diagram above for communications initiated by any number of other nodes, servers, or functions in the network.

[0067] 10 illustrates a method 270 performed by a UE 106 hosting an application 108. First, the UE 106 establishes a connection with a network 272, such as a RAN connected to a packet core network. Having established this network connection 272, the UE 106 may communicate with other nodes using a user plane connection to transmit data. Using such a user plane connection, a request is sent 274 to the ADF 102. This request may identify (explicitly or implicitly) an application server to which the UE-hosted application 108 is to be connected. The request may contain other information, including an explicit identification of the access network through which the UE 106 is connected, the capabilities and capacities of the UE 106, and other such related information. In response to sending this request, the UE 106 may expect to receive 276 a confirmation from the ADF 102 in the form of a network configuration response identifying the characteristics of the established connection. In some embodiments, this may include an identification of the format the application must use to communicate with the application server. Additionally, this may include identification of the particular server to connect to, any proxy servers through which the application server must be accessed, or instructions to reconnect to a different access network (possibly using the provided credentials).

[0068] FIG. 11 illustrates an exemplary configuration of a node 300 supporting the ADF 102 described above. The ADF 102 includes a network interface 310 through which the ADF 102 communicates with the UE 106, and a network element in any of the access network, the core network, and any other network between the UE 106 and the application server. The ADF 102 also includes a processor 302 capable of executing instructions stored in a readable medium 308. These instructions, when executed by the processor 302, cause the node 300 to operate as the ADF 102 according to the above description. The node 300 can be a general-purpose computing platform (either a physical node or a virtualized node) that is transformed into the ADF 102 and performs the above-mentioned method. The ADF 102 can also include a stored mapping table 306 that allows the user request to be received in a given format that is mapped to an instruction suitable for the selected network element. It should be understood that even network elements performing the same function may have different requirements for receiving confirmation information, and thus the mapping between the received request and the network element specific configuration information of the UE can be network element dependent.

[0069] As noted above, the direct connections illustrated in the figures are shown for illustrative purposes and should not be considered as limiting the scope of the invention, which is defined solely in the claims. Nodes shown to be logically connected to one another need not be directly connected as in the examples, but are shown as directly connected for purposes of illustration. [Explanation of symbols]

[0070] 102 Application Defined Functions 108 Applications 190 Standardized Application API 192 Calls 194 rules 196 Mapping 198 Execution 200 Discoveries 202 Integration 204 Available Network Features

Claims

1. A method of claim 1, comprising: receiving a request from a node via a first connection external to a managed network, the request being associated with a second connection between nodes internal to the managed network, the second connection being associated with a plurality of network elements internal to the managed network; generating, at an application description function, a set of configuration information according to the received request, the set of configuration information including a subset of a plurality of element-specific configuration data, each of the subsets of the plurality of element-specific configuration data being mapped to a respective one of the plurality of network elements associated with the second connection; sending corresponding configuration requests towards each of the different network elements associated with the second connection, the configuration requests including a subset of configuration data specific to each of the elements; A method comprising:

2. the request received from the node external to the managed network is formatted according to an outgoing application programming interface; The method of claim 1.

3. the configuration request is received from one of an application server, a user equipment node connected to the managed network, a proxy of the application server, and a proxy of the user equipment node; The method of claim 1.

4. the configuration request is formatted according to an application programming interface (API) associated with the network element; The method of claim 1.

5. The API is different from the outgoing API associated with the received request. The method of claim 4.

6. the request from a node external to the managed network is received through a data plane of a network other than the managed network; The method of claim 1.

7. the network element associated with the connection is in one of a control plane of the managed network and a management plane of the managed network; The method of claim 6.

8. sending the configuration request towards the network element includes sending the configuration request to a second network element within one of a control plane of the managed network and a management plane of the managed network. The method of claim 6.

9. the configuration request is transmitted via the management plane network entity to a network orchestrator; The method of claim 8.

10. the configuration request is sent towards a user equipment (UE) node connected to the managed network, the configuration request being a request for configuration of a connection associated with the UE; The method of claim 1.

11. the received request is received from the UE, and the configuration request is determined according to a second request received from an application server external to the managed network. The method of claim 10.

12. the received request is associated with a connection between the UE and the application server; The method of claim 11.

13. generating the configuration information further comprises generating a Quality of Service Flow Indicator (QFI) associated with the connection; The method of claim 1.

14. The managed network is one of a 5G core network, a 5G radio access network, an edge computing network, a 4G core network, a radio access network, and a Wi-Fi network; The method of claim 1.

15. the connections between nodes in the managed network include multiple connections across different managed network segments; The method of claim 1.

16. The connections in the plurality of connections include at least one of a connection between a UE and a base station, a connection between a UE and a wireless access point, a connection between a UE and a gNodeB, a connection between the gNodeB and a User Plane Function (UPF), a connection between the gNodeB and a gateway, a connection between two UPFs, and a connection between a gateway and a UPF; 16. The method of claim 15.

17. the connections between nodes within the managed network include connections associated with Internet of Things (IoT) devices; The method of claim 1.

18. An application description function (ADF) for generating configuration requests associated with connections within a managed network in accordance with requests received from outside the managed network, the configuration requests comprising: The ADF is a first network interface for receiving requests from outside the managed network; a second network interface for sending a plurality of requests to a plurality of different network elements within the managed network associated with the connection; 10. A processor executing instructions stored on a computer-readable medium that, when executed, causes the ADF to perform the method of claim 1, the method including: generating a set of configuration information including a plurality of element-specific configuration data subsets; and sending a corresponding configuration request to each of the different network elements, the corresponding configuration request including the respective element-specific configuration data subsets. Application Description Functions (ADFs), including:

Images