WO2022106019A1

WO2022106019A1 - Mobility support for extended reality applications in mobile communication networks

Info

Publication number: WO2022106019A1
Application number: PCT/EP2020/082831
Authority: WO
Inventors: Panagiotis SPAPIS; Stefano PARIS; Devaki Chandramouli; Rastin PRIES
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2020-11-20
Filing date: 2020-11-20
Publication date: 2022-05-27
Anticipated expiration: 2023-05-20

Abstract

Methods, systems and computer programs to support mobility for XR services are provided. A handover of a user equipment (UE) executing an extended reality (XR) application over a connection with a source base station comprises, in response to deciding to handover the UE, sending, by the source base station, a handover request to a target base station. The handover request comprises an XR context specifying a current state of the XR application. XR context information may also be utilized at the level of an Edge Data Network in order to resource adequate resources of a target Edge Application Server to support execution of the XR application after the handover.

Description

MOBILITY SUPPORT FOR EXTENDED REALITY APPLICATIONS IN MOBILE COMMUNICATION NETWORKS

FIELD

[0001] This disclosure generally relates to mobile communication networks such as a 5G communication network, and more particularly to handover procedures.

BACKGROUND

[0002] Mobile telecommunication services rely on a continuous connection to a network to work properly and take advantage of the full service. To ensure the continuous connection, a mobile device operating consuming a service of the network monitors the connection quality and regularly transmits measurement reports to the current base station indicating the current state of the radio quality. In the event of a quality drop, e.g. due to movement of the mobile station out of coverage of the current base station, the network supports a handover to another base station to maintain radio quality.

[0003] For new generations of mobile communication systems such as 5G networks currently under standardization by the 3rd Generation Partnership Project (3GPP), virtual reality applications executed by the mobile stations are to be supported, as specified e.g. by 3 GPP TR 26.928. Among these applications, extended Reality (XR) and Cloud Gaming are some of the most important 5G media applications under consideration in the industry. XR is an umbrella term for different types of realities and refers to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. Different application domains of XR Applications include entertainment, healthcare, education, etc.

[0004] Furthermore, 3GPP TS 23.558 defines architectural solutions for enabling Edge applications. This term refers to user application which are supported and hosted by server elements of particular networks being part of the overall communication network referred to as Edge networks. Edge networks are logically located between the Radio Access Network (RAN) which provides network access to the mobile stations and the core portion (core network) of the communication network. This architecture is schematically shown by FIG. 1. As FIG. 1 depicts, the Edge Data Network (EDN) contains Edge Application Server(s) (EAS) and the Edge Enabler Server (EES); the operation of the latter is supported by the Edge Configuration Server (ECS). The Edge Data Network (EDN) contains Edge Application Server(s)

SUBSTITUTE SHEET (RULE 26) (EAS) and the Edge Enabler Server (EES) and EDGE-X interfaces to communicate with the servers of the network. The UE contains an application client, which has the task for the proper execution of an MR/AR/XR application, and the Edge Enabler Client as interface to communicate with the other EDN network servers.

[0005] The EAS is the application server resident in the Edge Data Network, performing the server functions and is connected to the 3GPP core via Radio Access Network (RAN). The EES facilitates context transfer between EES(s) and EAS(s) and interacts with the 3 GPP core either directly (e.g. via PCF) or indirectly (e.g. via SCEF/NEF/SCEF+NEF). Additionally, the EES provides configuration information to Edge Enabler Client enabling exchange of application data traffic with the EAS. The ECS provides supporting functions needed for the Edge Enabler Client to connect with an EES. Additionally, the ECS supports the EES in identifying other EESs (and EASs) in case of application relocations. Furthermore, EDGE-9 symbolizes the connection to another EDN. In case of a relocation from one EAS to another, EDGE-9 is the connection from a source EES to a target EES.

[0006] In this context, handover procedures are sought that facilitate virtual-reality application and the envisaged network architecture.

SUMMARY

[0007] In this context, methods, systems and computer programs supporting mobility for XR services are presented.

[0008] According to a first aspect, a method to perform a handover in a communication network, the communication network comprising a plurality of base stations including a source base station and a target base station, wherein the method is for handing over a user equipment (UE) executing an extended reality (XR) application over a connection with the source base station, the method comprising in response to deciding to handover the UE, sending, by the source base station, a handover request to the target base station, the handover request comprising an XR context specifying a current state of the XR application.

[0009] According to a second aspect, a system to perform a handover in a communication network is provided. The communication network comprises a plurality of base stations including a source base station and a target base station. The system is for handing over a user equipment (UE) executing an extended reality (XR) application over a connection with the source base station. The source base station is arranged to in response to deciding to handover the UE, send a handover request to the target base station. The handover request comprises an XR context specifying a current state of the XR application.

[0010] According to a third aspect, a computer program is presented which comprises computer program code which, when executed by a computer, causes at least one computer to perform the method aspect mentioned above.

[0011] According to a fourth aspect, a method to perform a handover in a communication network is provided. The communication network comprises an Edge Configuration Server (ECS) and a source Edge Data Network (EDN) comprising a source Edge Enabler Server (EES) and a source Edge Application Server (EAS). The method is for handing over a user equipment (UE) executing an extended reality (XR) application over a connection with the source EDN. The method comprises an EAS relocation procedure comprising sending, by the source EES, UE and XR application information to the ECS, and receiving, by the source EES, a list with a number of Edge Application Servers suitable to support the XR application, the list including at least one target EAS of at least one target EDN.

[0012] According to a fifth aspect, a system to perform a handover in a communication network is provided. The communication network comprises an Edge Configuration Server (ECS) and a source Edge Data Network (EDN) comprising a source Edge Enabler Server (EES) and a source Edge Application Server (EAS). The system is for handing over a user equipment (UE) executing an extended reality (XR) application over a connection with the source EDN. The source EES is arranged to perform an EAS relocation procedure by being arranged to send UE and XR application information to the ECS, and receive a list with a number of Edge Application Servers suitable to support the XR application, the list including at least one target EAS of at least one target EDN.

[0013] According to a sixth aspect, a computer program is presented which comprises computer program code which, when executed by a computer, causes at least one computer to perform the aforementioned method aspect.

[0014] According to a seventh aspect, an apparatus for handing over a user equipment (UE) executing an extended reality (XR) application is provided. The apparatus is arranged to receive a handover request from a source base station, wherein the handover request comprises an XR context specifying a current state of the XR application.

[0015] Further refined aspects are set forth in the dependent claims. BRIEF DESCRIPTION OF THE FIGURES

[0016] Aspects and examples of the present disclosure are described with reference to the following figures, in which:

[0017] FIG. 1 shows an architecture for enabling edge applications.

[0018] FIG. 2 visualizes a handover procedure over time involving edge data networks.

[0019] FIG. 3 depicts a handover preparation procedure to support XR applications as described herein.

[0020] FIG. 4 relates to an EAS relocation procedure and context supporting the handover procedure of FIG. 3 at the level of the edge data networks.

[0021] FIG. 5 shows an admission control flowchart.

[0022] FIG. 6 shows an admission control flowchart based on conditional QoS requirements of the UE.

[0023] FIG. 7 depicts an internal structure of a base station and further network nodes.

DETAILED DESCRIPTION

[0024] 3GPP TR 26.928 defines the terms Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and extended Reality (XR) are defined as follows:

- Virtual reality (VR) is a rendered version of a delivered visual and audio scene. The rendering is designed to mimic the visual and audio sensory stimuli of the real world as naturally as possible to an observer or user as they move within the limits defined by the application. Virtual reality usually, but not necessarily, requires a user to wear a head mounted display (HMD), to completely replace the user's field of view with a simulated visual component, and to wear headphones, to provide the user with the accompanying audio. Some form of head and motion tracking of the user in VR is usually employed to allow the simulated visual and audio components to be updated in order to ensure that, from the user's perspective, items and sound sources remain consistent with the user's movements. Additional means to interact with the virtual reality simulation may be provided. - Augmented reality (AR) is when a user is provided with additional information or artificially generated items or content overlaid upon their current environment. Such additional information or content will usually be visual and/or audible and their observation of their current environment may be direct, with no intermediate sensing, processing and rendering, or indirect, where their perception of their environment is relayed via sensors and may be enhanced or processed.

- Mixed reality (MR) is an advanced form of AR where some virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene.

- Extended reality (XR) refers to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. XR includes representative forms such as AR, MR and VR and the areas interpolated among them. The levels of virtuality range from partially sensory inputs to fully immersive VR. A key aspect of XR is the extension of human experiences especially relating to the senses of existence (represented by VR) and the acquisition of cognition (represented by AR).

[0025] Likewise, the term XR is used herein as a superordinate category covering AR, MR and VR including purely virtual applications.

[0026] According to the descriptions of use cases of virtual reality applications such as XR applications given by 3GPP TR 22.842, many of the XR applications are expected to be stateful, meaning that the applications have a state describing the UE application status at a certain point of time. Additionally, the fact that the UEs are expected to interact (e.g., in gaming applications) implies that the various UEs' states should be shared among the UEs. This introduces several challenges during a handover (HO) procedure:

- The target gNB should be prepared and have adequate radio resources to accommodate the UE executing the XR application.

- In case of a handover failure, the UE will experience service interruption, thus the network should try to ensure seamless handover (considering also application relocation) to avoid an interruption of the XR application.

- In case of a User Plane Function (UPF) relocation, the new UPF may not be able to offer the XR service. - During the handover, the target EAS may not be properly prepared to take over the EAS functionalities from the previous EAS to avoid long delays.

[0027] The present disclosure addresses these challenges and generally relates to a handover in a communication network such as a mobile communication network, e.g. a 5G network. Note that the present disclosure relates to various types and generations of communication networks configured to communicate over the transmission medium using any of various radio access technologies (RATs), also referred to as wireless communication technologies, or telecommunication standards, such as GSM, UMTS (associated with, for example, WCDMA or TD-SCDMA air interfaces), LTE, LTE-Advanced (LTE-A), 5G new radio (5GNR), HSPA, 3GPP2 CDMA2000 (e.g, IxRTT, IxEV-DO, HRPD, eHRPD), etc.

[0028] The communication network is equipped with a plurality of base stations including a source base station and a target base station. The handing concerns a UE executing an XR application over a connection with the source base station. As used herein, the term "user equipment" may refer to any of various types of computer systems devices which are mobile or portable and which perform wireless communications. Examples of UEs include mobile telephones or smart phones, portable gaming devices, laptops, wearable devices (e.g, smart watch, smart glasses), Personal Digital Assistants (PDAs), portable Internet devices, music players, data storage devices, or other handheld devices, etc. In general, the term "UE" can be broadly defined to encompass any electronic, computing, and/or telecommunications device (or combination of devices) which is easily transported by a user and capable of wireless communication.

[0029] The present disclosure is particularly directed to enable the target base station (target gNodeB or gNB in 5G terminology) to support an XR application of the UE in terms of radio capabilities and regarding the resources at the Edge Data Network (EDN), as already introduced above. In embodiments, the target base station and the target EDN(s) are properly prepared to undertake the UE XR capabilities and the proper User Plane Function (UPF) is selected considering the XR capabilities of the Application Function (AF) regarding XR application aspects. Also, during handover, a proper UPF may be re-selected considering the XR capabilities of the target AF, also if the application were to be relocated during handover.

[0030] FIG. 2 visualizes an exemplary handover procedure described herein at a general level in a 5G use case. These mechanisms refer to all kinds of handover procedures, e.g. mobile and base station initiated, and also cover the cases of hard handover, dual connectivity handover, conditional handover and non-conditional handover. The communication network includes a plurality of base stations (gNBl, gNB2, gNB3), respectively forming a radio cell, i.e. a communication area (or coverage area) of the base station (Celli, Cell2, Cell3). As used herein, the term "base station" has the full breadth of its ordinary meaning, and at least includes a wireless communication station installed at a fixed location and used to communicate as part of a wireless telephone system or radio system. Base station gNBl operates as the source base station for the UE 12, while base station gNB2 operates as the target base station. The base stations are respectively linked to an EDN, i.e. the source base station to XR-EDN1 and the target base station to XR-EDN2. As mentioned above, the EDNs comprise a respective Edge Application Server (EAS), namely the source EDN XR-EDN1 comprises a source EAS linked to the source base station gNBl and the target EDN XR-EDN2 comprises a target EAS linked to the target base station gNB2. The source EAS serves the XR application to the UE over the connection 14 with the source base station.

[0031] A UE 12 executes a virtual reality application such as an XR, an MR, an VR, or an AR application and is first connected 14 to a source gNBl linked to a source XR-EDN1. The time axis at the bottom of FIG. 2 schematically shows the points of time of the events occurring during the handover procedure. At time tl, the UE 12 is connected to the source base station and is able to connect to the target base station gNB2, but the connection to gNBl is still stronger and preferred over gNB2. The target gNB2 with the target XR-EDN2 is set up to receive a handover request at a time tl when the radio conditions of the UE 12 deteriorate (e.g. by the UE 12 moving out of the coverage of the source gNBl, represented by cell 1). During the time period between time tl and time t2, the UE 12 might be connected to both base stations, the source base station gNBl and the target base station gNB2. After the handover at a time t2, the UE 12 is connected 16 to the target gNB2 linked to the target XR-EDN2 and is ready to release the connection 15 to the source gNBl, marked by the dashed line. In the event that the handover to the target base station gNB2 fails, the UE 12 is able to continue usage of the connection 15 to the source gNBl and e.g. a handover attempt to still another base station such as gNB3 may be undertaken.

[0032] In order to prepare the handover, the source gNBl transmits a handover request to the target gNB2 to enable the target gNB2 to reserve radio resources for the connection with the UE 12. According to the present disclosure, the source base station sends the handover request to the target base station in response to deciding to handover the UE 12, and the handover request includes an XR context specifying a current state of the XR application. Hence, the current state of the virtual reality application (i.e. the XR context) is included in the HO request from the source base station gNBl to the target base station gNB2. The target base station gNB2 takes into consideration the received XR context of the XR application and determines whether or not a sufficient quality of service level to continue execution of the XR application at the UE 12 with the corresponding traffic of the UE 12 can be provided. To this end, the target base station gNB2 performs an admission control procedure, which will be described further below.

[0033] FIG. 3 depicts the enhancements for the handover preparation in order to facilitate the admission of the UE in the target gNB by way of a message sequence chart, exemplarily for a 5G mobile communication network being based on 3GPP Release 16 specifications.

[0034] According to FIG. 3 in activity 31, the source gNB has configured UE measurement procedures and the UE reports according to the measurement configuration. Accordingly, the UE reports current channel and radio environment conditions to the source gNB and the source gNB evaluates the measurement reports from the UE in order to assess whether or not and when a handover might be due. Basics of measurements and handover criteria are known to the skilled person.

[0035] Secondly, in the handover decision activity 32, the source gNB decides to handover the UE in response to determining, based on the measurement reports, that a handover criterion is present.

[0036] Thirdly, in activity 33, the source gNB issues a Handover Request message to the target gNB, e.g. by passing a transparent Radio Resource Control (RRC) container with information to prepare the handover at the target base station. The information of the handover request includes e.g. a target cell ID with information (e.g., the current Quality of Service (QoS) flow to Dedicated Radio Bearer (DRB) mapping rules applied to the UE), the SIB 1 (System Information Block 1) from source gNB, the UE capabilities for different Radio Access Technologies (RATs), Protocol Data Unit (PDU) session related information- slice information and QoS flow level QoS profile(s), etc.). According to the present disclosure, the handover request also contains the XR context as explained above to enable the target gNB to perform admission control for the UE also with respect to the XR application currently executed between the UE and the source EDN, such as Degrees of Freedom (DoF) (i.e., 3DoF, 3DoF+, 6DoF, Constrained 6DoF); position of the UE; viewport of the MR application; position and an orientation of user within the XR application; latency and/or persistence of the XR application, and a split compute and/or rendering state of the XR application, and potentially others (in FIG. 3 denoted as "XR Characteristics").

[0037] Afterwards, in activity 34, an admission control procedure may be performed by the target gNB based on the XR context in order to accept or reject the handover request. The admission control procedure may comprise determining, by the target base station based on the XR context, whether radio resources of the target base station are sufficient to support traffic of the XR application with at least a similar quality of service as the connection with the source base station. To this end, the target base station evaluates the XR characteristics specified by the XR context to determine the resource demand of the XR application's radio traffic and then evaluates whether or not sufficient radio resources are available to handle the traffic of the XR application of the UE. If the XR characteristics are not adequately supported, the target gNB may reject the handover request. If the radio resources of the target base station are sufficient to support the XR characteristics, the target base station accepts the handover request.

[0038] In some embodiments, inputs from the target EDN are additionally considered in the admission control procedure 34 performed by the target base station, if available. Inputs from the target EDN may be available either upon request from the target gNB or pushed from the target EDN. An exemplary implementation of a mechanism to provide EDN input is given further below with respect of FIG. 4.

[0039] If the admission control procedure 34 of the target base station is successful, i.e. radio resources are sufficiently available, the target gNB prepares the handover with given Layer 1/ Layer 2 procedures and sends, in activity 35, a Handover Request Acknowledge to the source gNB.

[0040] In activity 36, the source gNB triggers the UE handover e.g. by sending an RRC Reconfiguration message to the UE, containing information to access the target cell, as e.g. per Release 16. This concludes the handover preparation phase 37 and UE and network enter the handover execution and completion phase.

[0041] As mentioned above, the XR context includes information specifying the current state of the XR application executed at the UE, referred to as XR characteristics. The XR characteristics may include the degrees of freedom of the XR application (DoF). In line with 3GPP TR 26.928, the DoF information of the XR context may include, depending on the particular XR application executed by the UE: - 3DoF : Three rotational and un-limited movements around the X, Y and Z axes (respectively pitch, yaw and roll). A typical use case is a user sitting in a chair looking at 3D 360 VR content on an HMD.

- 3DoF+: 3DoF with additional limited translational movements (typically, head movements) along X, Y and Z axes. A typical use case is a user sitting in a chair looking at 3D 360 VR content on an HMD with the capability to slightly move his head up/down, left/right and forward/backward.

- 6DoF: 3DoF with full translational movements along X, Y and Z axes. Beyond the 3DoF experience, it adds (i) moving up and down (elevating/heaving); (ii) moving left and right (strafing/swaying); and (iii) moving forward and backward (walking/surg- ing). A typical use case is a user freely walking through 3D 360 VR content (physically or via dedicated user input means) displayed on an HMD.

- Constrained 6DoF : 6DoF with constrained translational movements along X, Y and Z axes (typically, a couple of steps walking distance). A typical use case is a user freely walking through VR content (physically or via dedicated user input means) displayed on an HMD but within a constrained walking area.

[0042] Hence, the DoF information included in the XR context depends on the current mechanical movement of the UE.

[0043] The XR context may also include current physical attributes of the UE such as the UE's geographic position and viewport direction of the XR application, as well as position and orientation of the user within the XR application to maintain the state of the XR application. The position and an orientation of the user within the XR application in the request are used to prevent unexpected movements within the XR application, e.g. a sitting person in the application cannot stand up when the user is already standing.

[0044] The XR context may further include information about latency and/or persistence of the XR application, as well as the split compute and/or rendering state of the XR application. These attributes are utilized to ensure the continuously operating XR application without abrupt lagging.

[0045] In some embodiments, the handover procedure of FIGS. 2 and 3 is performed using Dual Connectivity (DC) functions to promote connection continuity in source and target cell during handover execution. In these embodiments, before handover preparation is initiated (tl - FIG. 2), the DC functionality is activated at the source server EDN1 exchanging XR application PDUs with the UE in uplink and downlink direction, while the target server EDN2 activates an XR application session for the UE triggered by EDN1. The source EDN1 keeps the current XR application state synchronized with the target server EDN2 by transferring UE context to the target EDN2, e.g. periodically updating the changes of the current state of the XR application by periodically transferring XR context updates to the target EDN2.

[0046] After the handover is completed (t2 - FIG. 2), the target EDN2 becomes the new serving EDN, i.e. the XR application PDU flow in downlink now passes through gNB2 from EDN2. The DC functions remain active, so that the serving EDN2 keeps the state of previous source EDN1 synchronized by transferring the XR context to the previous source EDN1 in the same manner as the aforementioned XR context synchronization.

[0047] At last, when the signal strength from the previous source gNBl falls below an offset (e.g. due to the UE moving further out of the radio coverage of the previous source gNBl), the previous source EDN1 is released and the DC functionality is deactivated.

[0048] When the previous DC handover procedure is employed, the synchronization between the two EDNs takes place and causes XR application information captured by UE (DoF information, view, position, angles, etc., as set out above) to be shared with both spatial computing servers (EAS) - using an uplink connection and the rendered 3D content to be transmitted only by the new serving EDN2 (and the EAS of the EDN2) - using a downlink connection.

[0049] Hence, the source and target EASs are enabled to coordinate the timely transfer of the XR context information. EASs are able to obtain the location information (exact or rough) of a UE from the EESs. The EESs may have this information from the Network Exposure Function (NEF) or other network entities with such information, such as the base stations or gNBs. The information provided by the EAS is used to proceed in the respective actions to enable the XR application context transfer of the UE to the EASs which are candidate to execute XR application at the server side and support the XR application for the UE.

[0050] In some embodiments, during the handover preparation phase, the XR application context may be transferred to multiple EASs that are associated with multiple potential target gNBs. The handover procedure type where multiple candidate target gNBs are prepared for a handover is referred to as Conditional Handover (CHO). These gNBs are also provided as candidate target gNBs to the UE as elaborated in 3GPP TS 38.300. Once the handover procedure is finalized, the XR application context will be released from the candidate gNBs and their respective EASs that will not eventually serve the UE, i.e. which have not become new serving gNBs / EASs. According to CHO procedures, the UE receives a list of potential gNBs, in order to promote that the handover will be successful and to increase reliability. The same gNBs that are sent to the UE in the CHO list (list containing the candidate gNBs) will be the gNBs associated with the EAS to serve the UE after the handover.

[0051] In this regard, FIG. 4 visualizes a proactive EAS relocation procedure and context release in the EDN. As mentioned above, the source EDN comprises a source Edge Enabler Server (EES1) and a source Edge Application Server (EAS1). Likewise, the target EDN comprises a source Edge Enabler Server (EES2) and a source Edge Application Server (EAS2). Further candidate EDNs may be considered, such as a third EDN with a third Edge Enabler Server (EES3) and a third Edge Application Server (EAS3). The Edge environment also includes the Edge Configuration Server (ECS).

[0052] In activity 41, the serving EAS (EAS1) subscribes to the EES1 for receiving UE location events. The EES1 subscribes to the 5G system for receiving UE location events. The EES relocation procedure may be executed in response to a mobility event indicating a potential future handover related to the UE executing the XR application. Hence, at a later point of time, in activity 42, the EES1 informs the serving EAS about a mobility event for UE based on notification from the 5G system. In activity 43, the EAS1 requests from the ECS to discover alternative EASs that can serve the UE exiting the coverage/serving area of EAS 1.

[0053] With continued reference to FIG. 4, in some embodiments, the source EES sends UE and XR application information to the ECS, and receives a list with a number of Edge Application Servers suitable to support the XR application, the list including the target EAS. This is shown by activities 44 and 45. Activity 44 retrieves information to prepare the potential target EASs for the relocation. The EES requests from the ECS the EAS list that can accommodate the UE. The request contains UE information and application information, potentially including the UE location, the UE accessed service, the UE accessed service characteristics, including, stateful/stateless service, interactive, supported DoF, view port, etc. and the UE capabilities, including, processing capabilities, memory, battery level.

[0054] In activity 45, the ECS provides to the EES1 the list of the EAS that can serve the UE as a response to the EES request. This first iteration provides the EASs that have the minimum conditions met to ensure that the UE is supported in the new location.

[0055] Afterwards, in activity 46, the EES1 sends a discovery request to the EESs supporting the EASs that can serve the UE. Hence, the target EAS receives the discovery request from the source EES and performs an application admission control procedure. To this end, in activities 47, the EES2 and EES3 evaluate if they can accommodate the UE, meaning that they can provide the resources needed for the UE.

[0056] With continued reference to FIG. 4, in some embodiments, the target EAS(s) indicate^), to the target base station by the target EAS based on the discovery request, an ability of the target EAS to support the XR application. Accordingly, in activity 48, the EES2 and EES3 inform the associated target base stations (gNBs) directly or indirectly (e.g., though other network functions responsible for network exposure) about their ability to accommodate the UE service request. Optionally, this information can also be used by the gNB for the admission control during handover. In some embodiments, the activity 48 may be triggered by a message from the associated target base stations (gNBs) in order to perform the admission control procedure 34, described further below (FIG. 5). Thus, in these embodiments, the procedure of FIG. 4 forms a logical part of the admission control procedure 34 of the target gNB.

[0057] In activity 49, the EES2 and EES3 respond to the request from the EES1 if they can accommodate the UE. In activity 50, EES1 informs EAS1 about the list of the EASs that can serve the UE after they responded whether their resources are sufficient or not. In this exemplary use case EAS2 and EAS3 are provided by the EAS list that can serve the UE in case of a handover.

[0058] With still continued reference to FIG. 4, the target EAS receives XR application information from the source EAS and reserves resources for the XR application to prepare the handover. Accordingly, in activity 51, the EAS1 transfers the XR application context to the EAS2 and EAS3 so as to be ready to accommodate the UE if the UE will be relocated to the respective EAS. In this exemplary use case, EAS2 is the selected target EAS. In activity 52, in case a mobility cancellation event is produced e.g. by the gNBs to release the UE context in case of a CHO (if the UE does not eventually handover to these gNBs). The mobility cancellation event is provided to the EES (i.e., EES3). Lastly, in activity 53, the EES3 informs the EAS3 to release the UE context, given that the UE will not be served by the EAS3. Thus, in response to a mobility event indicating a cancelation of the handover, the candidate target EAS which has not been selected, releases the previously reserved resources.

[0059] To exemplarily quantify the technical gains of preparing the handover as described above, e.g. also at the EDN level by providing XR application context information to the target EDN, an exemplary test scenario is assumed with multiple UEs and a HO failure rate of 0.5 and a CHO failure rate of 0.2. Furthermore, it is assumed that the delay cost for a successful HO/CHO is 50 ms and the context transfer between two edge cloud servers is 0.5 s. Having used a test evaluation scenario with 1000 handover events, the table below provides the mean values of the delay in case of a handover:

[0060] When a handover event is considered without proactive EDN preparation, the mean delay is in the range of 550 ms. The small number of handover failures slightly increases the mean delay value. The other two cases, with the proactive preparation have significantly reduced delay, since the time required for transferring the UE context from the one EDN to the other is omitted. In the case where the EDNs associated to the prepared gNBs (for the CHO) are not prepared, the mean delay is slightly increased; the small number HOs to gNBs with unprepared EDNs does not significantly impact to the mean delay. It should be noted though that in cases where the UE will end up being served by an unprepared EDN the delay will be in the range of 550 ms, as also mentioned above. Finally, it is to be noted that for different network configurations, the HO may end up with different delays.

[0061] In some embodiments, the admission control procedure 34 performed by the target base station in response to receiving the handover request comprises determining whether the link of the target base station to the target EDN has sufficient network resources to support traffic of the XR application; and/or determining whether the target EAS has sufficient computing resources to support the execution of the XR application. FIG. 5 shows a possible implementation of the admission control procedure performed for the level of the potential target EDNs in order to provide input for the admission control algorithm 34 of the target base station. Generally, the mechanism of FIG. 5 determines whether at least one EAS exist that has sufficient computing resources and at least one communication link to the target base station with sufficient network resources.

[0062] At activity 61, a list of EASs that might be able to serve the UE and the XR application executed by the UE is determined. The EASs on the list are checked, at activity 62, if computation resources as well as, at activity 63, the communication path composed of back- haul/core route and radio link meet the QoS requirements of the XR application executed at the UE. With respect to the computation resources of the EASs, it is e.g. checked if an EAS has sufficient free memory and computation power to support the XR application of the UE at the server side. With respect to the network resources, QoS metrics like delay, bandwidth and reliability of the communication link between the respective EAS and the target base station may be verified.

[0063] In some embodiments, activity 61 is performed by the target base station, potentially with support of further network elements. The evaluation of the EAS computing resources and of the respective link resources 63 in the respective activities 62 and 63 may be triggered by the target base station gNB2 by pulling the EAS capabilities to support the UE, or may be effected by pushing this information from the EAS to the target base station gNB2 (similar to activity 48 in FIG. 4). In case of gNB pulling EAS capabilities, the target base station gNB2 is aware from which target EAS to pull such information because each gNB may be associated to a limited (finite) number of EAS and may perform a request to the limited (finite) number of EAS. In case of the target EAS pushing this information to the target gNB, the EAS may know the target gNB2 using one or more of the following: through available location information (associated to location of the target gNBs), via knowledge of the associated gNBs (and pushing this information to one or more of the associated gNBs), via mobility knowledge available in the Network Exposure Function (NEF) specified by 5G specifications (or technically similar functions of other mobile telecommunication standards).

[0064] If, for a given EAS, at least a communication link that meets the aforementioned requirements exists and the EAS has enough computation resources, the EAS may be added to a candidate list of EASs. After the evaluation of all available EASs on the list is completed, it is determined, at activity 64, whether the candidate list of EASs is empty or whether there is at least one EAS on the candidate list. If the candidate list is empty, the handover request is rejected by the target base station in activity 65, otherwise the handover request is accepted by the target base station in activity 66.

[0065] In some refined embodiments, when computing resources and/or network resources are insufficient for any EASs, the handover may also be conditionally accepted instead of simply refused. The UE and/or the network (e.g. the source base station) may be informed of the current impossibility or uncertainty of satisfying the current QoS requirements for the XR application with the current resources. The final decision of the HO is left to the network (source base station) or the UE.

[0066] For example, the UE may decide to reduce the QoS requirements for the XR application and/or to continue the execution of the XR application or partial functionality of the XR application locally in order to reduce the XR application PDU traffic with the EAS to a degree so that at least one of the EASs on the list may become eligible to support the reduced QoS requirements of the XR application. The handover preparation including the admission control procedure of FIG. 5 may then be executed for a second time with an updated XR context specifying the reduced QoS requirements of the XR application in order to effect acceptance of the handover.

[0067] In some refined embodiments, executing the admission control procedure of FIG. 5 for multiple times may be spared by the UE providing multiple sets of QoS requirements, e.g. on a list of QoS requirements. The list of QoS requirements may be specified by the XR context. The QoS requirements on the list are classified into unconditional and conditional admission QoS requirements. For example, the optimal QoS requirements supporting execution of the XR application to a full extent (highest graphical resolution, smallest delay, i.e. highest network connection demands) may be classified as an unconditional QoS requirement. For the event the target base station, the target EAS or the link between both is determined to be unable to provide the unconditional QoS requirement, one or more conditional QoS requirements may be listed which specify reduced QoS requirements still supporting an execution of the XR application with reduced quality (e.g. reduced graphical resolution, less network traffic). Optionally, the QoS requirements are ranked and processed from unconditional QoS requirement set (e.g. defining the highest QoS requirements) to the least QoS requirements (e.g. minimum resources to run the XR application). This allows to check multiple sets of QoS requirements in a conditional manner within one iteration of the admission control procedure.

[0068] An exemplarily admission control procedure checking conditional QoS requirements is shown in FIG. 6. In some refined embodiments, the admission control starts by the UE sending a list of QoS requirements for the XR application to the network, at activity 71. This may occur asynchronously to the handover procedure, e.g. already when establishing the connection 14 with the source base station. Activity 71 may also encompass receiving, by the source base station, the list of the QoS requirements from the source base station by way of activity 33 of FIG. 3 during the handover procedure. Hence, the XR characteristics of FIG. 2 may include the conditional and unconditional QoS requirements of FIG. 6. [0069] During the handover procedure, the QoS requirements in the list are evaluated in sequence by the admission control algorithm, starting with activity 72, until one item in the list (i.e., a set of QoS requirements) can be provided by the network with the current available resources. Similar to FIG. 5, at activity 73, it is determined whether at least one EAS has computing resources and a network link to the target base station available which are sufficient for the QoS requirements considered in the current iteration of the process of FIG. 6. If the set of QoS requirements that can be provided with the current resources, activity 74 checks whether the currently tested QoS requirements were marked as unconditional (i.e. the resources are sufficient without any penalties), at activity 75. If affirmative, the handover is accepted, the source base station may be notified that the handover is admitted unconditionally, at activity 76. If, on the other hand, the currently tested set of QoS requirements that can be satisfied with the current resources was marked as conditional (i.e. the resources have some penalties, but are sufficient to run the XR application with reduced quality), the source base station may be notified that the handover is admitted in a conditional manner, at activity 80 and 81.

[0070] If activity 73 determines that the currently tested QoS requirements (unconditional or conditional) cannot be supported with the currently available resource, activity 77 checks whether there the list still includes a further set of the (further reduced) QoS requirements to be tested. If affirmative, the sub-process of activities 72 and 73 and so on are performed again in a further iteration. In case that no EAS can be found even though the QoS requirements are set to a minimum to still support execution of the XR application, i.e. the list of QoS requirements has been unsuccessfully processed completely and there is thus no further item on the list to be processed (activities 73 and 77), then the handover is rejected, at activity 78 and the source base station is notified that admission control failed (activity 79).

[0071] When the admission control procedure has accepted the handover request in activity 66, and more than one EAS was on the candidate list, the network (e.g. the target base station) may select the EAS. This selection may be based on multiple criteria like load balancing of network and EAS resources and energy efficiency. Furthermore, multiple EASs and communication links may be selected for reasons of redundancy to improve reliability.

[0072] In some embodiments, the EAS relocation procedure may be performed independent from or in parallel to a handover procedure between the source base station gNBl and a target base station gNB2. For example, the EAS relocation procedure with the application admission control at the level of the Edge Data Networks is performed proactively for any potential future handover situation in order to provide seamless service continuity to the UE running an XR application and accelerate any future handover procedure. In some embodiments, the EAS relation procedure may be performed inline in the course of a handover procedure between the source base station gNBl and a target base station gNB2. The results of the application admission control procedure may be pushed to the corresponding target base station gNB2 in an asynchronous manner. As already mentioned above, in these embodiments, the proactive EAS relocation procedure may be triggered by the at least one target base station gNB2 which may pull the results of the application admission control procedure at the EDN level to form a part of the admission control procedure of the target base station gNB2.

[0073] In some embodiments, the handover procedures may also facilitate selection of the new User Plane Function (UPF) of the communication network. According to the 5G architecture, the UPF is responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU session for interconnecting Data Networks. The EES may act as a trusted Application Function (AF) to the core network (e.g. 5G Core Network, 5GC) to provide capabilities of the EAS. As set out by 3GPP TS 23.501, this may be performed considering a generic interactions framework between AFs and 5GC; such interactions aim to impact, among others, UPF selection.

[0074] Besides the preparation for the handover of the UE and the preparation of the relocation in the EDN as described above, the UPF may be selected considering the current XR state of the XR application currently executed by the UE. To this end, to select a proper UPF able to support the UE with the target AF in the course of the handover procedures described herein, an AF request is supplemented with additional XR-application-related information.

[0075] The AF request as currently specified by 3GPP specifications contains numerous information elements, such as a traffic description, potential locations of applications, the target UE identifiers, spatial validity conditions, AF transaction identifiers, traffic routing requirements, application relocation possibilities, the UE IP address preservation indications, the temporal validity conditions and information on AF subscriptions to corresponding session management function events. Additionally, according to the present methodologies, the AF request is supplemented with additional XR-application-related information, such as:

- Stateful: specifies if the XR application is stateful or not, e.g. a one bit flag.

- Multi UE: specifies if the XR application supports interactions with multiple UEs.

- Supported DoF : specifies the degrees of freedom that are to be supported by an AF. [0076] In addition, the AF request may include EAS/AF load information. An EAS/AF is generally able to support a limited/finite number of UEs in case of XR applications due to processing and memory limitations. This information may be provided to the session management function and may be considered by the session management function for the UPF selection.

[0077] FIG. 7 illustrates a simplified block diagram of a network node 411 in accordance with some embodiments. Network node 411 may be a base station combined with an MME or AMF. Network node 411 has an antenna 415, which transmits and receives radio signals. A radio frequency (RF) transceiver module 414, coupled with the antenna, receives RF signals from antenna 415, converts them to baseband signals and sends them to processor 413. RF transceiver 414 also converts received baseband signals from processor 413, converts them to RF signals, and sends out to antenna 415. Processor 413 processes the received baseband signals and invokes different functional modules to perform features in network node 411. Memory 412 stores program instructions and data 420 to control the operations of the network node 411. In the example of FIG. 7, network node 411 also includes protocol stack 480 and a set of control functional modules and circuit 490 implementing the mobility management functionality described above. Suitable processors include, by way of example, a special purpose processor, a digital signal processor (DSP), a plurality of micro-processors, one or more micro-processor associated with a DSP core, a controller, a microcontroller, application specific integrated circuits (ASICs), file programmable gate array (FPGA) circuits, and other type of integrated circuits (ICs), and/or state machines. Other nodes of the communication network such as the servers of the EDNs are equipped accordingly, i.e. with similar internal components. Instead of RF transceiver module 414 and antenna 415, these nodes may be employed wired communication technologies in order to communicate with the other network nodes.

[0078] In general, the routines executed to implement the embodiments, whether implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions, or even a subset thereof, may be referred to herein as "computer program code" or simply "program code". Program code typically comprises computer-readable instructions that are resident at various times in various memory and storage devices in a computer and that, when read and executed by one or more processors in a computer, cause that computer to perform the operations necessary to execute operations and/or elements embodying the various aspects of the embodiments of the invention. Computer- readable program instructions for carrying out operations of the embodiments of the invention may be, for example, assembly language or either source code or object code written in any combination of one or more programming languages.

[0079] In certain alternative embodiments, the functions and/or acts specified in the flowcharts, sequence diagrams, and/or block diagrams may be re-ordered, processed serially, and/or processed concurrently without departing from the scope of the invention. Moreover, any of the flowcharts, sequence diagrams, and/or block diagrams may include more or fewer blocks than those illustrated consistent with embodiments of the invention.

[0080] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the embodiments of the disclosure. It will be further understood that the terms "comprise" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Furthermore, to the extent that the terms "includes", "having", "has", "with", "comprised of', or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprising".

[0081] While a description of various embodiments has illustrated all of the inventions and while these embodiments have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. The invention in its broader aspects is therefore not limited to the specific details, representative apparatus and method, and illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of the applicant’ s general inventive concept.

Claims

CLAIMS A method to perform a handover in a communication network, the communication network comprising a plurality of base stations including a source base station and a target base station, wherein the method is for handing over a user equipment (UE) executing an extended reality (XR) application over a connection with the source base station, the method comprising: in response to deciding to handover the UE, sending, by the source base station, a handover request to the target base station, the handover request comprising an XR context specifying a current state of the XR application. The method of claim 1, wherein the XR context comprises information about one or more of degrees of freedom of the XR application, a position of the UE, a viewport of the XR application, a position and an orientation of user within the XR application, a latency and/or persistence of the XR application, and a split compute and/or rendering state of the XR application. The method of claim 1 or claim 2, wherein the source base station and the target base station are linked to a respective Edge Data Network (EDN) comprising a respective Edge Application Server (EAS), namely a source EDN comprising a source EAS linked to the source base station and at least one target EDN comprising at least one target EAS linked to the target base station, wherein the source EAS serves the XR application to the UE over the connection with the source base station. The method of claim 3, the method comprising: performing, by target base station, an admission control procedure based on the XR context in order to accept or reject the handover request. The method of claim 4, wherein the admission control procedure comprises: determining, by the target base station based on the XR context, whether radio resources of the target base station are sufficient to support traffic of the XR application with at least a similar quality of service as the connection with the source base station. The method of claim 5, wherein the admission control procedure comprises: determining whether the link of the target base station to the target EDN has sufficient network resources to support traffic of the XR application; and/or determining whether the at least one target EAS has sufficient computing resources to support the execution of the XR application. The method of any one of claims 4 to 6, wherein the XR context comprises a list of sets of quality of service requirements of the XR application executed by the UE and performing the admission control procedure comprises determining whether at least one of the sets of quality of service requirements can be fulfilled by the target base station and/or the target EDN and the admission control procedure results in one of an unconditional accept, a conditional accept or a reject of the handover request. The method of any one of claims 3 to 7, wherein the communication network comprises an Edge Configuration Server (ECS) and the source EDN comprises a source Edge Enabler Server (EES), wherein the method comprises an EAS relocation procedure comprising: sending, by the source EES, UE and XR application information to the ECS, and receiving, by the source EES, a list with a number of Edge Application Servers suitable to support the XR application, the list including the at least one target EAS. The method of claim 8, wherein the at least one target EDN comprises at least one EES and the EAS relocation procedure is executed in response to a mobility event indicating a potential future handover related to the UE executing the XR application and comprises: receiving, at the at least one target EES, a discovery request from the source EES, performing an application admission control procedure, and indicating, to the target base station, performing the admission control procedure, by the at least one target EES based on the discovery request, an ability of the at least one target EAS to support the XR application. The method of claim 9, wherein the EAS relocation procedure further comprises: receiving, at the at least one target EAS, XR application information from the source EAS, reserving, by the at least one target EAS, resources for the XR application to prepare the handover. The method of claim 10, wherein the EAS relocation procedure further comprises: in response to a mobility event indicating a cancelation of the handover, releasing, by the at least one target EAS, the resources. The method of any one of claims 1 to 11, wherein the communication network is a mobile communication network according to 3 GPP specifications, in particular a 5G network. The method of any of claims 1 to 12, wherein the XR application is one of a Mixed Reality (MR) application and an Augmented Reality (AR) application. A system to perform a handover in a communication network, the communication network comprising a plurality of base stations including a source base station and a target base station, wherein the system is for handing over a user equipment (UE) executing an extended reality (XR) application over a connection with the source base station, wherein the source base station is arranged to: in response to deciding to handover the UE, send a handover request to the target base station, the handover request comprising an XR context specifying a current state of the XR application.

15. The system of claim 14, wherein the XR context comprises information about one or more of degrees of freedom of the XR application, a position of the UE, a viewport of the XR application, a position and an orientation of user within the XR application, a latency and/or persistence of the XR application, and a split compute and/or rendering state of the XR application.

16. The system of claim 14 or 15, wherein the source base station and the target base station are linked to a respective Edge Data Network (EDN) comprising a respective Edge Application Server (EAS), namely a source EDN comprising a source EAS linked to the source base station and at least one target EDN comprising at least one target EAS linked to the target base station, wherein the source EAS serves the XR application to the UE over the connection with the source base station.

17. The system of claim 16, wherein target base station is arranged to perform an admission control procedure based on the XR context in order to accept or reject the handover request.

18. The method of claim 17, wherein the target base station is arranged to perform the admission control procedure by being arranged to: determine, based on the XR context, whether radio resources of the target base station are sufficient to support traffic of the XR application with at least a similar quality of service as the connection with the source base station.

19. The system of claim 17 or claim 18, wherein target base station is arranged to perform the admission control procedure by further being arranged to: determine whether the link of the target base station to the target EDN has sufficient network resources to support traffic of the XR application; and/or determine whether the at least one target EAS has sufficient computing resources to support the execution of the XR application. The system of any one of claims 17 to 19, wherein the XR context comprises a list of sets of quality of service requirements of the XR application executed by the UE and the admission control procedure comprises determining whether at least one of the sets of quality of service requirements can be fulfilled by the target base station and/or the target EDN and the admission control procedure results in one of an unconditional accept, a conditional accept or a reject of the handover request. The system of any one of claims 16 to 19, wherein the communication network comprises an Edge Configuration Server (ECS) and the source EDN comprises a source Edge Enabler Server (EES), wherein the source EES is arranged to perform an EAS relocation procedure by being arranged to: send UE and XR application information to the ECS, and receive a list with a number of Edge Application Servers suitable to support the XR application, the list including the at least one target EAS. The system of claim 21, wherein the at least one target EDN comprises at least one EES and the EAS relocation procedure is executed in response to a mobility event indicating a potential future handover related to the UE executing the XR application and the at least one target EES is arranged to perform the EAS relocation procedure by being arranged to: receive a discovery request from the source EES, performing an application admission control procedure, and indicate, to the target base station, performing the admission control procedure, based on the discovery request, an ability of the at least one target EAS to support the XR application. The system of claim 22, wherein the at least one target EAS is arranged to perform the EAS relocation procedure by further being arranged to: receive XR application information from the source EAS, reserve resources for the XR application to prepare the handover. The system of claim 23, wherein the at least one target EAS is arranged to perform the EAS relocation procedure by further being arranged to: release the resources in response to a mobility event indicating a cancelation of the handover. The system of any one of claims 13 to 22, wherein the communication network is a mobile communication network according to 3 GPP specifications, in particular a 5G network. The system of any of claims 14 to 25, wherein the XR application is one of a Mixed Reality (MR) application and an Augmented Reality (AR) application. A computer program comprising computer program code which, when executed by a computer, causes at least one computer to perform the method of any one of claims 1 to 13. A method to perform a handover in a communication network, the communication network comprising an Edge Configuration Server (ECS) and a source Edge Data Network (EDN) comprising a source Edge Enabler Server (EES) and a source Edge Application Server (EAS), wherein the method is for handing over a user equipment (UE) executing an extended reality (XR) application over a connection with the source EDN, wherein the method comprises an EAS relocation procedure comprising: sending, by the source EES, UE and XR application information to the ECS, and receiving, by the source EES, a list with a number of Edge Application Servers suitable to support the XR application, the list including at least one target EAS of at least one target EDN. The method of claim 28, wherein the EAS relocation procedure is executed in response to a mobility event indicating a potential future handover related to the UE executing the XR application and comprises: receiving, at least one target EES of the at least one target EDN, a discovery request from the source EES, and indicating, to at least one target base station, performing an admission control procedure, by the at least one target EES based on the discovery request, an ability of the at least one target EAS to support the XR application.

30. The method of claim 29, wherein the EAS relocation procedure further comprises: receiving, at the at least one target EAS, XR application information from the source EAS, reserving, by the at least one target EAS, resources for the XR application to prepare the handover.

31. The method of claim 30, wherein the EAS relocation procedure further comprises: in response to a mobility event indicating a cancelation of the handover, releasing, by the at least one target EAS, the resources.

32. A system to perform a handover in a communication network, the communication network comprising an Edge Configuration Server (ECS) and a source Edge Data Network (EDN) comprising a source Edge Enabler Server (EES) and a source Edge Application Server (EAS), wherein the method is for handing over a user equipment (UE) executing an extended reality (XR) application over a connection with the source EDN, wherein the source EES is arranged to perform an EAS relocation procedure by being arranged to: send UE and XR application information to the ECS, and receive a list with a number of Edge Application Servers suitable to support the XR application, the list including at least one target EAS of at least one target EDN.

33. The system of claim 32, wherein the EAS relocation procedure is executed in response to a mobility event indicating a potential future handover related to the UE executing the XR application and at least one target EES of the at least one target EDN is arranged to perform the EAS relocation procedure by being arranged to: receive a discovery request from the source EES, and indicate, to at least one target base station, performing an admission control procedure, based on the discovery request, an ability of the at least one target EAS to support the XR application. 34. The system of claim 33, wherein the at least one target EAS is arranged to perform the EAS relocation procedure by being arranged to: receive XR application information from the source EAS, reserve resources for the XR application to prepare the handover.

35. The system of claim 34, wherein the at least one target EAS is arranged to perform the EAS relocation procedure by further being arranged to: release the resources in response to a mobility event indicating a cancelation of the handover.

36. A computer program comprising computer program code which, when executed by a computer, causes at least one computer to perform the method of any one of claims 28 to 31.

37. An apparatus for handing over a user equipment (UE) executing an extended reality (XR) application, wherein the apparatus comprises: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus at least to receive a handover request from a source base station, wherein the handover request comprises an XR context specifying a current state of the XR application.

38. The apparatus of claim 37, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus: perform an admission control procedure based on the XR context in order to accept or reject the handover request.

39. The apparatus of claim 38, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to perform the admission control procedure by causing the apparatus to: determine, based on the XR context, whether radio resources of the apparatus are sufficient to support traffic of the XR application with at least a similar quality of service as the source base station.

40. The apparatus of claim 39, wherein the apparatus is linked to a target Edge Data Network (EDN) comprising at least one target Edge Application Server (EAS) and wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to perform the admission control procedure by causing the apparatus to: determine whether the link of the apparatus to the target EDN has sufficient network resources to support traffic of the XR application; and/or determine whether the at least one target EAS has sufficient computing resources to support the execution of the XR application.

41. The apparatus of claim 40, wherein the XR context comprises a list of sets of quality of service requirements of the XR application executed by the UE and wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus further to perform the admission control procedure by causing the apparatus to determine whether at least one of the sets of quality of service requirements can be fulfilled by the apparatus and/or the target EDN and the admission control procedure results in one of an unconditional accept, a conditional accept or a reject of the handover request.

42. The apparatus of any one of claims 37 to 41, wherein the apparatus is a target base station.

43. An apparatus for handing over a user equipment (UE) executing an extended reality (XR) application, wherein the apparatus comprises means for receiving a handover request from a source base station, wherein the handover request comprises an XR context specifying a current state of the XR application.