Network node and method implemented therein

Abstract

A method implemented in a network node and a network node are provided. The method comprises: receiving a first message comprising first information, the first information comprising a service requirement for a data stream and an indication that the data stream is associated with a multi-modal data set; determining policy and charging control (PCC) rules for a packet data unit (PDU) session for the data stream based on the indication that the data stream is associated with a multi-modal data set; and transmitting a second message including information indicating the PCC rule associated with the data stream.

Description

[0001] This application is a divisional application of the patent application for invention with the application date of January 18, 2023, application number 202380022041.8, and invention title "Methods and Apparatuses for Associating Unimodal Streams for Synchronization and Resource Allocation".

[0002] Cross - reference to related applications

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 303,689, filed on January 27, 2022, and U.S. Provisional Patent Application No. 63 / 338,582, filed on May 5, 2022, each of which is incorporated herein by reference. Technical Field

[0004] This disclosure generally relates to the fields of communications, software, and coding, including, for example, methods, architectures, apparatuses, and systems related to associating unimodal streams for synchronization and resource allocation. Background Art

[0005] It can be understood that there are strong dependencies between unimodal data streams in a multimodal dataset. This dependency can be based on multiple factors.

[0006] Data from a specific unimodal data stream may be required to reach its destination within a synchronization threshold time so that the data is delivered to the application layer at the appropriate time.

[0007] Some unimodal data streams in a multimodal dataset may have varying priority levels. For example, one unimodal data stream may be critical, and if that unimodal data stream only experiences some delays or dropped packets, the quality of experience will be significantly affected. A second unimodal data stream in the same multimodal dataset may be less important or even optional, such that if the second unimodal data stream is delayed, dropped, or not successfully established, the user experience will not be significantly affected.

[0008] 5G systems currently may not support features that allow the system to be configured to know which unimodal data streams belong to the same multimodal dataset.

[0009] Improvements are needed in the association between unimodal data streams and multimodal datasets. Summary of the Invention

[0010] In one embodiment, a method implemented in a wireless transmit / receive unit (WTRU) may include: receiving a first message including information, the information including a session identifier of a session associated with a data stream of at least one other WTRU. The method may further include: sending a packet data unit (PDU) session establishment request including a second message to a network node, the second message including the session identifier; and receiving a PDU session establishment acceptance message from the network node, the PDU session establishment acceptance message indicating a quality of service (QoS) rule for traffic associated with the PDU session that the WTRU is to apply to.

[0011] The method may further include: receiving a PDU modification command indicating an index associated with one or more of the indicated QoS rules.

[0012] The sending step may include: transmitting the session identifier in both a NAS mobility management (NAS-MM) part and a NAS session management (NAS-SM) part of a NAS message. The first message may be received by an application of the WTRU, where the application may be an extended reality engine of the WTRU.

[0013] Before receiving the first message, the method may include: performing a discovery process with an extended reality application provider. The PDU session establishment request may be triggered by an extended reality engine of the WTRU.

[0014] In one embodiment, a wireless transmit / receive unit (WTRU) includes a processor, a transceiver unit, and a storage unit, and may be configured to: receive a first message including information, the information including a session identifier of a session associated with a data stream of at least one other WTRU. The WTRU may further be configured to: send a packet data unit (PDU) session establishment request including a second message to a network node, the second message including the session identifier; and be configured to: receive a PDU session establishment acceptance message from the network node, the PDU session establishment acceptance message indicating a quality of service (QoS) rule for traffic associated with the session that the WTRU is to apply to.

[0015] The WTRU may further be configured to: receive a PDU modification command indicating an index associated with one or more of the indicated QoS rules.

[0016] Sending to the network node may include: transmitting the session identifier in both the NAS mobility management (NAS-MM) part and the NAS session management (NAS-SM) part of the non-access stratum (NAS) message. The first message may be received by an application of the WTRU, and the application may be an extended reality engine of the WTRU.

[0017] The WTRU may be configured to: perform a discovery procedure with an extended reality application provider before receiving the first message.

[0018] The PDU session establishment request may be triggered by an extended reality engine of the WTRU.

[0019] In one embodiment, a method implemented in a network node may include: the step of receiving, from a WTRU, a packet data unit (PDU) session establishment request including a session identifier. The method may further include: the step of determining, based on the session identifier, a quality of service (QoS) rule for traffic that the WTRU applies to the PDU session; and the step of sending a PDU session establishment accept message to the WTRU, the PDU session establishment accept message indicating the QoS rule for traffic that the WTRU applies to the PDU session.

[0020] The method may further include: the step of sending a first message including the session identifier to a policy control function (PCF); and the step of receiving a second message from the PCF, the second message indicating a policy and charging control (PCC) rule associated with the session identifier; and wherein determining the QoS rule is based on the PCC rule associated with the session identifier.

[0021] The method may further include: the step of sending a PDU modification command indicating an index associated with one or more of the indicated QoS rules. The session identifier may be used in a user plane function (UPF) selection procedure.

[0022] The method may further include: the step of receiving a third message including information about expected traffic. The method may further include: the step of determining, based on the received information, that the traffic is expected; and the step of sending a notification to an access and mobility function (AMF), the notification indicating that the traffic is expected.

[0023] The session management function may use the session identifier to determine a data network name and single network slice selection assistance information associated with the PDU session establishment request.

[0024] In one embodiment, a network node includes a processor, a transceiver unit, and a storage unit, and may be configured to: receive, from a WTRU, a packet data unit (PDU) session establishment request including a session identifier. The network node may also be configured to: determine, based on the session identifier, a quality of service (QoS) rule for traffic associated with the PDU session applied by the WTRU; and be configured to: send to the WTRU a PDU session establishment acceptance message indicating the QoS rule for traffic associated with the PDU session applied by the WTRU.

[0025] The network node may also be configured to: send a first message including the session identifier to a policy control function (PCF); and receive a second message from the PCF, the second message indicating a policy and charging control (PCC) rule associated with the session identifier. Determining the QoS rule may be based on the PCC rule associated with the session identifier.

[0026] The network node may be configured to: send a PDU modification command indicating an index associated with one or more of the indicated QoS rules. The session identifier may be used in a user plane function (UPF) selection procedure.

[0027] The network node may also be configured to: receive a third message including information about expected traffic. The network node may also be configured to: determine, based on the received information, that the traffic is expected; and send a notification to an access and mobility management function (AMF) indicating that the traffic is expected.

[0028] A session management function may use the session identifier to determine a data network name and single network slice selection assistance information associated with the PDU session establishment request.

[0029] In one embodiment, a method implemented in a first wireless transmit / receive unit (WTRU) may include: receiving a paging message from a network node. The method may also include: sending a service request message to the network node. The method may also include: receiving from the network node a service acceptance message including information, the information including a traffic expected information element. The traffic expected information may trigger the WTRU to take an action to prepare for the traffic. The action may convey a notification to an application hosted on the WTRU, or the action may convey a notification to other devices communicatively connected to the WTRU.

[0030] The notification may include an indication of when the traffic is expected. The traffic expected information may include an indication of when the traffic is expected.

[0031] In another embodiment, a method implemented in a WTRU may include: receiving, from a network node, a first non-access stratum (NAS) message, where the first NAS message includes first information that indicates more than one set of QoS rules associated with the same PDU session; and receiving, from the network node, a second NAS message, where the second NAS message includes second information that indicates to the WTRU which one of the more than one set of QoS rules should be applied to the PDU session.

[0032] The first NAS message may be a PDU session establishment request or a PDU session modification request. The second NAS message may be a PDU session modification request. The first NAS message may include third information that indicates an index of at least one of the QoS rules, and the second NAS message may include fourth information that indicates that the index of the at least one of the QoS rules should be applied to the PDU session.

[0033] In another embodiment, a method implemented in a WTRU may include: receiving, from a network node, a NAS message that includes information that includes more than one set of QoS rules associated with the same PDU session and an index of one or more QoS rules. The method may include: receiving, from an application, a data packet and an index value. The method may further include: selecting, based on the index value, one of the one or more QoS rules; and transmitting the data packet using the selected one QoS rule. The NAS message may be a PDU session establishment request or a PDU session modification request.

[0034] In one embodiment, a wireless transmit / receive unit (WTRU) includes a processor and a non-transitory computer-readable storage medium storing instructions that, when executed on the processor, may operate to perform functions including: receiving a paging message from a network node; transmitting a service request message to the network node; receiving a service acceptance message from the network node that includes information that includes a traffic anticipation information element. The traffic anticipation information may trigger the WTRU to take action to prepare for traffic.

[0035] In another embodiment, a wireless transmit / receive unit (WTRU) includes a processor and a non-transitory computer-readable storage medium storing instructions that, when executed on the processor, can operate to perform functions including: receiving a first non-access stratum (NAS) message from a network node, wherein the first NAS message includes first information indicating more than one set of QoS rules associated with the same PDU session; and receiving a second NAS message from the network node, wherein the second NAS message includes second information indicating to the WTRU which QoS rule of the more than one set of QoS rules should be applied to the PDU session.

[0036] In another embodiment, a wireless transmit / receive unit (WTRU) includes a processor and a non-transitory computer-readable storage medium storing instructions that, when executed on the processor, can operate to perform functions including: receiving a NAS message from a network, the NAS message including information that includes more than one set of QoS rules associated with the same PDU session and an index of at least one QoS rule; and receiving a data packet and an index value from an application and using the index value from the application to select one QoS rule of the QoS rules received in the NAS message and using the selected QoS rule to transmit the packet.

[0037] In one embodiment, a method implemented in a network node includes: receiving a first message including first information, the first information including a service requirement of a data stream and an indication that the data stream is associated with a multimodal data set; determining, based on the indication that the data stream is associated with the multimodal data set, a policy and charging control (PCC) rule for a packet data unit (PDU) session of the data stream; and transmitting a second message including information indicating the PCC rule associated with the data stream.

[0038] In one embodiment, a network node includes a processor, a transceiver unit, and a storage unit, and is configured to: receive a first message including first information, the first information including a service requirement of a data stream and an indication that the data stream is associated with a multimodal data set; determine, based on the indication that the data stream is associated with the multimodal data set, a policy and charging control (PCC) rule for a packet data unit (PDU) session of the data stream; and transmit a second message including information indicating the PCC rule associated with the data stream. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with its accompanying drawings. Like the detailed description, the figures in such drawings are examples. Accordingly, the drawings (figures) and the specific embodiments should not be considered restrictive, and other equally valid examples are possible and contemplated. Additionally, like reference numerals (“ref.”) in the figures indicate like elements, and wherein:

[0040] Figure 1A is a system diagram illustrating an exemplary communication system;

[0041] Figure 1B is an illustration of an exemplary wireless transmit / receive unit (WTRU) that can be used within the communication system shown in Figure 1A a system diagram;

[0042] Figure 1C is an illustration of an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used within the communication system shown in Figure 1A a system diagram;

[0043] Figure 1D is an illustration of another exemplary RAN and another exemplary CN that can be used within the communication system shown in Figure 1A a system diagram;

[0044] Figure 2 is a system diagram illustrating an example of unicast and multicast supported within a data network associated with a 5G virtual network group;

[0045] Figure 3 is a system diagram illustrating an example of three traffic forwarding methods that can be used for 5G virtual network communication in a 5G system;

[0046] Figure 4 is a system diagram illustrating an example of a 5G extended reality interface and architecture;

[0047] Figure 5 is a message flow diagram illustrating an example of associating a PDU session with a multimodal data set;

[0048] Figure 6 is a message flow diagram illustrating an example of creating or modifying a multimodal data set;

[0049] Figure 7 is a message flow diagram illustrating an example of the configuration of a 5G system for correct policy detection and enforcement;

[0050] Figure 8 is a message flow diagram illustrating an example of a WTRU receiving an early data warning;

[0051] Figure 9is a flowchart illustrating an example of a method for establishing a multi-modal data stream implemented in a WTRU; and

[0052] Figure 10 is a flowchart illustrating an example of a method for establishing a multi-modal data stream implemented in a network node. Detailed implementation

[0053] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Additionally, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively referred to as "provided") herein. Although various embodiments are described and / or claimed herein in which a device, system, apparatus, etc. and / or any of its elements perform an operation, process, algorithm, function, etc. and / or any part thereof, it should be understood that any embodiment described and / or claimed herein assumes that any device, system, apparatus, etc. and / or any of its elements is configured to perform any operation, process, algorithm, function, etc. and / or any part thereof.

[0054] Example communication system

[0055] The methods, apparatuses, and systems provided herein are well-suited for communication involving both wired and wireless networks. Relative to Figures 1A to 1D An overview of various types of wireless devices and infrastructure is provided, where various elements of the network may utilize, perform, be arranged according to, and / or be adapted and / or configured for the methods, apparatuses, and systems provided herein.

[0056] Figure 1AFIG. 0 is a system diagram of an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 may enable the plurality of wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail (ZT) unique word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-sOFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0057] As Figure 1A shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the UEs 102a, 102b, 102c, 102d (any one of the WTRUs may be referred to as a "station" and / or "STA") may be configured to transmit and / or receive wireless signals and may include (or may be) a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop computer, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., a robot and / or other wireless devices operating in an industrial and / or automation processing chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any one of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0058] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to, for example, one or more communication networks such as CN 106 / 115, the Internet 110, and / or network 112. As an example, base stations 114a, 114b may be any one of a base transceiver station (BTS), a Node B (NB), an evolved Node B (eNB), a home Node B (HNB), a home evolved Node B (HeNB), a g Node B (gNB), a NR Node B (NR NB), a site controller, an access point (AP), a wireless router, etc. Although base stations 114a, 114b are each depicted as a single element, it should be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0059] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographical area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0060] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) may be used to establish air interface 116.

[0061] More specifically, as noted above, the communication system 100 may be a multi-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0062] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long-Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish the air interface 116.

[0063] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as NR radio access, which may use New Radio (NR) to establish the air interface 116.

[0064] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base stations 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together using, for example, the Dual Connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).

[0065] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0066] Figure 1A The base station 114b in may be, for example, a wireless router, a home Node B, a home evolved Node B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business premise, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any one of a microcell, a picocell, or a femtocell. As Figure 1A shown, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0067] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different Quality of Service (QoS) requirements such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, location-based services for mobile, prepaid calls, Internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not shown in Figure 1Ais shown, it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or different RATs. For example, in addition to being connected to RAN 104 / 113 that can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses any one of GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technology.

[0068] CN 106 / 115 can also act as a gateway for WTRUs 102a, 102b, 102c, 102d to access PSTN 108, Internet 110, and / or other networks 112. PSTN 108 can include a circuit-switched telephone network that provides plain old telephone service (POTS). Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet protocol suite. Network 112 can include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 can include another CN connected to one or more RANs, and the one or more RANs can use the same RAT as RAN 104 / 114 or a different RAT.

[0069] Some or all of the WTRUs 102a, 102b, 102c, 102d in communication system 100 can include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 1A the illustrated WTRU 102c can be configured to communicate with a base station 114a that can use cellular-based radio technology and with a base station 114b that can use IEEE 802 radio technology.

[0070] Figure 1B is a system diagram of an exemplary WTRU 102. As Figure 1B shown, WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other elements / peripherals 138, etc. It should be understood that while remaining consistent with the embodiments, WTRU 102 can include any sub-combination of the foregoing elements.

[0071] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal decoding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120, which can be coupled to a transmit / receive element 122. Although Figure 1B the processor 118 and the transceiver 120 are depicted as separate components, it should be understood that the processor 118 and the transceiver 120 can be integrated together, for example, in an electronic package or a chip.

[0072] The transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via an air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In one embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF signals and optical signals. It should be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0073] Although the transmit / receive element 122 is depicted as a single element in Figure 1B the WTRU 102 can include any number of transmit / receive elements 122. For example, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

[0074] The transceiver 120 can be configured to modulate the signals to be transmitted by the transmit / receive element 122 and demodulate the signals received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. For example, thus, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

[0075] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from any type of suitable memory (such as the non-removable memory 130 and / or the removable memory 132) and store data in any type of suitable memory. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from a memory that is not physically located on the WTRU 102 (such as, a server or a home computer (not shown)) and store data in that memory.

[0076] The processor 118 may receive power from a power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry battery packs (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), a solar cell, a fuel cell, etc.

[0077] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information via an air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the embodiments, the WTRU 102 may obtain location information by any suitable location determination method.

[0078] The processor 118 may also be coupled to other elements / peripherals 138, which may include one or more software modules / units and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connections. For example, the element / peripheral 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (e.g., for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, modules, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, etc. The element / peripheral 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geographical location sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0079] The WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with a particular subframe for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with a particular subframe for uplink (e.g., for transmission) or downlink (e.g., for reception)).

[0080] Figure 1C is a system diagram of the RAN 104 and the CN 106 according to one embodiment. As noted above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRU 102a, 102b, and 102c via the air interface 116. The RAN 104 may also communicate with the CN 106.

[0081] The RAN 104 may include evolved Node Bs 160a, 160b, 160c, but it should be understood that while consistent with the embodiments, the RAN 104 may include any number of evolved Node Bs. Each of the evolved Node Bs 160a, 160b, 160c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c via the air interface 116. In one embodiment, the evolved Node Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node B 160a, for example, may use multiple antennas to transmit wireless signals to the WTRU 102a and receive wireless signals from the WTRU.

[0082] Each of the evolved Node Bs 160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to manage radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), etc. As Figure 1C shown, the evolved Node Bs 160a, 160b, 160c may communicate with each other via the X2 interface.

[0083] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0084] The MME 162 may be connected to each of the evolved Node Bs 160a, 160b, 160c in the RAN 104 via the S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide control plane functions for handover between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0085] The SGW 164 can be connected via the S1 interface to each of the evolved Node Bs 160a, 160b, 160c in the RAN 104. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions such as anchoring the user plane during handovers between evolved Node Bs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the contexts of the WTRUs 102a, 102b, 102c, etc.

[0086] The SGW 164 can be connected to the PGW 166, which can provide the WTRUs 102a, 102b, 102c with access to a packet switched network (such as the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0087] The CN 106 can facilitate communication with other networks. For example, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to a circuit switched network (such as the PSTN 108) to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the CN 106 can include an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108, or can communicate with the IP gateway. In addition, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

[0088] Although the WTRU is described as a wireless terminal in Figures 1A to 1D it is contemplated that in some representative embodiments, such a terminal can (e.g., temporarily or permanently) use a wired communication interface to the communication network.

[0089] In a representative embodiment, the other network 112 can be a WLAN.

[0090] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or from the BSS. Traffic originating from outside the BSS and destined for an STA may reach the STA through the AP and may be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS may be transmitted to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be transmitted through the AP. For example, the source STA may transmit traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA using direct link setup (DLS) (e.g., directly between them). In some representative embodiments, DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within the IBSS or using the IBSS (e.g., all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to as an "ad hoc" communication mode in this document.

[0091] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel (such as the primary channel). The primary channel may be of a fixed width (e.g., 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In some representative embodiments, for example, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented in an 802.11 system. For CSMA / CA, the STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. Only one STA (e.g., only one station) may transmit at any given time in a given BSS.

[0092] High throughput (HT) STAs may communicate using 40 MHz wide channels, e.g., by combining the primary 20 MHz channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

[0093] A very high throughput (VHT) STA can support channels that are 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining eight contiguous 20 MHz channels, or by combining two non - contiguous 80 MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed separately with an inverse fast Fourier transform (IFFT) and time - domain processing. These streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations for the 80+80 configuration described above can be reversed, and the combined data can be delivered to the media access control (MAC) layer, entity, etc.

[0094] 802.11af and 802.11ah support operation modes below 1 GHz. There is a reduction in channel operation bandwidth and carriers in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the television white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non - TVWS spectrum. According to a representative embodiment, 802.11ah can support meter - type control / machine - type communication (MTC), such as MTC devices in a macro - coverage area. MTC devices can have certain capabilities, for example, limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices can include a battery with a battery life higher than a threshold (e.g., to maintain a very long battery life).

[0095] A WLAN system supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by an STA (which supports the minimum bandwidth operation mode) from all STAs operating in the BSS. In the example of 802.11ah, for an STA (e.g., an MTC-type device) that supports (e.g., only supports) the 1 MHz mode, the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the state of the primary channel. If the primary channel is busy, for example, because an STA (only supporting the 1 MHz operation mode) is transmitting to the AP, the entire available frequency band can be considered busy even if most of the band remains idle and may be available.

[0096] In the United States, the available frequency band for 802.11ah is 902 MHz to 928 MHz. In Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0097] Figure 1D FIG. is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As noted above, RAN113 can employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 113 can also communicate with CN 115.

[0098] The RAN 113 may include gNBs 180a, 180b, 180c, but it should be understood that the RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each of the gNBs 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c via the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the WTRUs 102a, 102b, 102c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multipoint (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and the gNB 180b (and / or gNB 180c).

[0099] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using various or scalable length subframes or transmission time intervals (TTIs) (e.g., including different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0100] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in a stand-alone configuration and / or a non-stand-alone configuration. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without accessing other RANs (e.g., such as evolved Node Bs 160a, 160b, 160c). In the stand-alone configuration, WTRUs 102a, 102b, 102c can use one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In the non-stand-alone configuration, WTRUs 102a, 102b, 102c can communicate / connect with gNBs 180a, 180b, 180c while also communicating / connecting with another RAN (such as evolved Node Bs 160a, 160b, 160c). For example, WTRUs 102a, 102b, 102c can implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node Bs 160a, 160b, 160c substantially simultaneously. In the non-stand-alone configuration, evolved Node Bs 160a, 160b, 160c can be used as a mobility anchor for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, 102c.

[0101] Each of gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to manage radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As Figure 1D shown, gNBs 180a, 180b, 180c can communicate with each other via the Xn interface.

[0102] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and at least one data network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0103] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRUs 102a, 102b, 102c, for example, based on the type of service used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases (such as services that rely on ultra-reliable low-latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc.). The AMF 162 may provide control plane functions for handover between the RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as Wi-Fi.

[0104] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0105] UPF 184a and 184b can be connected via the N3 interface to one or more of gNBs 180a, 180b, and 180c in the RAN 113, and these gNBs can provide access to a packet switched network (such as the Internet 110) to the WTRUs 102a, 102b, and 102c, for example, to facilitate communication between the WTRUs 102a, 102b, and 102c and IP-enabled devices. UPF 184a and 184b can perform other functions, such as routing and forwarding packets, implementing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0106] The CN 115 can facilitate communication with other networks. For example, the CN 115 can include an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108, or can communicate with this IP gateway. In addition, the CN 115 can provide access to other networks 112 to the WTRUs 102a, 102b, and 102c, and these other networks can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, and 102c can be connected to the DNs 185a and 185b via the UPF 184a and 184b through the N3 interface to the UPF 184a and 184b and the N6 interface between the UPF 184a and 184b and the local data network (DN) 185a and 185b.

[0107] In view of Figures 1A to 1D and Figures 1A to 1D In view of the corresponding descriptions, one or more or all of the functions described herein with reference to any of the following can be performed by one or more emulation elements / devices (not shown): WTRUs 102a - 102d, base stations 114a - 114b, evolved Node Bs 160a - 160c, MME 162, SGW 164, PGW 166, gNBs 180a - 180c, AMFs 182a - 182b, UPFs 184a - 184b, SMFs 183a - 183b, DNs 185a - 185b, and / or any other element / device described herein. The emulation device can be one or more devices configured to mimic one or more or all of the functions described herein. For example, the emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0108] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more functions or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices can perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device for testing purposes and / or can perform tests using over-the-air wireless communication.

[0109] The one or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test laboratory and / or a test scenario in a non-deployed (e.g., test) wired and / or wireless communication network to implement tests of one or more components. The one or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit system (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0110] The following description is for exemplary purposes and is not intended to limit in any way the applicability of the methods described herein to any wireless technology and / or, where applicable, to other wireless technologies. The term network in the present disclosure can refer to one or more gNBs, which in turn can be associated with one or more transmit / receive points (TRPs); or can refer to any other node in a radio access network.

[0111] As described in document TR22.847, the multimodal synchronization threshold can be defined as the maximum tolerable time interval at the start of two stimuli, where one stimulus is presented to one sense and the other stimulus is presented to another sense such that the accompanying sensory objects are perceived as being synchronous.

[0112] The following description describes functions that can be performed by a 5G extended reality (5GXR) application provider, 5GXR AF, and 5GXR AS. It should be understood that this is a logical description, and a server or network function can provide all or part of the 5GXR application provider, 5GXR AF, and 5GXR AS functions. In other words, the terms application server, application provider, and application function can be used interchangeably.

[0113] The WTRU may host 5G XR sensing applications, XR session handlers, 5G XR clients, and / or XR engines. In this document, 5G XR sensing applications, XR session handlers, 5G XR clients, and XR engines are sometimes referred to as applications. The description herein may equally apply to 5G XR sensing applications, XR session handlers, 5G XR clients, XR engines, or any type of application.

[0114] Document TR 22.847 studied the support for tactile and multimodal communication services. More specifically, Phase 1 (Release 18) (V 18.1.0) of document TR 22.847 defines multimodal data as input data from different kinds of devices / sensors or output data to different kinds of destinations (e.g., one or more WTRUs) required for the same task or application. Multimodal data may consist of more than one unimodal data, and there may be strong dependencies between each unimodal data. Unimodal data may be regarded as a type of data.

[0115] The device or sensor that generates (e.g., sends) unimodal data may be a WTRU or may use a WTRU to transmit unimodal data to the network. Unimodal data may be transmitted to an application hosted on other WTRUs or an application hosted on a network server.

[0116] The device or sensor that receives unimodal data may be a WTRU or may use a WTRU to receive unimodal data from the network. Unimodal data may be received from an application hosted on other WTRUs or an application hosted on a network server.

[0117] Unimodal data may be described as a data stream going to and / or from a WTRU, and multimodal data may be described as consisting of multiple data streams going to and / or from multiple WTRUs.

[0118] A multimodal data set may be a collection of unimodal data streams for the same task or application. For example, if IP flows and / or QoS flows are between multiple WTRUs and a single application server, the multimodal data set may be a collection. For example, an IP flow may carry sensor data, video information, tactile data, audio data, etc.

[0119] Examples of LAN support in a 5G system are described below.

[0120] As described in reference TS23.501 "System Architecture for the 5G System (5GS); Stage 2" (V 17.3.0.), the 5G system can support the management of 5G virtual network (VN) group identities and members, as well as 5G VN group data. To support dynamic 5G VN group identity and member management, the Network Exposure Function (NEF) can expose a set of services to manage (e.g., add / delete / modify) 5G VN groups and 5G VN members. The NEF can also expose services to dynamically manage 5G VN group data.

[0121] A VN group can be associated with configuration information referred to as "5G VN group data". The 5G VN group data can include PDU session type, DNN, single network slice selection assistance information (S-NSSAI), and application descriptor.

[0122] 5G VN group management can be configured by a network administrator (e.g., via an OAM system) or it can be dynamically managed by the AF (e.g., via the NEF).

[0123] The same process can be used to create and update groups.

[0124] Once the group information is configured (or modified) in the Unified Data Repository (UDR), the information can be sent to the Policy Control Function (PCF). The PCF can use this information to construct a UE / WTRU Routing Selection Policy (URSP) that can cause specific traffic to use the DNN and S-NSSAI associated with the VN group. Then, the URSP rules can be sent to one or more WTRUs that are part of the VN group.

[0125] The network can associate a VN group with a DNN, and when the WTRU establishes a PDU session to the DNN, the network can trigger secondary PDU session authentication.

[0126] As Figure 2 shown, both unicast and multicast can be supported within the DN associated with the 5G VN group. The PDU session anchor UPF can determine whether the communication is for unicast or multicast based on the destination address of the received data.

[0127] As Figure 3 shown, there are three traffic forwarding methods available for 5G VN communication in the 5G system. Figure 3 N6-based forwarding, N19-based forwarding, and local switching are illustrated.

[0128] An example of the 5G application layer architecture for XR is described below.

[0129] Document TR 26.928, "AN Support in 5G Systems" (V 16.1.0.), describes the application layer architecture that supports XR in 5G systems. The application layer architecture involves the client and network architectures, APIs, and media handling functions that support XR use cases.

[0130] Figure 4 is copied from document TR 26.928 and illustrates the following aspects of an example application layer architecture that supports XR in 5G systems.

[0131] The WTRU may host a 5G XR client that interfaces with a 5G XR Application Function (AF). The interface between the 5G XR client and the 5G XR AF may be referred to as X5. X5 messages may be transported on the user plane and may be API-based. The X5 interface may allow the 5G XR client to indirectly access services exposed by the NEF and PCF. A PDU session may be used to carry X5 traffic between the WTRU and the data network (DN) hosting the 5G XR AF.

[0132] The WTRU may host a 5G XR client that interfaces with a 5G XR Application Server (AS). The interface between the 5G XR client and the 5G XR AS may be referred to as X4. X4 messages may be transported on the user plane and may be API-based. The X4 interface may allow the 5G XR client to access XR-related data. The traffic carried on the X4 interface may be a single-modal data stream that is part of a multi-modal data set. In other words, the X4 interface may be carried on the user plane. A PDU session may be used to carry X4 traffic between the WTRU and the data network (DN) hosting the 5G XR AS.

[0133] The WTRU may host a 5G XR-aware application that interfaces with a 5G XR application provider. The interface between the 5G XR-aware application and the 5G XR application provider may be referred to as X8. The X8 interface is used for information exchange between the 5G XR-aware application and the 5G XR application provider, such as providing service access information to the 5G XR application provider. A PDU session may be used to carry X8 traffic between the WTRU and the data network (DN) hosting the 5G XR application provider.

[0134] In Figure 4 the context of and the remainder of this specification, the 5G XR AF, 5G XR AS, and 5G XR application provider may be referred to as an application server, application function, or network server.

[0135] Figure 4 The application layer architecture of is based on the application layer architecture of TS 26.501, "5G Media Streaming (5GMS); General Description and Architecture" (V 17.0.0.). TS 26.501 defines a preconfigured session identifier. The preconfigured session and the associated preconfigured session identifier may be created by the application provider.

[0136] The application provider can create a preconfigured session with the AF and can start the use of the preconfigured 5G media streaming system. During the establishment phase, the features to be used can be negotiated and detailed configurations can be exchanged. The AF can receive service access information for X5 (media session handling) and, if media content hosting can be negotiated, can also receive service access information for X2 (ingest) and X4 (media streaming). The WTRU client may need this information to access the service. Depending on the preconfiguration, only a reference to the service access information may be provided.

[0137] Example of 5G QoS framework

[0138] As described in TS23.501, the 5G QoS model can be based on QoS flows. A QoS flow can be associated with QoS requirements specified by QoS parameters and QoS characteristics. A QoS flow can be the finest granularity of QoS differentiation within a PDU session. A QoS flow ID (QFI) can be used to identify QoS flows in the 5G system. User plane traffic within a PDU session having the same QFI can receive the same traffic forwarding treatment (e.g., scheduling, admission threshold). The QFI can be carried in the encapsulation header on N3 (and N9), e.g., without any change to the e2e packet header.

[0139] A QoS flow can be controlled by the SMF and can be preconfigured or established via the PDU session establishment procedure or the PDU session modification procedure.

[0140] Any QoS flow can be characterized by: a QoS template provided by the SMF to the AN via the AMF over the N2 reference point or preconfigured in the AN, one or more QoS rules, and optionally QoS flow level QoS parameters associated with these QoS rules (these QoS rules can be provided by the SMF to the WTRU via the AMF over the N1 reference point and / or derived by the WTRU through application reflection QoS control), and one or more UL and DL PDRs provided by the SMF to the UPF.

[0141] In the current 5G system design, in addition to the QoS template, the SMF can also provide the NG-RAN with a prioritized list of alternative QoS templates. The alternative QoS templates can represent a combination of the QoS parameters packet delay budget (PDB), PER, and guaranteed flow bit rate (GFBR) that the application traffic can adapt to. When the NG-RAN transmits a notification that the QoS template is not satisfied to the SMF, if the currently satisfied values match the alternative QoS template, the NG-RAN can also include a reference to the alternative QoS template to indicate the QoS currently satisfied by the NG-RAN. Then, the SMF can transmit updated QoS rules to the WTRU via the PDU session modification procedure.

[0142] An example of a UE / WTRU Routing Selection Policy (URSP) is described below.

[0143] As described in document TS23.503 "Policy and Charging Control Framework for 5G Systems (5GS); Phase 2" (V 17.3.0.), a URSP rule can be a policy used by the WTRU to determine how to route outgoing traffic. The traffic can be routed to an established PDU session, the traffic can be offloaded to a non-3GPP access outside of the PDU session, the traffic can be routed outside of the PDU session via ProSe layer 3 WTRU-to-network relay, or the establishment of a new PDU session can be triggered.

[0144] Note that the WTRU application can request network connectivity using non-seamless offloading or ProSe layer 3 WTRU-to-network relay offloading. In this case, the WTRU will use non-seamless offloading for that application without evaluating the URSP rules. Otherwise, the WTRU can use the URSP rules to determine how to route the application traffic.

[0145] Each URSP rule can consist of two parts. The first part of the URSP rule can be a traffic descriptor that can be used to determine when the rule applies. When each component in the traffic descriptor matches the corresponding information from the application, it can be determined that the URSP rule applies. The second part of the URSP rule can be a list of Routing Selection Descriptors (RSDs). The list of routing selection descriptors can contain one or more routing selection descriptors. The RSDs can be listed in order of priority and describe the characteristics of the PDU session that can be used to carry the uplink application data. The characteristics of the PDU session can include the Session and Service Continuity (SSC) mode, the DNN, and the S-NSSAI. The RSD can alternatively include a non-seamless offloading indication, which indicates that the traffic can be transported outside of any PDU session via a non-3GPP access (e.g., WiFi).

[0146] For each newly detected application, the WTRU can evaluate the URSP rules in order of rule precedence and can determine whether the application matches the traffic descriptor of any URSP rule. When it is determined that a URSP rule applies to a given application, the WTRU can select a routing selection descriptor within that URSP rule in order of routing selection descriptor precedence.

[0147] When a valid routing descriptor is found, the WTRU may determine whether there is an existing PDU session that matches all the components in the selected routing descriptor. When there is a matching PDU session, the WTRU may associate the application with the existing PDU session. For example, the WTRU may route the traffic of the detected application over that PDU session. If none of the existing PDU sessions match the RSD, the WTRU may attempt to establish a new PDU session using the values specified by the selected routing descriptor.

[0148] As discussed in TS 24.526, "User Equipment (UE) Policy for 5G System (5GS); Phase 3" (V 17.5.0.), once traffic from an application is associated with a PDU session, an event may cause the WTRU to re-evaluate the URSP rules and associate the traffic from the application with a different PDU session. Two examples of events that may trigger a URSP re-evaluation are an implementation-dependent re-evaluation timer and the WTRU establishing access to a Wi-Fi network that provides Internet access without using the 5G system (e.g., non-seamless offloading becomes possible).

[0149] The traffic descriptor can be an application descriptor, an IP descriptor, a domain descriptor, a non-IP descriptor, a DNN, or a connection capability. The IP descriptor can be a destination IP 3-tuple (IP address or IPv6 network prefix, port number, protocol ID of the protocol over IP).

[0150] Examples of use cases that cause some problems are described below.

[0151] Document TR 22.847 describes various use cases involving the use of multi-modal data. A common theme in several use cases is that multiple modalities can be sent to multiple application servers simultaneously for further processing in a coordinated manner. Generally speaking, information can be collected from the user and the environment (e.g., from multiple WTRUs), the information is transmitted to multiple WTRUs, the information can be transmitted in separate streams, the network and possibly the WTRUs may need to know about the stream "grouping", and the information needs to be synchronized.

[0152] In the scenario of a real-time remote virtual reality service, a virtual reality (VR) user may use multiple independent devices to separately collect video, audio, environmental, and tactile data from a person and receive video, audio, environmental, and tactile feedback from one or more application servers for the same VR application.

[0153] Multiple results may need to arrive at distributed WTRUs simultaneously. In the scenario of sound field reproduction, sounds of different channels can be transmitted to distributed speakers to simulate sounds from a specific direction. Tiny time differences may cause large direction errors, thus affecting the user experience.

[0154] In another use case example, a data stream can be established from multiple camera WTRUs to the same application server. A video stream (e.g., a stream) from one camera may be more critical than a video stream (e.g., a stream) from a second camera. During network congestion, the 5G system should know that some streams are more important than others and be able to adjust, discard, or disable the streams when network congestion occurs. Additionally, packets of the same video stream may contribute differently to the user experience, so hierarchical QoS handling within the video stream can potentially relax this requirement and improve efficiency.

[0155] As described above, there may be strong dependencies between the single-modal data streams in a multi-modal dataset. This dependency can be based on multiple factors.

[0156] The single-modal data streams in a multi-modal dataset may have synchronization requirements. In other words, it may be required that data from a particular single-modal data stream reach their destination within a synchronization threshold time so that the data can be delivered to the application layer at the appropriate time (e.g., in a relatively synchronized manner with the rest of the multi-modal dataset).

[0157] Some of the single-modal data streams in a multi-modal dataset may have varying priority levels. For example, one single-modal data stream may be critical, and if that single-modal data stream only experiences some delays or dropped packets, the quality of experience may be significantly affected. A second single-modal data stream in the same multi-modal dataset may be less important or even optional, such that if the second single-modal data stream is delayed, dropped, or not successfully established, the user experience may not be significantly affected.

[0158] The 5G system currently does not support a feature that allows the system to be configured to know which single-modal data streams belong to the same multi-modal dataset. The embodiments proposed in this specification address how elements of the 5G system (e.g., WTRUs and network nodes) can be configured to know which single-modal data streams belong to the same multi-modal dataset.

[0159] Additionally, the 5G system may not know how the single-modal data streams in a multi-modal dataset depend on each other. In other words, the 5G system may not know whether some single-modal data streams have a higher priority than others, and the 5G system may not know whether there are synchronization requirements between the single-modal data streams. The embodiments proposed in this specification can describe what information (e.g., policy information) the 5G system can use to optimize the processing of the multi-modal dataset.

[0160] Once the 5G system knows how the single-modal data streams in a multi-modal dataset depend on each other, the 5G system can use this information to appropriately prioritize and allocate resources for the single-modal data streams in the multi-modal dataset. The embodiments presented in this specification can describe how a 5G system (e.g., a WTRU and a network node) can use policy information to appropriately prioritize and allocate resources for the single-modal data streams in a multi-modal dataset.

[0161] Once the 5G system knows how the single-modal data streams in a multi-modal dataset depend on each other, the 5G system can also use this information to appropriately synchronize the single-modal data streams in the multi-modal dataset. This specification describes how a 5G system (e.g., a WTRU and a network node) can use policy information to synchronize the single-modal data streams in a multi-modal dataset. Synchronizing the single-modal data streams in a multi-modal dataset may mean ensuring that all WTRUs are triggered and ready to receive or transmit data if necessary.

[0162] As previously mentioned, packets of the same video stream (e.g., a stream) may have different contributions to the user experience. However, the 5G system design can be such that the QoS rules applied in a WTRU have an IP flow-based granularity. Thus, the same importance (e.g., QFI) will be applied to all packets of the same IP flow of a PDU session.

[0163] In some cases, extended reality media service (XRM) traffic can be exchanged between WTRUs without involving an application server. In such a case, the 5G core network (5GC) needs to have a way to detect that the PDU sessions of an XRM session are related / linked so that the 5GC can configure the QoS rules and N4 rules of the PDU session in a coordinated manner.

[0164] A configuration example of the AF of a 5G XR service provider is described below.

[0165] According to various embodiments described in detail below, the AF of a 5G XR service provider can configure information about a multi-modal dataset in a 5G system. As described below, this information includes the service requirements of the data streams of the multi-modal dataset and the identities of the WTRUs that may be associated with the multi-modal dataset.

[0166] According to various embodiments described in detail below, a WTRU application can obtain multi-modal set information (e.g., a multi-modal set identifier). The WTRU can provide the multi-modal set information to the network during PDU session establishment so that the network can identify that the PDU session may be associated with the multi-modal dataset.

[0167] The various embodiments described in detail below provide enhanced details regarding the QoS framework of a 5G system, such that different QoS handling can be applied to packets of the same flow. The QoS framework enhancements can also be described such that a WTRU can (e.g., quickly) change which QoS rules or handling are applied.

[0168] According to the various embodiments described in detail below, the AF can introduce a set of policies for each service data flow according to an XRM session and can index these policies. The 5GS may be able to derive appropriate policy charging and control (PCC) rules, QoS rules, and N4 rules for each index and can convey them, along with the index, to the appropriate network entity. An application hosted by the WTRU can convey the index value to the WTRU to convey a specific configuration (e.g., decoding settings), and the WTRU can use the index value to select the corresponding QoS rules for the traffic.

[0169] According to the various embodiments described in detail below, the terms 5GXR AF and 5G application function (5GAF) may be used interchangeably.

[0170] According to the various embodiments described in detail below, once a multi-modal data flow is created, the 5G system can ensure that the WTRUs associated with the multi-modal data set are triggered to wake up (e.g., be in the 5GMM connected state) when they are requested to transmit or receive data, thereby reducing flow latency.

[0171] An example of associating a flow with a multi-modal data set is described below.

[0172] A 5GXR-aware application (also referred to as a 5GXR application) can discover the XR session it wants to join. This discovery operation can be performed on the X8 interface. The XR session can be associated with a multi-modal data set. The XR session can be associated with a session identifier and service access information. As part of this discovery operation, the 5GXR application can receive the session identifier and service access information. This information can be transmitted by the 5GXR service provider to the 5GXR application via the X8 interface. The 5GXR application can then provide this information to the XR engine via the X7 reference point and to the XR session handler via the X6 reference point.

[0173] The XR engine can provide this information to the MT part of the WTRU such that the XR engine can use it during PDU session establishment. The XR session handler can use the X5 interface to provide this information to the 5GXR AF. The 5GXR AS can use this information (e.g., via the NEF) to inform the network that the WTRU has joined the session.

[0174] Alternatively, the XR session handler can obtain the session ID from the 5G XR AF and use the X7 interface to provide the session ID to the XR engine. The XR engine can then use the session ID during PDU session establishment.

[0175] Alternatively, the session ID can be configured on the WTRU using a graphical user interface (GUI) hosted by the terminal equipment (TE) part of the WTRU and provided to the MT part of the WTRU via AT commands.

[0176] The session identifier can be related to a "preconfigured session identifier", "application identifier", "content hosting configuration identifier", or "application identifier".

[0177] A NEF application programming interface (API) can be defined that allows the 5G XR AF to request the creation of a multimodal data stream. The NEF API can be a new API or an enhanced version of the Nnef_ParameterProvision API. The Nnef_ParameterProvision API can be used to create VN groups. The API can be enhanced to allow the 5G XR AF to provide a session identifier to the network, or the 5G XR AF can provide an application descriptor to the network that maps to the session identifier and is provided to the 5G XR-aware application as the session identifier. The preconfiguration of the session identifier by the 5G XR AF via the NEF is discussed further below.

[0178] The 5G XR application can provide the session identifier and service access information to the XR engine via the X7 interface. This may involve the 5G XR application calling an API that passes the session identifier and service access information to the XR engine.

[0179] The single-modal stream of the WTRU associated with the multimodal data set will be located between the XR engine and the 5G XR AS and pass through the X4 interface.

[0180] When the XR engine is ready to initiate a single-modal stream associated with a multimodal data set, the XR engine can provide the session identifier and traffic descriptor to the mobile terminal (MT) part of the WTRU. For example, the XR engine can be an application running in the TE part of the WTRU, and the XR engine can call an API (such as an AT command (e.g., the +CGDONT AT command can be enhanced to allow the session identifier to be provided to the ME)) to provide the session identifier to the MT part of the WTRU. Note that (AT) commands are defined in TS 27.007 "AT command set for user equipment (UE)" (V 17.4.0).

[0181] The XR engine may provide a session identifier and a traffic descriptor to the MT part of the WTRU, and this may trigger the MT part of the WTRU to transmit a PDU session establishment request to the 5G core network. The PDU session establishment request may include a data network name (DNN), an S-NSSAI, and a session identifier. URSP rules may be used to determine the DNN or S-NSSAI. Alternatively, the DNN or S-NSSAI may be provided by the XR engine. Alternatively, the WTRU may not provide the DNN or S-NSSAI to the network. The SMF may receive the PDU session establishment request and may use the session identifier to determine that the PDU session can be used to carry a single-modal flow associated with a multi-modal set. The SMF may use the session identifier to retrieve PCC rules for the PDU session from the PCF, and if the WTRU does not provide the S-NSSAI and / or DNN in the PDU session establishment request, the SMF may use the session identifier to determine the S-NSSAI and / or DNN to be associated with the PDU session. The PCC rules obtained by the PCF may be used to derive QoS rules for the PDU session.

[0182] As described above, the 5G LAN feature of the 5G system allows the network to associate PDU sessions. All PDU sessions associated with the same DNN and S-NSSAI may be associated with the same 5G LAN. Without enhancement, using the 5G LAN feature to associate single-modal flows of a multi-modal set would be inefficient. The reason such a method would be inefficient is that the 5G LAN feature requires that all PDU sessions to the DNN / S-NSSAI combination be "associated". As described above, the WTRU may provide a session identifier to the network so that the network can determine which PDU sessions are associated, and thus can distinguish the handling of PDU sessions based on the multi-modal data sets associated with each PDU session. With this enhancement, many PDU sessions may use the same DNN / S-NSSAI combination, and the network can determine which of the PDU sessions are associated with the same multi-modal set.

[0183] Figure 5 An example process is shown of how the WTRU may assist the network in associating PDU sessions with multi-modal data sets.

[0184] In Figure 5In step 1, the 5G XR application on the WTRU may perform a discovery process with the 5G XR application provider. The result of this discovery process may be that the 5G XR application on the WTRU may receive a session identifier (ID) and service access information. The service access information may include a traffic descriptor (e.g., the IP address and port number of the traffic destination). As part of this discovery process, the 5G XR application may provide the 5G XR service provider with information about which services the 5G XR application wants to discover. For example, the 5G XR application may provide a flow type or application type (e.g., video stream, audio, etc.), a priority value, and / or location information during this discovery process, such that the 5G XR application provider can provide a session ID based on this information.

[0185] In Figure 5 In step 2, the 5G XR AF may call the NEF API to inform the network that a multi-modal data stream has been created. This API may be used by the 5G XR AF to provide the network with an application descriptor that maps to the session identifier and is provided to the 5G XR-aware application as the session identifier. This API may also be used by the 5G XR AF to configure the network with the identity of the device (e.g., the external ID of the external group ID) that may be associated with the multi-modal data set.

[0186] The 5G AF may also be able to provide the NEF with multiple policies to use throughout the life cycle of the XR session. For example, the 5G AF may provide multiple policies for each single-modal stream and / or for each WTRU. For example, each policy may apply to different frame rate values for video traffic.

[0187] The NEF may convey the multiple policies to the PCF. The PCF may use the multiple policies to derive multiple sets of PCC rules. The PCF may provide the multiple sets of PCC rules to the SMF of the PDU session serving the XRM session, and the SMF may use the multiple sets of PCC rules to generate corresponding sets of QoS rules and N4 rules. The corresponding sets of QoS rules may be conveyed to the WTRU, and the N4 rules may be conveyed to the UPF. Each set of QoS rules and a set of N4 rules in that group may be associated with an index.

[0188] When the application hosted by the WTRU provides an information unit for transmission and the application hosted by the WTRU provides an index value, the WTRU may determine which rules to use. For example, the application hosted by the WTRU may determine which index to provide to the WTRU based on how the codec is configured. The application hosted by the WTRU may have been configured with a mapping between codec / application settings and QoS index values. For example, if the WTRU is an XR session handler, the configuration information may have been received from the 5G XRAf via the X5 interface.

[0189] For each set of N4 rules, the PCF may provide a traffic detection rule or a pointer to a traffic detection rule to the user plane function (UPF). The UPF may use the traffic detection rule to detect the characteristics of traffic and determine which N4 rules to apply.

[0190] In Figure 5 step 3 of

[0191] In Figure 5 step 4 of

[0192] In Figure 5 step 5 of Figure 5 the 5G XR application in the WTRU may use the information about the multi-modal data set to configure the XR engine in the WTRU. The 5G XR application may provide a session identifier and service access information to the XR engine. The XR engine (which may be an application running in the TE part of the WTRU) may trigger the MT part of the WTRU to transmit a PDU session establishment request to the network. The XR engine may trigger the PDU session establishment by either explicitly requesting the PDU session establishment (e.g., by invoking an AT command) or starting to transmit traffic to the MT part of the WTRU for sending. When the XR engine triggers the PDU session establishment, the XR engine may provide the session identifier and service access information to the ME. The service access information may include a traffic descriptor used by the MT during URSP rule evaluation. The PDU session establishment request may also include information indicating the type of application that may use the PDU session. Alternatively, the SMF may be able to use the session identifier to determine the type of application that will use the PDU session. The WTRU may transmit a PDU session establishment request to the network. The PDU session establishment request may be a non-access stratum session management (NAS-SM) message and may be enhanced to include XR session information. The XR session information may be used by the SMF to identify that the PDU session will be associated with a specific multi-modal data set. During UPF selection, the SMF may use this information to ensure that a UPF relatively close to the 5G XR AS, a UPF that can be used to communicate with the 5G XR AS, and / or a UPF that is the same as the UPF used for PDU sessions of other WTRUs also associated with the multi-modal data set is selected. The XR session information may also be carried in a NAS mobility management (NAS-MM) message carrying the PDU session establishment request, such that the AMF may use this information during SMF selection (e.g., to select an SMF that can serve the multi-modal data set). In other words, the XR session information may be carried in both the NAS-MM part and the NAS-SM part of the message, such that both the AMF and the SMF may use the XR session information. The AMF may use the XR session information in the SMF selection process. The SMF may use the XR session information in the UPF selection process. The XR session information may be the session identifier provided to the 5G XR application in Figure 5 step 1 of

[0193] In Figure 5 step 6, the SMF will send a PDU session establishment acceptance message to the WTRU. The PDU session establishment acceptance message may include QoS rules. The SMF may derive QoS rules based on the PCC rules received from the PCF. The PCC rules may be derived by the PCF based on the information received from the NEF / 5GXR AF. For example, the 5GXR AF may have provided the network with the latency requirements of the single-modal flow of the multi-modal data set.

[0194] As described, the QoS rules provided to the WTRU may be enhanced such that these QoS rules can be associated with a QoS rule index or priority and a QoS mark is assigned on a per-packet basis. Additionally, as described, the QoS rules may be enhanced such that the QoS rules can indicate to the WTRU that packets that are part of a certain QoS flow should be discarded by the WTRU and not transmitted to the RAN node.

[0195] After Figure 5 step 6, the WTRU may establish a PDU session associated with the multi-modal data set and may be used to transmit and receive data associated with the multi-modal data set.

[0196] Examples of policies associated with the multi-modal data set are described below.

[0197] As described above, the NEF API may allow the 5GAF to configure information about the multi-modal data set in the network. The API may be an enhanced version of the Nnef_ParameterProvision API. The new API may be called the Nnef_MultiModalDataSetAPI.

[0198] This API may be used to configure the following information about the multi-modal data set in the network.

[0199] This API may allow the 5GAF to configure the DNN, S-NSSAI, and PDU session type to be associated with the multi-modal data set.

[0200] This API may allow the 5GAF to configure an application descriptor to be associated with the multi-modal set. As described in TS23.502 "Procedures for the 5G System (5GS)" (V 17.3.0.), the application descriptor may be used to construct URSP rules. As described in TS23.503 "5G System (5GS) Policy and Charging Control Framework; Phase 2" (V17.3.0.), the PCF may be configured with a mapping from the application descriptor to other information (e.g., IP filters and SSC mode) required to construct URSP rules.

[0201] In various embodiments, it may be desirable for the traffic of a multi-modal session to have the same DNN / S-NSSAI combination. In such cases, the WTRU may need to correctly establish / configure its URSP rules. Invoking the NEF API may trigger the PCF to provide a set of updated URSP rules to the WTRU involved in the XRM session. Each rule may have its unique priority order and may include a traffic descriptor and a list of routing descriptors. The traffic descriptor may include an IP descriptor (e.g., destination IP 3-tuple, application identifier, FQDN, and DNN provided by the application). As described below, the traffic descriptor may also include a new component reflecting the XR session ID. The WTRU may know to match the traffic associated with a certain XR session (i.e., matching the traffic descriptor) to the correct DNN / S-NSSAI combination.

[0202] The PCF may subscribe to notifications of policy data changes for multi-modal sessions at the UDR. Once the UDR detects a change, the UDR may notify the PCF of the updated policy control subscription profile via Nudr_DM_Notify. The PCF may then determine that the WTRU policy information needs to be sent to the WTRU. The PCF may send a policy association update request to the AMF via the Npcf_URPolicyControl UpdateNotify request, which includes the new WTRU policy information (e.g., URSP). This will trigger a WTRU configuration update process to send the information to the WTRU via the AMF, which will update the URSP rules at the WTRU.

[0203] The API may allow the 5GAF to configure the network with information on which WTRUs may be associated with a multi-modal data set. The API may allow the 5GAF to identify WTRUs with a list of GPSIs or an external group ID.

[0204] The API may allow the 5GAF to configure one or more session identifiers to be associated with a multi-modal data set.

[0205] The API may allow the 5GAF to configure the network with a multi-modal data set identifier.

[0206] The API may allow the 5GAF to indicate to the network which application descriptors and / or session identifiers are associated with each WTRU. The PCF may then use this association to determine which URSP rules need to be sent to the WTRU, which PCC rules need to be derived for the PDU session of each WTRU, and which QoS rules need to be sent to each WTRU. Without knowing this association, the PCF would need to send the same URSP rules and QoS rules to the WTRU. In a scenario where one WTRU associated with a multimodal set is generating a small amount of sensed environmental data and another WTRU is streaming video, different QoS rules and different URSP rules may be provided to the WTRU.

[0207] Another advantage of associating different session identifiers with different WTRUs is that it allows the multimodal data set to be configured such that not all flows are processed in the same way. For example, some WTRUs associated with the multimodal data set may be provided with session id-x. All WTRUs in the WTRUs using session id-x may be associated with non-critical high data rate environmental sensing data. Other WTRUs associated with the multimodal data set may be provided with session id-y. All WTRUs in the WTRUs using session id-y may be associated with critical low data rate environmental sensing data. Other WTRUs associated with the multimodal data set may be provided with session id-z. All WTRUs in the WTRUs using session id-z may be associated with high data rate video streams. Thus, all three session identifiers (session id-x, session id-y, and session id-z) may be associated with the same multimodal data set, and the traffic associated with each identifier may receive different processing from the network.

[0208] The API may also allow the 5GAF to configure the synchronization requirements or synchronization thresholds for each session ID, each flow ID, or each flow descriptor (e.g., IP 5-tuple). The PCF may use these synchronization requirements to derive PCC rules and URSP rules.

[0209] The 5GS may trigger a policy change request to the PCF. For example, if QoS notification control is activated / included in the PCC rules generated by the PCF, the RAN may notify the PCF via the SMF when the GFBR may no longer (or may again) be provided for a certain QoS flow.

[0210] Although the indication may relate to a specific unimodal data (e.g., video traffic), it may affect other modalities used in the XRM session (e.g., audio, tactile, etc.).

[0211] 5GS may need to re-evaluate not only the parameters and / or characteristics of the QoS flow for transporting video traffic, but also other QoS flows involved in the XR session to allow, for example, synchronized data transmission.

[0212] The synchronization requirements may also require 5GS to adapt other QoS flows. Adapting other QoS flows may mean that updated PCC rules can be sent to the SMF of the PDU session serving the XR session.

[0213] Additionally, if a change in one modality (data loss within a certain time interval) affects other modalities (e.g., another modality will be processed differently (discarded) within the same interval, e.g., discarded), the 5G system may be able to coordinate the handling of the two modalities (e.g., set the second modality to be discarded within an interval).

[0214] The PCF may receive an indication from the AF on when a policy update can be applied to the XRM session (e.g., the time when the policy update can be applied to the XRM session). The SMF may receive an indication from the PCF on the specific time of the policy change. The PCF may prepare the updated rules immediately after receiving a request from the AF, or the PCF may schedule the time to process the AF request, e.g., shortly before the time indicated by the AF for the new PCC rule to be implemented.

[0215] Meanwhile, if the PCF receives a policy change request to be implemented immediately or a policy change request to be implemented at a time before a pending previous request from the SMF, the new request can be processed and the previous request can now be rejected. This can allow the PCF to be consistent with any real-time requests regarding policy changes that may need to occur before the first request.

[0216] Figure 6 An example process of how 5G AF can create / configure or modify a multi-modal data set in the 5G system is shown.

[0217] In Figure 6 step 1, an event can trigger 5G AF to create or modify the information stored by the network for the multi-modal data set. Examples of events that will cause 5G AF to create or modify the information stored by the network for the multi-modal data set include requests from the 5G XR application provider, requests from the XR session handler, and requests from the 5G XR AS. The requests triggering 5G AF may include information about the multi-modal data set (e.g., service requirements), session identifiers or multi-modal data set identifiers, the identity of the WTRU associated with the multi-modal data set, and the group identifier of the WTRU associated with the multi-modal data set.

[0218] In Figure 6In step 2, 5GAF may invoke the NEF service to provide the information in step 2 to the 5G system. This service invocation may have the following effects: notifying the 5G system which WTRUs are allowed to be associated with the multimodal data set and how the 5G system should handle the traffic from the multimodal data (e.g., prioritize it).

[0219] The request from 5GAF may include multiple QoS policies for each flow and an index value for each flow. Each index value may correspond to a session configuration (e.g., codec settings), and as described above, the WTRU and UPF may be configured with multiple QoS rules or N4 rules and may be configured to determine which set of rules (i.e., which index) to apply.

[0220] In Figure 6 In step 3, the NEF may invoke the BSF service to determine which PCFs serve the WTRUs associated with the multimodal data set. Then, the NEF may invoke the service of each PCF to provide the PCF with information about the multimodal data set. This information includes the identities of the WTRUs that may be associated with the multimodal data set and includes the service requirements of the multimodal data set. The PCF may use this information to derive PCC rules for the flows of the multimodal data set.

[0221] For single-modal data flows, some application layer parameters may be pre-known and may take on a limited set of values. The 5GS may utilize this knowledge to anticipate different PCC rules for future use with multimodal traffic. A non-limiting example of this scenario is the frame rate value for video traffic (e.g., 60fps, 90fps...), which may affect the target guaranteed bit rate (GBR) while maintaining the same PDB requirements.

[0222] 5GAF / NEF may request the PCF to prepare multiple PCC rules for each modality and different codec settings. The PCF may create PCC rules for the UPF, RAN, and WTRU respectively, as well as corresponding PDRs, QoS templates, and QoS rules.

[0223] The application layer may create an index for each codec setting and generate a mapping between these settings and the index. When a specific coding setting is used, the index of that specific coding setting may be signaled to the 5GC (e.g., PCF, SMF, UPF) and signaled to the WTRU to enable the selection of the appropriate policies and rules to use.

[0224] In Figure 6 In step 4, the PCF responds to the NEF's service invocation. The PCF may provide the NEF with a session identifier (or service identifier).

[0225] In Figure 6In step 5, the NEF responds to a service invocation by the 5GAF. This response may include a session identifier (or service identifier) received from the PCF. These session identifiers (or service identifiers) may be transmitted by the 5GAF to the 5GXR application of the WTRU such that the WTRU may use these identifiers during PDU session establishment as described above.

[0226] An example of configuring a 5G system to detect the correct policy to apply is described below.

[0227] Figure 7 An example flow of the configuration of a 5G system for correct policy detection and enforcement is shown.

[0228] In Figure 7 step 1, the AF may determine multiple QoS policies for a flow. Which QoS policy is used for the flow may depend on the XRM session configuration (e.g., codec settings). The AF may associate an index value with each QoS policy.

[0229] In Figure 7 step 2, the AF may configure the WTRU-hosted application with the following information, i.e., information that the WTRU-hosted application may use to determine which QoS policy index can be used. For example, this configuration may indicate which QoS policy index can be used in each XRM session configuration (e.g., codec settings).

[0230] In Figure 7 step 3, the AF may call the NEF API to provide the network with a flow descriptor, a set of QoS policies, and the index value for each QoS policy.

[0231] In Figure 7 step 4, the NEF may provide the PCF with a flow descriptor, a set of QoS policies, and the index value for each QoS policy.

[0232] In Figure 7 steps 5a and 5b, the PCF may use the QoS policies to generate multiple sets of PCC rules and provide the multiple sets of PCC rules to the SMF serving the session. An index associated with each PCC rule may be provided to the SMF.

[0233] In Figure 7 step 6, the SMF may use each PCC rule to derive a set of QoS rules. The WTRU may receive the QoS rules and the index value associated with each QoS rule from the SMF.

[0234] In Figure 7In steps 7a and 7b, the WTRU-hosted application can generate units of data to be transmitted (e.g., IP packets or video frames) and can indicate to the NAS layer of the WTRU which index is associated with the data. The service data adaptation protocol (SDAP) layer of the WTRU can use the index value to determine which QoS rules to apply to the traffic. In other words, the SDAP layer of the WTRU can use the index value to determine which QFI label to apply to the traffic.

[0235] An example of synchronizing the start of a unimodal stream of a multimodal dataset when the WTRU is in the connected management idle (CM-IDLE) state is described below.

[0236] When an activity is started in a stream, it may be beneficial to take some WTRUs out of the CM-IDLE state, even if those WTRUs have not received the stream. In other words, it may be necessary to anticipate that other WTRUs will soon need to wake up and receive low-latency data. For example, the 5GXR AS or 5GXR application provider can detect that a WTRU will soon need to transmit or receive data from a unimodal stream of a multimodal set. For example, this detection can be based on the sensed data received by the 5GXR AS or 5GXR application provider. The sensed data can indicate an alarm condition that will trigger the need to stream an additional video feed.

[0237] The NEF API can be defined to allow the 5GXR AS or 5GXR application provider to indicate to the core network that certain WTRUs should be moved to the CM-CONNECTED state so that these WTRUs are ready to transmit or receive data. In other words, moving the WTRU to the CM-CONNECTED state will enable the WTRU to transmit or receive the data more quickly when the data becomes available.

[0238] This NEF API can be called Nnef_PendingData, and the API can allow the API caller (i.e., the 5GXR AS or 5GXR application provider) to provide the identity of the WTRUs that should be moved to the CM-CONNECTED state to the network and can allow the called API to provide a time window that indicates when the WTRUs should preferably be in the CM-CONNECTED state in the event that it is anticipated that they will need to transmit or receive data associated with the multimodal dataset.

[0239] This NEF API can also allow the caller to indicate the IP 5-tuple of the unimodal stream that will soon be activated. The network will use this information to determine which PDU session of the WTRU in the PDU session of the WTRU needs to be activated. Therefore, appropriate user plane resources will be activated in the event that a WTRU is anticipated to receive or transmit data for a multimodal set.

[0240] The NEF will query the BSF to determine the identity of the PCF serving the PDU session for carrying the single-mode flow. The NEF will forward the data notification to be processed to the PCF, and the PCF will forward the notification to the SMF. The SMF will send a message to the AMF to indicate that user plane resources need to be activated in case the expected WTRU needs to transmit or receive data.

[0241] The AMF can use the time window information to determine when to initiate a paging procedure (e.g., an information procedure) for the WTRU and how long to keep the WTRU in the CM-CONNECTED state after the WTRU responds to the paging by sending a service request message to the AMF.

[0242] When approaching the start time of the time window, the AMF can initiate a paging procedure with the RAN node. The paging procedure is initiated by the AMF by sending a paging message to the RAN node. As described in TS 23.502 "Procedures for the 5G System (5GS)" (V 17.3.0.), the paging message can include the NAS ID for paging the WTRU.

[0243] In response to receiving the paging message, the WTRU can send a service request message to the AMF, as described in TS 23.502. The AMF will respond to the service request by sending a NAS-MM service accept message to the WTRU. The service accept message can be defined in TS 24.501 "Non-Access Stratum (NAS) protocol for the 5G System (5GS); Phase 3" (V 17.5.0). The service accept message can be enhanced to indicate that the service request message was triggered because it is expected that the WTRU may need to transmit or receive data associated with a specific PDU session. For example, the service accept message can be enhanced to include a traffic expectation information element. The traffic expectation information element can be formatted like the PDU session status element defined in TS 24.501 and illustrated in Table 1 (which is copied from TS 24.501).

[0244]

[0245] Table 1: PDU session status information elements

[0246] The purpose of the traffic expectation information element can be to indicate for each PDU session whether the network anticipates traffic (e.g., but has not buffered downlink traffic yet). The PDU session inactivity / activity indication (PSI) in this information element can be used to indicate whether traffic is expected for each PDU session. Additionally, the service accept message can be enhanced to further include the time window within which activity is expected to occur within each PDU session.

[0247] When a WTRU receives an indication that traffic is expected within a certain PDU session, the WTRU may notify an application associated with that PDU session that uplink or downlink activity will soon occur. The MT part of the WTRU may notify the application located in the TE part of the WTRU via an AT command. This notification may help ensure that the application can respond quickly when the activity in the multimodal aggregation begins. The notification may include a time value derived from the time window information received in the service acceptance message.

[0248] When a WTRU receives an indication that traffic may be expected within a certain PDU session, the WTRU may notify other devices associated with that PDU session that uplink or downlink activity will soon occur. This notification may help ensure that the other devices can respond quickly when the activity in the multimodal aggregation begins. The other devices receiving the notification may be devices connected to the WTRU via a non-3GPP radio (such as Bluetooth). The notification method from the WTRU to the devices may be transmitted via a non-3GPP radio (such as a Bluetooth radio). The notification may include a time value derived from the time window information received in the service acceptance message. Figure 8 An example of this process is shown.

[0249] In Figure 8 In step 1, the SMF may receive information about expected flow traffic and use this information to determine that the traffic will soon be generated in the multimodal dataset and that the user plane resources associated with the single-modal data stream of the multimodal dataset should be activated. The information about expected flow traffic that the SMF may receive may be an indication triggered by the 5GXR AS in the case of expected traffic, or the information may be traffic pattern information configured by the 5GXR AF in the network.

[0250] In Figure 8 In step 2, the SMF may send a notification to the AMF to inform the AMF about the expected traffic. The AMF may transfer this notification to the AMF by invoking the Namf_Communication_N1N2MessageTransfer service.

[0251] Namf_Communication_N1N2MessageTransfer may be enhanced to indicate to the AMF that the notification is not triggered by the reception of a downlink but by the determination of expected traffic. The message may be further enhanced to include time information in order to inform the AMF when the traffic is expected, so that the AMF may be able to delay paging the WTRU until close to the start time of the expected traffic.

[0252] In Figure 8In step 3 thereof, the AMF may send a request to the RAN to page the WTRU (e.g., inform the WTRU), and the WTRU may be paged.

[0253] In Figure 8 In step 4 thereof, the WTRU may send a service request NAS-MM message to the AMF.

[0254] In Figure 8 In step 5 thereof, the AMF may send a service acceptance NAS-MM message to the WTRU. As described above, the service acceptance message may be enhanced to include a traffic anticipation information element, and the information in the traffic anticipation information element may be used by the WTRU to determine a notification of anticipated traffic to an application hosted in the TE part of the WTRU for a multimodal concentration.

[0255] In Figure 8 In step 6 thereof, the information in the traffic anticipation information element may also be used to trigger a notification or alert for an application hosted on other devices. The notification or alert may indicate an activity anticipated in the multimodal dataset, and the notification or alert may indicate the time when the traffic is anticipated. For example, the other device may be a device connected to the WTRU via a Bluetooth or WiFi connection. The other device may generate or receive data as part of the multimodal dataset, and the other device may route the data to and from the network via the PDU session of the WTRU.

[0256] In addition, the traffic anticipation information element may be sent to the WTRU in a registration acceptance message.

[0257] An example of synchronizing the initiation of a unimodal flow of a multimodal dataset when the WTRU is in a connection management connected state (CM-CONNECTED state) is described below.

[0258] In another example, the 5GXR AS or 5GXR application provider may detect that the WTRU will soon need to transmit or receive data for a unimodal flow from the multimodal set. The 5GXR AS or 5GXR application provider may provide the information to the network as described above, and the network may detect that the WTRU is in the CM-CONNECTED state.

[0259] As described above, the SMF may notify the AMF of the expected traffic. In one embodiment, the 5G system may be enhanced such that when the WTRU is in the CM-CONNECTED state and the AMF receives a notification of expected traffic for one of the PDU sessions in a PDU session for the WTRU, the AMF may transmit a NAS message to the WTRU to notify the WTRU of on which PDU session the expected traffic is expected. The NAS message may include a traffic expectation information element as described above. The WTRU may use the traffic expectation information element (e.g., to notify the application and the device of the expected traffic). The NAS message carrying the traffic expectation information element to the WTRU may be a NASDL TRANSPORT message. After receiving the traffic expectation notification, the WTRU may stay in the CM-CONNECTED state for a specified time.

[0260] An example of prioritizing unimodal streams of a multimodal dataset is described below.

[0261] As discussed above, the QoS framework of the 5G system may allow RAN nodes to be configured with alternative QoS templates for GBR QoS flows. The alternative QoS template may be provided by the SMF to the RAN node. If the RAN determines that it cannot meet the QoS template of the GBR QoS flow, the RAN node may apply one of the alternative QoS templates in the alternative QoS template for the GBR QoS flow and notify the SMF that the alternative QoS template is being applied.

[0262] When considering how the 5G system processes multimodal datasets, the alternative QoS template feature may be insufficient because this feature requires the RAN node to determine which flows should utilize the alternative QoS template. The RAN node may not be able to determine which flows are part of the same multimodal set and which flows have a lower priority and are less important for the multimodal set. This is especially true when we consider that the relative characteristics of the unimodal flows in a multimodal set are dynamic.

[0263] It is proposed to enhance the QoS framework of the 5G system such that the WTRU can be configured with alternative QoS rules. For example, the alternative QoS rules may be provided to the WTRU in a PDU session acceptance message or a PDU session modification complete message. At least one (e.g., each) alternative QoS rule information element in the alternative QoS rule information element may be formatted like a QoS rule information element. However, at least one (e.g., each) QoS rule information element in the QoS rule information element of the alternative QoS rule information element may also include a priority order or an index value. In response to the WTRU transmitting a PDU session establishment request with an XR session ID, the alternative QoS rules may be provided to the WTRU in a PDU session establishment acceptance message.

[0264] In addition, it is recommended to enhance the 5G system such that the 5G XR AF can convey a request to the network to adjust the QoS of the multi-modal set. The request can identify the multi-modal set by providing a combination of the WTRU identifier, S-NSSAI, and DNN. Alternatively, the request can explicitly identify the flow with the IP 5-tuple. The request can also indicate the priority or index value of the associated QoS rule / template that should be applied. This information can be forwarded to each SMF serving the PDU session of the indicated flow. The SMF can then convey a NAS-SM message (e.g., PDU session modification request) with the index or priority of the QoS template that should be applied. The WTRU can then apply a set of QoS rules from the alternative QoS rule information element instead of using the rules from the QoS rule information element. The SMF can also convey an N2 notification to the RAN node to indicate that the RAN node should apply the alternative QoS template.

[0265] Alternatively, the 5G XR application provider can use application layer messaging to indicate to the 5G XR-aware application that alternative QoS rules should be applied. The message can indicate the priority or index of the QoS rules. The 5G XR-aware application can provide the priority or index of the QoS rules to the 5G XR client.

[0266] Alternatively, the 5G XR AS can use application layer messaging to indicate to the 5G XR-aware application that alternative QoS rules should be applied. The message can indicate the priority or index of the QoS rules.

[0267] Alternatively, the XR engine can use internal configuration or policies to determine that alternative QoS rules can be applied. For example, the XR engine can determine which QoS rules should be applied based on the observed performance, round-trip time (RTT) measurements (e.g., performance measurement function), etc. The XR engine can also determine the QoS rules to be applied based on the type of packet being transmitted to the MT part of the WTRU for transmission. For example, the XR engine can determine that IP packets associated with an important part of a video frame should be associated with a first QoS rule (e.g., high priority), and IP packets associated with a less important part of the video frame should be associated with a second QoS rule (e.g., best effort). The XR engine can receive alternative QoS rules from the 5G XR application via the X6 interface, or the XR engine can receive alternative QoS rules from the 5G XR AF via the X5 interface. The rule can describe which marking should be applied to each type of packet. The rule can also indicate under which conditions the rule should be applied. An example of the condition under which the rule should be applied is the congestion level.

[0268] Examples of improved QoS differentiation are described below.

[0269] The XR engine may provide a QoS rule index or priority to the MT part of the WTRU, such that the MT can determine which QoS rule among the QoS rules is to be applied to a flow. The XR engine may provide the QoS rule index or priority on a per PDU session basis, such that the index is semi-static for that PDU session. Alternatively, the XR engine may provide the QoS rule index or priority on a per packet basis (e.g., provide an index to each packet that is transmitted by the XR engine for transmission), or the XR engine may provide the QoS rule index or priority only for packets that require a QoS rule from an alternative QoS rule information element.

[0270] The QoS framework may also be enhanced such that a QoS rule may instruct the WTRU that packets that are part of a certain QoS flow should be discarded by the WTRU and not transmitted to the RAN node. For example, a new QFI value may be allocated to indicate to the WTRU that packets of that flow may be discarded. This reserved QFI value will provide a mechanism for the 5G system to block non-essential flows by applying an alternative QoS template in the WTRU during congestion periods.

[0271] In an alternative approach, the URSP rule framework may be enhanced such that the traffic descriptor part of a URSP rule may include a traffic class differentiator index. The traffic class differentiator index may indicate the relative importance of a traffic flow and may be used by the URSP rule to map traffic from the same application flow to different PDU sessions. For example, packets from the same video stream may be assigned different traffic class differentiator indexes by the XR engine. Each packet and its associated traffic class differentiator index may be provided to the MT part of the WTRU. The traffic class differentiator index will be evaluated by the MT part of the WTRU during URSP evaluation, and the URSP rule may be configured such that packets from the same video stream may be transmitted via different PDU sessions. The network may configure different QoS rules for each PDU session. Continuing with the same example, each PDU session may be associated with a different DNN that maps to the same data network access identifier.

[0272] An example considering peer XR services is described below.

[0273] In one embodiment, although the WTRUs involved in a peer-to-peer session do not exchange user plane traffic with the 5G XR AF, these WTRUs may still request the 5G XR AF to provide them with an XR session ID. The WTRU initiating the session may transmit the request to the 5G XR AF via X5. The request from the WTRU may include a list of IDs of other WTRUs with which the WTRU wants to exchange XR traffic. This may trigger the 5G XR AF to start multi-modal data set creation by invoking the Nnef_MultiModalDataSet request mentioned above, and this may cause the AF to obtain a session identifier from the network (e.g., UDM), which can be used by the WTRU for peer-to-peer communication. The WTRU may provide XR service parameters (such as which traffic mode to use) to the 5G XR, and through the Nnef_MultiModalDataSet API, the 5G XR AF may provide QoS requirements for the peer-to-peer session.

[0274] As mentioned above, the WTRU may provide the XR session ID during a PDU session establishment request or a PDU session modification request. If the WTRU transmits the same XR session ID, the network may use this information to know that the resulting flows are associated. One way for the WTRU to agree on the session ID may be to exchange the ID via a D2D link such as PC5.

[0275] In another embodiment, in addition to providing the XR session ID, the WTRU may also be configured with a group ID that can be obtained from the WTRU SIM. This group ID can become part of the WTRU subscription in this way. The XR application may request the network to change the group ID parameters of certain WTRUs. Thus, different peer groups using the same XR session ID can also be uniquely identified by the group ID and session ID they provide during PDU session establishment.

[0276] Compared with the client-server architecture, the requirements of the peer-to-peer method may be different. For example, in terms of latency requirements, the latency from one WTRU to another WTRU may cover the uplink leg from the transmitting WTRU (e.g., WTRU1) to the anchor UPF, and the downlink leg from the anchor UPF to the anchor of the receiving WTRU (e.g., WTRU2) and then to the receiving WTRU. Therefore, in order to meet the latency requirements in one direction, the network may need to apply latency requirements to both WTRUs. For example, apply PDB1 to the WTRU1 QoS flow1 uplink and PDB2 to the WTRU2 QoS flow2 downlink.

[0277] The GBR for the traffic exchange between the WTRU1 and the WTRU2 in one direction can be the minimum of the GBRs of the above QoS flow1 and QoS flow2. Therefore, the network may need to know how to map the service data flow (SDF) from the peer traffic to the appropriate QoS flows for the two WTRUs.

[0278] In one embodiment, for each WTRU, multiple values of QoS parameters (PDB, PER, GBR, etc.) can be provided to the PCF according to the QoS flow (e.g., for the PDB parameter, the PCF can receive PDB1 within {5ms, 15ms, 20ms} and receive PDB2 within {10ms, 15ms, 30ms}). When the application QoS requirements of the XR service can be provided to the network (if the application knows that this is a peer - type scenario, the application can know that this is a dual - branch requirement), the PCF can select the best QoS pair (one QoS for each branch) to meet the requirements. For example, for the 30ms latency requirement of the peer XR service, the PCF can select (15ms, 15ms) or can also select (20ms, 10ms) as the appropriate values for PDB1 and PDB2.

[0279] During the XR session, if the PDB in one branch changes, or the QoS parameters change, the PCF can re - evaluate the QoS flows involved to ensure a successful combination. In the PCC rule, there may be an indication of QoS parameters (GBR, PDB), a session identifier for identifying the XR session, a dual - branch PDB or latency requirement, and a list of WTRUs (e.g., WTRU2) that can exchange peer XR traffic within this session.

[0280] If the QoS parameters of the first QoS flow involved in the peer XR session change, the SMF / PCF can check whether there are dual - branch requirements, and if there are such requirements, check which other WTRUs (e.g., WTRU ID list) may be involved in this session. Then, the PCF may need to check the PCC rules of the QFIs of the other WTRUs involved in this session and re - evaluate.

[0281] Figure 9Depicts an example of a method 900 for establishing a multimodal data stream implemented in a WTRU. The method 900 may include a step in which the WTRU may receive 910 a first message including information, the information including a session identifier of a session associated with a data stream of at least one other WTRU. The method 900 may include another step in which the WTRU may send 920 a packet data unit session establishment request including a second message to a network node, the second message including the session identifier; and the method 900 may include a step in which the WTRU may receive 930 from the network node a PDU session establishment acceptance message, the PDU session establishment acceptance message indicating the quality of service rules that the WTRU applies to traffic associated with the PDU session.

[0282] Figure 10 Depicts an example of a method 1000 for establishing a multimodal data stream implemented in a network node. The method 1000 may include a step in which the network node may receive 1010 from a WTRU a packet data unit session establishment request including a session identifier. The method 1000 may further include a step in which the network node may determine 1020, based on the session identifier, the quality of service rules that the WTRU applies to traffic associated with the PDU session. The method 1000 may further include a step in which the network node may send 1030 to the WTRU a PDU session establishment acceptance message, the PDU session establishment acceptance message indicating the quality of service rules that the WTRU applies to traffic associated with the PDU session.

[0283] Although the features and elements are provided above in specific combinations, those of ordinary skill in the art will understand that each feature or element may be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this patent application, which are intended to be illustrative of various aspects. Many modifications and variations may be made without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. Unless expressly provided otherwise, any element, act, or statement used in the specification of this application should not be construed as critical or essential to the invention. Functional equivalent methods and apparatuses within the scope of the present disclosure, other than those enumerated herein, will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full scope of equivalents of such claims entitled thereto. It should be understood that the present disclosure is not limited to a particular method or system.

[0284] For simplicity, the foregoing embodiments have been discussed in terms of and with structures for infrared-capable devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but are applicable to other systems that use other forms of electromagnetic or non-electromagnetic waves (such as acoustic waves).

[0285] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or multiple images displayed on a time basis. Also, as used herein, when referred to, the term "user equipment" and its abbreviation "UE", the term "remote", and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of a plurality of embodiments of the WTRU; (iii) a device having wireless capabilities and / or having wired capabilities (e.g., tetherable) configured with some or all of the structures and functions of the WTRU, in particular; (iii) a device having wireless capabilities and / or having wired capabilities configured with less than all of the structures and functions of the WTRU; or (iv) the like. Details of an example WTRU that may represent any WTRU described herein are provided. Also, various disclosed embodiments herein are described above and below as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than a head-mounted display may be utilized and that some or all of the present disclosure and the various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an augmented reality experience. Figures 1A to 1D In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or a processor. Examples of computer-readable media include electronic signals (sent via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0286]

[0287] ​Variations of the methods, apparatuses, and systems provided above are possible without departing from the scope of the present invention. Given the various embodiments that are applicable, it should be understood that the illustrated embodiments are merely examples and should not be regarded as limiting the scope of the following claims. For example, the embodiments provided herein include a handheld device that may include any suitable voltage source (such as a battery, etc.) that provides any suitable voltage or is used in conjunction with such a voltage source.

[0288] In addition, in the embodiments provided above, a processing platform, a computing system, a controller, and other devices including a processor are pointed out. These devices may include at least one central processing unit (“CPU”) and a memory. In accordance with the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions may be executed by various CPUs and memories. Such actions and operations or instructions may be referred to as being “executed,” “computer-executed,” or “CPU-executed.”

[0289] Those of ordinary skill in the art will know that actions and operations or instructions in symbolic representation include the manipulation of electrical signals by a CPU. The electrical system represents data bits, which may result in the ultimate transformation or reduction of electrical signals and the retention of data bits at memory locations in a memory system, thereby reconfiguring or otherwise altering the operation of the CPU and performing other processing of signals. The memory locations that hold data bits are physical locations having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the above platforms or CPUs, and other platforms and CPUs may also support the provided methods.

[0290] Data bits may also be held on a computer-readable medium, which includes magnetic disks, optical disks, and any other volatile (e.g., random access memory (“RAM”)) or non-volatile (e.g., read-only memory (“ROM”)) mass storage systems readable by a CPU. The computer-readable medium may include cooperative or interconnected computer-readable media that exist uniquely on a processing system or are distributed among multiple interconnected processing systems, which may be local or remote with respect to the processing system. It should be understood that the embodiments are not limited to the above memories, and other platforms and memories may also support the provided methods.

[0291] In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0292] There is little difference between the hardware implementation and the software implementation in various aspects of the system. The use of hardware or software is generally (but not always, as in some contexts, the choice between hardware and software may become important) a design choice representing a trade-off between cost and efficiency. There may be various media (e.g., hardware, software, and / or firmware) that can implement the processes and / or systems and / or other technologies described herein, and the preferred medium may vary with the context of the deployment process and / or system and / or other technology. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a medium that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0293] The foregoing detailed description has set forth various embodiments of the devices and / or processes by use of block diagrams, flowcharts, and / or examples. In cases where such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented, individually and / or jointly, by a wide range of hardware, software, firmware, or virtually any combination thereof. In one embodiment, several parts of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may be equivalently implemented, in whole or in part, as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing the circuitry and / or writing the code for the software and / or firmware would be well within the skill of those in the art in light of this disclosure. Additionally, those skilled in the art will know that the mechanisms of the subject matter described herein can be distributed in a variety of forms as a program product, and that illustrative embodiments of the subject matter described herein apply regardless of the particular type of signal bearing medium used to actually effect such distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media (such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memories, etc.); and transmission type media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0294] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein and then use engineering practices to integrate such described devices and / or processes into a data processing system. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system via a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally may include one or more of the following: a system unit housing; a video display device; memory, such as volatile memory and non-volatile memory; processors, such as microprocessors and digital signal processors; computing entities, such as operating systems, drivers, graphical user interfaces, and application programs; one or more interaction devices, such as touchpads or screens; and / or control systems, including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or amounts). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0295] The subject matter described herein sometimes illustrates different components included within or connected to different other components. It should be understood that such depicted architectures are merely examples and that in fact many other architectures can be implemented that achieve the same functionality. In a conceptual sense, any arrangement of components that achieves the same functionality is effectively "associated" such that the desired functionality can be achieved. Thus, any two components that are combined herein to achieve a particular function can be considered to be "associated" with each other such that the required function is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered to be "operably connected" or "operably coupled" to each other to achieve the desired function, and any two components that can be so associated can also be considered to be "operably coupleable" to each other to achieve the desired function. Specific examples of operably coupleable include, but are not limited to, components that can physically mate and / or physically interact and / or components that can wirelessly interact and / or wirelessly communicate and / or components that can logically interact and / or can logically communicate.

[0296] Regarding substantially any plural and / or singular terms used herein, those skilled in the art can appropriately convert from plural to singular and / or from singular to plural according to the context and / or application. For clarity, various singular / plural permutations may be explicitly set forth herein.

[0297] Those skilled in the art should understand that, generally speaking, the terms used in this text, especially in the appended claims (e.g., the subject matter of the appended claims), are usually intended to be "open-ended" terms (e.g., the term "comprising" should be interpreted as "comprising but not limited to", the term "having" should be interpreted as "having at least", the term "containing" should be interpreted as "containing but not limited to", etc.). Those skilled in the art should also understand that if the intention is to specify a particular number of introduced claim recitation objects, such intention will be explicitly recited in the claims, and in the absence of such recitation objects, there is no such intention. For example, in cases where only one item is contemplated, the term "single" or similar language may be used. To facilitate understanding, the appended claims and / or the description herein below may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitation objects. However, the use of such phrases should not be construed as implying that any particular claim including such introduced claim recitation objects is limited to an embodiment including only one such recitation object by the indefinite article "a" or "an" introducing the claim recitation object. This is the case even when the same claim includes the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). This also applies to the use of the definite article for introducing claim recitation objects. In addition, even when a particular number of introduced claim recitation objects are explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the stated number (e.g., in the absence of other modifiers, the bare recitation of "two recitation objects" means at least two recitation objects or two or more recitation objects). Additionally, in those instances where a convention similar to "at least one of A, B, and C, etc." is used, generally speaking, the meaning of such construction is that those skilled in the art will understand the convention (e.g., "a system having at least one of A, B, and C" will include but not be limited to a system having A alone, having B alone, having C alone, having A and B simultaneously, having A and C simultaneously, having B and C simultaneously, and / or having A, B, and C simultaneously, etc.). In those instances where a convention similar to "at least one of A, B, or C, etc." is used, generally speaking, the meaning of such construction is that those skilled in the art will understand the convention (e.g., "a system having at least one of A, B, or C" will include but not be limited to a system having A alone, having B alone, having C alone, having A and B simultaneously, having A and C simultaneously, having B and C simultaneously, and / or having A, B, and C simultaneously, etc.). Those skilled in the art should also understand that in fact, regardless of whether in the specification, the claims, or the drawings, any separate words and / or phrases presenting two or more alternative terms should be understood to contemplate the possibility of including one of the terms, any one of the terms, or both of the terms.For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B". Additionally, as used herein, the term "any of" followed by a listing of multiple items and / or multiple item categories is intended to include the item and / or item category "any of", "any combination of", "any multiple of", and / or "any combination of multiples of" individually or in combination with other items and / or other item categories. Further, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "quantity" is intended to include any number, including zero. And, as used herein, the term "plurality" is intended to be synonymous with "a plurality of".

[0298] Moreover, in instances where the features or aspects of the present disclosure are described in terms of a Markush group, those skilled in the art will recognize that the present disclosure is also described in terms of any individual member of the Markush group or a subgroup of the members.

[0299] As those skilled in the art will understand, for any and all purposes (such as for providing a written description), all ranges disclosed herein also cover any and all possible subranges and combinations of their subranges. Any listed range can be readily recognized as fully describing and enabling the same range to be divided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be readily divided into a lower third, a middle third, an upper third, etc. As those skilled in the art will also understand, all language such as "up to", "at least", "greater than", "less than", etc. includes the recited number and refers to a range that can subsequently be divided into subranges as described above. Finally, as those skilled in the art will understand, a range includes each individual number. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to a group having 1, 2, 3, 4, or 5 units, etc.

[0300] Furthermore, unless otherwise specified, the claims should not be construed as limited to the order or elements provided. Additionally, the use of the term "means for" in any claim is intended to invoke 35 U.S.C.§112, 6 or the means-plus-function claim format, and any claim without the term "means for" is not intended to be so.

Claims

1. A method implemented in a network node, the method comprises: receiving a first message comprising first information, the first information comprising service requirements of a data stream and an indication that the data stream is associated with a multimodal data set; determining, based on the indication that the data stream is associated with a multimodal data set, a policy and charging control (PCC) rule for a packet data unit (PDU) session of the data stream; and sending a second message comprising information indicating the PCC rule associated with the data stream.

2. The method according to claim 1, the method comprises: determining, based on the indication that the data stream is associated with a multimodal data set, a data network name / single network slice selection assistance information (DNN / S-NSSAI) combination associated with the multimodal data set; and sending a third message comprising information indicating a user equipment routing selection policy (URSP) rule to a radio transmit / receive unit (WTRU); wherein the URSP rule comprises the DNN / S-NSSAI combination, and wherein the WTRU is associated with at least one stream of the multimodal data set.

3. The method according to claim 1, wherein at least one other data stream is part of the multimodal data set.

4. The method according to claim 3, wherein the data stream is associated with a first WTRU, and the at least one other data stream of the multimodal data set is associated with a second WTRU; wherein the first WTRU and the second WTRU are different.

5. The method according to claim 1, wherein the indication that the data stream is associated with a multimodal data set is a multimodal data set identifier.

6. The method according to claim 1, wherein the second message is sent to a session management function (SMF) network element.

7. The method according to claim 1, wherein the first message is received from an application function (AF).

8. The method according to claim 7, wherein the first message is received from the AF via a network exposure function (NEF).

9. The method according to claim 1, wherein the network node is a policy control function (PCF) network element.

10. A network node, the network node comprising a processor, a transceiver unit and a storage unit, and being configured to: receive a first message comprising first information, the first information comprising service requirements of a data stream and an indication that the data stream is associated with a multimodal data set; determine, based on the indication that the data stream is associated with a multimodal data set, a policy and charging control (PCC) rule for a packet data unit (PDU) session of the data stream; and send a second message comprising information indicating the PCC rule associated with the data stream.

11. The network node according to claim 10, the network node being configured to: Determine a data network name / single network slice selection assistance information (DNN / S-NSSAI) combination associated with the multimodal data set based on the indication that the data stream is associated with the multimodal data set; and Send a third message including information indicating a user equipment routing selection policy (URSP) rule to a wireless transmit / receive unit (WTRU); wherein the URSP rule includes the DNN / S-NSSAI combination, and wherein the WTRU is associated with at least one stream of the multimodal data set.

12. The network node according to claim 10, wherein at least one other data stream is part of the multimodal data set.

13. The network node according to claim 12, wherein the data stream is associated with a first WTRU, and the at least one other data stream of the multimodal data set is associated with a second WTRU; wherein the first WTRU and the second WTRU are different.

14. The network node according to claim 10, wherein the indication that the data stream is associated with the multimodal data set is a multimodal data set identifier.

15. The network node according to claim 10, wherein the second message is sent to a session management function (SMF) network element.

16. The network node according to claim 10, wherein the first message is received from an application function (AF).

17. The network node according to claim 16, wherein the first message is received from the AF via a network exposure function (NEF).

18. The network node according to claim 10, wherein the network node is a policy control function (PCF) network element.

Images