Updating protocol data unit set parameters based on analysis in wireless communication system

Abstract

There is provided a method in an application entity of a wireless communication system for managing performance of one or more virtual experience applications, the method comprising: receiving performance parameters for a virtual experience application session; determining a network requirement for the virtual experience application session based on the received performance parameter, where determining the network requirement includes identifying one or more protocol data unit (PDU) sets for the virtual experience application session; and determining a respective PDU set parameter for each of the identified sets of PDUs based on the determined network requirements.

Description

Technical Field

[0001] The subject matter disclosed herein generally relates to the field of determining and / or updating protocol data unit (PDU) set parameters based on analysis in a wireless communication system or network, and more particularly to the field of analysis related to virtual experience application services or sessions (such as related to the performance or quality of service of performance virtual experience application services or sessions). Background Art

[0002] As used herein, the term "virtual experience" is a general term for different types of virtual reality, including but not limited to extended reality (XR), virtual reality, augmented reality, mixed reality, and the metaverse. XR itself can be used as a general term for different types of reality (examples of which are virtual reality, augmented reality, and mixed reality).

[0003] Virtual experience application services are subject to strict bandwidth and latency constraints in order to deliver an appropriate quality of service and quality of experience to the end-users of the virtual experience application services. Such strict bandwidth and latency constraints can make it challenging to deliver virtual experience application services over a wireless communication network. Summary of the Invention

[0004] In the context of XR media services, the 3GPP SA2 working group recently introduced the concept of "PDU set" to group a series of PDUs carrying information units at the application level. Thus, each PDU within a PDU set can be processed according to the same QoS requirements and a set of associated constraints on latency budget and error rate, while providing support for differentiated QoS handling at the PDU set level to the RAN. This increases the granularity of the traditional 5G QoS flow framework, allowing the RAN to optimize the mapping between QoS flows and DRBs to meet the strict XR media requirements (e.g., high-speed transmission with a short latency budget).

[0005] Disclosed herein is a process for collecting data related to XR-specific attributes and deriving a per-service profile (e.g., PDU set, media or service type, or even per-XR session) of the traffic within an XR session. The process can be implemented by an application entity.

[0006] A method in an application entity of a wireless communication system is provided for managing the performance of one or more virtual experience applications. The method includes: receiving performance parameters for a virtual experience (e.g., XR) application session; determining, based on the received performance parameters, network requirements for the virtual experience application session, wherein determining the network requirements includes identifying one or more protocol data unit PDU sets for the virtual experience application session; and determining, based on the determined network requirements, corresponding PDU set parameters for each PDU set among the identified PDU sets.

[0007] There is also provided an application entity for a wireless communication system, the application entity comprising: a transceiver; and a processor coupled to the transceiver, the processor and the transceiver being configured such that the application entity: receives performance parameters for a virtual experience application session; determines network requirements for the virtual experience application session based on the received performance parameters, wherein the determination of the network requirements includes identifying one or more sets of protocol data units (PDUs) for the virtual experience application session; and determines corresponding PDU set parameters for each of the identified sets of PDUs based on the determined network requirements.

[0008] There is also provided a user equipment (UE) device, the UE device comprising: a transceiver; and a processor coupled to the transceiver, the processor and the transceiver being configured such that the UE device: receives configuration information specifying, for each of one or more sets of PDUs for a virtual experience application session, one or more parameters related to one or more performance attributes of the PDU set; and monitors one or more parameters of the virtual experience application session according to the received configuration information. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] To describe the manner in which the advantages and features of the present disclosure can be obtained, the present disclosure is described by reference to certain devices and methods shown in the accompanying drawings. Each of these drawings depicts only certain aspects of the present disclosure and should not therefore be considered to limit its scope. For clarity, the drawings may have been simplified and are not necessarily drawn to scale.

[0010] A method and apparatus for collecting data related to XR-specific attributes and deriving a performance analysis for each service profile will now be described by way of example only with reference to the accompanying drawings, in which:

[0011] Figure 1 a wireless communication system is depicted;

[0012] Figure 2 a user equipment device is depicted;

[0013] Figure 3 a network node is depicted;

[0014] Figure 4 an overview of a core network architecture for processing sets of PDUs is illustrated;

[0015] Figure 5 an exemplary XR enabler service is illustrated;

[0016] Figure 6 a process in which the XR enabler influences PDU set parameters / requirements based on an analysis is illustrated;

[0017] Figure 7 illustrates a process in which PDU set parameters / requirements are updated or influenced based on analysis; and

[0018] Figure 8 is a process flow diagram showing certain steps of a method for determining PDU set parameters / requirements. Detailed Description

[0019] Those skilled in the art will understand that aspects of the present disclosure may be implemented as a system, apparatus, method, or program product. Accordingly, the arrangements described herein may be implemented in entirely hardware form, entirely software form (including firmware, resident software, microcode, etc.), or in a form combining software and hardware aspects.

[0020] For example, the disclosed methods and apparatuses may be implemented as hardware circuits, including custom very large scale integration (“VLSI”) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed methods and apparatuses may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed methods and apparatuses may include one or more physical or logical blocks of executable code, which may be organized, for example, as objects, procedures, or functions.

[0021] In addition, the methods and apparatuses may take the form of a program product, which is implemented in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transmissive. The storage device may not implement a signal. In certain arrangements, the storage device only uses a signal for accessing the code.

[0022] Any combination of one or more computer-readable media may be utilized. The computer-readable medium may be a computer-readable storage medium. The computer-readable storage medium may be a storage device storing the code. The storage device may be, but is not limited to, for example, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micro-mechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0023] More specific examples (a non-exhaustive list) of storage devices will include: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable compact disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this specification, a computer-readable storage medium can be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0024] Throughout this specification, references to examples of a particular method or apparatus, or like language, mean that a particular feature, structure, or characteristic described in connection with the example is included in at least one implementation of the methods and apparatuses described herein. Thus, unless expressly stated otherwise, references to features of examples of a particular method or apparatus, or like language, may, but do not necessarily, refer to the same example, but rather to “one or more but not all examples”. Unless expressly stated otherwise, the terms “including”, “comprising”, “having” and variations thereof mean “including but not limited to”. Unless expressly stated otherwise, a list of items does not imply that any or all of the items are mutually exclusive. Unless expressly stated otherwise, the terms “a”, “an” and “the” also mean “one or more”.

[0025] As used herein, a list with the conjunction “and / or” includes any single item in the list or a combination of items in the list. For example, the list of A, B, and / or C includes only A, only B, only C, the combination of A and B, the combination of B and C, the combination of A and C, or the combination of A, B, and C. As used herein, a list using the term “one or more of...” includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, the combination of A and B, the combination of B and C, the combination of A and C, or the combination of A, B, and C. As used herein, a list using the term “one of...” includes one and only one item from any single item in the list. For example, “one of A, B, and C” includes only A, only B, or only C, and does not include the combination of A, B, and C. As used herein, “a member selected from the group consisting of A, B, and C” includes one and only one of A, B, or C, and does not include the combination of A, B, and C. As used herein, “a member selected from the group consisting of A, B, and C and combinations thereof” includes only A, only B, only C, the combination of A and B, the combination of B and C, the combination of A and C, or the combination of A, B, and C.

[0026] In addition, the described features, structures, or characteristics herein may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the present disclosure. However, those skilled in the relevant art will recognize that the disclosed methods and apparatuses may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the present disclosure.

[0027] Aspects of the disclosed methods and apparatuses are described below with reference to schematic flowcharts and / or schematic block diagrams of methods, apparatuses, systems, and program products. It will be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executed via the processor of the computer or other programmable data processing apparatus can create means for implementing the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0028] The code can also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to operate in a particular manner, such that the instructions stored in the storage device produce an article of manufacture that includes instructions for implementing the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0029] The code can also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices, thereby producing a computer-implemented process, such that the code executed on the computer or other programmable apparatus provides a process for implementing the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0030] The schematic flowcharts and / or schematic block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods, and program products. In this regard, each block in the schematic flowcharts and / or schematic block diagrams may represent a module, segment, or portion of code that includes one or more executable instructions for implementing the specified logical function(s).

[0031] It should also be noted that in some alternative implementations, the functions shown in the blocks may not occur in the order shown in the figures. For example, in fact, two consecutive blocks shown may be executed substantially simultaneously, or these blocks may sometimes be executed in the reverse order, depending on the functions involved. Other steps and methods equivalent in function, logic, or effect to one or more blocks or portions thereof of the figures shown may be envisioned.

[0032] The description of elements in each figure may refer to elements in subsequent figures. In all the figures, the same numerals represent the same elements.

[0033] Figure 1 An embodiment of a wireless communication system 100 is depicted in which methods and apparatuses for collecting data related to XR-specific attributes and deriving a per-traffic profile (e.g., PDU set, media or traffic type, or even per-XR session) of traffic within an XR session for performance analysis can be implemented. In one embodiment, the wireless communication system 100 includes a remote unit 102 and a network unit 104. Although Figure 1 a specific number of remote units 102 and network units 104 are depicted, those skilled in the art will recognize that any number of remote units 102 and network units 104 may be included in the wireless communication system 100.

[0034] In one embodiment, the remote unit 102 may include a computing device such as a desktop computer, laptop computer, personal digital assistant (“PDA”), tablet computer, smart phone, smart TV (e.g., a TV connected to the Internet), set-top box, gaming console, security system (including security cameras), in-vehicle computer, network device (e.g., router, switch, modem), aircraft, drone, etc. In some embodiments, the remote unit 102 includes a wearable device such as a smart watch, fitness band, optical head-mounted display, etc. Additionally, the remote unit 102 may be referred to as a subscriber unit, mobile station, mobile terminal, user, terminal, mobile terminal, fixed terminal, subscriber station, UE, user terminal, device, or other terms used in the art. The remote unit 102 may communicate directly with one or more of the network units in the network unit 104 via UL communication signals. In certain embodiments, the remote unit 102 may communicate directly with other remote units 102 via sidelink communication.

[0035] Network element 104 can be distributed over a geographical area. In some embodiments, network element 104 may also be referred to as an access point, access terminal, base, base station, Node B, eNB, gNB, home Node B, relay node, device, core network, air server, radio access node, AP, NR, network entity, access and mobility management function (“AMF”), unified data management function (“UDM”), unified data repository (“UDR”), UDM / UDR, policy control function (“PCF”), radio access network (“RAN”), network slice selection function (“NSSF”), operation, administration, and maintenance (“OAM”), session management function (“SMF”), user plane function (“UPF”), application function, authentication server function (“AUSF”), security anchor function (“SEAF”), trusted non-3GPP gateway function (“TNGF”), application function, service enabler architecture layer (“SEAL”) function, vertical application enabler server, edge enabler server, border configuration server, mobile edge computing platform function, mobile edge computing application, application data analytics enabler server, SEAL data delivery server, middleware entity, network slice capability management server, or any other term used in the art. Network element 104 is generally part of a radio access network that includes one or more controllers communicatively coupled to one or more corresponding network elements 104. The radio access network is generally communicatively coupled to one or more core networks, which may be coupled to other networks such as the Internet and public switched telephone networks. These and other elements of the radio access network and core network are not shown, but are generally well known to those of ordinary skill in the art.

[0036] In one implementation, wireless communication system 100 complies with the New Radio (NR) protocol standardized in 3GPP, where network element 104 transmits on the downlink (DL) using an orthogonal frequency division multiple access (“OFDM”) modulation scheme, and remote unit 102 transmits on the uplink (UL) using a single carrier frequency division multiple access (“SC-FDMA”) scheme or an OFDM scheme. However, more generally, wireless communication system 100 may implement some other open or proprietary communication protocol, such as WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth , ZigBee, Sigfox, and other protocols. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0037] Network element 104 can serve multiple remote units 102 within a service area (e.g., a cell or a cell sector) via a wireless communication link. Network element 104 transmits DL communication signals to serve remote units 102 in the time domain, frequency domain, and / or spatial domain.

[0038] Figure 2 User equipment device 200 is depicted that can be used to implement the methods described herein. User equipment device 200 is used to implement one or more of the solutions described herein. User equipment device 200 conforms to one or more of the user equipment devices described in the embodiments herein. Specifically, user equipment device 200 can be Figure 1 identical or the same as remote unit 102. User equipment device 200 includes a processor 205, a memory 210, an input device 215, an output device 220, and a transceiver 225.

[0039] Input device 215 and output device 220 can be combined into a single device, such as a touch screen. In some implementations, user equipment device 200 does not include any input device 215 and / or output device 220. User equipment device 200 can include one or more of the following: processor 205, memory 210, and transceiver 225, and may not include input device 215 and / or output device 220.

[0040] As depicted, transceiver 225 includes at least one transmitter 230 and at least one receiver 235. Transceiver 225 can communicate with one or more cells (or wireless coverage areas) supported by one or more base units. Transceiver 225 can be operable on unlicensed spectrum. Additionally, transceiver 225 can include multiple UE panels supporting one or more beams. Additionally, transceiver 225 can support at least one network interface 240 and / or application interface 245. Application interface(s) 245 can support one or more APIs. Network interface(s) 240 can support 3GPP reference points, such as Uu, N1, PC5, etc. As would be understood by one of ordinary skill in the art, other network interfaces 240 can be supported.

[0041] The processor 205 may include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 205 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field-programmable gate array (“FPGA”), or a similar programmable controller. The processor 205 may execute instructions stored in the memory 210 to perform the methods and routines described herein. The processor 205 is communicatively coupled to the memory 210, the input device 215, the output device 220, and the transceiver 225.

[0042] The processor 205 may control the user equipment device 200 to implement the user equipment device behavior described herein. The processor 205 may include an application processor (also referred to as the “main processor”) that manages application domains and operating system (“OS”) functions and a baseband processor (also referred to as the “baseband radio processor”) that manages radio functions.

[0043] The memory 210 may be a computer-readable storage medium. The memory 210 may include volatile computer storage media. For example, the memory 210 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). The memory 210 may include non-volatile computer storage media. For example, the memory 210 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 210 may include both volatile computer storage media and non-volatile computer storage media.

[0044] The memory 210 may store data related to implementing the service category field as described herein. The memory 210 may also store program code and related data, such as an operating system or other controller algorithms operating on the device 200.

[0045] The input device 215 may include any known computer input device, including a touchpad, buttons, a keyboard, a stylus, a microphone, etc. The input device 215 may be integrated with the output device 220, for example, as a touchscreen or a similar touch-sensitive display. The input device 215 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. The input device 215 may include two or more different devices, such as a keyboard and a touchpad.

[0046] The output device 220 may be designed to output visual, auditory, and / or tactile signals. The output device 220 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 220 may include, but is not limited to, a liquid crystal display (“LCD”), a light emitting diode (“LED”) display, an organic LED (“OLED”) display, a projector, or a similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, the output device 220 may include a wearable display that is separate from but communicatively coupled to the remainder of the user device apparatus 200, such as a smartwatch, smart glasses, a heads-up display, etc. Additionally, the output device 220 may be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0047] The output device 220 may include one or more speakers for generating sound. For example, the output device 220 may generate an audible alert or notification (e.g., a beep or a ringtone). The output device 220 may include one or more haptic devices for generating vibration, movement, or other tactile feedback. All or part of the output device 220 may be integrated with the input device 215. For example, the input device 215 and the output device 220 may form a touchscreen or a similar touch-sensitive display. The output device 220 may be located near the input device 215.

[0048] The transceiver 225 communicates with one or more network functions of a mobile communication system or network via one or more access networks. The transceiver 225 operates under the control of the processor 205 to transmit messages, data, and other signals, and also to receive messages, data, and other signals. For example, the processor 205 may selectively activate the transceiver 225 (or a portion thereof) at a particular time in order to transmit and receive messages.

[0049] The transceiver 225 includes at least one transmitter 230 and at least one receiver 235. One or more transmitters 230 may be used to provide uplink communication signals to a base unit of a wireless communication system. Similarly, one or more receivers 235 may be used to receive downlink communication signals from the base unit. Although only one transmitter 230 and one receiver 235 are illustrated, the user device apparatus 200 may have any suitable number of transmitters 230 and receivers 235. Additionally, the (multiple) transmitters 230 and the (multiple) receivers 235 may be of any suitable type of transmitter and receiver. The transceiver 225 may include a first transmitter / receiver pair for communicating with the mobile communication system via a licensed radio spectrum, and a second transmitter / receiver pair for communicating with the mobile communication system via an unlicensed radio spectrum.

[0050] A first transmitter / receiver pair that can be used to communicate with a mobile communication system over a licensed radio spectrum, and a second transmitter / receiver pair that can be used to communicate with a mobile communication system over an unlicensed radio spectrum can be combined into a single transceiver unit, such as a single chip that performs functions for use with both the licensed radio spectrum and the unlicensed radio spectrum. The first transmitter / receiver pair and the second transmitter / receiver pair can share one or more hardware components. For example, certain transceivers 225, transmitters 230, and receivers 235 can be implemented as physically separate components that access shared hardware resources and / or software resources, such as network interface 240.

[0051] One or more transmitters 230 and / or one or more receivers 235 can be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-chip, an application-specific integrated circuit (“ASIC”), or other types of hardware components. One or more transmitters 230 and / or one or more receivers 235 can be implemented and / or integrated into a multi-chip module. Other components, such as network interface 240 or other hardware components / circuits, can be integrated with any number of transmitters 230 and / or receivers 235 into a single chip. The transmitters 230 and receivers 235 can be logically configured as transceivers 225 that use one or more common control signals, or as modular transmitters 230 and receivers 235 implemented in the same hardware chip or multi-chip module.

[0052] Figure 3 Additional details of a network node 300 that can be used to implement the methods described herein are depicted. The network node 300 can be an implementation of an entity in a wireless communication network (e.g., one or more of the wireless communication networks described herein, such as, Figure 1 the wireless communication system 100). Specifically, the network node 300 can be consistent with or the same as Figure 1 the network unit 104. The network node 300 can be, for example, the UE device 200 described above, or a network function (NF) or application function (AF) of one or more wireless communication networks of the embodiments described herein, or another entity, such as Figure 1 the wireless communication system 100. The network node 300 includes a processor 305, a memory 310, an input device 315, an output device 320, and a transceiver 325.

[0053] The input device 315 and the output device 320 can be combined into a single device, such as a touch screen. In some implementations, the network node 300 does not include any input device 315 and / or output device 320. The network node 300 can include one or more of the following items: a processor 305, a memory 310, and a transceiver 325, and may not include an input device 315 and / or an output device 320.

[0054] As depicted, the transceiver 325 includes at least one transmitter 330 and at least one receiver 335. Here, the transceiver 325 communicates with one or more remote units 200. Additionally, the transceiver 325 can support at least one network interface 340 and / or an application interface 345. The (multiple) application interfaces 345 can support one or more APIs. The (multiple) network interfaces 340 can support 3GPP reference points, such as Uu, N1, N2, and N3. As understood by those of ordinary skill in the art, other network interfaces 340 can be supported.

[0055] The processor 305 can include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 305 can be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or a similar programmable controller. The processor 305 can execute instructions stored in the memory 310 to perform the methods and routines described herein. The processor 305 is communicatively coupled to the memory 310, the input device 315, the output device 320, and the transceiver 325.

[0056] The memory 310 can be a computer-readable storage medium. The memory 310 can include volatile computer storage media. For example, the memory 310 can include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). The memory 310 can include non-volatile computer storage media. For example, the memory 310 can include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 310 can include both volatile computer storage media and non-volatile computer storage media.

[0057] The memory 310 can store data related to establishing multipath unicast links and / or mobility operations. For example, as described herein, the memory 310 can store parameters, configurations, resource allocations, policies, etc. The memory 310 can also store program code and related data, such as an operating system or other controller algorithms operating on the network node 300.

[0058] The input device 315 may include any known computer input device, including a touchpad, buttons, a keyboard, a stylus, a microphone, etc. The input device 315 may be integrated with the output device 320, for example, as a touch screen or a similar touch-sensitive display. The input device 315 may include a touch screen such that text can be input using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. The input device 315 may include two or more different devices, such as a keyboard and a touchpad.

[0059] The output device 320 may be designed to output visual, auditory, and / or tactile signals. The output device 320 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 320 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, the output device 320 may include a wearable display separated from the rest of the network node 300 but communicatively coupled thereto, such as a smartwatch, smart glasses, a head-up display, etc. In addition, the output device 320 may be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0060] The output device 320 may include one or more speakers for generating sound. For example, the output device 320 may generate an audible alert or notification (e.g., a beep or a ringtone). The output device 320 may include one or more haptic devices for generating vibration, movement, or other tactile feedback. All or part of the output device 320 may be integrated with the input device 315. For example, the input device 315 and the output device 320 may form a touch screen or a similar touch-sensitive display. The output device 320 may be located near the input device 315.

[0061] The transceiver 325 includes at least one transmitter 330 and at least one receiver 335. One or more transmitters 330 may be used to communicate with a UE, as described herein. Similarly, one or more receivers 335 may be used to communicate with network functions in a PLMN and / or RAN, as described herein. Although only one transmitter 330 and one receiver 335 are illustrated, the network node 300 may have any suitable number of transmitters 330 and receivers 335. In addition, the (s)transmitter(s) 330 and the (s)receiver(s) 335 may be any suitable type of transmitter and receiver.

[0062] In Release 18, 3GPP is studying enhancements to support XR (Extended Reality) media within the 3GPP core network. The main principle of the solution under discussion is to allow the core network to ensure the delivery of media packets that are very important for restoring media services at the application level even when the media packets are sent via a best-effort bearer.

[0063] Most of the solutions proposed in 3GPP SA2 propose network identification of important packets in PDU concentration. The terms for PDU sets in 3GPP TR23.700-60 are as follows:

[0064] · PDU set: A PDU set consists of one or more PDUs that carry the payload of an information unit generated at the application level (e.g., frames or video slices for XRM services as used in TR 26.926). In some implementations, the application layer requires all PDUs in the PDU set to use the corresponding information unit. In other implementations, when some PDUs are lost, the application layer can still recover part or all of the information unit.

[0065] PDU set-specific QoS requirements can be defined to be pre-configured in the 3GPP core network or provided by the AF. The QoS requirements for a PDU set can be defined using any combination of the following parameters:

[0066] · PDU set delay budget (PSDB);

[0067] · PDU set error rate (PSER); and

[0068] · Whether the PDU is essential.

[0069] The term PDU set delay budget (PSDB) is used in this document to define the upper limit of the time by which a PDU set can be delayed between the UE and the N6 endpoint at the UPF. PSDB applies to DL PDU sets received by the UPF via the N6 interface and UL PDU sets sent by the UE.

[0070] The term PDU set error rate (PSER) is used in this document to define the ratio of the PDU sets discarded by the NG-RAN to the total PDU sets sent to the UE.

[0071] Whether the PDU is essential indicates whether all PDUs in the PDU set are required by the receiver.

[0072] Packets belonging to a PDU set are processed by the core network as Figure 4 shown, Figure 4 illustrating an overview of the core network (CN) XRM architecture for processing PDU sets. Figure 4System 400 is shown, which includes an Extended Reality Media Application Function (XRM AF) 410, a Policy and Control Function (PCF) 415, a Session Management Function (SMF) 420, an Access and Mobility Function (AMF) 425, a Radio Access Network (RAN) 430, a User Equipment (UE) 435, a User Plane Function (UPF) 440, and an Extended Reality Application 445. The UE 435 may include the Remote Unit 102 or the User Equipment Device 200 as described herein. The RAN 430 may include the Base Unit 104 or the Network Node 300 as described herein. The operation of System 400 will now be described in an example of downlink traffic, and a similar process may be operative for uplink traffic.

[0073] At 480, the XRM AF 410 determines the PDU set requirements.

[0074] At 481, the XRM Application Function 410 provides the QoS requirements for the packets of the PDU set and the information identifying the application (i.e., the 4-tuple or the application id) to the PCF 415. The QoS requirements may include PSDB and PSER. The XRM AF 410 may also include the importance parameter for the PDU set and the information for the core network to identify the packets belonging to the PDU set.

[0075] At 482, the PCF 415 derives the QoS rules for the XR application and the specific QoS requirements for the PDU set. The QoS rules may use the 4G QoS identifier (5QI) for XR media traffic. The PCF 415 sends the QoS rules to the SMF 420. The PCF 415 may include the Policy and Charging Control (PCC) rules per importance of the PDU set in the communication to the SMF 420. The PCC rules may be derived based on the information received from the XRM AF 410 or based on the operator configuration.

[0076] At 483, the SMF 420 establishes the QoS flow according to the QoS rules of the PCF 415, configures the UPF to route the packets of the XR application to the QoS flow, and in addition, implements the PDU set processing. The SMF 420 also provides a QoS profile containing the PDU set QoS requirements to the RAN 430 via the AMF 425. The AMF 425 may provide the QoS profile containing the PDU set QoS requirements to the RAN 430 in the N2 Session Management (SM) container. In addition, the AMF 425 may provide the QoS rules to the UE 435 in the N1 SM container.

[0077] At 484, the UPF 440 examines the packets and determines the packets belonging to a PDU set. The packet examination may include examining RTP packets. When the UPF 440 detects a packet of a PDU set, the UPF 440 marks the packet belonging to the PDU set within the GTP-U header. The GTP-U header information includes the PDU set sequence number and the size of the PDU set. The UPF 440 may also determine the importance of the PDU set based on the UPF 440 implementation method, the information provided by the XRM AF 410, or the information provided as metadata from the XRM application server. Based on the importance of the PDU set, the UPF 440 may route the traffic to the corresponding QoS flow 1 (according to the rules received from the SMF 420), or include the importance of the PDU set within the GTP-U header. The QoS flow 1 may include GTP-U headers, and these headers may include PDU set information.

[0078] At 485, the RAN 430 identifies the packets belonging to a PDU set (based on the GTP-U marking), and processes the packets of the PDU set according to the QoS requirements of the PDU set provided by the SMF 420. The RAN 430 may receive the QFI, the QoS profile of the QoS flow, including PDSB and PSER, from the SMF 420 (via the AMF 425) during the PDU session establishment / modification. The RAN 430 examines the GTP-U header and ensures that all packets of the same PDU set are processed according to the QoS profile. This may include the packets of the PDU set in the radio bearer carrying the QoS flow 1. This may also include sending the packets of the PDU set that do not belong to a different radio bearer carrying the QoS flow 2.

[0079] The above example relates to downlink (DL) traffic. Reciprocal processing applies to uplink (UL) traffic, where the UPF440 packet examination role is taken by the UE 435, which is expected to examine the uplink packets, determine the packets belonging to a PDU set, and signal the PDU set to the RAN 430 accordingly for scheduling and resource allocation corresponding to the associated DRB that can meet the PDU set QoS requirements (i.e., PSDB and PSER). The low-level signaling mechanism associated with UL UE to RAN information transfer depends on the specifications and implementations of the RAN signaling procedures.

[0080] In this document, extended reality (XR) is used as an umbrella term for different types of reality, examples of which are virtual reality, augmented reality, and mixed reality.

[0081] Virtual Reality (VR) is a rendered version of a delivered visual and audio scene. In this case, the rendering is designed to mimic as naturally as possible the visual and auditory stimuli of the real world as the observer or user moves within the boundaries defined by the application. Virtual Reality typically (but not necessarily) requires the user to wear a Head-Mounted Display (HMD) to completely replace the user's field of view with a simulated visual component, and headphones to provide accompanying audio to the user. In VR, some form of head and motion tracking of the user is also typically required to allow the simulated visual and audio components to be updated to ensure that objects and sound sources remain consistent with the user's movement from the user's perspective. In some implementations, additional methods of interacting with the virtual reality simulation may be provided, but are not strictly necessary.

[0082] Augmented Reality (AR) refers to the situation where the user is provided with additional information or artificially generated items, or content that is overlaid on their current environment. Such additional information or content is typically visual and / or auditory, and their observation of their current environment can be direct, without intermediate sensing, processing, and rendering, or indirect, where their perception of their environment is relayed via sensors and can be enhanced or processed.

[0083] Mixed Reality (MR) is an advanced form of AR where some virtual elements are inserted into the physical scene with the aim of providing the illusion that these elements are part of the real scene.

[0084] XR refers to all real and virtual combined environments and human-machine interactions generated by computer technology and wearable devices. It includes representative forms such as AR, MR, and VR, as well as the interpolation regions between them. The level of virtuality ranges from partial sensory input to fully immersive VR. In some circles, a key aspect of XR is considered to be the extension of human experience, particularly human experience related to presence (represented by VR) and cognitive acquisition (represented by AR).

[0085] In 3GPP Release 17, the 3GPP SA4 working group analyzed the media transport protocols and XR service models in the technical report TR 26.926 (v1.1.0) titled "Business Models and Quality Assessment Methods for Media and XR Services in 5G Systems", and determined the QoS requirements in terms of latency budget, data rate, and error rate required for a satisfactory experience at the application level. This led to the addition of 4 5G QoS Identifiers (5QIs) for 5GS XR QoS flows. These 5QIs are defined in Table 5.7.4-1 of 3GPP TS 23.501 (v17.5.0) and are represented as latency-critical GBR 5QIs with values ranging from 87 to 90. The latter are applicable to XR video streams as well as the control metadata required to provide immersive and interactive XR experiences.

[0086] The XR video service mainly consists of multiple DL / UL video streams with high resolution (e.g., typically at least 1080p binocular buffering), high frames per second (e.g., 60+fps), and high bandwidth (e.g., typically at least 20-30Mbps). These video streams need to be sent over the network with minimal latency (usually capped at 15-20ms) to maintain reduced end-to-end application round-trip latency. Given the dependence of XR applications on cloud / edge processing (e.g., content download, viewport generation and configuration, viewport update, viewport rendering, media encoding / transcoding, etc.), this latter requirement is crucial.

[0087] The following additional assumptions have also been agreed upon:

[0088] · NG-RAN is the only entity that discards packets of a PDU set in case of congestion.

[0089] · For a QoS flow, there can be multiple priority PDU sets. In case of congestion, NG-RAN discards the lower-priority PDU sets.

[0090] · NG-RAN discards all PDUs of a PDU set.

[0091] The analytics consumer NF can be one or more of AF, OAM, and 5G core NFs (e.g., SMF, AMF, PCF). The complete list of potential analytics consumer NFs for each analytics output provided by NWDAF is shown in Table 1 below.

[0092] NWDAF Analysis Output Example Analysis of Consumer NF Slice Load Level PCF, NSSF Observed Service Experience PCF, OAM NF Load Analysis All 5G Core NFs, OAM Network Performance Analysis PCF, NEF, AF or OAM UE Mobility Analysis AMF, SMF UE Communication Analysis AMF, SMF, PCF Expected UE Behavior Analysis AMF, UDM, AF or OAM Abnormal Behavior Analysis AMF, SMF, PCF User Data Congestion Analysis NEF, AF QoS Sustainability Analysis AF

[0093] Table 1: Example Analytics Consumer NFs

[0094] In particular, to support XR services, the following analytics are relevant to the present disclosure. Such analytics can be beneficial to mobile XR users or XR service providers / vertical domains, which need to deploy XRM services in a target area and time (e.g., for an event), and which need to perform statistics / predictions on QoS / network performance and availability.

[0095] Observed experience analytics provides an indication of the service consumer experience for application traffic when routed over a 3GPP network. Examples include the average of the observed service MoS and / or the variance of the observed service MoS, which indicate the service MoS distribution for services such as audiovisual streams and non-audiovisual streams such as V2X and web browsing services.

[0096] QoS sustainability analytics provides information on QoS change statistics for a past analysis target period in a certain area, or the likelihood of QoS change for a future analysis target period in a certain area.

[0097] Network performance analysis provides statistics or predictions on gNB status information, gNB resource usage, communication performance, and mobility performance in the area of interest.

[0098] User data congestion analysis provides analysis related to user data congestion, which can be related to the congestion encountered when transmitting user data through the control plane or the user plane or both.

[0099] In addition, in 3GPP SA6, enabling services include analysis enabling at the edge / vertical domain.

[0100] More specifically:

[0101] As described in TS23.436 and TS23.434, the Application Data Analytics Enabling Service (ADAES) provides analysis services for application servers or application sessions (e.g., between two UEs or between a UE and a server), and provides analysis services for edge load / performance. An example is to collect measurements / analysis on QoS / QoE from the UE side, as well as from the 5GC and OAM, and derive analysis (e.g., statistics / predictions) on the performance of the application server (e.g., game server or IIoT server).

[0102] As specified in TS23.435 and TS23.434, the Network Slice Capability Enabling (NSCE) service provides slice enabling services. One of these services is as specified in Article 9.7 of TS23.435 regarding network slice related performance and analysis monitoring. In this service, the NSCE server collects KQI data of the service, network performance related data, and information of the end user from the NSCE client, and collects slice related analysis from the 5GC / OAM, and opens slice related performance data and analysis to vertical consumers.

[0103] The SEAL Data Delivery (SEAL-D) service (e.g., see TR 23.700-34, TS 23.433) includes the measurement of a specific KI (Article 4.3 of 23.700-44) that studies the quality of data transmission (including, for example, end-to-end latency) between the SEALDD client (UE) and the SEALDD server (optionally collocated with the VAL server). Such application quality measurement can be used by vertical servers to allow application layer service adaptation.

[0104] Other SEAL services (such as network resource management) can provide conversion capabilities for monitoring and allowing QoS adaptation to be triggered at the application layer.

[0105] Since XR services are vertical-domain oriented, the enabling layer can be enhanced to support QoS / QoE translation and analysis enabling for XR applications. This can be achieved by enhancing existing enablers or new XR enabling services.

[0106] QoS / QoE requirements and data can be metrics that may vary for different service types within an XR application. For an XR session, the data required for different service types can be as follows:

[0107] - For video data: latency, PER, XR MOS, stalling events, stalling rate, throughput, PSDB, and PSER, coding rate / video quality, minimum-maximum frame rate, other QoE aspects.

[0108] - For sensor data: e2e latency, availability, reliability, data freshness, group / cluster information, and connection density.

[0109] - For haptic-related data: packet size, reliability (%), latency (ms), average data rate.

[0110] - Per PDU set: PSDB and PSER, coding rate / video quality per set, importance factor / priority, packet loss rate per PDU set, jitter.

[0111] - For an XR session: QoE metrics (including immersion (the "believability" of the XR effect)), application QoS metrics (e.g., latency, jitter, reliability, rate, etc.) (which can be aggregated), or minimum-maximum values per XR session, round-trip interaction latency, user interaction latency.

[0112] Figure 5 FIG. shows a schematic diagram of an exemplary XR enabling service 500.

[0113] As Figure 5 shown, an XR (e.g., metaverse) enabling device can include two logical entities / modules. They are as follows:

[0114] The XR enabling server 502 on the DN / EDN side 503, which includes server-side middleware capabilities such as an edge / cloud provider or PaaS / SaaS at the vertical domain.

[0115] The XR enabling client 504 on the UE side 505, which can provide measurements / data on the performance of an XR application session (e.g., for UE-to-UE sessions and UE-to-network sessions), and report relevant data to the XR enabling server 502.

[0116] The XR enabler server 502 can be a logical entity included within any other enabler (or set of enablers), or can consume enabler services related to XR (e.g., metaverse) application services.

[0117] The XR enabler service or server or function is a newly proposed middleware entity on the platform and / or UE side, which is configured to provide open and conversion capabilities to virtual experience application services. Such capabilities can include, for example, QoS requirement conversion, and can interact with XR applications via APIs and with the core network via interfaces.

[0118] One problem to be solved is how to perceive the observed service experience of an application based on PDU set markings and how to act proactively, such as when indicating possible predictive changes, to ensure that XRM service requirements are met.

[0119] The XRM service can also be defined or referred to as the XR application service or XR service.

[0120] The XRM server, XR application server, and XR server can be the same or equivalent entities.

[0121] The XR application can have server and client counterparts.

[0122] A mechanism for XRM (e.g., mobile metaverse) customized service optimization triggered by the AF or enabler / middleware entity is described herein.

[0123] A method executed at an application entity is described herein, and the application entity can be a trusted AF or XR enabler server or any other enabler service. The method includes the following steps:

[0124] 1. XR application / vertical subscription enabler service, e.g., to the XR enabler / AF. The enabler service includes supporting monitoring, notification, and / or influencing QoS parameters for one or more XR sessions of one or more XR UEs. Optionally, the server can provide a list of acceptable video qualities for the XR session.

[0125] 2. The XR AF / enabler determines the PDU set for the XR application session or service based on the application QoS / QoE requirements. It also determines the parameters for each PDU set (e.g., PSDB and PSER) and the importance of each PDU set. This determination can be based on the analysis and / or statistics of QoS for each different service and / or media type / PDU set. For example, these analyses can be provided by the NWDAF or ADAES.

[0126] 3. The XR AF / enabler configures the monitoring of the XR session, which can be differentiated for different services (e.g., i-frames, p-frames, sensor data, tactile data, etc.) per XR session and PDU set. The monitoring requirements can be for each video quality / encoding rate.

[0127] 4. The XR AF / enabler sends the configuration (i.e., the determined configuration information) to the XR user. This can include the PDU set information and the monitoring configuration based on steps 2 and / or 3 above.

[0128] 5. After receiving a monitoring event, the XR AF / enabler triggers the adaptation of the QoS requirements and / or the importance factor per PDU set to ensure that the QoS requirements applied per XR session are met.

[0129] 6. The XR AF / enabler notifies the XR application / vertical domain and the network / user of the adaptation of the PDU set information, and in particular the QoS requirements and / or the importance factor for one or more PDU sets within the XR application.

[0130] Now referring to Figure 6 An embodiment will be described in which the XR enabler affects the PDU set parameters / requirements based on NWDAF analysis.

[0131] Figure 6 is a schematic diagram of a process 600 in which the XR enabler affects the PDU set parameters / requirements based on NWDAF analysis.

[0132] Process 600 can involve an XR application / enabler client 602, an XR enabler client 604, an XR UE 606, a RAN 608, a UPF 610, an SMP 612, a NEF 614, an XR enabler server 616, and an XRM application server 618.

[0133] The XR application / enabler client 602, the XR enabler client 604, the XR UE 606, the RAN 608, the UPF 610, the SMP 612, the NEF 614, the XR enabler server 616, and the XRM application server 618 can be the same as or consistent with any network entity, function, or node described herein. For example, the XR enabler client 604, the XR UE 606, the RAN 608, the UPF 610, the SMP 612, the NEF 614, the XR enabler server 616, and / or the XRM application server 618 can be the same as Figure 3 the network node 300 shown and described in more detail above. The XR UE 606 can be the same as or consistent with any UE described herein. For example, the XR UE 606 can be the same as Figure 2The same as the UE 200 shown and described in more detail above. The XR application / enabler client 602 and the XR enabler client 604 may be located at a UE (e.g., XR UE 606), which may be the same as or consistent with any UE described herein, e.g., Figure 2 the UE 200 shown and described in more detail above.

[0134] The following prerequisites for method 600 may apply:

[0135] - The XR enabler server may be authorized as a trusted AF to manage XR applications for a target area (e.g., PLMN, TA / cell, edge service area, and / or slice area).

[0136] - The XR enabler server may have received relevant configurations for PDU set types and supported services / target KPIs from the OAM / management system.

[0137] At 620, the XRM application server 618 sends a subscription request (or request) to subscribe to XR-related enabling services to the XR enabler server 616 (or service or function). Such services may be provided, for example, on an edge platform / telecom cloud. Such services may be for a given application service or session. For example, such a session may be related to an XR-enabled multi-player / single-player game or a mobile metaverse service. The request may include a list of application QoS / QoE requirements, regions and times of interest, and required capabilities and levels of openness per XR session / service. The request may include the slice / slice instance to which the XRM service is expected to connect.

[0138] At 622, the XR enabler server 616 authorizes the request (possibly with the support of the management system) and sends a subscription response to the XRM application server 618. The subscription response may be a positive or negative result.

[0139] At 624, the XR enabler server 616 determines per-session and per-PDU set QoS targets based on the application QoS requirements. The XR enabler server 616 may first identify the PDU set (or such information may be given), and may map the identified PDU set to QoS attributes and importance parameters for the PDU set, as well as information for the core network to identify packets belonging to the PDU set.

[0140] In this embodiment, the XR enabler server 616 identifies the PDU set to be used and its information (e.g., using known traffic types and characteristics) based on the XR application requirements.

[0141] The PDU set configuration is discussed in 3GPP TR 23.700-60. For XR / media services, a set of packets is used to carry the payload of the PDU set (e.g., frames, video slices / tile). At the media layer, the packets in such a PDU set are decoded / processed as a whole. For example, in the case where all or a specific number of packets carrying a frame / video slice are successfully delivered, the frame / video slice can be decoded. For example, a frame within a GOP (Group of Pictures) can be decoded by the client only if all the frames it depends on are successfully received.

[0142] The determination of QoS targets per session and per PDU set can be based on the analysis / statistics of QoS per different service type / PDU set. For example, these analyses can be provided by NWDAF or ADAES and can be based on subscription / request.

[0143] At this step (i.e., at 624), the XR enabler server 616 can also identify the monitoring requirements per PDU set within the XR session. This means that for video-related PDU sets or haptic / sensor-related PDU sets, the performance QoS monitoring from the UE can be different. The triggering criteria and / or frequency / thresholds for reporting monitoring events can be different based on the type of service. For example, for video data, MOS, stall event rate, and / or packet loss rate per PDU set type can be reported, while for sensor data, the monitored parameters can include PER, latency, and / or number of retransmissions.

[0144] At 626, the XR enabler server 616 connects (i.e., establishes a session or issues a request) to the XR enabler client 604 at a UE (e.g., XR UE 606) within the XR service area and configures the reporting for monitoring the performance of the XR session for each type of service / PDU set.

[0145] At 628, the XR enabler client 604 applies the configuration and also notifies the XR application client 602 of the PDU set and importance information for the UL. The XR enabler client 604 can send a mapping (e.g., a mapping table, including the mapping between the PDU set / i-frame and importance) to the XR application client 602.

[0146] At 630, the XR enabler client 604 sends a response to the enabler server 616.

[0147] At 632, the XR enabler server 616 creates an AF request and sends it to the NEF 614, thus providing the QoS requirements and importance per PDU set to the NEF 614. Additional steps can occur at the 5GS, such as the steps described in more detail above Figure 4 as described in more detail.

[0148] At 634, the XR enabler server 616 subscribes to network / QoS monitoring events from the NEF 614. This subscription can be per PDU set or common to each XR session and can include subscriptions for all events required for all traffic types within the XR session.

[0149] At 636, the XR enabler server 614 receives monitoring events based on the subscription 634.

[0150] The XR enabler server 616 can also subscribe to and receive real-time analysis from the ADAES and / or NWDAF related to predictions of XR session / PDU set performance.

[0151] At 638, the XR enabler server 616 processes or evaluates the received monitoring events. The monitoring events can include but are not limited to QoS degradation indications, network congestion expectations. For example, based on per-XR session (multiple) target KPIs and per-PDU set QoS targets, the XR enabler server 616 determines the actions to be performed. The action can be to update the QoS profile or request more resources for one or more PDU sets. The goal of this action can be to ensure that end-to-end XR session requirements (including multimodal transport) are met. Requesting resources (e.g., additional resources) can include sending a request to the 5GC (e.g., to the SMF via the NEF, or to the PCF via N5) to change the QoS profile mapped to the corresponding network session / PDU set or update the PCC rules to apply new traffic policies. This can be as described in 3GPP TS 23.502, clause 4.15.6.6a: AF session with the required QoS update procedure.

[0152] At 640 and 642, the determined actions can be executed, for example, by the XR enabler server 616. In this embodiment, the XR enabler server 616 sends 640 the updated QoS parameters / requirements to the SMF 612 via the NEF 614 (via the control plane), or sends 642 the updated QoS requirements to the UPF 610 (via the user plane if the XR enabler server 616 interacts with the UPF 610 via N6).

[0153] At 644, the 5GC (i.e., the SMF 612 or the PCF) updates the PCC rules based on the XR enabler server request.

[0154] At 646, the 5GC provides a response or confirmation (ACK) to the XR enabler server 616. This can be provided via the NEF 614 or directly.

[0155] At 648, the XR enabler server 616 notifies the involved XR enabler clients 604 of the updated QoS parameters per XR session. In this step, the notification may also include some expected / predicted performance degradation and / or alerts to adapt the application behavior (e.g., adapt the encoding rate for video traffic according to the determined actions).

[0156] Therefore, a process for the XR enabler to influence the PDU set parameters / requirements based on NWDAF analysis is provided.

[0157] Figure 7 It is a schematic diagram of the illustrated process 700, where the PDU set parameters / requirements are updated or influenced based on NWDAF / ADAES analysis.

[0158] The process 700 may involve NWDAF and / or ADAES 702 (hereinafter referred to as NWDAF / ADAES), PCF and / or SMF and / or RAN 704 (hereinafter referred to as PCF / SMF / RAN), NEF 706, XR AF 708, and XRM application server 710.

[0159] NWDAF / ADAES, PCF / SMF / RAN 704, NEF 706, XR AF 708, and XRM application server 710 may be the same as or consistent with any network entity, function, or node described herein. For example, NWDAF / ADAES, PCF / SMF / RAN 704, NEF 706, XR AF 708, and XRM application server 710 may be the same as Figure 3 the network node 300 shown and described in more detail above.

[0160] At 712, the XRM application server 710 provides the application QoS / QoE requirements per XR service / session to the XR AF 708. In this embodiment, it is assumed that the XR AF 608 is a trusted third party or an MNO-deployed AF.

[0161] At 714, the XR AF 708 subscribes to the XR customized analysis from the NWDAF / ADAES 702, e.g., based on the required capabilities. Such analysis may be related to the statistics / prediction of the optimal PDU set size and the setting of the importance and QoS parameters per PDU set. The analysis may be based on historical data or real-time measurements.

[0162] At 716, the XR AF 708 may receive the analysis, which is based on the subscription at 714 and the requirements received at 712.

[0163] At 718, the XR AF 708 determines the PDU set requirements.

[0164] At 720, based on the determined PDU set requirements, the XR AF 708 provides the PCF / SMF / RAN 704 with the QoS requirements (e.g., PSDB and PSER) for the packets of the PDU set. The XR AF 708 may provide the PCF / SMF / RAN 704 with information identifying the application (e.g., 5-tuple or application id). The XR AF 708 may also send to the PCF / SMF / RAN 704 the importance parameter for the PDU set and / or information for the core network to identify the packets belonging to the PDU set. The XR AF 708 may also send to the PCF / SMF / RAN 704 the PDU set information, such as the PDU set ID, the mobility pattern for the interested XR UE(s) (which may include a set of waypoints in the interested area), and the possible alternative QoS parameters (a set of different QoS attributes) and their per-PDU-set priorities.

[0165] At 722, the PCF derives the QoS rules for the XR application (i.e., uses 5QI for the XR media service) and the specific QoS requirements for the PDU set (which may include alternative QoS attributes and their priorities) (optionally using the PDU set identification given by the AF). The PCF configures the SMF accordingly. The PCF may merge the PCC rules (i.e., the derived rules) according to the importance of each PDU set, which may conform to the information received from the XR AF 708 or be based on the operator configuration.

[0166] In this embodiment, the SMF establishes the QoS flow according to the QoS rules derived by the PCF, configures the UPF to route the packets of the XR application to the QoS flow, and furthermore, implements the PDU set processing. The SMF may additionally provide the RAN via the AMF with a QoS profile containing the PDU set QoS requirements. The UPF examines the packets and determines the packets belonging to the PDU set (e.g., by examining the RTP packets). When the UPF detects the packets of the PDU set, the UPF marks the packets belonging to the PDU set within the GTP-U header. The GTP-U header information includes the PDU set sequence number and the PDU set size. The UPF may also determine the importance of the PDU set based on the UPF implementation method, the information provided by the AF, or the information provided as metadata from the application server. Based on the importance of the PDU set, the UPF may route the traffic to the corresponding QoS flow (e.g., according to the rules received from the SMF), or include the importance of the PDU set in the GTP-U header.

[0167] The RAN identifies the packets belonging to the PDU set (e.g., based on the GTP-U marking) and processes the packets of the PDU set according to the QoS requirements of the PDU set provided by the SMF.

[0168] The following steps can occur during the runtime phase (i.e., while the XR session is running).

[0169] At 726, the XR AF 708 subscribes to network monitoring events and / or analytics related to different PDU sets / service types within the XR session. Thus, the XR AF 708 can receive network monitoring events and / or XR customized analytics.

[0170] At 728, upon receiving the monitoring events and / or the analysis output from the NWDAF / ADAES 702, the XR AF 708 processes or evaluates the monitoring events and / or the analytics. The monitoring events can include, but are not limited to, QoS degradation indications or network congestion predictions. Based on the per-XR session (multiple) target KPIs and the QoS targets per PDU set, the XR AF 708 determines the actions to be performed. The action can be to update the QoS profile or request more resources for one or more PDU sets. The goal of the action can be to ensure that the end-to-end XR session requirements (including multimodal transport) are met.

[0171] At 730, the determined actions can be performed, for example, by the XR AF 708. In this embodiment, the XR AF 708 sends updated QoS requirements to the SMF 704 via the NEF 706, for example. This can include a possible change in the importance per PDU set. If this is a predicted QoS requirement change, it can be provided as an early notification indicating the time range for the expected QoS target update per PDU set.

[0172] At 732, the 5GC (i.e., the SMF / PCF 704) updates the PCC rules based on the XR AF request.

[0173] At 734, the 5GC (i.e., the SMF / PCF 704) provides a response or confirmation (ACK) to the XR AF 708. The response can be provided via the NEF 706 or directly.

[0174] At 736, the XR AF 708 notifies the XR application server 710 of the updated QoS parameters per XR session. In this step, the notification can also include some expected / predicted performance degradation and / or alerts to adapt the application behavior (e.g., adapting the coding rate for video services according to the determined actions).

[0175] Thus, a process for updating or influencing PDU set parameters / requirements based on NWDAF / ADAES analysis is provided.

[0176] In one aspect, a method is provided that is performed in an application entity of a wireless communication system or network. Figure 8is a process flow diagram showing certain steps of method 800. In some embodiments, method 800 may be performed by a processor (such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.) that executes program code. Method 800 is used to manage the performance of one or more virtual experience applications. The method includes: receiving 810 performance parameters (such as QoS / QoE parameters or requirements) for a virtual experience application session (such as an XR, AR, VR, or metaverse application session); based on the received performance parameters, determining 820 the network requirements for the virtual experience application session, where determining the network requirements includes identifying one or more sets of protocol data units (PDUs) for the virtual experience application session; and based on the determined network requirements, determining 830 corresponding PDU set parameters for each set of PDUs in the identified set of PDUs. The PDU set parameters may include one or more QoS attributes for the PDU set, an importance parameter / rank for the PDU set, and / or information for identifying packets belonging to the PDU set.

[0177] The method may further include sending to at least one entity (such as to the PCF / SMF via the NEF, or to the UPF) any one or both of the following: (i) one or more PDU set parameters, and / or (ii) configuration information. The configuration information may be based on the one or more PDU set parameters. The configuration information may be a configured monitoring requirement / request. The configuration information may be used to configure one or more parameters (such as monitoring events) related to monitoring one or more performance attributes of the identified one or more sets of PDUs within a wireless communication system / network. The entity may be an entity arranged to monitor one or more parameters related to one or more performance attributes of the identified one or more sets of PDUs, or an entity arranged to cause the monitoring of one or more parameters. The configuration information may be used to configure one or more monitoring events (such as QoS degradation indication / event / expectation, or network congestion event or expectation, etc.) related to monitoring one or more performance attributes of the identified one or more sets of PDUs within a wireless communication system / network. The configuration information may specify or include one or more monitoring events.

[0178] The method may further include obtaining and processing at least one monitoring parameter (such as measurement or analysis / statistics) corresponding to one or more monitoring events, such as an indication that the event has or will occur and / or a corresponding value.

[0179] The method may further include: triggering an action within a wireless communication system in response to acquiring and processing at least one monitoring parameter. The purpose of the action may be to ensure that performance parameters of an extended reality service are met. The action may include an action selected from an action group, the action group including: updating (i.e., adapting) corresponding PDU set parameters (e.g., QoS requirements or profiles) of one or more PDU sets, and sending the updated PDU set parameters or a plurality of parameters to at least one entity; and requesting more resources for one or more PDU sets in the PDU set. Requesting resources (e.g., additional resources) may include sending a request to the 5GC (e.g., to the SMF via the NEF or to the PCF via N5) to change the QoS profile mapped to the corresponding network session / PDU set or update the PCC rule to apply a new service policy. This may be as specified in clause 4.15.6.6a of 3GPP TS 23.502: AF session with the required QoS update procedure.

[0180] The method may further include performing the action.

[0181] The method may further include acquiring an analysis related to the performance of one or more PDU sets. Determination of the identity of one or more PDU sets and / or the corresponding PDU set parameters may be performed using the acquired analysis.

[0182] Configuration information may be used to configure monitoring of one or more parameters for one or more predefined video quality levels or coding rates within a wireless communication system / network.

[0183] Configuration information may be used to configure one or more user equipment (UE) devices to monitor one or more parameters within a wireless communication system / network.

[0184] Sending may include sending the configuration information to the UE or an application server serving the UE.

[0185] Performance parameters may be included in a subscription message or request.

[0186] The performance parameters are application QoS or QoE requirements.

[0187] Each PDU set parameter may be selected from a parameter group, the parameter group including: QoS attributes for the PDU set, importance parameters / rankings for the PDU set, and information for identifying packets belonging to the PDU set.

[0188] Transmission may include sending one or more PDU set parameters to a core network function (e.g., to the PCF or via the NEF, e.g., if the AF is not trusted). For example, QoS requirements for packets of the PDU set, importance parameters for the PDU set, and / or information for the core network to identify packets belonging to the PDU set may be sent to the PCF. Additionally, information identifying the XR application, PDU set information (such as the PDU set ID), the mobility pattern for the interested XR UE(s), and / or possible alternative QoS parameters, and optionally the per-PDU set priority may also be sent to the PCF.

[0189] In another aspect, an application entity for a wireless communication system / network is provided. The apparatus includes a transceiver and a processor coupled to the transceiver. The processor and the transceiver are arranged such that the application entity: receives performance parameters (e.g., QoS / QoE parameters / requirements) for a virtual experience application session; based on the received performance parameters, determines network requirements for the virtual experience application session, where the determination of the network requirements includes identifying one or more protocol data unit PDU sets for the virtual experience application session; and based on the determined network requirements, determines corresponding PDU set parameters for each PDU set among the identified PDU sets. The PDU set parameters may include one or more QoS attributes for the PDU set, importance parameters / rankings for the PDU set, and / or information for identifying packets belonging to the PDU set.

[0190] The processor and the transceiver may also be arranged such that the application entity sends either or both of the following to at least one entity: (i) one or more PDU set parameters, and (ii) configuration information. The configuration information may be a configured monitoring requirement / request. The configuration information may be based on one or more PDU set parameters. The configuration information may be used to configure one or more parameters (e.g., monitoring events) related to one or more performance attributes of the identified one or more PDU sets monitored within the wireless communication system / network.

[0191] In another aspect, a UE device is provided, the UE device including a transceiver; and a processor coupled to the transceiver. The processor and the transceiver are arranged such that the UE device: receives configuration information specifying one or more parameters (e.g., monitoring events) related to one or more performance attributes of each PDU set among one or more PDU sets for a virtual experience application session; and monitors one or more parameters of the virtual experience application session according to the received configuration information.

[0192] The UE can monitor application QoS parameters (e.g., channel loss, latency, throughput, PER, etc.) for an XR application session, and based on this configuration, the UE can act by periodically providing reports or in response to an event occurrence (e.g., if a certain metric reaches a threshold, e.g., loss > X%, the UE can trigger a notification to the server).

[0193] The processor and transceiver can also be arranged such that the UE device sends a report on one or more monitored parameters of the virtual experience application session based on the configuration information.

[0194] The virtual experience application session can be a session conducted between the UE device (i.e., XR device) and a server using a network session, or a session conducted between the UE device and another UE device using a network session (e.g., a session between two XR devices using network-assisted device-to-device communication).

[0195] The above systems and methods tend to enable XR applications to set and dynamically adjust QoS parameters for application sessions including different types of traffic (video, audio, sensor data, tactile) to ensure that XR service requirements are met.

[0196] The enabling layer provides a new capability and mechanism to allow the conversion of XR application session requirements into per-PDU set and cross-PDU set QoS requirements (e.g., setting importance / priority). This capability may also require new application layer signaling from XR UEs to monitor performance. With optional analytics support, the XR enabler server / AF can proactively trigger application or network layer adaptation to ensure that XR service requirements are met. This is often applicable to mobile metaverse use cases because multiple XR users are expected to participate in a mobile environment in a metaverse application session; therefore, dynamically configuring and adapting per-PDU set QoS requirements is often beneficial.

[0197] Traditionally, the behavior of new APIs for per-PDU set QoS conversion above the AF / application layer entities and processes / networks has not been considered. Additionally, the interaction with the UE's configuration for reports that distinguish each type of traffic within an XR application session has not been considered.

[0198] In some embodiments, the XR enabler server (which can be a newly defined entity in SA6) plays a key role in the configuration of PDU sets and QoS parameters and supports monitoring and adaptation of dynamic trigger requirements from the UE side.

[0199] In some embodiments, the XR AF (which can be defined as in SA2) acts as an intermediate AF between the XR server and 5GS to convert application QoS requirements into requirements for per-PDU set requirements and also uses analytics to proactively adapt network behavior to ensure that XR requirements are met.

[0200] Other aspects of the present invention are provided by the subject matter of the following clauses:

[0201] 1. A method at an application entity for managing the performance of one or more extended reality applications. The method includes:

[0202] - Receiving XR application requirements;

[0203] - Determining network QoS requirements based on the XR application requirements, where the network QoS requirements are a mapping to multiple PDU sets, PDU set QoS requirements, importance requirements, or a combination thereof;

[0204] - Configuring monitoring requirements based on the network QoS requirements, where the monitoring requirements include multiple monitoring events related to at least one performance attribute of at least one PDU set for an XR application session;

[0205] - Sending the configured monitoring requirements and / or network QoS requirements to at least one entity (where the entity can be a network or an XR application entity, and the network or XR application entity is assigned to monitor at least one performance attribute based on the requirements);

[0206] - Obtaining at least one monitoring parameter corresponding to the configured monitoring events for at least one PDU set of the XR application session;

[0207] - Triggering network QoS requirement adaptation based on the monitoring events; and

[0208] - Sending the updated network QoS requirements to the network and / or XR application entity.

[0209] 2. The method according to any one of the preceding clauses, further comprising obtaining and using analytics (e.g., for the determining, configuring, and / or triggering steps).

[0210] 3. The method according to any one of the preceding clauses, wherein the monitoring and network requirements can be provided for each given quality / coding rate or for a list of quality / coding rates.

[0211] 4. The method according to any one of the preceding clauses, further comprising subscribing to receive XR application requirements.

[0212] 5. The method according to any one of the preceding clauses, further comprising sending a mapping of PDU sets / media types / traffic types and / or importance that can be used for UL to the UE.

[0213] 6. The method according to any one of the preceding clauses, wherein the XR application requirements are QoS or QoE requirements.

[0214] 7. The method according to any one of the preceding clauses, wherein the sending is performed towards the network via the user plane or the control plane.

[0215] 8. The method according to any one of the preceding clauses, wherein the sending is performed towards one or more UEs and / or an XR application server.

[0216] 9. The method according to any one of the preceding clauses, wherein the configuration can be performed after a request / response between the application entity and the UE.

[0217] 10. A network arranged to perform the method according to any one of the preceding clauses.

[0218] It should be noted that the above methods and apparatuses illustrate rather than limit the present invention, and those skilled in the art will be able to design many alternative arrangements without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in the claims, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfill the functions of several units recited in the claims. Any reference signs in the claims should not be construed as limiting their scope.

[0219] In addition, although examples have been given in the context of a specific communication standard, these examples are not intended to limit the communication standards to which the disclosed methods and apparatuses can be applied. For example, although specific examples have been given in the context of 3GPP, the principles disclosed herein can also be applied to another wireless communication system and, in fact, to any communication system using routing rules.

[0220] The method can also be implemented in a set of instructions stored on a computer-readable medium, which, when loaded into a computer processor, a digital signal processor (DSP), etc., causes the processor to execute the above method.

[0221] The described methods and apparatuses can be practiced in other specific forms. The described methods and apparatuses are to be considered illustrative and not restrictive in all respects. Accordingly, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes within the meaning and scope of equivalence of the claims should be included within their scope.

[0222] The following abbreviations are relevant to the field addressed by this specification:

[0223] UE User Equipment PDU Set Protocol Data Unit Set UL Uplink DL Downlink QoS Quality of Service XR Extended Reality PSDB PDU Set Delay Budget PDB Packet Delay Budget PSER PDU Set Error Rate NWDAF Network Data Analytics Function UPF User Plane Function SMF Session Management Function ADAES Application Data Analytics Enablement Server

[0224] ADAEC Application Data Analytics Enablement Client

[0225] XRM XR and Media

[0226] SEAL Service Enabler Architecture Layer

[0227] MOS Mean Opinion Score

Claims

1. A method in an application entity of a wireless communication system, the method for managing the performance of one or more virtual experience applications, the method comprising: Receiving performance parameters for a virtual experience application session; Based on the received performance parameters, determining network requirements for the virtual experience application session, wherein determining the network requirements includes identifying one or more sets of protocol data units (PDUs) for the virtual experience application session; And Based on the determined network requirements, determining corresponding PDU set parameters for each of the identified sets of PDUs.

2. The method according to claim 1, further comprising: Sending to at least one entity any one or both of the following: (i) one or more PDU set parameters, and / or (ii) configuration information based on the one or more PDU set parameters; wherein The configuration information is for configuring one or more parameters related to one or more performance attributes of the one or more identified sets of PDUs monitored within the wireless communication system.

3. The method according to claim 2, wherein the entity is an entity arranged to monitor the one or more parameters related to the one or more performance attributes of the one or more identified sets of PDUs, or an entity arranged to cause the monitoring of the one or more parameters.

4. The method according to claim 2 or 3, wherein the configuration information is for configuring one or more monitoring events related to one or more performance attributes of the one or more identified sets of PDUs monitored within the wireless communication system.

5. The method according to claim 4, further comprising: Obtaining and processing at least one monitoring parameter corresponding to the one or more monitoring events; And Triggering an action within the wireless communication system in response to obtaining and processing the at least one monitoring parameter.

6. The method according to claim 5, wherein the action includes an action selected from an action group, the action group including: Updating the corresponding PDU set parameters for one or more sets of PDUs, and sending the updated PDU set parameters to the at least one entity; And Requesting more resources for one or more sets of PDUs in the set of PDUs.

7. The method according to any one of claims 2 to 6, wherein the configuration information is for configuring one or more parameters related to one or more predefined video quality levels or coding rates monitored within the wireless communication system.

8. The method according to any one of claims 2 to 7, wherein the configuration information is for configuring the one or more parameters to be monitored by one or more user equipment (UE) devices within the wireless communication system.

9. The method according to any one of claims 2 to 8, wherein the sending includes sending the configuration information to a UE or an application server serving the UE.

10. The method according to any one of claims 2 to 9, wherein the sending includes sending the one or more PDU set parameters to a core network function.

11. The method according to any one of claims 1 to 10, further comprising: Obtain analysis related to the performance of one or more PDU sets; wherein the identification of the one or more PDU sets and / or the determination of the corresponding PDU set parameters are performed using the obtained analysis.

12. The method according to any one of claims 1 to 11, wherein the performance parameter is included in a subscription request.

13. The method according to any one of claims 1 to 12, wherein the performance parameter is an application QoS or QoE requirement.

14. The method according to any one of claims 1 to 13, wherein each PDU set parameter is selected from a parameter group, the parameter group comprising: QoS attributes for the PDU set, importance parameters / rankings for the PDU set, and information for identifying packets belonging to the PDU set.

15. An application entity for a wireless communication system, the apparatus comprising: a transceiver; and a processor coupled to the transceiver, the processor and the transceiver being configured such that the application entity: receives performance parameters for a virtual experience application session; based on the received performance parameters, determines network requirements for the virtual experience application session, wherein the determination of the network requirements includes identifying one or more protocol data unit PDU sets for the virtual experience application session; and based on the determined network requirements, determines corresponding PDU set parameters for each of the identified PDU sets.

16. The application entity according to claim 15, wherein the processor and the transceiver are further configured such that the application entity: sends to at least one entity any one or both of the following: (i) one or more PDU set parameters, and (ii) configuration information based on the one or more PDU set parameters; wherein the configuration information is used to configure one or more parameters related to one or more performance attributes of the one or more PDU sets identified and monitored within the wireless communication system.

17. A user equipment UE apparatus, comprising: a transceiver; and a processor coupled to the transceiver, the processor and the transceiver being configured such that the UE apparatus: receives configuration information that specifies, for each of one or more PDU sets of a virtual experience application session, one or more parameters related to one or more performance attributes of the PDU set; and monitors the one or more parameters of the virtual experience application session according to the received configuration information.

18. The UE apparatus according to claim 17, wherein the processor and the transceiver are further configured such that the UE apparatus: sends a report on the monitored one or more parameters of the virtual experience application session based on the configuration information.

19. The UE apparatus according to claim 17 or 18, wherein the virtual experience application session is a session conducted between the UE apparatus and a server using a network session, or a session conducted between the UE apparatus and another UE apparatus using a network session.

Images