A first node, a second node, and a third node, a communication system, and a method for handling the mobility of one or more ongoing communication sessions for a device, performed thereby.

Abstract

A method for handling mobility of an ongoing communication session from a source (121) to a target domain (122), each domain comprising at least a first and a second communication network (102). Each session comprises a group of traffic flows having requirements for a quality of service or experience (QoE). A first node (111) determines (202) for each group of flows, in each session having similar requirements for QoE, i) a correspondence between a first set of resources belonging to the first communication network (101) and a respective second set of resources belonging to the second communication network (102) required for the shift, and ii) a respective priority in the shift. The second set of resources comprises a respective pair of service meshes. The first node (111) determines (205) an allocation of a time budget for the shift and provides (206) one or more indications indicative of the determined allocation.

Description

Technical Field

[0001] The present disclosure generally relates to the field of handling mobility in communication networks, and more particularly to a first node, a second node, and a third node for handling the mobility of one or more ongoing communication sessions for a device from a source domain to a target domain, and a method performed thereby.

Background Art

[0002] Computer systems within a communication network can comprise one or more network nodes. A node can comprise one or more processors, memories, receiving ports, and transmitting ports that can execute different functions and operations together with computer program code. A node can be, for example, a server. Nodes can execute all of their functions entirely on the cloud.

[0003] A communication network can cover a geographical area that can be divided into cell areas, and each cell area can be a different type of node, a network node within a radio access network (RAN), a radio network node, or a transmission point (TP), depending on the technology and terminology used, for example, an access node such as a base station (BS), for example, a radio base station (RBS), etc., for example, a gNB, evolved Node B (「eNB」), 「eNodeB」, 「Node B」, 「B node」, or base transceiver station (BTS). A base station can be, for example, a wide area base station, a mid-range base station, a local area A baseThere may be different classes of base stations, such as ground stations and home base stations, and they are based on transmit power, and therefore also on cell size. A cell is a geographical area at a base station site where radio coverage is provided by a base station. A single base station located at a base station site can provide service in one or more cells. Furthermore, each base station may support one or more communication technologies. A telecommunications network can also be a non-cellular system, with network nodes that can provide service to receiving nodes, such as user equipment with serving beams.

[0004] The third-generation partnership project (3GPP®), a standardization body, is currently in the process of specifying a new radio interface called next-generation radio, new radio (NR), or 5G-UTRA, as well as a fifth-generation (5G) packet core network (sometimes referred to as the 5G core network, abbreviated as 5G core (5GC)).

[0005] In 5GC, the Session Management Function (SMF) can support different functions, such as session establishment, modification, and release, as well as policy-related functions, such as interface termination toward policy control functions, billing data collection, billing interface support, and control and coordination of billing data collection in the User Plane Function (UPF). The SMF can receive policy and billing control (PCC) rules from the Policy Control Function (PCF) and configure the UPF accordingly. The UPF can support the processing of user plane (UP) traffic based on rules received from the SMF, such as packet inspection and different enforcement actions such as reporting for billing and quality of service (QoS) processing. The PCF can be understood as supporting a unified policy framework for managing network behavior. The PCF can provide policy and billing control (PCC) rules to the Policy and Billing Enforcement Function (PCEF). The PCF can provide policy rules to the UE via the Access and Mobility Function (AMF). The AMF can manage the access of the UE, for example, when the UE may be connected via different access networks and UE mobility modes. Specifically, AMF can be used to transfer UE rules from PCF to UE. Application functions (AFs) can interact with the 3GPP® core network via network exposure functions (NEFs). AFs can enable external parties to use public application programming interfaces (APIs) provided by the network operator. NEFs can support different functions, for example, different public APIs.

[0006] End users consuming AF through user equipment (UE) may have specific quality of experience (QoE) requirements. Even when UE can move across sites, it may be necessary to maintain good QoE along with session continuity. Session continuity can typically be achieved using seamless service migration and traffic shift (TS) approaches between source and target domains. A domain can be understood as having hardware and software resources that support a group of applications running on a group of computers and interconnected by a group of service meshes that comprise a group of connected networks. A domain may comprise a mobile network (MN) and an edge cloud (EC) network, such as a service mesh-based edge cloud network.

[0007] The latest generation of mobile networks (5G) can have mobility support based on the following components described in Non-Patent Document 1.

[0008] Firstly, AMF, with its three different service and session continuation modes (SSC), provides different levels of disruption during migration.

[0009] Secondly, it is an efficient radio access network (RAN) handover (HO) based on the concept of a tracking area (TA) list, where a cell can be grouped into one or more TAs that can be assigned to a UE as a registered area (RA). The concept of an RA can be used as a base station for the network to track the location of a UE.

[0010] Thirdly, support for registration renewal procedures for UE mobility, where the registration type can be set to Mobility Registration Renewal (MRU). This mechanism can support the re-selection of a new AMF and the transfer of UE-related contexts.

[0011] Fourth, there may be two mechanisms for performing a Next Generation (NG) Radio Access Network (RAN) Handover (HO). The first mechanism may be an Xn-based HO. An Xn-based HO may include a direct handover between NG-RAN nodes via a direct interface known as the Xn interface, including HO preparation and execution stages. At the end of HO execution, the target NG-RAN node can request the AMF to switch the downlink (DL) data path from the source to the target NG-RAN node. The AMF can then request each SMF to switch the data path toward the new NG-RAN node. The SMF can then update the UPF serving the protocol data unit (PDU) session. This Xn-based HO mechanism can only be applied to mobility within the AMF and cannot be used when AMF relocation is required. The second mechanism may be an N2-based HO. An N2-based HO may include the ability of an NG-RAN node to initiate a handover with signaling over the 5G core (5GC) network. This typically involves AMF relocation. NG-RAN nodes can transmit signaling via AMF, which can also include changes to AMF and / or SMF / UPF. N2-based HO also, preparation and may include execution phases. Signaling can always be transported via the core network, but data transfer can occur either directly in the RAN or via the UPF in the core network. This N2-based HO mechanism can be used when there is no Xn signaling interface between the source and target NG-RAN.

[0012] Fifth, the latest generation of mobile networks (5G) may have mobility support, based on the fact that UE-related context data can be transported across different networks. Sixth, there is a traffic steering mechanism managed by traffic policies that can be dynamically injected by SMF and enforced by UPF. Traffic steering may enable dynamic route selection during service migration, including optimized route selection for session data transport.

[0013] Seventh, selective traffic routing to a data network (DN) can support the UPF in diverting traffic to different (local) PDU session anchor (PSA) UPFs and merging downlink (DL) traffic to the UE, for example, by facilitating HO using an uplink classifier (UL-CL) mechanism. This can be achieved based on traffic discovery and traffic forwarding rules provided to the UPF by the SMF. As another example, selective traffic routing to a DN can facilitate HO using an IPv6 multihoming mechanism, allowing the UE to be assigned multiple IPv6 prefixes in a single PDU session. Each prefix may be provided by a separate PSA UPF, each of which has its own N6 interface to the DN. This UPF can support branch point (BP) functionality, which allows it to forward UL traffic to different PSAs and merge DL traffic to the UE. A DN can be understood as an IP network outside the mobile network, but can be connected to the mobile network.

[0014] Eighth, there is very general support for the impact of AF on traffic routing via control plane (CP) solutions. This can allow AF to provide input to 5GC on how certain traffic may need to be routed. AF can send requests directly to the PCF or via the NEF, which can then send requests to the PCF. [Prior art documents] [Non-patent literature]

[0015] [Non-Patent Document 1] S. Rommer, P. Hedman, M. Olsson, L. Frid, S. Sultana and C. Mulligan, 5G Core Networks Powering Digitalization, London: Elsevier Ktd, 2020. Cloud-based computing environments can support service migration, for example, through live service migration using the Checkpoint Restore in Userspace (CRIU) tool for migrating containers, or through simple migration, for example, by service replica instantiation in the target domain and replica teardown in the source domain. Cloud-based computing environments can support traffic shifting, for example, through traffic management frameworks such as L4 / L7 service meshes, and can support incremental deployment of applications, for example, blue / green deployment and canary deployment. This can be done based on mechanisms such as traffic splitting and traffic mirroring at the microservice level, among other things. Support for UE mobility is not common in cloud-native frameworks. The lack of such support for UE mobility in cloud-native frameworks, particularly in mobile edge clouds, can lead to service interruptions or significant quality degradation of services provided to UEs during mobility, thereby negatively impacting the performance of communication networks due to inefficient resource management and resulting in an unsatisfactory user experience. [Overview of the project]

[0016] As part of the development of embodiments of this specification, one or more problems relating to existing technologies are first identified and discussed.

[0017] Generally, current 3GPP® standards for supporting UE mobility (Non-Patent Literature 1) primarily cover systems and mechanisms in mobile networks, but they do not specify many details regarding interaction with AF hosted in edge clouds (ECs). It can be understood that there are important details about these cloud-native applications that are ignored by most 3GPP® standards. Cloud-native applications can generally be based on a set of microservices connected as a service chain and deployed across distributed data centers (DCs). While the latest generations of mobile networks have high-level descriptions of how AF can influence traffic steering in mobile networks, they do not have details on exactly how application interactions can be performed, especially for efficient UE mobility support.

[0018] The de facto standards fostered by the open-source cloud-native community are limited in that they are primarily focused on the development of cloud-native technologies and frameworks, and to some extent, are geared towards distributed clouds. However, to a considerable extent, they seem to fall outside the scope of how these technologies may need to be adapted to deep e-commerce, which may require very close awareness and interaction with mobile networks to guarantee performance, not just best-effort performance. In particular, there are no well-known methods for designing e-commerce native applications that can take mobility support into account, or how mobile e-commerce platforms can provide complexity abstractions regarding mobility support for applications.

[0019] In the cloud-native community, there are fairly new and popular practices or frameworks for unified traffic management based on so-called service meshes. L4 / L7 service meshes can be understood as supporting a very fine-grained level of control over traffic, based, among other things, on strategies such as traffic splitting and traffic mirroring. This traffic management mechanism can give limited support at the microservice level, focusing on a one-hop oriented approach, for example, handling communication between pairs of microservices. It can be understood that a service-chain oriented mechanism for traffic management is necessary, considering not only the performance between each pair of microservices but also the impact on the entire service chain.

[0020] Currently, L4 / L7 service meshes appear inefficient and insufficient in terms of their applicability to mobile e-commerce / telco clouds, as they do not provide performance guarantees. On the contrary, they can generate data path overhead, i.e., extra latency. Furthermore, this framework does not provide dedicated support for the requirements of applications hosted in mobile e-commerce, such as UE mobility support and differentiated traffic handling.

[0021] In short, procedures for mobility support in mobile networks do not interact with or consider information regarding service migration and traffic shift in EC, nor do EC technologies consider information regarding handover procedures in mobile networks.

[0022] Embodiments of this specification address negligence, misalignment, and non-coordination between mobile networks and EC when performing service migration and traffic shifts during UE mobility events. These issues can be caused by fragmentation of different technological domains, such as mobile networks, cloud, and applications, resulting from the separation of concerns involved in the mobile EC ecosystem. It can be understood that addressing these technological limitations is crucial to providing the performance assurance required by the more stringent requirements of next-generation applications.

[0023] Therefore, an objective of the embodiments herein is to improve the handling of mobility in a communication network. In particular, an objective of the embodiments herein is to improve the handling mobility of one or more ongoing communication sessions for a device from a source domain to a target domain.

[0024] According to a first aspect of the embodiments of this specification, the objective is achieved by a computer implementation method performed by a first node. The method is for handling the mobility of one or more ongoing communication sessions for a device from a source domain to a target domain. Each of the source domain and the target domain comprises at least a first communication network and a second communication network. Each of the one or more ongoing communication sessions comprises a group of traffic flows having requirements for quality of service or experience. The first node operates in at least one of the first communication network, the second communication network, and another communication network. For a group of traffic flows, the first node determines the respective correspondence between each first set of resources belonging to the first communication network and each second set of resources belonging to the second communication network, which are estimated to be necessary for the shift in each of the one or more ongoing communication sessions having similar requirements for quality of service or experience. The first set of resources comprises each pair of core mobile networks comprising one or more source mobile networks and one or more target mobile networks. The second set of resources comprises each pair of service meshes comprising a source service mesh and a target service mesh. The first node also determines the respective priority in the shift for each pair of resources in each of the one or more ongoing communication sessions that have similar requirements for quality of service or experience for each group of traffic flows. The first node then determines the allocation of the time budget for the shift between the first and second communication networks. This is done for each of the first and second communication networks and communicationIt is executed by doing so. The determination of the time budget allocation is based on each pair of the core mobile network, each pair of the service mesh, and each priority according to the respective end-to-end performance requirements of the shifts. Then, the first node gives one or more indications to at least one of a second node operating within the first communication network and a third node operating within the second communication network. The one or more indications indicate the determined Distribution shown.

[0025] According to a second aspect of the embodiments of this specification, the object is achieved by a computer-implemented method executed by a second node. The method is for handling the mobility of one or more ongoing communication sessions for a device from a source domain to a target domain. Each of the source domain and the target domain comprises at least a first communication network and a second communication network. Each of the one or more ongoing communication sessions comprises a respective group of traffic flows having respective requirements for the quality of service or experience. The second node operates in the first communication network. The second node provides, to a first node operating in at least one of the first communication network, the second communication network, and another communication network, each of the respective groups of traffic flows in each of the one or more ongoing communication sessions having similar requirements for the quality of service or experience, the first communication network In reality feasible first fruitA feasible migration budget is provided. The second node then obtains from the first node, for each group of traffic flows in each of the one or more ongoing communication sessions to be shifted from the source domain to the target domain, one or more indications indicating each group of traffic flows having similar requirements for quality of service or experience or experience, and an allocation of the time budget for the shift between the source domain and the target domain. The obtained allocation of the time budget is based on the first feasible migration budget provided and the respective end-to-end performance requirements for the shift, which are feasible for the first communication network.

[0026] According to a third aspect of the embodiments of the present specification, the object is achieved by a computer-implemented method executed by a third node. The method is for handling the mobility of one or more ongoing communication sessions for a device from a source domain to a target domain. Each of the source domain and the target domain comprises at least a first communication network and a second communication network. Each of the one or more ongoing communication sessions comprises a respective group of traffic flows having respective requirements for quality of service or experience. The third node operates in the second communication network. The third node provides a second migration budget executable in the second communication network to a first node operating in at least one of the first communication network, the second communication network, and another communication network, for each respective group of traffic flows in each of the one or more ongoing communication sessions having similar requirements for quality of service or experience. The third node also obtains one or more third indications indicating the allocation of a time budget for the shift between the first communication network and the second communication network, for each respective group of traffic flows in each of the one or more ongoing communication sessions to be shifted from the source domain to the target domain, from the first node, for each respective group of traffic flows having similar requirements for quality of service or experience. The obtained allocation of the time budget is based on the provided second migration budget executable in the second communication network.

[0027] According to a fourth aspect of the embodiments of this specification, the objective is achieved by a first node for handling the mobility of one or more ongoing communication sessions for a device from a source domain to a target domain. Each of the source domain and the target domain is configured to include at least a first communication network and a second communication network. Each of the one or more ongoing communication sessions is configured to include each group of traffic flows having respective requirements for quality of service or experience. The first node is configured to operate in at least one of the first communication network, the second communication network, and another communication network. For each group of traffic flows, the first node is further configured to determine, for each of the one or more ongoing communication sessions having similar requirements for quality of service or experience, the respective correspondence between i) a first set of resources configured to belong to the first communication network and a second set of resources configured to belong to the second communication network, which is presumed to be necessary for the shift. The first set of resources is configured to include each pair of core mobile networks configured to include one or more source mobile networks and one or more target mobile networks. The second set of resources is configured to comprise each pair of service meshes, each configured to include a source service mesh and a target service mesh. The first node is also configured to determine, for each group of traffic flows, the respective priority of each pair of resources in shifts for each of the one or more ongoing communication sessions having similar requirements for quality of service or experience. The first node is also configured to determine the allocation of time budgets for shifts between the first and second communication networks by exchanging communications with each of the first and second communication networks.The determination of time budget allocation is configured to be based on each pair of core mobile networks, each pair of service meshes, and their respective priorities, according to the end-to-end performance requirements for each shift. The first node is further configured to give one or more indications to at least one of the following: a second node configured to operate in the first communication network, and a third node configured to operate in the second communication network. The one or more indications are configured to show the allocation configured to be determined.

[0028] According to a fifth aspect of the embodiments of this specification, the objective is achieved by a second node for handling the mobility of one or more ongoing communication sessions for a device from a source domain to a target domain. Each of the source domain and the target domain is configured to include at least a first communication network and a second communication network. Each of the one or more ongoing communication sessions is configured to include each group of traffic flows having respective requirements for quality of service or experience. The second node is configured to operate in the first communication network. The second node is further configured to provide the first node, which is configured to operate in at least one of the first communication network, the second communication network, and another communication network, with a first executable migration budget executable in the first communication network for each group of traffic flows in each of the one or more ongoing communication sessions having similar requirements for quality of service or experience. The second node is also configured to receive one or more third indications from the first node, configured to show the allocation of a time budget for the shift between the source and target domains for each group of traffic flows in each of the one or more ongoing communication sessions that should be shifted from the source domain to the target domain, and for each group of traffic flows that have similar requirements for quality of service or experience. The time budget allocation configured to be received is configured to be based on a first viable migration budget that is viable for the first communication network configured to be provided, and the respective end-to-end performance requirements for the shift.

[0029] According to a sixth aspect of the embodiments of this specification, the objective is achieved by a third node for handling the mobility of one or more ongoing communication sessions for a device from a source domain to a target domain. Each of the source domain and the target domain is configured to include at least a first communication network and a second communication network. Each of the one or more ongoing communication sessions is configured to include each group of traffic flows having respective requirements for quality of service or experience. The third node is configured to operate in the second communication network. The third node is further configured to provide the first node, which is configured to operate in at least one of the first communication network, the second communication network, and another communication network, with a second feasible migration budget for each group of traffic flows in each of the one or more ongoing communication sessions having similar requirements for quality of service or experience. The third node is also configured to receive one or more third indications from the first node, configured to show the allocation of a time budget for the shift between the first and second communication networks for each group of traffic flows in each of the one or more ongoing communication sessions that should be shifted from the source domain to the target domain, and for each group of traffic flows that have similar requirements for quality of service or experience. The time budget allocation configured to be received is configured to be based on a second migration budget that is feasible for the second communication network configured to be provided.

[0030] As a first advantage, it can be understood that embodiments of this specification are built upon a novel converged or aligned traffic differentiation system in a second communication network (e.g., a service mesh-based edge cloud) in accordance with QoS assurance and UE session information of a first communication network (e.g., a mobile network).

[0031] Another advantage is that the embodiments of this specification, based on the concept of a group of traffic flows or traffic aggregates, can reduce cross-domain signaling between a first communication network, e.g., a mobile network, and a second communication network, e.g., an edge cloud, and thus reduce congested inter-domain control planes. This can result in reduced communication costs and energy savings.

[0032] Another advantage may be understood to be that embodiments of this specification enable signaling forwarding between a first communication network, for example, a mobile network, and a data network, and between the data network and a service mesh, to be performed both based on their associated migration budgets and taking into account the priorities associated with the traffic aggregate.

[0033] As a further advantage, embodiments of this specification can be understood to perform the dynamic allocation of available migration budgets, such as e2e service downtime, between a first communication network, such as a mobile network, and a second communication network, such as an edge cloud, along with the optimized selection of traffic shifting strategies and traffic shifting scheduling. [Brief explanation of the drawing]

[0034] Examples of embodiments of this specification will be described in more detail with reference to the accompanying drawings, as described below. [Figure 1] Figure 1 is a schematic diagram showing a non-limiting example of a communication system according to the embodiments of this specification. [Figure 2] Figure 2 is a flowchart showing an embodiment of the method at the first node according to the embodiments of this specification. [Figure 3] Figure 3 is a flowchart showing an embodiment of the method at the second node according to the embodiments of this specification. [Figure 4] Figure 4 is a flowchart showing an embodiment of the method at the third node according to the embodiments of this specification. [Figure 5] Figure 5 is a schematic diagram illustrating a non-limiting example of the method performed by the first node, the second node, and the third node according to embodiments of this specification. [Figure 6] Figure 6 is a schematic diagram illustrating a non-limiting example of the method performed by the first node, the second node, and the third node according to embodiments of this specification. [Figure 7] Figure 7 is a schematic diagram illustrating a non-limiting example of the method performed by the first node, the second node, and the third node according to embodiments of this specification. [Figure 8] Figure 8 is a schematic diagram illustrating a non-limiting example of the method performed by the first node, the second node, and the third node according to embodiments of this specification. [Figure 9] Figure 9 is a schematic diagram illustrating a non-limiting example of the method performed by the first node, the second node, and the third node according to embodiments of this specification. [Figure 10] Figure 10 is a schematic diagram illustrating a non-limiting example of the method performed by the first node, the second node, and the third node according to embodiments of this specification. [Figure 11] Figure 11 is a schematic block diagram showing two non-limiting examples a) and b) of the first node according to embodiments herein. [Figure 12] Figure 12 is a schematic block diagram showing two non-limiting examples a) and b) of the second node according to embodiments herein. [Figure 13] Figure 13 is a schematic block diagram showing two non-limiting examples a) and b) of the third node according to embodiments herein. [Modes for carrying out the invention]

[0035] The present disclosure and certain aspects of its embodiments may provide solutions to the problems described in the “Summary of the Invention” section or other problems. Various embodiments are proposed herein that address one or more of the problems disclosed herein.

[0036] In general, the embodiments described herein may be understood to relate to converged traffic shifting for service mesh-based mobile e-commerce.

[0037] The overarching objective of the embodiments herein can be understood as providing a convergence mechanism for optimized traffic shifting, aligned with the mobile network for the mobile edge cloud during UE mobility events. The overarching technical effect can then be understood as providing an efficient traffic steering mechanism that can provide performance assurance even during UE mobility events by providing seamless, integrated cloud-native traffic shifting.

[0038] Embodiments of this specification can be based on a novel cloud-native approach to traffic management known as L4 / L7 service mesh. Furthermore, embodiments of this specification can enable enhanced traffic shifting by aligning with information and signaling from mobile networks.

[0039] Embodiments of this specification may further aim to enable cross-domain signaling during UE mobility, for example, mobile network-EC reduction, by at least one of the following options. In one aspect, embodiments of this specification provide a mapping between different levels of traffic aggregation and session management supported by the mobile network user plane toward service mesh-based EC, based on elements constituting the mobile network user plane, such as PDU sessions, quality of service (QoS) flows, and service data flows (SDFs). In a second aspect, embodiments of this specification provide a service mesh-based traffic shifting strategy based on aligned traffic flow groups, which may be referred to herein as “traffic aggregation,” instead of per microservice pair, which may be understood as a common approach in service meshes today. In a third aspect, embodiments of this specification provide an efficient method for propagating mobility event notifications toward associated data networks and toward associated service meshes for each traffic aggregate between mobile networks, based on priority information derived from associated migration budgets.

[0040] Embodiments of this specification may, as a first option, further aim to enable the dynamically aligned delivery of available migration budgets between mobile networks and the cloud in an optimized manner by providing inter-domain awareness of traffic exchange status for selecting the most appropriate strategy for efficient traffic shifting in a service mesh, such as traffic mirroring or traffic splitting. As a second option, embodiments of this specification may aim to enable the dynamically aligned delivery of available migration budgets between mobile networks and the cloud in an optimized manner by providing a method for prioritizing or organizing which traffic aggregates may need to be shifted first to meet the migration budget.

[0041] Herein, embodiments are described more fully with reference to the accompanying drawings illustrating the embodiments. In this section, the embodiments described herein are illustrated by exemplary embodiments. It should be noted that these embodiments are not mutually exclusive. Components from one embodiment or example may be implicitly assumed to be present in another embodiment or example, and it will be obvious to those skilled in the art how those components may be used in other exemplary embodiments. All possible combinations are not described for the sake of brevity.

[0042] Figure 1 shows two non-limiting examples in panels "a" and "b" of a communication system in which embodiments of this specification may be implemented. The communication system comprises a first communication network 101 and a second communication network 102. In some embodiments, the communication system may also comprise another communication network 103.

[0043] In some examples, one of the first communication networks 101, another communication network 103, may be understood to be a mobile network. A mobile network may be understood to refer to the mobile core network, which provides or facilitates access to the mobile core network wirelessly, for example, via RAN or Wi-Fi. A mobile core network mode may be understood to be the central part of the entire mobile network. A mobile network may be understood to enable, for example, mobile subscribers to obtain access to services they may be entitled to use. A mobile core network may be understood to be responsible for functions such as subscriber profile information, subscriber location, service authentication, and any necessary switching functions for voice and data sessions. Embodiments may be, for example, a 5G core (5GC) or an advanced packet core (EPC).

[0044] Both the first communication network 101 and the other communication network 103 may be computer networks in some exemplary implementations, as shown in the non-limiting example in Figure 1a. In other exemplary implementations, as shown in the non-limiting example in Figure 1b, the communication system may be implemented in a telecommunications system, sometimes also called a telecommunications network, cellular radio system, cellular network, or wireless communication system. In some examples, the telecommunications system may comprise network nodes that can serve receiving nodes, such as radio devices, along with serving beams. In some examples, the telecommunications system may be a network, such as a 5G system, or a newer system that supports similar functionality. In some examples, the telecommunications system may be a Long-Term Evolution (LTE) network, such as a 4G system, such as LTE Frequency Division Duplex (FDD), LTE Time Division Duplex (TDD), LTE Half-Duplex Frequency Division Duplex (HD-FDD), or LTE operating in unlicensed bands. Telecommunications systems include Wideband Code Division Multiple Access (WCDMA®), Universal Terrestrial Radio Access (UTRA) TDD, Global System for Mobile Communications (GSM) network, GSM / GSM Evolutionary Extended Data Rate (EDGE) Radio Access Network (GERAN), Ultra Mobile Broadband (UMB), EDGE, Multi-standardIt can further support other technologies such as networks with combinations of radio access technologies (RATs) like wireless (MSR) base stations and multiple RAT base stations, any 3rd Generation Partnership Project (3GPP®) cellular networks, wireless local area networks (WLANs) or WiFi networks, global interoperability for microwave access (WiMAX), IEEE 802.15.4-based low-power short-range networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LowPAN), and any combination of Zigbee, Z-Wave, and Bluetooth Low Energy (BLE), as well as cellular networks or systems. Telecommunication systems can support, for example, low-power wide-area networks (LPWANs). LPWAN technologies may include Long-Range Physical Layer Protocol (LoRa), Haystack, SigFox, LTE-M, and Narrowband IoT (NB-IoT).

[0045] A second communication network 102, and in some examples another communication network 103, may be understood as a network of computers in the cloud, e.g., servers. In particular, in some embodiments, one of the first communication networks 101, and in some examples another communication network 103, may be understood as an edge cloud network, e.g., a service mesh-based edge cloud. An edge cloud network may be understood as a set of data networks that provide connectivity to a cloud ecosystem encompassing storage and computing assets hosting a set of distributed applications or workloads. An edge cloud network may be geographically close to the mobile network points where it exists and therefore close to the end users it can serve.

[0046] Another communication network 103 can be understood as a network different from either the first communication network 101 or the second communication network 102.

[0047] The communication system may comprise multiple nodes, including a first node 111, a second node 112, and a third node 113. Each of the first node 111, the second node 112, and the third node 113 can be understood as a first computer system, a second computer system, and a third computer system, respectively. In some examples, each of the first node 111, the second node 112, and the third node 113 may be implemented as a standalone server in a host computer in the cloud, for example. In some examples, each of the first node 111, the second node 112, and the third node 113 may be a distributed node or distributed server, with some of their respective functions implemented locally by, for example, a client manager, and some of their functions implemented in the cloud by, for example, a server manager. In yet another embodiment, each of the first node 111, the second node 112, and the third node 113 may be implemented as a processing resource in a server farm.

[0048] In some embodiments, the first node 111, the second node 112, and the third node 113 may all be independent, separate nodes. In other embodiments, the first node 111 and either the first node 111 or the third node 113 may be located in the same place or may be the same node. All possible combinations are not shown in Figure 1 for the sake of simplification.

[0049] It can be understood that the communication system may have more nodes than those shown in Figure 1.

[0050] The first node 111, the second node 112, and the third node 113 can all be understood as nodes capable of handling mobility functions. That is, the first node 111, the second node 112, and the third node 113 can all be understood as nodes capable of handling the mobility of one or more ongoing communication sessions for devices such as the device 130 described below, from the source domain 121 to the target domain 122. As mentioned above, a domain can be understood to have hardware and software resources that support a group of applications running on a group of compute machines and interconnected by a group of service meshes that are part of a group of connected networks. A domain can comprise a mobile network (MN) and an edge cloud (EC) network, such as a service mesh-based edge cloud network.

[0051] The first node 111 operates in at least one of the first communication network 101, the second communication network 102, and another communication network 103. The first node 111 can be understood as a node that handles interactions between the first communication network 101, for example, a mobile network, and the second communication network 102, for example, an edge cloud domain. The first node 111 can exchange communications between the first communication network 101 and the second communication network 102. The first node 111 may hold a mapping representation between the topology of the first communication network 101 and the second communication network 102. The first node 111 may be referred to herein as an inter-domain hierarchical node. In some specific examples, the first node 111 may be implemented as part of a UPF, for example, in a 5GC network, or as part of an edge cloud management node, for example, in a service mesh-based edge cloud.

[0052] The second node 112 operates in the first communication network 101. The second node 112 may be referred to herein as a mobile network node. In some specific examples, the second node 112 may be, for example, a UPF in a 5GC network.

[0053] The third node 113 operates in the second communication network 102. The third node 113 may be referred to herein as an EC node, for example, a service mesh (SM) based EC node. In some specific examples, the third node 113 may be an edge cloud management node.

[0054] The communication system may comprise device 130, which comprises multiple devices as shown in Figure 1. Device 130 may also be known, to give some further examples, as user equipment (UE), wireless device, mobile terminal, wireless terminal and / or mobile station, mobile phone, cellular phone, or laptop with wireless capabilities, or customer premises equipment (CPE). In this context, device 130 is, for example, a portable, pocket-sized, handheld, computer-integrated, or vehicle-mounted mobile device capable of communicating voice and / or data via RAN and communicating with other entities such as servers, laptops, personal digital assistants (PDAs), or tablet computers (also known as wireless-capable tablets), devices with wireless interfaces such as simply tablets, machine-to-machine (M2M) devices, printers, or file storage devices, modems, laptop-integrated devices (LEEs), laptop-mounted devices (LMEs), USB dongles, or other wireless network units capable of communicating via wireless links within the communication system. Device 130 may be wireless, i.e., capable of wireless communication in the communication system, and in some specific examples, may be capable of supporting beamforming transmission. Communication may take place, for example, between two devices, between a device and a wireless network node, and / or between a device and a server. Communication may also take place, for example, through RANs and potentially one or more core networks contained within the communication system.

[0055] A communication system may comprise one or more radio network nodes, the radio network node 140 being shown in Figure 1b. The radio network node 140 may typically be a base station or transmit point (TP), or any other network unit capable of providing services to radio devices or machine-type nodes in the communication system. The radio network node 140 may be, for example, a radio network node in a 5G gNB, 4G eNB, or alternative 5G radio access technology, such as fixed or WiFi. The radio network node 140 may be, for example, a wide-area base station, a medium-range base station, a local area base station, and a home base station, based on transmit power and thus coverage size. The radio network node 140 may be a fixed relay node or a mobile relay node. The radio network node 140 may support one or more communication technologies, the names of which may depend on the technology and terminology used. The radio network node 140 may be directly connected to one or more networks and / or one or more core networks.

[0056] A communication system covers a geographical area that can be divided into cell areas, and each cell area can be serviced by a wireless network node, although one wireless network node can serve one or more cells.

[0057] The first node 111 may communicate with the second node 112 via the first link 151, for example, a wireless link or a wired link. The first node 111 may communicate with the third node 113 via the second link 152, for example, a wireless link or a wired link. The third node 113 may communicate directly or indirectly with the second node 112 via the third link 153, for example, a wireless link or a wired link. The second node 112 may communicate directly or indirectly with the device 130 via the fourth link 154, for example, a wireless link or a wired link. The second node 112 may communicate directly or indirectly with the wireless network node 140 via the fifth link 155, for example, a wireless link or a wired link. The wireless network node 140 may communicate with the device 130 via the sixth link 156, for example, a wireless link. The first link 151, the second link 152, the third link 153, the fourth link 154, the fifth link 155, and / or the sixth link 156 may be direct links, or they may be via one or more computer systems or one or more core networks within the communication system, or they may be via an optional intermediate network. The intermediate network may be one or more of the public network, private network, or hosted network, and the intermediate network may be a backbone network or the internet, if any, not shown in Figure 1.

[0058] In general, the use of “first,” “second,” “third,” “fourth,” “fifth,” and / or “sixth” in this specification may be understood as any way of indicating different elements or entities, and not as to confer cumulative or chronological characteristics to the nouns that these adjectives modify.

[0059] While terminology from Long-Term Evolution (LTE) / 5G is used in this disclosure to illustrate embodiments thereof, this should not be considered to limit the scope of embodiments herein to the systems described above. Other wireless systems supporting similar or equivalent functionality may also benefit from leveraging the ideas covered in this disclosure. In future telecommunications networks, for example in sixth-generation (6G), the terminology used herein may need to be reinterpreted to take into account possible changes in terminology in future technologies.

[0060] Next, an embodiment of a computer-implemented method, performed by the first node 111, will be described with reference to the flowchart shown in Figure 2. This method can be understood as being for handling the mobility of one or more ongoing communication sessions for device 130 from source domain 121 to target domain 122. Each of the source domain 121 and target domain 122 comprises at least a first communication network 101 and a second communication network 102. Each of the one or more ongoing communication sessions comprises each group of traffic flows having respective requirements for quality of service or experience. The first node 111 operates in at least one of the first communication network 101, the second communication network 102, and another communication network 103.

[0061] As mentioned above, the first communication network 101 may be a mobile network, and the second communication network 102 may be an edge cloud network.

[0062] The method may include the actions described below. In some embodiments, all actions can be performed. In some embodiments, some of the actions can be performed. In Figure 2, optional actions are indicated by dashed boxes. Where applicable, one or more embodiments can be combined. All possible combinations are not described for the sake of brevity. It should be noted that the embodiments herein are not mutually exclusive. Components from one example or embodiment may be implicitly assumed to be present in another example or embodiment, and how those components may be used in other examples or embodiments will be obvious to those skilled in the art.

[0063] In Figure 2, optional actions are shown as dashed boxes.

[0064] Action 201 In the communication process within a communication system In this action 201, the first node 111 can obtain one or more first indications from the second node 112. One or more first indications may represent groups of traffic flows in one or more ongoing communication sessions, i.e., ongoing communication sessions for device 130, which should be shifted from source domain 121 to target domain 122. A group of traffic flows may be referred to herein as a traffic aggregate.

[0065] At least one of the following may apply: In some embodiments, each group of traffic flows may span a group of microservices. In some embodiments, each of one or more ongoing communication sessions may be a PDU session. In some embodiments, each group of traffic flows having similar requirements for quality of service or experience may be a traffic aggregate. In some embodiments, one or more ongoing communication sessions may be handled by a service mesh (SM).

[0066] One or more first indications may also indicate, for each group of traffic flows in each of one or more ongoing communication sessions having similar requirements for quality of service or experience, at least one of the following options: as a first option, i) each pair of nodes, e.g., UPFs, where the shift is presumed to be necessary to handle each group of traffic flows. Each pair of nodes may comprise each source node in source domain 121 and each target node in target domain 122. In some embodiments, each node in a separate pair of nodes may be one of a) a protocol data unit (PDU) session anchor, b) a node managing the user plane, and c) a UPF.

[0067] Each individual pair of nodes can correspond to each pair of core mobile networks and each pair of service mesh (SMs).

[0068] As a second option, ii) a first priority for each when processing the shift. As a third option, iii) a first time budget requirement for each shift. The time budget requirement can be understood as a desired time interval indicating the time during which the traffic shift may need to be fully executed, and as a result, the quality of the experience may not be significantly degraded, for example, with respect to thresholds. As a fourth option, iv) a first individual load for each individual node pair. As a fifth option, v) a second individual load to be shifted for each individual node pair. As a sixth option, vi) a first viable migration budget for each individual node pair. The viable migration budget can be understood as the actual or estimated delay that can be met for each node pair to complete the traffic shift process. The first viable migration budget can be understood as a first viable migration budget that is viable for the first communication network 101.

[0069] The acquisition of one or more first indications can be performed by receiving one or more first indications, for example, via the first link 151.

[0070] Action 202 In this action 202, the first node 111 determines, for each group of traffic flows, the respective correspondence between the first set of resources belonging to the first communication network 101 and the respective second set of resources belonging to the second communication network 102, which is estimated to be necessary for the shift, for each of the one or more ongoing communication sessions having similar requirements for quality of service or experience. The first set of resources comprises each pair of core mobile networks, each comprising one or more source mobile networks and one or more target mobile networks. The second set of resources comprises each pair of service meshes (SMs), each comprising a source service mesh and a target service mesh.

[0071] Some features may be built on the assumption that traffic can be categorized into groups of traffic flows (also referred to herein as traffic aggregates (TAs)) and can share similar QoS requirements, and therefore similar migration budgets. Sharing QoS requirements can be understood as essentially meaning that these groups of traffic flows can share the same user plane in the first communication network 101. It can also be assumed that each or a DN has an ingress (entry point) or edge gateway that can enable external connectivity and can associate a set of SMs. As mentioned above, a DN can be understood as an IP network outside the mobile network, but may be connected to the mobile network.

[0072] The first node 111 can perform traffic shift association and aggregation in this action 202. That is, for both the source domain 121 and the target domain 122, the first node 111 can identify all core mobile networks that can be associated with groups of traffic flows that may need to be shifted, along with the relevant service mesh (SM) in the second communication network 102. These SMs may be involved in traffic shift processing that requires notification of the event.

[0073] In action 202, the first node 111 also determines the respective priority for shifting resources to each pair for each group of traffic flows, for each of the one or more ongoing communication sessions that have similar requirements for quality of service or experience. The first node 111 may also estimate an aggregated priority score per core mobile network based on the individual priority scores associated with each group of traffic flows to be shifted.

[0074] The decisions in this Action 202 regarding each response and its priority may be based on one or more first indications obtained.

[0075] In this action 202, the first node 111 can determine the mapped traffic aggregation model. That is, the first node 111 can construct a representation mapping of a group of traffic flows, for example, Tas, using the second communication network 102 that serves the mobile device 130. Note that in this case, only traffic aggregates with the shift_Traffic parameter can be set to True. In a non-restrictive example where each group of traffic accommodations can be called a TA, such a mapped traffic aggregate model may be represented as follows: TIFF0007835847000001.tif154166 Action 203 In this action 203, the first node 111 provides one or more second indications to the third node 113. The one or more second indications are obtained based on one or more first indications acquired.

[0076] The first node 111 can help perform the alignment and coordination of traffic differentiation (TD) mechanisms by aligning with mechanisms within the first communication network 101, for example, a mobile network, and propagating information on how to mark and classify traffic flows within the second communication network 102, for example, a service mesh-based edge cloud, into traffic aggregates. These traffic aggregates can associate specific identifiers related to traffic aggregates within the first communication network 101, and can also propagate minimal configuration information between domains with minimal end-user privacy information.

[0077] Provision, for example, transmission, may be performed via a second link 152.

[0078] Action 204 In this action 204, the first node 111 can obtain a first feasible migration budget from the first communication network 101 for each group of traffic flows that have similar requirements for quality of service or experience. From the second communication network 102, the first node 111 can obtain a second feasible migration budget in this action 204 for the second communication network 102.

[0079] Action 205 In action 205, the first node 111 determines the allocation of the time budget for the shift between the first communication network 101 and the second communication network 102. The first node 111 does this by exchanging communications with each of the first communication network 101 and the second communication network 102. The determination of the time budget allocation in action 205 is based on each pair of core mobile networks, each pair of service meshes, and their respective priorities, according to their respective end-to-end performance requirements for the shift. The end-to-end performance requirements may be understood as part of the overall QoS requirements and may contribute to determining them.

[0080] The decision on the allocation of the time budget in this action 205 may also be based on the first viable migration budget obtained and the second migration budget obtained.

[0081] In this action 205, the first node 111 may perform time budget negotiation. This may be performed by the first node 111, which enables the allocation of source and target UPF → source and target DN → source and target SM based on the migration budget between the first communication network 101 and the second communication network 102, for example, the available end-to-end migration budget and the feasible migration budget in the first communication network 101.

[0082] The first node 111 can be understood as a node that can operate in an interdomain hierarchy, which can be understood as a hierarchy that handles the interaction between the domains of the first communication network 101 and the second communication network 102. To perform this action 205, the first node 111 can, for example, hold a mapping representation between the topology of the first communication network 101 and the second communication network 102 as a result of performing actions 202 and 204. In a non-restrictive example, each node in a pair of nodes may be a UPF, each group of traffic aggregates may be called a TA, and such a mapped infrastructure model may be represented as follows: The first node 111 can also hold a mapped application model, namely a mapping representation between service data flows (SDFs) that may have been instantiated in the first communication network 101 and microservice chains that may have been instantiated in the second communication network 102. The first node 111 can also track a service mesh hosting microservice instances that may form part of a microservice chain (MC).

[0083] In a non-restrictive example, this can be expressed as follows: TIFF0007835847000002.tif16165 Action 206 In this action 206, the first node 111 is in the first communication network 101. operation The second node 112 and the second communication network 102 operation Provide one or more indications to at least one of the third nodes 113. The one or more indications indicate the determined allocation in action 205. The one or more indications provided may be understood as one or more third indications.

[0084] The provision, for example, the transmission in this action 206, may be performed, for example, via the first link 151 or the second link 152.

[0085] In this action 206, the first node 111 can perform the preparation of traffic shift notifications. That is, the first node 111 can prepare aggregated notifications of traffic shift events and associated priority information for each core mobile network with respect to a group of traffic flows to be shifted. The first node 111 can perform traffic shift prioritization and notification transmission. Based on discovery information related to the core mobile networks, the first node 111 can send aggregated traffic shifting notifications and associated priorities to each core mobile network by scheduling notifications based on aggregated priority scores related to each core mobile network.

[0086] Next, an embodiment of a computer implementation method performed by the second node 112 will be described with reference to the flowchart shown in Figure 3. This method can be understood as being for handling the mobility of one or more ongoing communication sessions for device 130 from source domain 121 to target domain 122. Each of the source domain 121 and target domain 122 comprises at least a first communication network 101 and a second communication network 102. Each of the one or more ongoing communication sessions comprises each group of traffic flows having their respective requirements for quality of service or experience. The second node 112 operates in the first communication network 101.

[0087] As mentioned above, the first communication network 101 may be a mobile network, and the second communication network 102 may be an edge cloud network.

[0088] The method may include the actions described below. In some embodiments, all actions can be performed. In some embodiments, some of the actions can be performed. In Figure 3, optional actions are indicated by dashed boxes. Where applicable, one or more embodiments can be combined. All possible combinations are not described for the sake of brevity. It should be noted that the embodiments herein are not mutually exclusive. Components from one example or embodiment may be implicitly assumed to be present in another example or embodiment, and how those components may be used in other examples or embodiments will be obvious to those skilled in the art.

[0089] Some of the following detailed explanations relate to the actions described for the first node 111 and correspond to the same references provided above; therefore, for the sake of brevity, they will not be repeated here. For example, a group of traffic flows may be referred to herein as a traffic aggregate.

[0090] In Figure 3, optional actions are shown as dashed boxes.

[0091] Action 301 In this action 301, the second node 112 may determine one or more service chains from all the services in each of one or more ongoing communication sessions for device 130, each having requirements to be executed in its respective sequence over time.

[0092] A service can be understood as part of software accessible via its network interface. Software can be a separate application component that implements specific logic that can be consumed by end users, such as microservices hosted in an edge cloud.

[0093] Action 302 Action 302 allows the second node 112 to map one or more service chains, each having its own requirements for service or experience quality, to a group of traffic flows.

[0094] In this action 302, the second node 112 can perform multi-level traffic differentiation control and implementation. The first communication network 101 can perform multi-level differentiation of traffic flows based on UE session management and QoS-related information. That is, traffic flows can be distinguished based on configurations from the user plane of the first communication network 101, such as PDU sessions, QoS flows, and / or SDFs. The first communication network 101 can perform traffic marking and classification and apply differentiated traffic steering strategies based on the relevant QoS rules for the traffic.

[0095] In this action 302, the second node 112 may perform multi-level traffic association and aggregation by identifying the consumed microservice chains and how they can be associated with different elemental parts of the user plane of device 130, for example, PDU sessions, data radio bearers (DRBs), QoS flows, and SDFs, among other things.

[0096] Action 303 In this action 303, the second node 112 can determine the end-to-end performance requirements for each of the determined groups of traffic flows.

[0097] In this action 302, the second node 112 can perform performance constraint retrieval. That is, the second node 112 can extract the end-to-end performance requirements and / or constraints associated with each group of traffic flows. Examples of performance constraints may be expected latency and bandwidth.

[0098] Action 304 In action 304, the second node 112 can determine which groups of traffic flows in each of one or more ongoing communication sessions having similar respective requirements for quality of service or experience should be shifted from source domain 121 to target domain 122, and in action 304, the second node 112 can perform a traffic shift assessment. That is, the second node 112 can assess and identify all associated groups of traffic flows that may need to be shifted, for example, by comparing expected performance with actual performance. Actual performance may be measured, estimated, and / or predicted. Once it is determined which groups of traffic flows may need migration, this function can also identify the relevant PSAs and UPFs involved in the traffic shift in both source domain 121 and target domain 122.

[0099] Action 305 Action 305 allows the second node 112 to determine, for each of the determined groups of traffic flows, at least one of the following options based on the respective service or experience quality requirements: First option: i) each pair of nodes estimated to be required for the shift to handle each group of traffic flows. Each pair of nodes may comprise each source node in source domain 121 and each target node in target domain 122. Second option: ii) each first priority when handling the shift. Third option: iii) each first time budget requirement for the shift. Fourth option: iv) each first load for each pair of nodes. Fifth option: v) each second load to be shifted for each pair of nodes. Sixth option: vi) each first viable migration budget for each pair of nodes.

[0100] Each first priority determination may be based on the respective end-to-end performance requirements determined in action 303. In the second option, in action 305, the second node 112 may perform traffic shift prioritization. That is, the second node 112 may rank groups of traffic flows based on the associated migration budget and assign a priority score that may be in the range of 0 to 10, for example, where 10 represents the highest priority.

[0101] In the third option, action 305 allows the second node 112 to perform estimation and / or acquisition of time budget requirements. This function may enable the first communication network 101 to estimate or acquire the end-to-end migration budget associated with each group of traffic flows. This migration budget may be expressed as an acceptable delay time during the traffic shift process.

[0102] In the case of the fourth option, in this action 305, the second node 112 may perform traffic load measurement (dimensioning). That is, the second node 112 may estimate or predict the total ongoing or future traffic load in a UPF associated with a group of traffic flows, for example, a pair of UPFs in source domain 121 and UPFs in target domain 122. Note that this estimation may take into account all groups of traffic flows and UEs served by each UPF, and is not limited to the associated groups of traffic flows or UEs.

[0103] In the fifth option, action 305 allows the second node 112 to perform traffic shift load dimensionalizing. That is, the second node 112 can estimate or predict ongoing or future traffic loads that may need to be shifted within a group of traffic flows, for example, within a source domain 121 in a target domain 122 and a pair of UPFs associated with the UPF.

[0104] In the case of the sixth option, in this action 305, the second node 112 can perform an estimate of a feasible time budget. That is, the second node 112 can estimate or predict a feasible migration budget for the associated group of traffic flows. To this end, the second node 112 may consider the traffic shift priority score associated with the group of traffic flows, and / or the associated migration budget versus total traffic load, and the load of traffic to be shifted in the associated node, for example, UPF.

[0105] In this action 305, the second node 112 can determine the total traffic and traffic aggregation model. These models may be constructed and may only be available within the domain of the first communication network 101 as a way to represent groups of total traffic and traffic flows.

[0106] In a non-restrictive example where each node in a pair of nodes can be a UPF, device 130 could be a UE, and each group in a traffic aggregate could be called a TA, and such a mapped infrastructure model could be represented as follows: TIFF0007835847000003.tif45156TIFF0007835847000004.tif254153 Action 306 In this action 306, the second node 112 may give one or more first instructions to the first node 111. One or more first instructions may indicate at least one of the following: In some embodiments, one or more indications may indicate each group of traffic flows in each of one or more ongoing communication sessions, i.e., ongoing communication sessions for device 130, for which one or more indications should be shifted from source domain 121 to target domain 122.

[0107] In some embodiments, one or more first indications may alternatively or additionally indicate, for each group of traffic flows in each of one or more ongoing communication sessions having similar requirements for quality of service or experience, at least one of the following determined: As a first option, i) each pair of nodes, e.g., UPFs, for which a shift is presumed to be necessary to handle each group of traffic flows. Each pair of nodes may comprise each source node in source domain 121 and each target node in target domain 122.

[0108] As a second option, ii) the first priority for each when processing the shift. As a third option, iii) the first time budget requirement for each shift. As a fourth option, iv) the first load for each pair of nodes. As a fifth option, v) the second load to be shifted for each pair of nodes. As a sixth option, vi) the first viable migration budget for each pair of nodes.

[0109] At least one of the following may apply: In some embodiments, each group of traffic flows may span a group of microservices. In some embodiments, each of one or more ongoing communication sessions may be a PDU session. In some embodiments, each group of traffic flows having similar requirements for quality of service or experience may be a traffic aggregate. In some embodiments, one or more ongoing communication sessions may be handled by a service mesh (SM).

[0110] In some embodiments, each node in each pair of nodes may be one of the following: a) a PDU session anchor, b) a node managing the user plane, and c) a UPF.

[0111] Each pair of nodes can correspond to each pair of core mobile networks and each pair of service mesh (SM).

[0112] Action 307 Action 307 provides the first node 111, which takes action in at least one of the first communication network 101, the second communication network 102, and another communication network 103, with a first feasible migration budget that can be executed in the first communication network 101 for each group of traffic flows in each of one or more ongoing communication sessions having similar requirements for quality of service or experience.

[0113] Provision, for example, transmission, may be performed, for example, via the first link 152.

[0114] Action 308 In this action 308, the second node 112 obtains one or more third indications from the first node 111. The one or more third indications indicate the allocation of a time budget for the shift between the source domain 121 and the target domain 122 for each group of traffic flows in each of the one or more ongoing communication sessions that should be shifted from the source domain 121 to the target domain 122, and for each group of traffic flows that have similar requirements for quality of service or experience. The obtained allocation of the time budget is based on the first feasible migration budget provided, which is feasible for the first communication network 101, and the respective end-to-end performance requirements for the shift.

[0115] The acquired allocation of the time budget for the shift may further depend on the respective correspondence in each of the one or more ongoing communication sessions having similar requirements for quality of service or experience for each group of traffic flows. Each correspondence may be between a first set of resources belonging to the first communication network 101 and a second set of resources belonging to the second communication network 102 that is estimated to be necessary for the shift. The first set of resources comprises each pair of one or more source core mobile networks and one of one or more target mobile networks. The second set of resources may comprise each pair of service meshes comprising a source service mesh and a target service mesh.

[0116] The acquired allocation of the time budget for shifts may be based on the respective priorities in the shifts for each pair of resources for each group of traffic flows, for each of the one or more ongoing communication sessions that have similar requirements for quality of service or experience.

[0117] Next, an embodiment of a computer implementation method performed by the third node 113 will be described with reference to the flowchart shown in Figure 4. This method can be understood as being for handling the mobility of one or more ongoing communication sessions for device 130 from source domain 121 to target domain 122. Each of the source domain 121 and target domain 122 comprises at least a first communication network 101 and a second communication network 102. Each of the one or more ongoing communication sessions comprises each group of traffic flows having their respective requirements for quality of service or experience. The third node 113 operates in the second communication network 102.

[0118] As mentioned above, the first communication network 101 may be a mobile network, and the second communication network 102 may be an edge cloud network.

[0119] The method may include the following actions. Several embodiments are included herein. In some embodiments, the method may include all actions. In other embodiments, the method may include two or more actions. Where applicable, one or more embodiments may be combined. All possible combinations are not described for the sake of brevity. It should be noted that the embodiments herein are not mutually exclusive. Components from one example may be implicitly assumed to be present in another example, and it will be obvious to those skilled in the art whether those components can be used in other embodiments. In Figure 4, optional actions are indicated by dashed lines.

[0120] Some of the following detailed explanations relate to the operation described for the first node 111 and correspond to the same references provided above; therefore, for the sake of brevity, they will not be repeated here. For example, a group of traffic flows may be referred to as a traffic aggregate in this specification.

[0121] Action 401 Action 401 allows the third node 113 to obtain one or more second indications from the first node 111. One or more second indications may indicate at least one of the following options for each group of traffic flows in each of one or more ongoing communication sessions that should be shifted from the source domain 121 to the target domain 122, which has similar requirements regarding the quality of service or experience: The first option is that i) each first set of resources in the first communication network 101 is estimated to be needed for the shift. The second option is that ii) each second set of resources in the second communication network 102 is estimated to be needed for the shift. The third option is that iii) each first priority when processing the shift.

[0122] Each first set of resources may comprise at least one of the following: as a first option, i) each pair of nodes, e.g., UPF, which Shift is estimated to need to handle each group of traffic flows. Each pair of nodes may comprise each source node in source domain 121 and each target node in target domain 122.

[0123] As a second option, ii) the first priority for each when processing the shift. As a third option, iii) the requirement for the first time budget for each shift. As a fourth option, iv) the first load for each pair of nodes. As a fifth option, v) the second load to be shifted for each pair of nodes. As a sixth option, vi) the first viable migration budget for each pair of nodes.

[0124] At least one of the following may apply: In some embodiments, each group of traffic flows may span a group of microservices. In some embodiments, each of one or more ongoing communication sessions may be a PDU session. In some embodiments, each group of traffic flows having similar requirements for quality of service or experience may be a traffic aggregate. In some embodiments, one or more ongoing communication sessions may be handled by a service mesh (SM).

[0125] In some embodiments, each node in each pair of nodes may be one of the following: a) a PDU session anchor, b) a node managing the user plane, and c) a UPF.

[0126] Each pair of nodes can correspond to each pair of core mobile networks and each pair of service mesh (SM).

[0127] Action 402 In this action 402, the third node 113 can determine, for each pair of service meshes, i) the respective loads, ii) the respective loads corresponding to the traffic to be shifted, and iii) a second migration budget that can be implemented in the second communication network 102. The second migration budget may be determined based on the determined respective loads and the respective loads corresponding to the traffic to be shifted.

[0128] Judging can be understood as, for example, calculating or deciding.

[0129] To determine the respective loads, the third node 113 may perform a traffic load measurement. That is, the third node 113 may estimate or predict the total ongoing or future traffic load in each group of traffic flows, for example, in pairs of SMs associated with an SM in source domain 121 and an SM in target domain 122. It should be noted that this estimation may take into account all groups of traffic flows and UEs served by each SM, and is not limited to the associated groups of traffic flows or UEs.

[0130] To determine the load corresponding to the traffic that should be shifted, the third node 113 may perform traffic shift dimensioning. That is, the third node 113 may estimate or predict the load of ongoing or future traffic that needs to be shifted in the SM associated with each group of traffic flows, for example, a pair of SMs in source domain 121 and SMs in target domain 122.

[0131] To determine a feasible second migration budget for the second communication network 102, the third node 113 can perform an estimation of the traffic shift time budget. That is, the third node 113 can estimate or predict a feasible migration budget, i.e., an acceptable delay for traffic shifts, for a group of relevant traffic flows and for each of the available traffic shift strategies in the second communication network 102. To this end, the third node 113 may consider the traffic shift priority score associated with each group of traffic flows, and / or the associated migration budget versus total traffic load, the load of traffic to be shifted in the associated SM, and the type of traffic shift strategy.

[0132] In non-specific examples, the following mapped infrastructure model may apply. TIFF0007835847000005.tif98163 Action 403 In this action 403, the third node 113 may provide the first node 111, which operates in at least one of the first communication network 101, the second communication network 102, and another communication network 103, with a second feasible migration budget for each group of traffic flows in each of one or more ongoing communication sessions having similar requirements for quality of service or experience in the second communication network 102.

[0133] The second migration budget provided may be based on one or more second indications obtained in Action 401.

[0134] Action 404 In this action 404, the third node 113 obtains one or more third indications from the first node 111. The one or more third indications indicate the allocation of a time budget for the shift between the first communication network 101 and the second communication network 102 for each group of traffic flows in each of the one or more ongoing communication sessions that should be shifted from the source domain 121 to the target domain 122, and for each group of traffic flows that have similar requirements for quality of service or experience. The obtained time budget allocation is based on the provided second migration budget that is feasible for the second communication network 102.

[0135] Action 405 In this action 405, the third node 113 may determine a strategy for shifting based on one or more third indications obtained and the available resources in the second communication network 102 estimated by the third node 113.

[0136] The determined strategy for shifting may further be based on each determined load, each load corresponding to the traffic to be shifted, and each first priority.

[0137] In this action 405, the third node 113 can perform an optimized selection of traffic shift strategies. Specifically, based on a list of migration budgets associated with each of the available traffic shift strategies, the third node 113 can select the most reliable traffic shift strategy that can satisfy the end-to-end migration budget for each group of traffic flows, based on the feasible migration budgets in the first communication network 101 and the second communication network 102.

[0138] Action 406 In this action 406, the third node 113 can start executing the shift based on the strategy determined in action 405.

[0139] In this action 406, the third node 113 can perform traffic shift prioritization and notification reception. Each DN receives a notification from the first node 111 and can forward the information in order based on its associated priority score, i.e., the notification is propagated first to those with higher priority scores.

[0140] Action 406 also allows the third node 113 to perform traffic shift priority configuration. That is, the third node 113 may update the priority configuration for each relevant service mesh for components of both the control plane and the data plane (DP) in order to schedule the efficient execution of traffic shifts based on the relevant priorities.

[0141] Figure 5 is a schematic diagram illustrating an embodiment of the aligned traffic differentiation: system according to an embodiment of this specification. In this non-limiting example, the first communication network 101 is a mobile network, the second communication network 102 is a service mesh-based edge cloud network, and the other communication network 103 provides connectivity to the interdomain hierarchy. Figure 5 schematicly illustrates a high level of context and assumptions that can be used as a baseline for aligning a traffic differentiation mechanism between the mobile network and the service mesh-based edge cloud. Based on this aligned traffic differentiation mechanism, systems and methods for convergent traffic shifting procedures during UE mobility events can be implemented according to embodiments of this specification. For multi-level traffic differentiation control and implementation, the mobile network can perform multi-level differentiation of traffic flows based on UE session management and QoS-related information, for example, traffic flows can be differentiated based on configurations from the mobile network's user plane, such as PDU sessions, QoS flows, and SDFs. The mobile network can perform traffic marking and classification and apply differentiated traffic steering strategies based on the relevant QoS rules for the traffic. In cross-domain traffic differentiation alignment, the cross-domain hierarchy can help align and coordinate traffic differentiation mechanisms by aligning with mechanisms within the mobile network and propagating information on how traffic flows are marked and classified into traffic aggregations within a service mesh-based edge cloud. These traffic aggregates may have specific identifiers related to traffic aggregates within the mobile network, and minimum configuration information can be propagated between domains with minimal to no disclosure of end-user private information.For traffic differentiation management, control, and implementation, a service mesh-based edge cloud can differentiate traffic flows based on traffic aggregates mapped from the mobile network, such as traffic aggregate identifiers and configuration information. The service mesh can perform traffic marking and classification, and apply differentiated traffic steering strategies based on configuration rules associated with traffic aggregate identifiers.

[0142] Figure 6 is a schematic diagram illustrating an embodiment of an efficient inter-domain traffic shifting signaling system according to this specification. In this non-limiting example, the first communication network 101 is a mobile network, the second communication network 102 is a service mesh-based edge cloud network, the first node 111 operates in an inter-domain hierarchy, and the device 130 is a UE. Figure 6 schematicly illustrates efficient signaling between the mobile network and the edge cloud domain, which may, for example, be related to traffic shifting events when a UE mobility trigger occurs. The primary triggers considered are UE mobility-related events that can be signaled, predicted, or estimated in some way by the mobile network. Several features can be built on the assumption that traffic can be categorized into traffic aggregates (TAs) that can share similar QoS requirements and therefore similar migration budgets. Sharing QoS requirements can be understood as meaning that these TAs can share the same mobile network user plane. It can also be assumed that each DN can have an ingress gateway or edge gateway that can enable external connectivity and can associate a set of service meshes. The mobile network can track identifiers associated with moving UEs and, based on that, perform the following functions: First, multi-level traffic association and aggregation. The mobile network can identify consumed microservice chains and how they can be associated with different parts of the UE's user plane, such as PDU sessions, DRBs, QoS flows, and SDFs. Second, performance constraint lookup. The mobile network can extract end-to-end performance requirements and / or constraints associated with each TA. Examples of performance constraints could be expected latency and bandwidth. Third, traffic shift evaluation. The mobile network can evaluate and identify all relevant TAs that may need to be shifted, for example, by comparing expected performance with actual performance.Actual performance can be measured, estimated, and / or predicted. Once it is determined which TAs may require migration, this function can also identify the relevant PSAs and UPFs involved in the traffic shift in both the source domain 121 and the target domain 122. A fourth function is traffic shift prioritization. The mobile network can rank TAs based on their associated migration budget and assign them priority scores that can range from 0 to 10, for example, where 10 represents the highest priority.

[0143] The inter-domain hierarchy can perform the following functions. Firstly, it can perform traffic shift association and aggregation. The inter-domain hierarchy can identify all data networks (DNs) that may be associated with TAs that may need to be shifted along with the relevant service mesh (SM) in the edge cloud for both source domain 121 and target domain 122. These SMs may be involved in the traffic shifting process and may require notification of events. The inter-domain hierarchy can also estimate an aggregated priority score per DN based on the individual priority scores associated with each TA to be shifted. Secondly, it can perform traffic shift notification preparation. The inter-domain hierarchy can prepare aggregated notifications of traffic shift events and relevant priority information for each DN regarding the TA to be shifted. Thirdly, it can perform traffic shift prioritization and notification sending. Based on the discovery information associated with the DNs, the inter-domain hierarchy can send aggregated traffic shift notifications and associated priorities to each DN by scheduling notifications based on the aggregated priority score associated with each DN.

[0144] A service mesh-based edge cloud can perform the following functions. Firstly, it can perform traffic shift prioritization and notification reception. Each DN can receive notifications from the inter-domain hierarchy and forward the information sequentially based on its associated priority score. Notifications are first propagated to users with higher priority scores. Secondly, it can perform traffic shift priority configuration. The inter-domain hierarchy can update priority-related configurations in each relevant service mesh for components in both the control plane and data plane to schedule efficient execution of traffic shifts based on the relevant priorities. For details on the proposed method for efficient inter-domain traffic shift signaling, see the description of Figure 8.

[0145] Figure 7 is a schematic diagram illustrating an optimized inter-domain traffic shift strategy selection that may be performed according to embodiments of this specification. In this non-limiting example, the first communication network 101 is a mobile network, the second communication network 102 is a service mesh-based edge cloud network, and the other communication network 103 provides connectivity to the inter-domain hierarchy. Figure 7 schematically illustrates an optimized selection of a traffic shift strategy in a service mesh edge cloud. This selected strategy may be based on dynamic negotiation of the allocation of migration budgets assigned for traffic shifts to be coordinated with the mobile network, which may be performed according to embodiments of this specification. The system in Figure 7 can perform the procedure in Figure 9 for all TAs that require shifting.

[0146] The mobile network can perform the following functions: As a first function, the mobile network can perform estimation and / or acquisition of time budget requirements. This function may enable the mobile network to estimate or acquire the end-to-end migration budget associated with each TA. This migration budget may be expressed as the acceptable delay time during the traffic shift process. As a second function, the mobile network can perform traffic load measurement. The mobile network may estimate or predict the total ongoing or future traffic load in a UPF associated with a TA, for example, a pair of UPFs in source domain 121 and UPFs in target domain 122. Note that this estimation may consider all TAs and UEs served by each UPF, and is not limited to the relevant TA or UE. As a third function, the mobile network can perform traffic shift load measurement. The mobile network may estimate or predict the ongoing or future traffic load that needs to be shifted in a UPF associated with a TA, for example, a pair of UPFs in source domain 121 and UPFs in target domain 122. As a fourth function, the mobile network can perform feasible time budget estimation. The mobile network can estimate or predict a feasible migration budget, i.e., an acceptable delay for traffic shifting, for the relevant TA. To this end, the mobile network can consider the traffic shift priority score associated with the TA, and / or the associated migration budget versus total traffic load and the load of traffic that should be shifted in the associated UPF.

[0147] The interdomain hierarchy can perform the following functions. Firstly, the interdomain hierarchy can negotiate the allocation of time budgets. Based on the available end-to-end migration budgets and feasible migration budgets in the mobile network, the interdomain hierarchy enables the allocation of migration budgets between the mobile network and service mesh-based edge clouds, for example, source and target UPF → source and target DN → source and target SM.

[0148] A service mesh-based edge cloud can perform the following functions: Firstly, it can perform traffic load dimensioning. The service mesh-based edge cloud can estimate or predict the ongoing or future total traffic load in a pair of SMs associated with a TA, for example, an SM in the source and an SM in the target domain. Note that this estimation may consider all TAs and UEs served by each SM, and is not limited to the relevant TA or UE. Secondly, it can perform traffic shift dimensioning. The service mesh-based edge cloud can estimate or predict the ongoing or future traffic load that needs to be shifted in a pair of SMs associated with a TA, for example, an SM in the source and an SM in the target domain. Thirdly, it can perform traffic shift time budget estimation. For a relevant TA and each of the available traffic shift strategies, the service mesh-based edge cloud can estimate or predict a feasible migration budget, i.e., an acceptable delay for traffic shifts. To this end, a service mesh-based edge cloud can consider the traffic shift priority score associated with the TA, and / or the associated migration budget versus total traffic load, the load of traffic shifted in the associated SM, and the type of traffic shift strategy. As a fourth function, a service mesh-based edge cloud can perform an optimized selection of traffic shift strategies.Based on a list of migration budgets associated with each available traffic shift strategy, the service mesh-based edge cloud can select the most reliable traffic shift strategy that meets each TA's end-to-end migration budget, based on the feasible migration budget in the mobile network.

[0149] Figure 8 is a schematic diagram illustrating an efficient inter-domain traffic shifting signaling configuration that may be implemented according to embodiments of this specification. In this non-limiting example, the first communication network 101 is a mobile network, the second communication network 102 is a service mesh-based edge cloud network, and the other communication network 103 provides connectivity to the inter-domain hierarchy. Figure 8 schematically illustrates the mechanism provided by embodiments of this specification for performing efficient traffic shifting signaling across the mobile network and service mesh-based edge cloud domains based on traffic aggregation, as described above, with the indicated reference numbers corresponding to the actions. In 801, the mobile network can acquire a UE mobility trigger and then proceed to the actions corresponding to the reference numbers shown in Figure 8, as described above.

[0150] Figure 9 is a schematic diagram illustrating an optimized traffic shift strategy selection that may be performed according to embodiments of this specification. In this non-limiting example, the first communication network 101 is a mobile network, the second communication network 102 is a service mesh-based edge cloud network, and the other communication network 103 provides connectivity to the inter-domain hierarchy. Figure 9 schematically illustrates a mechanism provided by embodiments of this specification for performing an optimized selection of a traffic shift strategy in a service mesh-based edge cloud coordinating with the mobile network domain, based on traffic aggregation and source and target tuples related to migration. This method may be triggered not only by UE mobility events but also periodically, as described above and in actions corresponding to the indicated reference numbers.

[0151] Non-limiting examples The methods of the embodiments described herein can be illustrated using non-limiting examples shown in the schematic diagram of Figure 10. Figure 10 schematically illustrates a PDU session, QoS flow, and session data flow in a 5G user plane. As shown in Figure 10, an end user may simultaneously consume several applications, such as listening to music, watching movies, and sending SMS messages, via the same device 130, e.g., UE. These consumed service chains may belong to the same or different applications and may have different service level agreements (SLAs) or QoE requirements. Thus, they may be served by the same or different PDU sessions having the same / different PDU session anchors (PSAs), the same / different QoS flows, and different service data flows (SDFs). Figure 10 also shows the DRB portion of the 5G radio and how the traffic aggregate can be mapped in traffic classification filters in different parts of the network, the UE and UPF, and, in particular, in the insertion of QoS flow identifiers (QFIs) into IP flows. In Figure 10, SDAP represents the Service Data Adaptive Protocol, and TFT represents the Traffic Flow Template. Figure 10 can be understood to correspond to aspects of actions 301, 302, and 305.

[0152] In mobile networks, traffic steering mechanisms may operate or be enforced at the traffic aggregation level. During UE mobility-triggered service migrations, there may typically be several PDU sessions, QoS flows, and SDFs associated with the moving UE. These different levels of traffic aggregation may require careful assessment to identify and determine an appropriate traffic shift strategy in coordination with the edge cloud platform and edge cloud host applications. It may then be possible to reduce signaling by having a migration strategy that acts on the traffic aggregate, which may also take into account the QoS required for traffic prioritization and scheduling according to the associated migration budget.

[0153] This can be thought of as a UE consuming two applications, for example. On one hand, a movie streaming application via movie streaming application provider 1 has the following microservice chain: v1. movie_streaming → movie_playback → movie_caching → movie_storage and v2. movie_search → movie_previewing → view_reviews → enter_review. On the other hand, a music streaming application via music streaming provider 1 has the following microservice chain: m1. music_streaming → music_playback → music_caching → music_storage and m2. music_search → music_previewing → view_reviews → enter_review.

[0154] During UE mobility-triggered microservice migration, one PDU session with three different QoS flows may be assumed, and therefore three different traffic aggregates: TA1 for latency-sensitive chain v1 of video streaming application provider 1, TA2 for latency-sensitive chain m1 of music streaming provider 1, and TA3 for non-latency-sensitive chains v2 and m2.

[0155] Therefore, the system can perform the following identification, association, and estimation functions: ● Mobile network: ○ Identify all consumed microservice chains (v1, v2, m1, m2) ○ Mapping consumed microservice chains to traffic aggregates: ■ v1 → TA1 ■ m1 → TA2 ■ v2, m2 → TA3 ○ Obtain the e2e performance constraint per TA: ■ TA1: Delay time: 200 ms ■ TA2: Delay time: 300 ms ■ TA3: Delay time: 1000 ms ○ Identify TAs that may require traffic shifting. sensitive Only TA1 and TA2 are included. ○ Identify UPFs associated with TA1 and TA2: ■ Source domain: UPF1 ■ Target domain: UPF2 ○ Estimation of traffic shift priority per TA: ■ TA1: Priority 10 (High priority because it is related to movie streaming and is sensitive to latency) ■ TA2: Priority 7 ○ Estimation of traffic shift budget per TA: ■ TA1: migration_budget: 100 ms ■ TA2: migration_budget: 150 ms ■ TA3: migration_budget: 700 ms ○ Estimation of total traffic load per UPF pair: ■ (UPF1, UPF2): 80% -> Slightly higher load ○ Estimate the load associated with the traffic shifted for each UPF pair: ■ (UPF1, UPF2): 95% -> Most traffic needs to be shifted. ○ Estimate the feasible traffic shift budget per UPF pair: ■ (UPF1, UPF2): 60ms ■ Inter-domain hierarchy: ○ Identify the data networks associated with the two TAs mentioned above. ■ TA1: Source UPF1 → DN11; Target UPF2 → DN12 ■ TA2: Source UPF1 → DN21; Target UPF2 → DN22 ○ Identify the SM associated with the above DN ■ Source DN11 → SM11; Target DN12 → SM12 ■ Source DN21 → SM21, Target DN22 → SM22 ○ Estimate traffic shift priority per DN pair, where the movie streaming chain has a high priority and the music streaming chain has a medium priority. ■ (DN11, DN12): priority10 ■ (DN21, DN22): priority7 ○ To implement migration within the e2e migration budget, each TA negotiates the allocation of time budget between the mobile network and the service mesh-based edge cloud. ■ TA1: e2e_migration_budget 100ms; MN_feasible_migration_budget 60ms; EC_feasible_migration_budget 40ms ■ TA2: e2e_migration_budget 150ms; MN_feasible_migration_budget 90ms; EC_feasible_migration_budget 60ms ● Service mesh-based edge cloud: ○ Estimation of total traffic load per SM pair: ■ (SM11, SM12): 60% -> Medium load ■ (SM21, SM22): 40% -> Medium load ○ Estimate the load associated with the shifted traffic for each SM pair: ■ (SM11, SM12): 80% -> Most traffic needs to be shifted. ■ (SM21, SM22): 50% —> Half of the traffic needs to be shifted. ○ Estimation of feasible traffic shift budget per TA: ■ TA1: 35ms ■ TA2: 50ms ○ Select the most reliable traffic shift strategy for each TA: ■ TA1: gradual_traffic_splitting ■ TA2: constant_traffic_mirroring Therefore, the system can construct the following model: ● Mapped infrastructure model ○ UPF Tuple ->(UPF_id_s, UPF_id_t) ■ (UPF1, UPF2) ■ total_traffic_load: 80% ■ traffic_shifting_load: 95% ■feasible_migration_budget: 60ms ○ UPF_id ->{DN_1,...,DN_p}: ■ UPF1 -> {DN11, DN21} (source) ■ UPF2 -> {DN12, DN22} (Target) ○ DN Tuples ->(DN_id_s, DN_id_t): ■ Related to TA1 (DN11, DN12) ■ Related to TA2 (DN21, DN22) ○ DN_id ->{SM_1,...,SM_n}: ■ DN11 -> {SM11} ■ DN12 -> {SM12} ■ DN21->{SM21} ■ DN22 -> {SM22} ○ TA1's SM Tuple -> (SM_id_s, SM_id_t): ■ Associated with {SM11, SM12}, TA1 ■ total_traffic_load: 60% ■ {(gradual_traffic_splitting, 35 ms), (constant_traffic_shifting, 70 ms)} ○ TA2's SM Tuple -> (SM_id_s, SM_id_t): ■ Associated with {SM21, SM22}, TA2 ■ total_traffic_load: 40% ■ {(constant_traffic_shifting, 65 ms), (constant_trafficc_mirroring,50 ms)} ● Mapped application models ○ QF_id -> MC_id: ■ QF11 -> MC_v1 (Microservice Chain v1) ■ QF21 -> MC_m1 (Microservice chain m1) ■ QF31 -> MC_v2, MC_m2 ○ MC_id ->{SM_1, ..SM_j}: ■ MC_v1 ->{SM11} ■ MC_m1 ->{SM21} ■ MC_v2 ->{SM11} ■ MC_m2 ->{SM21} ● Traffic and traffic aggregation models ○ Total traffic ■ UE_id: UE1 ■ {TA_QoS1,..., TA_QoSi}:{TA1, TA2, TA3} ○ Traffic aggregation ■ MC_v1 TA ● TA_id: TA1 ● UserPlane_s:{PDUSession11, DRB11, QF11, SDF11, PSA11, UPF1, DN11} ● UserPlane_t:{PDUSession12, DRB12, QF12, SDF12, PSA12, UPF2, DN1} ● QoS_reqs: {Delay time 200ms} ● migration_budget: 100ms ● shift_traffic: True ● priority_score: 10 ■ MC_m1 TA ● TA_id: TA2 ● UserPlane_s:{PDUSession21, DRB21, QF21, SDF21, PSA21, UPF1, DN21} ● UserPlane_t:{PDUSession22, DRB22, QF22, SDF22, PSA22, UPF2, DN22} ● QoS_reqs: {Latency 300ms} ● migration_budget: 150 ms ● shift_traffic: True ● priority_score: 7 ■ ... ● Mapped traffic aggregation model ○ TA:{(TA1, priority_score_10), (TA2, priority_score_7), (TA3, priority_score_1)} ○ ServiceMeshes: ■ TA1 -> {SM11, SM12} ■ TA2 -> {SM21, SM22} ○ aggregated_priority_score: In this simple case, the SM has only one TA that associates the aggregated priority score with the individual priority scores, but this can differ in more complex cases. ■ {SM11, SM12}: priority_10 {SM21, SM22}: priority_7 To summarize the above overview, it can be understood that certain embodiments of this specification may relate, among other things, to models for inter-domain traffic aggregation, traffic shift signaling, budget allocation, and traffic shift prioritization based on the requested migration budget and the feasible migration budget, in both mobile networks and service mesh-based edge clouds.

[0156] Certain embodiments of this specification may be systems and methods for performing alignment and coordination between a mobile network and a service mesh-based edge cloud in order to support UE mobility events.

[0157] Some specific embodiments may provide systems and methods for performing efficient inter-domain traffic shift signaling between mobile networks and service mesh-based edge clouds.

[0158] Some specific embodiments may provide systems and methods for performing optimized selection of traffic shift strategies in a service mesh-based edge cloud, in conjunction with mobile networks.

[0159] Certain embodiments disclosed herein may offer one or more of the following technical advantages, which can be summarized as follows:

[0160] As a first advantage, it can be understood that embodiments of this specification are built upon a novel, converged or aligned traffic differentiation system in a service mesh-based edge cloud, in accordance with QoS assurance and UE session information of the mobile network.

[0161] Another advantage is that the embodiments of this specification, based on the concept of a group of traffic flows or traffic aggregates, can reduce cross-domain signaling between mobile networks and edge clouds, and thus reduce congested inter-domain control planes. This can result in reduced communication costs and energy savings.

[0162] Another advantage is that embodiments of this specification may enable signaling forwarding between mobile networks and data networks, and between data networks and service meshes, to be performed both taking into account the priorities associated with the traffic aggregate based on their associated migration budgets.

[0163] As a further advantage, embodiments of this specification can be understood to use optimized selection of traffic shifting strategies and scheduling of traffic shifts to perform the dynamic allocation of available migration budgets between mobile networks and edge clouds, such as end-to-end service downtime.

[0164] Figure 11 shows two different examples in panels a) and b) of an arrangement in which the first node 111 may perform the method operation described above in relation to Figures 2 and / or Figures 5-9. In some embodiments, the first node 111 may include the following configuration shown in Figure 11a. The first node 111 can be understood as being for handling the mobility of one or more ongoing communication sessions for device 130 from source domain 121 to target domain 122. Each of the source domain 121 and target domain 122 is configured to include at least a first communication network 101 and a second communication network 102. Each of the one or more ongoing communication sessions is Quality of service or experienceIt is configured to have each group of traffic flows having their respective requirements. The first node 111 is configured to operate in at least one of the first communication network 101, the second communication network 102, and another communication network 103.

[0165] Several embodiments are included herein. Components from one embodiment may be implicitly assumed to be present in another embodiment, and it will be apparent to those skilled in the art how those components may be used in other exemplary embodiments. In Figure 11, optional boxes are indicated by dashed lines. Some of the following detailed descriptions relate to the operation described for the first node 111 and correspond to the same references provided above, and are therefore not repeated here. For example, a group of traffic flows may be referred to herein as a traffic aggregate.

[0166] The first node 111 is configured, for example, by a determination unit 1101 within the first node 111 to determine, for each traffic flow group, in each of one or more ongoing communication sessions having similar requirements for one of the following service or experience quality: As a first option, the correspondence between each first set of resources configured to belong to the first communication network 101 and each second set of resources configured to belong to the second communication network 102, which is presumed to be necessary for the shift. The first set of resources is configured to consist of each pair of core mobile networks configured to consist of one or more source mobile networks and one or more target mobile networks. The second set of resources is configured to consist of each pair of service meshes configured to consist of a source service mesh and a target service mesh. As a second option, the first node 111 is configured to configure and determine, for each group of traffic flows, the respective priority for the shift of each pair of resources in each of one or more ongoing communication sessions having similar requirements for service or experience quality.

[0167] The first node 111 also, for example, by the determination unit 1101 within the first node 111, determines each of the first communication network 101 and the second communication network 102. communication By doing so, between the first communication network 101 and the second communication network 102 shift It is configured to determine the allocation of the time budget for each shift. The determination of the time budget allocation is configured to be based on each pair of core mobile networks, each pair of service meshes, and their respective priorities, according to the end-to-end performance requirements of each shift.

[0168] The first node 111 is also configured, for example, by a providing unit 1102 within the first node 111, to provide one or more indications to at least one of the following: a second node 112 configured to operate within the first communication network 101, and a third node 113 configured to operate within the second communication network 102. The one or more indications are configured to show a distribution that is to be determined.

[0169] In some embodiments, the first communication network 101 may be configured as a mobile network, and the second communication network 102 may be configured as an edge cloud network.

[0170] In some embodiments, the first node 111 may be configured by an acquisition unit 1103 within the first node 111, which is configured to perform, for example, for each group of traffic flows having similar requirements for quality of service or experience, i) a first feasible migration budget from the first communication network 101 to the first communication network 101, and ii) a second migration budget from the second communication network 102 to the second communication network 102. The determination of time budget allocation may be configured to further depend on the first feasible migration budget configured to be acquired and the second migration budget configured to be acquired.

[0171] In some embodiments, one or more indicators configured to be provided may be configured to be one or more third indicators.

[0172] In some embodiments, the first node 111 may be further configured to obtain one or more first indications from the second node 112, for example, by an acquisition unit 1103. The one or more first indications may be configured to indicate each group of traffic flows in each of one or more ongoing communication sessions that should be shifted from the source domain 121 to the target domain 122. Alternatively, the one or more first indications may be configured to indicate, for each group of traffic flows in one or more ongoing communication sessions having similar requirements for quality of service or experience, at least one of the following: i) each pair of nodes configured to estimate that a shift is needed to handle each group of traffic flows, each pair of nodes configured to include each source node in the source domain 121 and each target node in the target domain 122; ii) each first priority for handling the shift; iii) each first time budget requirement for the shift; iv) each second load to be shifted per pair of nodes; v) each pair of nodes, and vi) each first feasible migration budget per pair of nodes. The determination of each response and its respective priority may be configured to be based on one or more first indications configured to be obtained.

[0173] In some embodiments, the first node 111 may be further configured to provide one or more second indications to a third node 113, for example, by a providing unit 1102. The one or more second indications may be configured to be based on one or more first indications configured to be acquired.

[0174] In some embodiments, each node in each pair of nodes may be configured as one of a) a PDU session anchor, b) a node managing the user plane, and c) a UPF. Each pair of nodes may be configured to correspond to each pair of core mobile networks and each pair of service meshes.

[0175] In some embodiments, a) each group of traffic flows may be configured to span a group of microservices; b) each of one or more ongoing communication sessions may be configured to be a PDU session; c) each group of traffic flows having similar requirements for quality of service or experience may be configured to be a traffic aggregate; and d) one or more ongoing communication sessions may be configured to be handled by a service mesh.

[0176] Embodiments of this specification, along with computer program code for performing the functions and operations of the embodiments herein, may be implemented via one or more processors, such as processor 1104 in the first node 111 shown in Figure 11. The program code described above may also be provided as a computer program product, for example, in the form of a data carrier that carries the computer program code for performing the embodiments herein when loaded into the first node 111. One such carrier may be in the form of a CD-ROM disk. However, it is executable on other data carriers, such as a memory stick. The computer program code may also be provided as pure program code on a server and downloaded to the first node 111.

[0177] The first node 111 may further comprise a memory 1105 having one or more memory units. The memory 1105 is configured to be used to store acquired information, stored data, configurations, scheduling, and applications, etc., in order to perform the method described herein when it is executed on the first node 111.

[0178] In some embodiments, the first node 111 can receive information via the receiving port 1106 from, for example, the second node 112, the third node 113, the fourth node 114, device 130, and / or other nodes. In some examples, the receiving port 1106 may be connected to, for example, one or more antennas in the first node 111. In other embodiments, the first node 111 can receive information via the receiving port 1106 from another structure in the communication system. Since the receiving port 1106 can communicate with the processor 1104, the receiving port 1106 can then send the received information to the processor 1104. The receiving port 1106 may also be configured to receive other information.

[0179] The processor 1104 in the first node 111 may be further configured to transmit or send information through a transmit port 1107 that can communicate with the processor 1104 and memory 1105 to, for example, the second node 112, the third node 113, the fourth node 114, device 130, another node, and / or another structure in the communication system.

[0180] Those skilled in the art will also understand that any of the above-described units 1101-1103 may refer to one or more processors configured with a combination of analog and digital circuits, and / or software and / or firmware stored in memory that executes as described above when executed by one or more processors, such as processor 1104. One or more of these processors, as well as other digital hardware, may be contained in a single application-specific integrated circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled on a system-on-a-chip (SoC).

[0181] Any of the above-mentioned units 1101 to 1103 may be the processor 1104 of the first node 111, or an application running on such a processor.

[0182] Therefore, for the first node 111, the methods according to the embodiments described herein can each be implemented by a computer program 1108 comprising instructions, i.e., software code portions, that cause at least one processor 1104 to perform the operations described herein, so as to be executed by the first node 111 when the computer program 1108 is executed on at least one processor 1104. The computer program 1108 product can be stored in a computer-readable storage medium 1110. The computer-readable storage medium 1110 in which the computer program 1108 is stored may contain instructions that cause at least one processor 1104 to perform the operations described herein, so as to be executed by the first node 111 when the computer program 1108 is executed on at least one processor 1104. In some embodiments, the computer-readable storage medium 1110 may be a non-temporary computer-readable storage medium such as a CD-ROM disk or a memory stick, or it may be stored in cloud space. In other embodiments, the computer program 1108 product may be stored on a carrier containing the computer program, the carrier being one of the following: electrical signals, optical signals, radio signals, or computer-readable storage medium 1110.

[0183] The first node 111 may include an interface unit to facilitate communication between the first node 111 and other nodes or devices, such as the second node 112, the third node 113, the fourth node 114, device 130, another node, and / or another structure in the communication system. In some specific examples, the interface may include a transceiver configured, for example, to send and receive radio signals via an air interface according to an arbitrary standard.

[0184] In other embodiments, the first node 111 may include the following configuration shown in Figure 11b. The first node 111 may include one or more processors, such as a processing circuit 1104, within the first node 111 and memory 1105. The first node 111 may also include a radio circuit 1110, which may include, for example, a receive port 1106 and a transmit port 1107. The processing circuit 1104 may be configured or operable to perform method actions according to Figure 2 and / or Figures 5-9 in a manner similar to that described in relation to Figure 11a. The radio circuit 1110 may be configured in the communication system to set up a second node 112, a third node 113, a fourth node 114, a device 130, another node, and / or another structure, and to maintain at least a radio connection.

[0185] Accordingly, embodiments of this specification also relate to a first node 111 operable to handle the mobility of one or more ongoing communication sessions for a device 130 from a source domain 121 to a target domain 122, wherein each of the source domain 121 and the target domain 122 is operable to comprise at least a first communication network 101 and a second communication network 102, and each of the one or more ongoing communication sessions is operable to comprise each group of traffic flows having respective requirements for quality of service or experience, and the first node 111 is operable to operate in at least one of the first communication network 101, the second communication network 102, and another communication network 103. The first node 111 may comprise a processing circuit 1104 and a memory 1105, the memory 1105 containing instructions executable by the processing circuit 1104, thereby the first node 111 is further operable to perform actions described herein with respect to the first node 111, for example, in Figure 2 and / or Figures 5-9.

[0186] Figure 12 shows two different examples in panels a) and b) of arrangement configurations in which the second node 112 performs the method operation described above in relation to Figure 3 and / or Figures 5-9, respectively. In some embodiments, the second node 112 may include the following configuration shown in Figure 12a. The second node 112 can be understood as being for handling the mobility of one or more ongoing communication sessions for device 130 from source domain 121 to target domain 122. Each of the source domain 121 and target domain 122 is configured to have at least a first communication network 101 and a second communication network 102. Each of the one or more ongoing communication sessions is configured to have each group of traffic flows having respective requirements for quality of service or experience. The second node 112 is configured to operate the first communication network 101.

[0187] Several embodiments are included herein. Components from one embodiment may be implicitly assumed to be present in another embodiment, and it will be obvious to those skilled in the art how those components may be used in other exemplary embodiments. In Figure 12, optional boxes are indicated by dashed lines. Some of the following detailed descriptions relate to the operation described for the second node 112 and correspond to the same references provided above, and are therefore not repeated here. For example, a group of traffic flows may be referred to herein as a traffic aggregate.

[0188] The second node 112 is configured, for example, by a providing unit 1201 within the second node 112 to provide the first node 111, which is configured to operate in at least one of the first communication network 101, the second communication network 102, and another communication network 103, with a first feasible migration budget that can be provided to the first communication network 101 for each group of traffic flows in each of one or more ongoing communication sessions having similar requirements for quality of service or experience.

[0189] The second node 112 is also configured to obtain, for example, by an acquisition unit 1202 within the second node 112, one or more third indications from the first node 111 for each group of traffic flows in each of the one or more ongoing communication sessions to be shifted from source domain 121 to target domain 122, each group of traffic flows having similar requirements for quality of service or experience, and which are configured to indicate the allocation of a time budget for the shift between source domain 121 and target domain 122. The time budget allocation configured to be obtained is configured to be based on a first viable migration budget that is viable to the first communication network 101 configured to be provided, and the respective end-to-end performance requirements of the shift.

[0190] In some embodiments, the first communication network 101 may be configured as a mobile network, and the second communication network 102 may be configured as an edge cloud network.

[0191] In some embodiments, the allocation of the time budget for shifts configured to be acquired may be further configured, for each group of traffic flows, in each of one or more ongoing communication sessions having similar requirements for quality of service or experience, based on the respective correspondence between i) a first set of resources configured to belong to a first communication network 101 and a second set of resources configured to belong to a second communication network 102 which is estimated to be necessary for the shift. The first set of resources may be configured to comprise each pair of one or more source core mobile networks and one of one or more target mobile networks. The second set of resources may be configured to comprise each pair of service meshes configured to comprise a source service mesh and a target service mesh. The allocation of the time budget for shifts configured to be acquired may also be further configured, for each group of traffic flows, in each of one or more ongoing communication sessions having similar requirements for quality of service or experience, based on the respective priority of each pair of resources in the shift.

[0192] The second node 112 may also be configured to allocate, for example, groups of traffic flows in each of one or more ongoing communication sessions having similar respective requirements for quality of service or experience, which should be shifted from the source domain 121 to the target domain 122 by a decision unit 1202 within the second node 112.

[0193] Furthermore, the second node 112 may be configured, for example, by a determination unit 1202 within the second node 112 to determine, based on the respective requirements of service or experience quality, one of the following: i) each pair of nodes configured to include each source node in the source domain 121 and each target node in the target domain 122, which are estimated to require a shift to handle each group of traffic flows; ii) each first priority when handling the shift; iii) each first time budget requirement for the shift; iv) each first load to be shifted for each pair of nodes; v) each second load for each pair of nodes; and vi) each first viable migration budget for each pair of nodes.

[0194] The second node 112 may also be configured to provide one or more first indications to the first node 111, for example, by a providing unit 1201 within the second node 112. One or more first indications may be configured to indicate at least one of the following: i) each group of traffic flows in each of one or more ongoing communication sessions that should be shifted from source domain 121 to target domain 122; and ii) each group of traffic flows in each of one or more ongoing communication sessions that have similar requirements for quality of service or experience, wherein the at least one determined is a) each pair of nodes configured to be required for the shift to handle each group of traffic flows, each pair of nodes configured to comprise each source node in source domain 121 and each target node in target domain 122; b) each first priority in handling the shift; c) each first time budget requirement for the shift; d) each first load per pair of nodes; e) each second load to be shifted per pair of nodes; and f) each first feasibility of migration budget per individual pair of nodes.

[0195] In some embodiments, each node in each pair of nodes may be configured to be one of the following: a) a PDU session anchor, b) a node managing the user plane, and c) a UPF. Each pair of nodes may be configured to correspond to each pair of core mobile networks and each pair of service meshes.

[0196] In some embodiments, a) each group of traffic flows may be configured to span a group of microservices; b) each of one or more ongoing communication sessions may be configured to be a PDU session; c) each group of traffic flows having similar requirements for quality of service or experience may be configured to be a traffic aggregate; and d) one or more ongoing communication sessions may be configured to be handled by a service mesh.

[0197] The second node 112 may also be configured, for example, by a determination unit 1202 within the second node 112, to determine one or more service chains from all services in each of one or more ongoing communication sessions for device 130, each of which has requirements to be performed over time in its respective sequence.

[0198] The second node 112 may also be configured to map one or more chains of services, which are configured to be determined by, for example, a mapping unit 1204 within the second node 112, to each group of traffic flows configured to have their respective requirements for quality of service or experience.

[0199] The second node 112 may be configured, for example, to determine the respective end-to-end performance requirements for each of the respective groups of traffic flows configured to be determined by the determination unit 1202 within the second node 112. Each first priority determination may be configured to be based on the respective end-to-end performance requirements configured to be determined.

[0200] Embodiments of this specification, along with computer program code for performing the functions and operations of the embodiments herein, may be implemented via one or more processors, such as processor 1205 in the second node 112 shown in Figure 12. The aforementioned program code may also be provided as a computer program product, for example, in the form of a data carrier that carries the computer program code for performing the embodiments herein when loaded into the second node 112. One such carrier may be in the form of a CD-ROM disk. However, it is executable on other data carriers, such as a memory stick. The computer program code may also be provided as pure program code on a server and downloaded to the second node 112.

[0201] The second node 112 may further comprise a memory 1206 having one or more memory units. The memory 1206 is configured to be used to store acquired information, stored data, configurations, scheduling, and applications, etc., in order to perform the method described herein when executed on the second node 112.

[0202] In some embodiments, the second node 112 can receive information via the receive port 1207 from, for example, the first node 111, the third node 113, another node, and / or device 130. In some examples, the receive port 1207 may be connected to, for example, one or more antennas in the second node 112. In other embodiments, the second node 112 can receive information via the receive port 1207 from another structure in the communication system. Since the receive port 1207 can communicate with the processor 1205, the receive port 1207 can then send the received information to the processor 1205. The receive port 1207 may also be configured to receive other information.

[0203] The processor 1205 in the second node 112 may be further configured to transmit or send information through a transmit port 1208 that can communicate with the processor 1205 and memory 1206 to, for example, the first node 111, the third node 113, another node, device 130, and / or another structure in the communication system.

[0204] Those skilled in the art will also understand that any of the above-described units 1201-1204 may refer to one or more processors configured with a combination of analog and digital circuits, and / or software and / or firmware stored in memory that execute as described above when executed by one or more processors, such as processor 1205. One or more of these processors, as well as other digital hardware, may be contained in a single application-specific integrated circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled on a system-on-a-chip (SoC).

[0205] Any of the above-mentioned units 1201 to 1204 may be a processor 1205 of the second node 112, or an application running on such a processor.

[0206] Accordingly, the methods according to the embodiments described herein for the second node 112 can each be implemented by means of a computer program 1209 comprising instructions, i.e., a software code portion, that cause at least one processor 1205 to perform the operations described herein, so as to be executed by the second node 112 when the computer program 1205 is executed on at least one processor 1205. The computer program 1209 product can be stored in a computer-readable storage medium 1210. The computer-readable storage medium 1210 storing the computer program 1209 may contain instructions that cause at least one processor 1205 to perform the operations described herein, so as to be executed by the second node 112 when the computer program 1205 is executed on at least one processor 1205. In some embodiments, the computer-readable storage medium 1210 may be a non-temporary computer-readable storage medium such as a CD-ROM disk or a memory stick, or it may be stored in cloud space. In other embodiments, the computer program 1209 product may be stored on a carrier containing the computer program, which is one of the following: an electrical signal, an optical signal, a wireless signal, or a computer-readable storage medium 1210.

[0207] The second node 112 may include an interface unit to facilitate communication between the second node 112 and other nodes or devices, such as the first node 111, the third node 113, another node, device 130, and / or another structure in the communication system. In some specific examples, the interface may include a transceiver configured, for example, to send and receive radio signals via an air interface according to an arbitrary standard.

[0208] In other embodiments, the second node 112 may include the following configuration shown in Figure 12b. The second node 112 may include one or more processors, such as a processing circuit 1205, within the second node 112 and memory 1206. The second node 112 may also include a radio circuit 1211, which may include, for example, a receive port 1207 and a transmit port 1208. The processing circuit 1205 may be configured or operable to perform the method operation shown in Figure 3 and / or Figures 5-9, in a manner similar to that described in relation to Figure 12a. The radio circuit 1211 may be configured to set up and maintain at least a radio connection with the first node 111, the third node 113, another node, device 130, and / or another structure in the communication system.

[0209] Accordingly, embodiments of this specification also relate to a second node 112 operable to handle the mobility of one or more ongoing communication sessions for device 130 from source domain 121 to target domain 122, wherein each of the source domain 121 and target domain 122 is operable to comprise at least a first communication network 101 and a second communication network 102, and each of the one or more ongoing communication sessions is operable to comprise each group of traffic flows having respective requirements for quality of service or experience, and the second node 112 is operable to operate in the first communication network 101. The second node 112 may comprise a processing circuit 1205 and a memory 1206, the memory 1206 containing instructions executable by the processing circuit 1205, thereby the second node 112 is further operable to perform operations relating to the second node 112 as described herein, for example, in Figure 3 and / or Figures 5-9.

[0210] Figure 13 depicts two different examples in panels a) and b) of the arrangement configuration in which the third node 113 performs the method operation described above in relation to Figures 4 and / or 5-9. In some embodiments, the third node 113 may include the following configuration shown in Figure 13a. The third node 113 can be understood as being for handling the mobility of one or more ongoing communication sessions for device 130 from source domain 121 to target domain 122. Each of the source domain 121 and target domain 122 is configured to include at least a first communication network 101 and a second communication network 102. Each of the one or more ongoing communication sessions is configured to include each group of traffic flows having respective requirements for quality of service or experience. The third node 113 is configured to operate in the second communication network 102.

[0211] Several embodiments are included herein. Components from one embodiment may be implicitly assumed to be present in another embodiment, and it will be obvious to those skilled in the art how those components may be used in other exemplary embodiments. In Figure 13, optional boxes are indicated by dashed lines. Some of the following detailed descriptions relate to the operation described for the third node 113 and correspond to the same references provided above, and are therefore not repeated here. For example, a group of traffic flows may be referred to herein as a traffic aggregate.

[0212] The third node 113 is configured, for example, by a providing unit 1301 within the third node 113 to provide the first node 111, which is configured to operate in at least one of the first communication network 101, the second communication network 102, and another communication network 103, with a second feasible migration budget for each group of traffic flows in each of one or more ongoing communication sessions having similar requirements for quality of service or experience in the second communication network 102.

[0213] The third node 113 is also configured to obtain, for example, one or more third indications from the first node 111 by an acquisition unit 1302 within the third node 113, for each group of traffic flows in each of the one or more ongoing communication sessions to be shifted from source domain 121 to target domain 122, each group of traffic flows having similar requirements for quality of service or experience, which are configured to indicate the allocation of a time budget for the shift between the first communication network 101 and the second communication network 102. The time budget allocation configured to be obtained is configured to be based on a second migration budget that is feasible for the second communication network 102, which is configured to be provided.

[0214] In some embodiments, the first communication network 101 may be configured as a mobile network, and the second communication network 102 may be configured as an edge cloud network.

[0215] The third node 113 may be further configured to determine a policy for movement by a decision unit 1303 within the third node 113, which is configured to determine available resources in the second communication network 102, based on one or more third indications configured to be acquired.

[0216] The third node 113 may further consist of, for example, a start decision unit 1304 within the third node 113, which is configured to initiate the execution of the migration based on a strategy configured to be determined.

[0217] The third node 113 may be configured, for example, to retrieve one or more second indications from the first node 111 by an acquisition unit 1302 within the third node 113. The one or more second indications may be configured to indicate, for each group of traffic flows in each of one or more ongoing communication sessions that should be shifted from the source domain 121 to the target domain 122 which has similar requirements regarding the quality of service or experience, at least one of the following: i) each first set of resources in the first communication network 101 configured to be estimated as necessary for the shift; ii) each second set of resources in the second communication network 102 configured to be estimated as necessary for the shift; and iii) each first priority when processing the shift. The second migration budget configured to be provided may be configured to be based on the one or more second indications configured to be retrieved.

[0218] In some embodiments, each first set of resources may be configured to include at least one of the following: i) each pair of nodes configured to have each source node in source domain 121 and each target node in target domain 122, which are estimated to be required for the shift to handle each group of traffic flows; ii) each first priority when handling the shift; iii) each first time budget requirement for the shift; iv) each first load per pair of nodes; v) each second load to be shifted per pair of nodes; and vi) each first viable migration budget per pair of nodes.

[0219] In some embodiments, each node in each pair of nodes may be configured as one of a) a PDU session anchor, b) a node managing the user plane, and c) a UPF. Each pair of nodes may be configured to correspond to each pair of core mobile networks and each pair of service meshes.

[0220] In some embodiments, a) each group of traffic flows may be configured to span a group of microservices; b) each of one or more ongoing communication sessions may be configured to be a PDU session; c) each group of traffic flows having similar requirements for quality of service or experience may be configured to be a traffic aggregate; and d) one or more ongoing communication sessions may be configured to be handled by a service mesh.

[0221] In some embodiments, the third node 113 may be configured, for example, by a decision unit 1303 within the third node 113, to determine, for each pair of service meshes, i) each load, ii) each load corresponding to the traffic to be shifted, and iii) a second migration budget that can be implemented for the second communication network 102. The second migration budget may be configured to be determined based on each load configured to be determined and each load configured to correspond to the traffic to be shifted.

[0222] In some embodiments, the strategy for shifting, as configured to be determined, may be configured to be further based on each load, as configured to be determined. Each load may be configured to correspond to the traffic to be shifted and its respective first priority.

[0223] Embodiments of this specification, along with computer program code for performing the functions and operations of the embodiments herein, may be implemented via one or more processors, such as processor 1305 in the third node 113 shown in Figure 13. The aforementioned program code may also be provided as a computer program product, for example, in the form of a data carrier that carries the computer program code for performing the embodiments herein when loaded into the third node 113. One such carrier may be in the form of a CD-ROM disk. However, it is executable on other data carriers, such as a memory stick. The computer program code may also be provided as pure program code on a server and downloaded to the third node 113.

[0224] The third node 113 may further comprise a memory 1306 having one or more memory units. The memory 1306 is configured to be used to store acquired information, stored data, configurations, scheduling, and applications, etc., in order to perform the method described herein when executed on the third node 113.

[0225] In some embodiments, the third node 113 can receive information via the receiving port 1307 from, for example, the first node 111, the second node 112, another node, and / or device 130. In some examples, the receiving port 1307 may be connected to, for example, one or more antennas in the third node 113. In other embodiments, the third node 113 can receive information via the receiving port 1307 from another structure in the communication system. Since the receiving port 1307 can communicate with the processor 1305, the receiving port 1307 can then send the received information to the processor 1305. The receiving port 1307 may also be configured to receive other information.

[0226] The processor 1305 in the third node 113 may be further configured to transmit or send information through a transmit port 1308 that can communicate with the processor 1305 and memory 1306 to, for example, the first node 111, the second node 112, another node, device 130, and / or another structure in the communication system.

[0227] Furthermore, those skilled in the art will understand that the above-mentioned units 1301-1304 may refer to one or more processors configured with a combination of analog and digital circuits, and / or software and / or firmware stored in memory that executes as described above when executed by one or more processors, such as processor 1305. One or more of these processors, as well as other digital hardware, may be contained in a single application-specific integrated circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled on a system-on-a-chip (SoC).

[0228] The aforementioned units 1301-1304 may be the processor 1305 of the third node 113, or an application running on such a processor.

[0229] Therefore, with respect to the third node 113, the methods according to the embodiments described herein can each be implemented by means of a computer program 1309 comprising a software code portion, which provides instructions to cause at least one processor 1305 to perform the operations described herein, so as to be executed by the third node 113 when the computer program 1305 is executed on at least one processor 1305. The computer program 1309 product can be stored in a computer-readable storage medium 1310. The computer-readable storage medium 1310 on which the computer program 1309 is stored may provide instructions to cause at least one processor 1305 to perform the operations described herein, so as to be executed by the third node 113 when the computer program 1309 is executed on at least one processor 1305. In some embodiments, the computer-readable storage medium 1310 may be a non-temporary computer-readable storage medium such as a CD-ROM disk or a memory stick, or it may be stored in cloud space. In other embodiments, the computer program 1309 product may be stored on a carrier containing the computer program, which is one of the following: an electrical signal, an optical signal, a wireless signal, or a computer-readable storage medium 1310.

[0230] The third node 113 may include an interface unit to facilitate communication between the third node 113 and any other node or device, such as the first node 111, the second node 112, another node, device 130, and / or another structure in the communication system. In some specific examples, the interface may include a transceiver configured, for example, to send and receive radio signals via an air interface according to an arbitrary standard.

[0231] In other embodiments, the third node 113 can include the following configuration shown in FIG. 13b. The third node 113 can include one or more processors, such as processor 1305, in the third node 113 and in memory 1306. The third node 113 can also include a wireless circuit 1311 that can include, for example, a receiving port 1307 and a transmitting port 1308. The processing circuit 1305 is configured or operable to perform method operations according to FIGS. 4 and / or FIGS. 5-9 in a manner similar to that described in connection with FIG. 13a. The wireless circuit 1311 can be configured to set up and maintain at least a wireless connection with any one of the first node 111, the second node 112, another node, device 130, and / or another structure within the communication system.

[0232] Thus, embodiments herein also relate to a third node operative to handle the mobility of one or more ongoing communication sessions for device 130 from source domain 121 to target domain 122, each of source domain 121 and target domain 122 being operable to include at least a first communication network 101 and a second communication network 102, each of the one or more ongoing communication sessions being operable to include respective groups of traffic flows having respective requirements regarding quality of service or experience, and the third node being operable to operate the second communication network 102. The third node can include a processing circuit 1305 and a memory 1306, the memory 1306 including instructions executable by the processing circuit 1305, whereby the third node is further operable to perform the operations described herein with respect to the third node in, for example, FIGS. 4 and / or FIGS. 5-9.

[0233] When the terms "comprise" or "comprising" are used, they are non-limiting, i.e., "consist at least of".

[0234] The embodiments of this specification are not limited to the above-described preferred embodiments. Various alternatives, modifications, and equivalents can be used. Therefore, the above embodiments should not be construed as limiting the scope of the present invention.

[0235] In general, all terms used in this specification should be interpreted according to their ordinary meanings in the relevant technical field, unless a different meaning is clearly given and / or implied from the context in which they are used. All references to a / an / element, apparatus, component, means, step, etc. should be construed liberally as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless the step is explicitly described as following or preceding another step and / or it is implicit that the step must follow or precede another step. Any feature of any embodiment disclosed herein can be applied to any other embodiment, whenever appropriate. Similarly, any advantage of any embodiment can be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the accompanying embodiments will become apparent from the following description. As used herein, when a list of alternatives separated by commas follows the phrase "at least one of:", and the last alternative is before the term "and", it can be understood to mean that only one of the alternatives in the list can be applicable, two or more of the alternatives in the list can be applicable, or all of the alternatives in the list can be applicable. This expression can be understood to be equivalent to a list of options separated by commas following the phrase "at least one of:", and the term "or" following the last option.

[0236] Both the terms processor and circuit can be understood as hardware components in this specification.

[0237] Where used herein, the phrase "in some embodiments" is used to indicate that features of the embodiments described may be combined with any other embodiments or examples disclosed herein.

[0238] Where used herein, the phrase “in some examples” is used to indicate that the features of the examples described may be combined with any other embodiments or examples disclosed herein.

Claims

1. A computer implementation method performed by a first node (111), the method for handling the mobility of one or more ongoing communication sessions for a device (130) from a source domain (121) to a target domain (122), each of the source domain (121) and the target domain (122) comprising at least a first communication network (101) and a second communication network (102), each of the one or more ongoing communication sessions comprising a group of traffic flows having requirements for quality of service or experience, the first node (111) operating in at least one of the first communication network (101), the second communication network (102) and another communication network (103), the method, (202) Determining for each group of traffic flows that one or more ongoing communication sessions have similar requirements for quality of service or experience, A correspondence between a first set of resources belonging to the first communication network (101) and a second set of resources belonging to the second communication network (102), which are estimated to be necessary for the shift, The first set of resources comprises a pair of core mobile network nodes, each having one or more source mobile network nodes and one or more target mobile network nodes. The second set of resources comprises a pair of service meshes, each including a source service mesh and a target service mesh. The aforementioned correspondence, The priority in the shift for each pair of resources, To determine, Determining the allocation of the time budget for the shift (205) by communicating with the first communication network (101) and the second communication network (102), wherein the determination of the allocation of the time budget (205) is based on the pair of core mobile network nodes, the pair of service meshes and the priority, in accordance with the end-to-end performance requirements for the shift. Providing one or more indications (206) to at least one of the second node (112) operating within the first communication network (101) and the third node (113) operating within the second communication network (102), wherein the one or more indications indicate the determined allocation. Methods that include...

2. The method according to claim 1, (204) to obtain for each of the aforementioned groups of traffic flows having similar requirements for the quality of service or experience, From the first communication network (101), a first executable migration budget that can be executed to the first communication network (101), From the second communication network (102), a second migration budget that can be executed to the second communication network (102), This further includes obtaining, Determining the allocation of the time budget (205) is a method further based on the acquired first feasible migration budget and the acquired second migration budget.

3. The method of claim 2, wherein the one or more indications provided are one or more third indications, and the method further One or more first indications from the second node (112) that indicate the group of traffic flows in each of the one or more ongoing communication sessions to be shifted from the source domain (121) to the target domain (122), and for each of the group of traffic flows in each of the one or more ongoing communication sessions having similar requirements for quality of service or experience, A pair of nodes, the node pair, which is estimated to require the shift to process the group of traffic flows, the node pair including a source node in the source domain (121) and a target node in the target domain (122), The first priority when processing the aforementioned shift, The first time budget requirement for the shift, The first load per node pair, For each pair of nodes, the second load to be shifted, The first feasible migration budget for each node pair, To obtain at least one of the above, and (201), Providing the one or more second indications to the third node (203), wherein the one or more second indications are based on the one or more first indications obtained (113), It further includes, A method for determining the correspondence and priority, based on one or more first indications obtained.

4. The method according to claim 3, wherein each of the nodes in the pair of nodes is Protocol Data Unit (PDU) session anchor, A node that manages the user plane, User Plane Function (UPF), A method in which each pair of nodes corresponds to a core mobile network pair and a service mesh pair.

5. The method according to claim 1, The aforementioned group of traffic flows spans across groups of microservices. Each of the one or more ongoing communication sessions is a PDU session. The group of traffic flows having similar requirements for the quality of service or experience is a traffic aggregate, and The aforementioned one or more ongoing communication sessions are handled by the service mesh. A method which is at least one of the following.

6. A computer implementation method performed by a third node (113), the method handling the mobility of one or more ongoing communication sessions for a device (130) from a source domain (121) to a target domain (122), each of the source domain (121) and the target domain (122) comprising at least a first communication network (101) and a second communication network (102), each of the one or more ongoing communication sessions comprising a group of traffic flows having requirements for quality of service or experience, and the third node (113) operating in the second communication network (102). To provide a first node (111) operating in at least one of the first communication network (101), the second communication network (102), and another communication network (103), with a second migration budget feasible for the second communication network (102) for each group of traffic flows in each of the one or more ongoing communication sessions having similar requirements for quality of service or experience (403), Obtaining one or more third indications (404) from the first node (111) for groups of traffic flows in each of the one or more ongoing communication sessions to be shifted from the source domain (121) to the target domain (122), each of which has similar requirements for quality of service or experience, the allocation of a time budget for the shift between the first communication network (101) and the second communication network (102), wherein the obtained time budget allocation is based on the second migration budget provided to the second communication network (102) that is feasible. Methods that include...

7. The method according to claim 6, Determining a strategy for the shift (405) based on the one or more third indications obtained and the available resources in the second communication network (102), as estimated by the third node (113), Starting the execution of the shift based on the determined strategy (406), Methods that further include the above.

8. The method according to claim 6, Obtaining one or more second indications (401) from the first node (111), wherein the one or more second indications are for each group of traffic flows in each of the one or more ongoing communication sessions that should be shifted from the source domain (121) to the target domain (122) having similar requirements for quality of service or experience, A first set of resources within the first communication network (101) that are estimated to be necessary for the shift, A second set of resources within the second communication network (102) that are estimated to be necessary for the shift, The first priority when processing the aforementioned shift, Including obtaining at least one of the following: The second migration budget provided is based on the one or more second indications obtained by the method.

9. The method according to claim 8, wherein the first set of resources is A pair of nodes estimated to be required for the shift to process a group of traffic flows, comprising a source node in the source domain (121) and a target node in the target domain (122), The first priority when processing the aforementioned shift, The first time budget requirement for the shift, The first load per node pair, For each pair of nodes, the second load to be shifted, The first feasible migration budget for each node pair, A method that includes at least one of the following.

10. The method according to claim 9, wherein each of the nodes in the pair of nodes is Protocol Data Unit (PDU) session anchor, A node that manages the user plane, User Plane Function (UPF), A method in which one of the following applies, where the pair of nodes corresponds to a pair of core mobile networks and a pair of service meshes.

11. The method according to claim 6, The aforementioned group of traffic flows spans across groups of microservices. Each of the one or more ongoing communication sessions is a PDU session. The aforementioned group of traffic flows having similar requirements for the quality of service or experience is a traffic aggregate, and The aforementioned one or more ongoing communication sessions are handled by the service mesh. A method that is at least one of the following.

12. The method according to claim 8, Determining each pair of service mesh (402), The third load and A fourth load corresponding to the traffic to be shifted, A second migration budget (102) that can be implemented in the second communication network, A method further comprising determining the second migration budget, wherein the second migration budget is determined based on the determined third load and the fourth load corresponding to the traffic to be shifted.

13. A method according to claim 12, wherein the determined strategy for the shift is further based on the determined third load, the fourth load corresponding to the traffic to be shifted, and the first priority.

14. A computer implementation method performed by a second node (112), the method for handling the mobility of one or more ongoing communication sessions for a device (130) from a source domain (121) to a target domain (122), wherein each of the source domain (121) and the target domain (122) comprises at least a first communication network (101) and a second communication network (102), each of the one or more ongoing communication sessions comprises a group of traffic flows having requirements for quality of service or experience, the second node (112) operates in the first communication network (101), and the method is, To provide a first executable migration budget (307) to a first node (111) operating in at least one of the first communication network (101), the second communication network (102), and another communication network (103), for a group of traffic flows in each of the one or more ongoing communication sessions having similar requirements for quality of service or experience, in the first communication network (101), (308) obtaining one or more third indications from the first node (111) that show the allocation of a time budget for the shift between the source domain (121) and the target domain (122) for groups of traffic flows in each of the one or more ongoing communication sessions to be shifted from the source domain (121) to the target domain (122), the groups of traffic flows having similar requirements for quality of service or experience, wherein the obtained allocation of the time budget is obtained based on the first viable migration budget provided to the first communication network (101) and the end-to-end performance requirements for the shift. A method that includes this.

15. The method according to claim 14, wherein the acquired allocation of the time budget for the shift is, for each group of traffic flows, in each of the one or more ongoing communication sessions having similar requirements for quality of service or experience, A correspondence between a first set of resources belonging to the first communication network (101) and a second set of resources belonging to the second communication network (102) that is estimated to be necessary for the shift, The first set of resources comprises a pair of one or more source core mobile network nodes and one or more target mobile network nodes, The second set of resources comprises a pair of service meshes, each including a source service mesh and a target service mesh. The aforementioned correspondence, The priority in the shift for the resource pair, A method based on that.

16. The method according to claim 15, wherein the method further comprises: Determining the group of traffic flows in each of the one or more ongoing communication sessions that have similar requirements for the quality of service or experience and should be shifted from the source domain (121) to the target domain (122) (304), With respect to the group of traffic flows that has been determined, a determination is made based on requirements for the quality of service or experience (305), A pair of nodes, the node pair, which is estimated to require the shift to process a group of traffic flows, the node pair including a source node in the source domain (121) and a target node in the target domain (122), The first priority when processing the aforementioned shift, The first time budget requirement for the shift, The first load per node pair, For each pair of nodes, the second load to be shifted, The first feasible migration budget for each node pair, (305) Determine at least one of the following: Providing one or more first indications to the first node (111) (306), wherein the one or more first indications are The group of traffic flows in each of the one or more ongoing communication sessions that are to be shifted from the source domain (121) to the target domain (122), and For each of the groups of traffic flows in each of the one or more ongoing communication sessions having similar requirements for the quality of service or experience, A pair of nodes which is estimated to require the shift to process the group of traffic flows, the pair of nodes including a source node in the source domain (121) and a target node in the target domain (122), The first priority when processing the aforementioned shift, The first time budget requirement for the shift, The first load for each pair of nodes, For each pair of nodes, the second load to be shifted and The first feasible migration budget for each pair of nodes, At least one determination and To show or provide at least one of the following, Methods that include...

17. The method according to claim 16, wherein each of the nodes in the pair of nodes is Protocol Data Unit (PDU) session anchor, A node that manages the user plane, User Plane Function (UPF), This method involves either a pair of nodes corresponding to a core mobile network pair or a service mesh pair.

18. The method according to claim 14, The aforementioned group of traffic flows spans across groups of microservices. Each of the one or more ongoing communication sessions is a PDU session. The aforementioned group of traffic flows having similar requirements for the quality of service or experience is a traffic aggregate, and The aforementioned one or more ongoing communication sessions are handled by the service mesh. A method which is at least one of the following.

19. The method according to claim 17, (301) Determining from all services in each of the one or more ongoing communication sessions for the device (130) one or more service chains that have the requirement to be executed in sequence over time, (302) Mapping the determined one or more service chains to the group of traffic flows having the requirements for quality of service or experience, Determining the end-to-end performance requirements of the determined traffic flow group (303), wherein the determination of the first priority is based on the determined end-to-end performance requirements, Methods that further include the above.

20. A first node (111) for handling the mobility of one or more ongoing communication sessions for a device (130) from a source domain (121) to a target domain (122), wherein each of the source domain (121) and the target domain (122) is configured to include at least a first communication network (101) and a second communication network (102), each of the one or more ongoing communication sessions is configured to include a group of traffic flows having requirements for quality of service or experience, the first node (111) is configured to operate in at least one of the first communication network (101), the second communication network (102), and another communication network (103), and the first node (111) is configured to perform the method according to any one of claims 1 to 5.

21. A third node (113) for handling the mobility of one or more ongoing communication sessions for a device (130) from a source domain (121) to a target domain (122), wherein each of the source domain (121) and the target domain (122) is configured to include at least a first communication network (101) and a second communication network (102), each of the one or more ongoing communication sessions is configured to include a group of traffic flows having requirements for quality of service or experience, the third node (113) is configured to operate in the second communication network (102), and the third node (113) is configured to perform the method according to any one of claims 6 to 13.

22. A second node (112) for handling the mobility of one or more ongoing communication sessions for a device (130) from a source domain (121) to a target domain (122), wherein each of the source domain (121) and the target domain (122) is configured to include at least a first communication network (101) and a second communication network (102), each of the one or more ongoing communication sessions is configured to include a group of traffic flows having requirements for quality of service or experience, the second node (112) is configured to operate in the first communication network (101), and the second node (112) is configured to perform the method of any one of claims 14 to 19.

Images