Synchronization of multi-modal streams

Abstract

A device for synchronizing a multi-modal flow may receive synchronization information associated with a protocol data unit (PDU) session. The synchronization information may indicate a first flow classifier, a second flow classifier, and a synchronization threshold. A first data stream may be determined based on the first stream classifier. A second data stream may be determined based on the second stream classifier. The first data stream and the second data stream may be associated with the PDU session. A synchronization measurement may be determined based on the synchronization information. The synchronization measurement indicates a synchronization value indicating synchronization between the first data stream and the second data stream. The device may determine that the first data stream and the second data stream are asynchronous based on the synchronization measurement.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 324,432 filed on March 28, 2022 and U.S. Provisional Patent Application No. 63 / 435,422 filed on December 27, 2022, the contents of which are hereby incorporated herein by reference. Background Art

[0003] Mobile communications using wireless communications continue to evolve. The fifth generation of mobile communications radio access technology (RAT) may be referred to as 5G New Radio (NR). The previous generation (legacy) mobile communications RAT may be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the invention

[0004] Disclosed herein are systems, methods, and tools for synchronizing multimodal streams. A device (e.g., a wireless transmit / receive unit (WTRU)) may receive synchronization information associated with a protocol data unit (PDU) session. The synchronization information may indicate a first stream classifier, a second stream classifier, and a synchronization threshold. The device may determine a first data stream based on the first stream classifier and determine a second data stream based on the second stream classifier. The first data stream and the second data stream may be associated with the PDU session. The device may determine a synchronization measurement based on the synchronization information. The synchronization measurement may indicate a synchronization value indicating synchronization between the first data stream and the second data stream. The device may determine that the first data stream and the second data stream are asynchronous based on the synchronization measurement being at or above the synchronization threshold. The device may transmit a message to a network node indicating that the first data stream and the second data stream are asynchronous.

[0005] The synchronization value may be based at least in part on a time duration between a first time value associated with the first data stream and a second time value associated with the second data stream. The synchronization value may be based at least in part on a time difference. The device may determine a first time value associated with the arrival of data of the first data stream and a second time value associated with the arrival of data of the second data stream, and determine the time difference using the first time value and the second time value. The time difference may indicate a time duration between the first time value and the second time value.

[0006] The message may indicate a time difference, wherein the time difference is used to synchronize the first data stream and the second data stream. The message may indicate a request to synchronize the first data stream and the second data stream based on the time difference. The message may indicate a request to synchronize the first data stream and the second data stream. The message may be a non-access stratum session management (NAS-SM) message, and wherein the network node is a session management function (SMF).

[0007] The first stream classifier may include a packet filter. Determining the first data stream based on the first stream classifier may involve the device determining that multiple PDU sets are associated with the data type based on the packet filter. The first data stream may include multiple PDU sets. The first stream classifier may include a stream identifier. Determining the first data stream based on the first stream classifier may involve the device determining that the multiple PDU sets include an indication of the stream identifier. The first data stream may include multiple PDU sets. The indication of the stream identifier may be included in the headers of the multiple PDU sets.

[0008] The WTRU and / or the user plane function (UPF) may transmit a synchronization status message to the network function and / or the application server. The WTRU and / or the UPF may add information to the header of the protocol data unit (PDU). For example, information may be added to the header so that another WTRU and / or the UPF may detect which PDU sets are to be synchronized (e.g., need to be synchronized). The network function and / or the application server may use this information to improve the overall quality of experience of the WTRU and other WTRUs that are part of the same multimodal data set. For example, the WTRU, the application function (AF), or the UPF may provide synchronization functionality. The synchronization functionality may include calculating the degree to which a stream is synchronized or not synchronized, and determining how much to delay one or more streams so that the degree to which the stream is synchronized is within a synchronization threshold. Synchronization correction may be applied to correct jitter problems in the stream. The network layer synchronization and jitter improvement process may be used to enhance the application layer protocol, and the application layer protocol may be used to correct synchronization and jitter problems. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0010] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system.

[0011] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within the illustrated communication system.

[0012] Figure 1D is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of yet another example RAN and yet another example CN for use within the illustrated communication system.

[0013] Figure 2 Examples of protocol data unit (PDU) sets and PDU set flows are shown.

[0014] Figure 3 An example of a set of PDUs in a synchronization group is shown.

[0015] Figure 4 An example of a PDU header is shown.

[0016] Figure 5 An example of synchronization status notification based on non-access stratum (NAS) is shown.

[0017] Figure 6 An example of synchronization status notification based on X5 is shown.

[0018] Figure 7 An example of synchronization at a user plane function (UPF) via delay provided by a session management function (SMF) is shown.

[0019] Figure 8 An example of synchronization at the UPF via the delay provided by the SMF is shown. DETAILED DESCRIPTION

[0020] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through 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 unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0021] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, 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 WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include 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, 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, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0022] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0023] The base station 114a may be part of the 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. The base station 114a and / or the base station 114b may be configured to send 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 a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrums. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

[0024] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

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

[0026] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA) that may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-APro).

[0027] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using New Radio (NR).

[0028] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, for example using 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 transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0029] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), 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), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0030] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another 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 a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0031] The RAN 104 / 113 may be in communication 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, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not described in detail in the text, the CN 106 / 115 may be 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, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Figure 1A Although not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0034] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0035] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of 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 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0039] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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, and the like. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0041] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0042] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, 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. Peripheral device 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 geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0043] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (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 via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0044] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0045] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over 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 and / or receive wireless signals from the WTRU 102a.

[0046] Each of the evolved Node Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0047] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being 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.

[0048] The MME 162 may be connected to each of the evolved Node-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve 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 particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

[0050] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0051] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

[0052] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

[0053] In a representative embodiment, the other network 112 may be a WLAN.

[0054] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STA) 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 carries traffic away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the destination STA (e.g., directly between them) using a direct link establishment (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

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

[0056] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0057] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 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 by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be sent by sending STA. At the receiver of the receiving STA, the above-mentioned operation for 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0058] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

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

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

[0061] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 in accordance with an embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0062] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over 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 send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to 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 an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0063] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths over time).

[0064] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

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

[0066] 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 possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the 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.

[0067] 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 WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching 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 WiFi.

[0068] 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 implementation and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0069] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

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

[0071] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0072] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may 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 in order to test other devices within the communication network. One or more simulation devices may 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 may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0073] 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 scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which may include one or more antennas) can be used by the simulation device to send and / or receive data.

[0074] References to timers herein may refer to a time, a time period, time tracking, time period tracking, combinations thereof, and / or the like. References to expiration of a timer herein may refer to determining that a time has occurred or a time period has expired.

[0075] A protocol data unit (PDU) set may include one or more PDUs (e.g., frames and / or video slices for an extended reality media (XRM) service) carrying a payload of an information unit (e.g., a unit) generated at the application layer, which may be used at the application layer. The application layer may use the PDUs (e.g., all PDUs) in the PDU set (e.g., required) to use the corresponding information unit. In an example, if one or more PDUs are lost, the application layer may recover portions of the information unit.

[0076] A multimodal synchronization threshold may be defined as the maximum tolerable time interval between the onset of stimuli (e.g., two stimuli), one of which is presented to one sense and the other to another sense, such that the accompanying sensory objects are perceived as being synchronized. A synchronization threshold may be described as the maximum tolerable time interval between the transmission or reception of a stream (e.g., two streams). For example, if the time interval between the transmission or reception of a stream is greater than the synchronization threshold, the stream may be described as being asynchronous, asynchronous, or asynchronous. Similarly, if the time interval between the transmission or reception of a stream is less than the synchronization threshold, the stream may be described as being synchronous or synchronous.

[0077] As described with respect to PDU sets, the information unit may be an application layer information unit.The terms "information unit" and "application layer information unit" are used interchangeably herein.

[0078] The terms "application server" and "application function" are used interchangeably herein.

[0079] This article uses the following acronyms:

[0080]

[0081]

[0082] Multimodal data may be provided. Multimodal data may be input data from different devices and / or sensors, or output data to different destinations (e.g., one or more WTRUs) used (e.g., required) for the same task and / or application. Multimodal data may include multiple unimodal data, and dependencies may exist between unimodal data (e.g., each unimodal data). Unimodal data may be considered as one type of data.

[0083] A device and / or sensor that generates (e.g., transmits) unimodal data may be a WTRU or may use a WTRU to transmit unimodal data to a network. The unimodal data may be transmitted to applications hosted on other WTRUs and / or applications hosted on network servers.

[0084] The device and / or sensor receiving the unimodal data may be a WTRU or may use a WTRU to receive the unimodal data from the network. The unimodal data may be received from applications hosted on other WTRUs and / or applications hosted on a network server.

[0085] As described herein, unimodal data may be a data stream to and / or from a WTRU, and multimodal data may include multiple data streams to and / or from multiple WTRUs.

[0086] A multimodal data set may be a collection of unimodal data flows for a task and / or application (e.g., the same task and / or application). For example, a multimodal data set may be a collection of a set of Internet Protocol (IP) flows and / or QoS flows between multiple WTRUs and an application server (e.g., a single application server). For example, an IP flow may carry sensor data, video information, tactile data, audio data, etc.

[0087] A QoS framework may be provided. A QoS model may be based on QoS flows. A QoS flow may be associated with QoS characteristics (e.g., requirements) specified by one or more QoS parameters and / or one or more QoS characteristics. A QoS flow may be the granularity of QoS differentiation in a PDU session (e.g., the finest granularity of QoS differentiation). A QoS flow ID (QFI) may be used to identify QoS flows in a system. User plane services with a QFI (e.g., the same QFI) within a PDU session may receive the same service forwarding treatment (e.g., scheduling and / or admission thresholds). The QFI may be carried in an encapsulation header on N3 (e.g., and / or N9), for example, without changes (e.g., any changes) to an end-to-end (E2E) packet header.

[0088] QoS flows may be controlled by the SMF and may be pre-configured and / or established via a PDU session establishment procedure or a PDU session modification procedure.

[0089] The QoS flow may be characterized by one or more of a QoS profile, a QoS rule, and an N4 rule. The QoS profile, the QoS rule, and the N4 rule may indicate a QoS flow priority, a QoS class identifier (e.g., a QoS parameter), an UL PDR, and a DL PDR. The QoS flow may be controlled by the SMF. The QoS flow may be preconfigured. The QoS flow may be established via a PDU session establishment procedure, a PDU session modification procedure, and the like. The QoS flow may be characterized by a QoS profile. For example, the SMF may provide the QoS profile to the AN via the N2 reference point. For example, the QoS profile may be preconfigured in the AN. One or more of the QoS rules, the QoS flow priority, and the QoS class identifier may be provided to the WTRU by the SMF, for example, via the AMF via the N1 reference point. The WTRU may derive one or more of the QoS rules, the QoS flow priority, and the QoS class identifier, for example, by applying reflective QoS control. The SMF may provide the UPF with an N4 rule indicating the UL PDR and DL PDR associated with the QoS flow.

[0090] In an embodiment, a QoS flow may be characterized by a QoS profile provided by the SMF to an access network (AN) via the AMF over the N2 reference point or pre-configured in the AN by one or more QoS rules, by (e.g., optionally by) one or more QoS flow level QoS parameters associated with the QoS rules, any of which may be provided by the SMF to the WTRU via the AMF over the N1 reference point and / or derived by the WTRU through application of reflective QoS control and one or more uplink (UL) and downlink (DL) packet detection rules (PDRs) provided by the SMF to a user plane function (UPF).

[0091] Supporting haptic and / or multimodal communication services may provide for a number of multimodal use cases where an application utilizes (eg, requires) the transmission of multiple unimodal data streams (eg, audio, video, and / or haptics) to be simultaneously broadcast to a user.

[0092] In an example, synchronization may be used (e.g., required). For example, a user may consume a multi-sensory application experience using multiple independent devices (e.g., WTRUs). In this case, multimodal streams may be distributed between devices (e.g., a video stream played on a TV, an audio stream played on a sound system, etc.). For example, multiple users may consume the same media (e.g., a group of users watching a football game together while talking to them on a call), and the media may be presented (e.g., simultaneously) to the users in the group (e.g., all users). For example, multiple players may participate in a gaming session with extended reality (XR) content that may be shared.

[0093] In the examples described herein, multiple time-dependent streams may be distributed in a distributed WTRU. The time difference between the streams (e.g., even a small time difference) may affect the user experience (e.g., audio plays later than video). The time difference may cause one or more users to consume the media before other users. It may take time for the later users (e.g., consuming the media after other users) to catch up with the other users.

[0094] An XR application (e.g., a single XR application) may use (e.g., require) a set of unimodal data streams (e.g., audio, video, and / or haptics) for simultaneous delivery and playback to a user. In this case, data from a multimodal stream may be delivered in a time window for presentation to the user (e.g., simultaneously). Failure to do so may degrade the quality of experience (QoE) of the application. A multimodal application experience may include streams with varying modes and / or types of data (e.g., audio, video, and / or haptics), and the modes and / or types of data (e.g., each mode and / or type) may impose varying requirements (e.g., synchronization and / or latency) on transmission.

[0095] In order to present multimodal data to the user simultaneously, interrelated (e.g., temporal) data may be delivered to the distributed WTRU synchronously. The synchronization threshold of the multimodal stream may specify the permissible time interval between the start of two stimuli (e.g., visual, audio, and / or tactile). Failure to meet the synchronization threshold may cause the user to perceive the multimodal media as being out of sync. Different modalities (e.g., streams) may have different data rates (e.g., packet rates) and / or decoding rates. For example, streams carrying video, audio, and / or tactile feedback may have different data rates and / or decoding rates. In an example, the network conditions under which the streams (e.g., each stream) are transmitted may cause the streams to arrive at the destination (e.g., WTRU) at different times, resulting in asynchronous delivery (e.g., asynchronous delivery and / or asynchronous delivery), asynchronous playback (e.g., media such as audio and video may be played in an asynchronous manner), and / or increased buffering. The buffering capacity of the WTRU may constrain the extent to which the WTRU can synchronize data streams.

[0096] In an example where the arrival time of a stream exceeds a synchronization threshold (e.g., the streams are considered asynchronous), the system may be able to change the way one or more of the streams are processed by the network to bring the streams within the synchronization threshold. The system may support features that allow the system to be notified that one or more streams have exceeded the synchronization threshold. For example, the system may be notified that one or more streams are asynchronous. In the system, the application layer may be able to detect that the stream is not synchronized and take application layer actions to synchronize the stream (e.g., reduce the frame rate and / or codec settings). If the system is able to take actions to bring the stream within the synchronization threshold, the application layer may be able to avoid taking actions that may reduce QoE (e.g., such as reducing the frame rate and / or using less desirable codec settings). If notified of a synchronization problem (e.g., the stream is asynchronous), the system may make adjustments (e.g., allocate more resources) so that no action at the application layer (e.g., frame rate reduction) needs to be taken. Allowing the system to make adjustments to promote synchronization can lead to more efficient use of network resources because the network can be configured to allocate enough resources (e.g., only enough resources) to provide a service level used (e.g., required) by the application. The network may ensure that participants (e.g., all participants) in an extended reality and media (XRM) service receive data at the appropriate time and that no participant can gain an advantage by receiving data before other participants (e.g., in a gaming scenario). The system may be configured such that it can obtain synchronization related information (e.g., from a WTRU and / or network function) and use this information to determine how to allocate resources to flows and help improve synchronization of flows (e.g., asynchronous flows may be resolved), which may help the WTRU avoid buffer underflow and / or overflow conditions.

[0097] In the case where the multimodal streams are within the synchronization threshold (e.g., meeting the synchronization requirement and / or preventing the streams from becoming asynchronous), the system may not support features that allow the system to be notified that the streams meet the synchronization threshold. If the system is notified that the streams meet the synchronization threshold (e.g., the streams are not asynchronous), the system may redistribute resources among the streams such that the resources are distributed among the streams depending on their usage (e.g., freeing resources not used by some streams and allocating resources to other streams that need more). The system may be configured to receive notifications about synchronized streams and (e.g., based on the notifications) redistribute resources among the streams.

[0098] The WTRU and / or UPF may transmit a synchronization status message to the network function and / or application server. The synchronization status message may indicate whether one or more flows are synchronous or asynchronous.

[0099] The WTRU and / or UPF may add information in the header of the PDU (eg, so that other WTRUs or UPFs can detect which sets of PDUs are synchronized).

[0100] The network function and / or application server may use this information to improve the quality of experience of the WTRU and other WTRUs that are part of the same multimodal data set. For example, the WTRU, AF and / or UPF may provide synchronization functionality. The synchronization functionality may include calculating the degree to which flows are synchronized or not synchronized. The synchronization functionality may include determining how much to delay one or more flows to increase the degree to which the flows are synchronized (e.g., to reduce the time interval between flows, e.g., to bring the degree to which the flows are synchronized within a synchronization threshold).

[0101] The concepts for synchronization correction can be applied to correct jitter problems in a flow.The network layer synchronization and / or jitter improvement process described herein can be used to enhance an application layer protocol that can be used to correct synchronization and / or jitter problems.

[0102] XR (e.g., 5GXR) applications and XR session handlers may be examples of WTRU hosted applications. The functionality described herein residing in a WTRU hosted application may reside in a layer between the PDU layer and the application layer or in the Service Data Adaptation Protocol (SDAP) layer.

[0103] A PDU may be associated with a PDU set. As described herein, a PDU set may include one or more PDUs. One or more PDUs may carry a payload of a unit (e.g., a unit) of information generated at the application layer (e.g., a frame or video slice for an XRM service). One or more PDUs may be and / or may have the same or similar priority (e.g., importance requirement) at the application layer.

[0104] Figure 2An example of a PDU set having N PDUs is illustrated. The PDUs (eg, each PDU) in the PDU set may be associated with a PDU header. Figure 2 Examples of PDU sets and PDU set flows are shown. Figure 2 As shown, a PDU set associated with information units of the same type may be referred to as a PDU set flow.

[0105] Figure 3 An example of a PDU set in a synchronization group is shown below. Figure 3 As shown, three PDU streams may (e.g., may need to) be synchronized and may be associated with the same synchronization group identifier. In an example, a PDU stream (e.g., one PDU stream) may carry audio data, a PDU stream (e.g., one PDU stream) may carry video data, and a PDU stream (e.g., one PDU stream) may carry haptic data (e.g., haptic feedback). PDU streams (e.g., all PDU streams, e.g., one PDU stream) may be sent and received via the same or different PDU sessions. Figure 3 The three PDUs shown in the figure collect current. Figure 3 As shown, a PDU set may be identified by a PDU set identifier, and the PDU set identifier may be (eg, may need to be) unique within a PDU set flow.

[0106] In some examples, the PDU header may be populated in the uplink. Figure 4 An example of a PDU header is shown.

[0107] The header may include a PDU set identifier such as Figure 4 As shown. The PDU set identifier may be a number that is unique within a PDU session. The WTRU may utilize the PDU set identifier to populate the PDU header in the uplink. The WTRU may use PDU set association and processing rules to determine which PDU set identifier should be associated with the information unit. The PDU set identifier may be incremented when (e.g., each time) a PDU set is sent in a stream and may have a defined modulo count. For example, if three bits are allocated to represent the PDU set identifier, the PDU sets may be numbered 0, 1, 2, 3, 4, 5, 6, 7, 0, 1, etc. Assigning PDU set identifiers in this manner may help the WTRU and UPF detect discarded packets.

[0108] The PDU set association and processing rules may be received by the WTRU in a NAS-SM message (e.g., a PDU session establishment accept message or a PDU session modification command) from an SMF that serves a PDU session associated with an application that generates an information unit. The PDU set association and processing rules may include a packet filter and / or a PDU set flow identifier (e.g., a flow classifier). For example, a first data flow may be determined based on a first flow classifier, and a second data flow may be determined based on a second flow classifier. The WTRU may compare the information unit to the packet filter, and if the WTRU determines that the information unit matches the packet filter, the WTRU may associate the information unit with the PDU set flow identifier (e.g., associate the information unit with the PDU set association and processing rules). The information unit may be assigned to a PDU set, and the header of the PDU in the PDU set may include the determined PDU set flow identifier.

[0109] The packet filters compared to the application layer information elements may be based on the IP 5-tuple or application layer traffic descriptors (eg, such as I-frames, P-frames, etc.).

[0110] The PDU in the PDU set may include header information indicating the sequence of the PDUs in the PDU set. For example, the information in the header may indicate that the PDU is the first PDU in a PDU set including 5 PDUs.

[0111] If multiple information units match the same packet filter and are assigned to a PDU set identifier (e.g., the same PDU set identifier), the corresponding PDU sets may be referred to as PDU set flows, such as Figure 2 shown.

[0112] Different PDU sets may be synchronized within a synchronization threshold. PDU sets associated with different PDU set identifiers may (e.g., may need to) be synchronized. The PDU set association and handling rules may include information (e.g., synchronization information) indicating to the WTRU which PDU sets (e.g., which may be identified by a PDU set identifier) ​​are to be synchronized (e.g., need to be synchronized). The PDU set association and handling rules (e.g., synchronization information) may indicate a synchronization threshold for the PDU set flow and a synchronization group identifier.

[0113] The WTRU may populate the headers of the PDUs in the PDU set with the synchronization group identifier and the PDU set identifier. The UPF may use the synchronization group identifier and / or the PDU set identifier to detect which PDU sets may be used to perform synchronization measurements, which PDU sets may be synchronized, and which PDU sets may be delayed by the UPF to improve synchronization measurements. In order to reduce the amount of information to be sent (e.g., the amount of information that needs to be sent), the WTRU may choose to populate (e.g., only populate) the headers of the PDUs in the PDU set with the synchronization group identifier.

[0114] In an example, multiple WTRUs may send flows that may be part of a synchronization group (e.g., the same synchronization group). Multiple WTRUs may populate a PDU header with a synchronization group identifier (e.g., the same synchronization group identifier). The UPF may use this information to synchronize a set of PDUs as described herein. The UPF may use measurement information received from a first WTRU to determine how to synchronize a PDU sent from a second WTRU (e.g., to determine a delay of the PDUs).

[0115] The WTRU may provide information to the SMF indicating which PDU set flows are associated with the same synchronization group identifier. This information may be transmitted to the SMF in a NAS-SM message (such as a PDU Session Modification Command or a PDU Session Establishment Request). In an example, the AF may provide the information to the SMF. If the AF provides the information to the SMF, the information may be transmitted via a Network Open Function (NEF) and / or Policy Control Function (PCF) service call. The SMF may use this information to detect which flows to synchronize (e.g., which flows need to be synchronized), thereby removing the need for the WTRU to add the synchronization group identifier in the header.

[0116] The PDU header may be populated in the downlink. The UPF may receive IP packets from the data network in the downlink. The IP packets may originate from an application server. The UPF may be configured with packet detection rules that detect which IP packets are part of the same information unit. The packet detection rules may be enhanced to include a PDU collection identifier that may be associated with an information unit and may be assigned to a PDU in a PDU set that carries the information unit to the WTRU. The UPF may populate the PDU header with the PDU collection identifier.

[0117] The packet detection rule (e.g., or a reference to the packet detection rule) may be received by the UPF in an N4 message (e.g., an N4 session modification request) from the SMF servicing the PDU session associated with the application that generated the information unit. The packet detection rule may include a packet filter and / or a PDU set flow identifier (e.g., a flow classifier). The UPF may compare the IP packet to the packet filter. If the WTRU determines that the information unit matches the packet filter, the WTRU may associate the information unit with the PDU set flow identifier. The information unit may be assigned to a PDU set, and the header of the PDU in the PDU set may include the determined PDU set flow identifier.

[0118] The packet filters compared to the IP packets may be based on the IP 5-tuple and / or application layer traffic descriptors (eg, such as I-frames, P-frames, etc.).

[0119] A PDU in a PDU set may include header information indicating the sequence of the PDUs in the PDU set. For example, the information in the header may indicate that the PDU is the first PDU in a PDU set including five (5) PDUs.

[0120] If multiple information units match the same packet filter and are assigned the same PDU set identifier, the corresponding PDU sets may be referred to as PDU set flows, such as Figure 2 shown.

[0121] Different PDU sets may be synchronized within a synchronization threshold. PDU sets associated with different PDU set identifiers may be synchronized (e.g., may need to be synchronized). Packet detection rules may be enhanced to include information indicating to the UPF a PDU set that is identified with a PDU set identifier and / or may be synchronized. Packet detection rules (e.g., synchronization information) may indicate a synchronization threshold for a PDU set as well as a synchronization group identifier.

[0122] The UPF may populate the headers of the PDUs in the PDU Set with the synchronization group identifier. The WTRU may use the synchronization group identifier to detect which PDU sets may be used to perform synchronization measurements, which PDU sets may be synchronized, and which PDU sets may be delayed by the WTRU access stratum to improve synchronization measurements. In order to reduce the amount of information sent (e.g., the amount of information that needs to be sent), the UPF may choose to populate (e.g., only populate) the headers of the PDUs in the PDU Set with the synchronization group identifier.

[0123] The WTRU may detect and / or notify the network of synchronization status, for example, to improve the quality of experience.

[0124] Features associated with NAS notifications are provided. A WTRU may detect that data from a stream that the WTRU is transmitting and / or receiving is not synchronized (eg, sufficiently synchronized) with a second stream. The second stream may be associated with the WTRU or a second WTRU.

[0125] In an example, a WTRU application hosted in a terminal equipment (TE) portion of a WTRU may detect that a flow is not synchronized (e.g., sufficiently synchronized) and may cause a buffer overflow or underflow. The WTRU application may provide synchronization information to a mobile terminal (MT) portion of the WTRU. The MT portion of the WTRU may associate the synchronization information with a PDU session used by the WTRU application. The MT portion of the WTRU may associate the synchronization information with an IP 5-tuple and / or a QoS flow of a PDU session.

[0126] The WTRU may transmit synchronization information along with an identification of the associated PDU session, IP 5-tuple, and / or QoS flow to the network (eg, so that the network may take action to improve the synchronization status of the flow).

[0127] In an example, the WTRU may transmit synchronization information and information about an associated PDU session, IP 5-tuple, and / or QoS flow to the network via a NAS-SM message. The message may be received by an SMF associated with the PDU session. The SMF may use the information to perform one or more actions, such as transmitting updated QoS rules to the WTRU and / or transmitting QoS enforcement rules (QER) to the UPF. The SMF may forward the synchronization information to the PCF (e.g., so that the PCF may update policy charging and control (PCC) rules and / or UE routing policy (URSP) rules). The SMF may forward the synchronization information to the NWDAF so that the NWDAF may consider the synchronization information when generating network data analysis.

[0128] In an example, the synchronization information received by the SMF may relate to a flow that may be part of a multimodal session having flows that may be associated with one or more WTRUs (e.g., other WTRUs). The SMF may use the synchronization information to determine whether to transmit updated QoS rules to the one or more WTRUs (e.g., other WTRUs) and whether to transmit updated QERs to the UPF for flows of the other WTRUs.

[0129] In an example, the WTRU may be triggered to transmit synchronization information by a request from the application layer. Other events may trigger the WTRU to transmit synchronization information. The WTRU may receive configuration information that may be used to determine when to transmit synchronization reports. For example, the WTRU may receive configuration information from the SMF via a NAS-SM message. The configuration information may be associated with a PDU session. The configuration information may include one or more of the following fields. These fields may include a time value indicating how often the WTRU may transmit a synchronization report when the PDU session is active (e.g., the WTRU is in the CM-CONNECTED state). These fields may include a packet filter indicating which IP stream synchronization reports may be transmitted. The packet filter may be based on an IP 5-tuple, a PDU set identifier, a packet type (e.g., an I frame or a P frame), or a combination thereof. These fields may include a synchronization threshold that indicates to the WTRU that synchronization information will be transmitted (e.g., only needs to be transmitted) when the synchronization measurement meets and / or exceeds the threshold. For a PDU session used by a multimodal application, a PDU session modification request may be generated (e.g., network initiated or WTRU initiated). Generating a PDU session modification request may trigger the WTRU to transmit synchronization information. QoS flows carrying application traffic (e.g., certain QoS flows) may change their characteristics. Changing the characteristics of a QoS flow may trigger the WTRU to transmit synchronization information. Data traffic (e.g., data traffic other than multimodal traffic) carried within a specific QoS flow (which is shared with a multimodal traffic) may trigger (e.g., be the source of) a PDU session modification request. In this case, the network may require the WTRU to transmit (e.g., or the WTRU may independently determine to transmit) synchronization information to the network to evaluate whether the synchronization between the multimodal flows is synchronized (e.g., within a synchronization threshold).

[0130] Figure 5 An example based on NAS synchronization status notification is shown.

[0131] As about Figure 5As described, at 502, the WTRU-hosted application may trigger the establishment of a PDU session. The WTRU-hosted application may provide a service descriptor or an XRM session identifier to the MT portion of the WTRU. When the PDU session is established, the WTRU may provide a service descriptor or an XRM session identifier to the network (e.g., so that the network can determine which other PDU sessions and / or flows are associated with the PDU session). Other PDU sessions and / or flows may be associated with other WTRUs. Once the PDU session is established, the WTRU-hosted application (e.g., an XR application) may begin transmitting and / or receiving multimodal data. When the PDU session is established, the WTRU-hosted application may provide an identifier associated with the PDU session to the WTRU-hosted application. For example, the identifier associated with the PDU session may be a context identifier (CID).

[0132] As about Figure 5 As described, at 504, the WTRU-hosted application may determine information about the synchronization state of a stream associated with the application. Example information associated with the synchronization state of a stream is listed in Table 1. The WTRU-hosted application may transmit information associated with the synchronization state of a stream to the MT portion of the WTRU. For example, the WTRU-hosted application may invoke an AT command to provide information about the synchronization state of a stream to the MT portion of the WTRU. When the WTRU-hosted application provides information about the synchronization state of a stream to the MT portion of the WTRU, the WTRU-hosted application may provide the MT portion of the WTRU with an XRM session identifier, a service descriptor, and / or an identifier associated with a PDU session. For example, the identifier associated with a PDU session may be a context identifier.

[0133] The synchronization status information provided herein may indicate whether a stream is properly synchronized. The synchronization status information may indicate the extent to which a stream is correctly synchronized or not correctly synchronized (e.g., the information may indicate that data is arriving, on average too early, or too late by 1 ms). The WTRU-hosted application may not be responsible for determining whether a stream is synchronized. The WTRU-hosted application may report (e.g., only report) information about a stream so that another entity (e.g., a network or application server) can determine whether a stream is synchronized and the extent to which a stream is (or is not) synchronized. The synchronization status information may include information that can be used by a network or application server to determine whether a stream is synchronized and the extent to which a stream is correctly synchronized or not correctly synchronized. Table 1 shows an example of information that may be included in the synchronization status information.

[0134] The synchronization status information may be based on measurements. The measurements may be performed at the WTRU. For example, the WTRU may measure the difference in arrival or transmission times of associated PDUs (e.g., a difference measurement) and use the measurement as a synchronization measurement. The difference measurement may be between the arrival time or transmission time of the first PDU in two PDU sets or a burst of PDU sets. A burst of PDUs may be multiple PDUs transmitted at similar times or simultaneously. The difference measurement may be between the arrival time or transmission time of the last PDU in two PDU sets or a burst of PDU sets.

[0135] The difference measurement may refer to the time difference between the arrival or transmission of the first PDU in two PDU sets or bursts, or the time difference between the arrival or transmission of the last PDU in two PDU sets or bursts. The time difference may be used for various purposes, such as synchronizing different data streams or analyzing the performance of a communication system.

[0136] For example, if two data streams convey bursts of PDUs, then the difference measurement between the arrival times of the first PDUs of the two bursts can be used to determine the latency between the data streams.The difference measurement between the arrival times of the last PDUs of the two bursts can be used to determine the latency between the data streams.

[0137] The difference measurement can also be used to analyze the performance of the communication system. For example, if the difference measurement between two PDU sets or bursts is long, this can indicate a problem in the communication system, such as congestion or a bottleneck along the transmission path.

[0138] Difference measurements can be used to measure differences between multiple PDU sets or bursts (e.g., in addition to measuring the time difference between two PDU sets or bursts). Difference measurements between multiple PDU sets or bursts can be used to analyze the performance of a communication system over time and to measure the effectiveness of optimization techniques. A burst of PDUs can be multiple PDUs transmitted at similar times or simultaneously.

[0139] As about Figure 5As described, at 506, the WTRU may transmit a NAS-MM message to the AMF. The NAS message may be triggered by a message transmitted during the preparation of the synchronization status information, or by a timer configured in the NAS layer to periodically trigger the WTRU to transmit a NAS-MM message to the AMF. The access layer may trigger the NAS-MM layer to transmit a report. The access layer may periodically transmit a trigger to the NAS layer when a PDU set is received and / or when a synchronization problem is detected. The NAS-MM message may include a NAS-SM message and / or a PDU session ID. An identifier (e.g., cid) associated with a PDU session during the preparation of the synchronization status information may be used by the WTRU to determine the PDU session ID. The NAS-SM message may include a PDU session ID and / or synchronization status information. The synchronization status information may include an identifier of a multimodal data set (e.g., an XRM session identifier received from an application hosted by the WTRU). The NAS-MM message may identify one or more flows associated with the synchronization information. These flows may be identified by a synchronization group identifier, a PDU set flow identifier, an IP 5-tuple, or a QoS flow ID. The AMF may forward the NAS-SM message to the SMF. The AMF can use the PDU session ID in the NAS-MM part of the message to determine which SMF to transmit the NAS-SM message to. Due to the XRM session identifier provided during the PDU session establishment, the SMF can know what XRM session identifier is associated with the PDU session.

[0140] As about Figure 5 As described, at 508, the SMF may receive synchronization status information. The SMF may use the synchronization status information to trigger one or more of the following actions (e.g., it may improve the overall quality of experience of the WTRU-hosted application and / or the overall quality of experience of applications hosted on other WTRUs associated with the WTRU-hosted application). The SMF may receive synchronization status information from multiple WTRUs (e.g., other WTRUs that are part of a multimodal data set). The SMF may use the synchronization status information from multiple WTRUs to determine what actions to trigger and how to configure these actions. For example, the SMF may use multiple reports to derive QoS rules and latency information. The actions may include the SMF using the synchronization status information to derive QoS rules for the PDU session and transmitting the QoS rules to the WTRU and / or a radio access network (RAN) node.

[0141] The SMF may use the synchronization status information to derive QoS rules for PDU sessions for other WTRUs (e.g., other WTRUs hosting applications that are part of the same multimodal data set). The action may include the SMF using the synchronization status information to derive a QER and forwarding the QER to the UPF associated with the PDU session. The SMF may use the synchronization status information to derive a QER for PDU sessions for other WTRUs (e.g., other WTRUs hosting applications that are part of the same multimodal data set). The action may include the SMF using the synchronization status information to derive a data delay value. The data delay value may be transmitted to the UPF associated with the PDU session. The UPF may apply the data delay value to uplink traffic or downlink traffic from the PDU session.

[0142] The SMF may provide separate delay values ​​for uplink and downlink traffic. The SMF may provide delay values ​​for flows (e.g., specific flows) specific to a PDU session. The delay values ​​may be configured per IP 5-tuple. The SMF may use the synchronization status information to derive data delay values ​​for services associated with PDU sessions of other WTRUs (e.g., other WTRUs hosting applications that are part of the same multimodal data set). The action may include the SMF forwarding the synchronization status information to the PCF. The action may include the SMF forwarding the synchronization status information to the NWDAF. The action may include the SMF forwarding the synchronization status information to an application server and / or application function. The information may be transmitted to the application server and / or application function via the NEF.

[0143] As about Figure 5 As described, at 510, the UPF may receive synchronization status information from the SMF. The UPF may use the synchronization status information to determine what QoS processing to apply to downlink data, whether to apply processing delay to downlink traffic and / or uplink traffic, and / or how much processing delay to apply to downlink traffic and / or uplink traffic.

[0144] As about Figure 5 As described, at 512, the PCF may receive synchronization status information from the SMF. The PCF may use the synchronization status information to derive PCC rules and / or URSP rules. The PCC rules and / or URSP rules may be associated with the WTRU that transmits the synchronization status information and may be associated with other WTRUs associated with the same multimodal data set. As described herein, the synchronization status information may include an XRM session identifier for the multimodal data set. The PCF may use the XRM session identifier to determine which PDU sessions and WTRUs are associated with the multimodal data set.

[0145] As about Figure 5As described above, at 514, the NWDAF may receive synchronization status information from the SMF. The NWDAF may use the synchronization status information to calculate data analysis. For example, the NWDAF may use the synchronization status information to calculate analysis related to quality of experience.

[0146] As about Figure 5 As described, at 516, the AS may receive synchronization status information from the SMF. The AS may receive the synchronization status information via the NEF. The AS may use the synchronization status information to trigger one or more actions described herein (e.g., such as adjusting the QoS of a stream associated with a multimodal data set by calling a NEF API (such as Nnef_TrafficInfluence)). The AS may use the synchronization status information to adjust application services (e.g., by changing codec settings, frame rates, etc.). These actions may include the AS transmitting the synchronization status information to the PCF. The synchronization status information may be transmitted to the PCF via the NEF. The AS may provide an XRM session identifier to the NEF, and the NEF may use the XRM session identifier to query the binding support function (BSF) to determine which PCFs may receive the synchronization status information. As described herein, the PCF may use the synchronization status information to take actions to improve the quality of experience (e.g., updating PCC rules that trigger the SMF to request the UPF to adjust the delay applied to some streams, etc.). These actions may include the AS transmitting the synchronization status information to the NWDAF. The synchronization status information may be transmitted to the NWDAF via the NEF. As described herein, the NWDAF may use synchronization state information when computing data analytics, such as quality of experience information. These actions may include AS-triggered changes to application layer services (eg, such as changing codec settings, frame rate, etc.).

[0147] The synchronization state information received by the AS may be associated with a flow that is part of a multimodal set. Changes to a flow that the AS may trigger may affect other flows in the multimodal set. Other flows in the multimodal set may be associated with other WTRUs.

[0148] As described herein, the SMF, NWDAF, PCF, and AS / AF may receive synchronization status information and / or trigger actions based on the synchronization status information. In an example, the synchronization status information may be transmitted to a network function or server that indicates (or configures) actions for the SMF, PCF, and / or NWDAF to take. The network function or server may indicate (or configure) actions for other network functions to improve the overall quality of experience. These network functions may include a QoE monitoring network function.

[0149] After transmitting the NAS-MM message described herein (e.g., Figure 5), the WTRU may trigger synchronization status information preparation. Triggering synchronization status information preparation may cause the WTRU to start calculating how the flows are synchronized (e.g., the WTRU may perform Figure 5 If the WTRU determines that the synchronization information is to be transmitted again (eg, needs to be transmitted) to the network, the WTRU may transmit a NAS-MM message (eg, the WTRU may perform Figure 5 506 in the process).

[0150] As described herein, synchronization status information may be transmitted by the WTRU to the SMF. In an example, the network may include a synchronization report repository function (SRRF). The WTRU may transmit synchronization status information to the SRRF. The SRRF may calculate the degree to which the flow is synchronized or not synchronized, and may transmit guidance information to the SMF that may be used to calculate QoS rules and / or delay values ​​described herein.

[0151] Provides features associated with user-side notifications. Figure 5 As shown, the WTRU may use NAS signaling to communicate synchronization status information to a network function and / or application server (eg, so that the network function and / or application server can take action to improve the overall user experience).

[0152] Figure 6 An example of synchronization status notification based on X5 is shown. Figure 6 As shown, the synchronization status information may be transmitted to the network via user plane signaling. The user plane signaling may terminate at the application server, and / or the application server may forward the synchronization status information to the network function and / or trigger the network function to take action to improve the overall quality of experience. In an example, the X5 interface may be enhanced to allow the WTRU-hosted application to transmit synchronization status information via the user plane.

[0153] As about Figure 6 As described, at 602, a WTRU-hosted application such as an XR (e.g., 5GXR) application may trigger the establishment of a PDU session. The WTRU-hosted application may use the PDU session to transmit and / or receive data streams as part of a multimodal data set. Other applications (e.g., other XR applications) may transmit and / or receive data streams as part of a multimodal data set. Other applications may be hosted on other WTRUs.

[0154] As about Figure 6 As described above, at 604, the WTRU-hosted application (eg, XR session handler) may determine synchronization status information of a stream associated with the application. Table 1 lists examples of synchronization status information of a stream.

[0155] The synchronization status information provided herein may indicate whether a flow is synchronized (e.g., correctly synchronized). The synchronization status information may indicate the extent to which a flow is correctly synchronized or not correctly synchronized (e.g., the information may indicate that data is arriving, on average too early, or too late by 1 ms). A WTRU-hosted application may not be responsible for determining whether a flow is synchronized. A WTRU-hosted application may report (e.g., only report) information about a flow, such as to enable another entity (e.g., a network or application server) to determine whether a flow is synchronized and the extent to which a flow is synchronized or not synchronized. The synchronization status information may include information that may be used by a network or application server to determine whether a flow is synchronized and the extent to which a flow is synchronized or not synchronized. Table 1 shows an example of information that may be included in the synchronization status information.

[0156] As about Figure 6 As described, at 606, the WTRU hosted application may transmit synchronization status information to an application server (e.g., XR AF). The synchronization status information may include or be transmitted with an XRM session identifier associated with the multimodal data stream. As described herein, information from Table 1 may be included in the synchronization status information.

[0157] At 608, an application server (AS) may receive synchronization status information. The AS may use this information to trigger one or more of the following actions (e.g., it may improve the overall quality of experience of applications hosted by the WTRU and may improve the quality of experience of applications hosted on other WTRUs and associated with the applications hosted by the WTRU (e.g., overall quality of experience)). The action may include the AS transmitting the synchronization status information to the PCF. The information may be transmitted to the PCF via the NEF. The AS may provide an XRM session identifier to the NEF, and the NEF may use the XRM session identifier to query the BSF to determine which PCFs may receive the synchronization status. As described herein, the PCF may use the synchronization status information to take actions to improve the quality of experience (e.g., update a PCC rule that triggers the SMF to request the UPF to adjust the delay applied to some flows, etc.). The action may include the AS transmitting the synchronization status information to the NWDAF. The information may be transmitted to the NWDAF via the NEF. As described herein, the NWDAF may use the synchronization status information to calculate data analysis (e.g., such as quality of experience information). The action may include the AS triggering changes to application layer services (e.g., such as changing codec settings, frame rate, etc.).

[0158] The AS may receive synchronization status information from multiple WTRUs (e.g., other WTRUs that are part of a multimodal data set). The AS may use the synchronization status information from multiple WTRUs to determine what actions to trigger and how to configure the actions that may be triggered. For example, the AS may use multiple reports to derive QoS rules and / or latency information.

[0159] For example, the AS may receive synchronization status information from one WTRU and use the synchronization status information to adjust settings associated with a second WTRU (e.g., a different WTRU) that is part of a multimodal set (e.g., the same multimodal set). For example, the AS may use the synchronization status information from the first WTRU to determine to invoke a NEF / PCF API that reconfigures QoS requirements for flows associated with the second WTRU.

[0160] Examples of the content of synchronization status information are provided. The synchronization status information may include identification information that may be used to associate the information with a WTRU, PDU session, and / or data flow that is part of the same multimodal data set. The identification information may be an XRM session identifier. A data flow may be identified by an IP 5-tuple. A PDU session may be identified by a PDU session ID. A WTRU may be identified by an IMSI, a SUCI, or an external identifier.

[0161] As described herein, information from the application layer may be part of the notification. For example, the synchronization status information may be based on the Real-Time Control Protocol (RTCP). The RTCP transmitter / receiver may report a packet number and / or an octet number. The report may include a timestamp and may be used to derive the synchronization status information. For example, the packet number may be used to derive a PDU set number, and / or a header of a PDU in a PDU set may have a field populated with the RTCP packet number. For example, a WTRU-hosted application may use an application programming interface (API) or an attention (AT) command to provide synchronization status information including the timing of the first packet and / or last packet of a received or transmitted PDU set (e.g., any received or transmitted PDU set). For example, an RTCP media stream related identifier or SyncGroupId may be used to derive a synchronization group identifier in the synchronization status information.

[0162] The information (e.g., additional information) may be part of the synchronization status information. In an example, the information from Table 1 may be derived from the access layer. For example, the access layer may detect presentation time, PDU set arrival time, and / or synchronization error value. The information from the access layer may be provided along with a PDU session ID and / or a PDU set stream identifier (e.g., so that the NAS layer can determine the stream associated with the report).

[0163] Table 1

[0164]

[0165]

[0166] Features associated with synchronization flows are provided. Synchronization at the UPF via a delay provided by the SMF may be provided.

[0167] In an example, the system may configure the UPF via the SMF to introduce delays into one or more streams to synchronize one or more streams with other streams to improve the synchronization of the streams (e.g., to prevent the streams from becoming asynchronous), such as Figure 7 shown. Figure 7 An example of synchronizing flows at the UPF via delays provided by the SMF is illustrated. The SMF may transmit an N4 message to the UPF to configure the UPF to introduce delays to one or more flows. The N4 message may be an N4 Session Modification Request enhanced to allow the SMF to identify one or more flows and the desired delay or delay range for the identified flows. These flows may be identified with an IP 5-tuple.

[0168] In an example, a WTRU may receive one or more synchronization rules for a PDU data set flow (e.g., a flow). The synchronization rules may specify a PDU data set flow associated with one or more functions and / or services. The synchronization rules may specify an order in which the WTRU performs and / or analyzes synchronization of the one or more flows.

[0169] In an example, the WTRU may receive synchronization information associated with a PDU session. The PDU session may include one or more streams, such as a PDU data set stream. The synchronization information may include one or more synchronization rules, which may be criteria for determining when and how to synchronize data between two or more data streams. The synchronization rules may define the types of data streams that should be synchronized, the time and frequency at which the data streams may be synchronized, and the order in which the data streams may be synchronized. The synchronization rules may also specify details such as the protocol to be used for data transfer, the user credentials to be used to access the data, the frequency of the synchronization process, a threshold for synchronization, a threshold for desynchronization, a value for synchronization, a value for desynchronization, a level of synchronization, a level of desynchronization, and the like.

[0170] As about Figure 7As described, at 702, the WTRU may detect that the first flow is not synchronized with one or more other flows. For example, the WTRU may detect that the first flow may be asynchronous with one or more other flows. This detection may be performed in the access stratum portion of the WTRU. The access stratum portion of the WTRU may receive information indicating which flows may be synchronized and a synchronization threshold indicating the degree to which the flows will be synchronized from the NAS portion of the WTRU (for example, one or more flows may be asynchronous and may need to be synchronized). The access stratum may use the information from the NAS portion of the WTRU to determine whether the flow may be synchronized with one or more other flows (for example, the flow may be asynchronous with one or more flows). When the access stratum determines the synchronization status of the flow with respect to one or more flows, the access stratum may transmit an indication to the NAS portion of the WTRU to indicate that the first flow is synchronized with one or more other flows, or is not synchronized with one or more flows (for example, asynchronous with one or more flows). The indication from the access stratum may identify the flow with a PDU set flow ID, an IP 5-tuple, and / or a QoS flow ID.

[0171] In an example, synchronization information may be used to determine a synchronization measurement. The synchronization measurement may indicate a synchronization level between the first data stream and the second data stream. The first data stream and the second data stream may be associated with a PDU session. The WTRU may determine that the first data stream and the second data stream are asynchronous based on a threshold. For example, when the synchronization measurement value is above a threshold, the WTRU may determine that the first data stream and the second data stream are asynchronous. As another example, when the synchronization measurement value is below a threshold, the WTRU may determine that the first data stream and the second data stream are asynchronous.

[0172] As about Figure 7 As described, at 704a to 704e, in a first option, the WTRU may transmit a synchronization request message to the application server, as described herein. The request message may indicate a value of synchronization, may indicate that one or more flows are asynchronous, may indicate a value of asynchronous, may indicate a request to synchronize one or more flows, a combination thereof, and the like. As described with respect to Figure 7As described, at 704a, the WTRU may transmit an application layer message to an application server (e.g., AF) to indicate that the first stream is not synchronized with one or more other streams. The message may identify the stream (e.g., identified by an IP 5-tuple) and indicate a delay value or a range of delay values ​​that can be applied to the service to synchronize the stream. For example, the message may include information from Table 1. The message may indicate whether a delay may be introduced on a downlink service, an uplink service, or both. In an example, the message may be transmitted within a stream to be synchronized (e.g., a stream that may be identified as asynchronous and / or may need synchronization), and the application server may determine that the stream receiving the message is to be synchronized (e.g., the stream may have been identified as asynchronous and / or may need synchronization). The message may include information from Table 1 (e.g., any one of the information) (e.g., so that the application server can use information from Table 1 to determine which delay value to apply and which streams the delay value should be applied to).

[0173] As about Figure 7 As described above, at 704b, the application server may transmit a message to the network to request that the network introduce a delay to the flow identified in the synchronization request process described herein (e.g., in Figure 7 The request may be transmitted to the NEF. The NEF may use the BSF to determine which PCF is servicing the PDU session and may forward the request to the PCF. The application server may transmit a message to the network to request that the network introduce a delay to another flow that is part of a multimodal set (e.g., the same multimodal set) of the identified flow (e.g., the flow identified at 704a). The other flows may be associated with different WTRUs.

[0174] As about Figure 7 As described above, at 704c, the request from the AS / NEF may trigger the PCF to transmit updated PCC rules to the SMF.

[0175] As about Figure 7 As described, at 704d, the PCF can respond to the application server by indicating whether the requested delay can be applied. If the PCF indicates that the delay can not be applied, the application server can try to take different actions to improve the quality of experience (e.g., adjust codec settings and / or frame rate).

[0176] As about Figure 7 As described, at 704e, the application server may respond to the WTRU hosted application with an indication of whether the request delay may be applied. If the application server indicates that the delay may not be applied, the WTRU hosted application may attempt to take different actions to improve the quality of experience (e.g., adjust codec settings and / or frame rate).

[0177] As about Figure 7As described, at 7063a to 706b, in the second option, the WTRU may transmit a synchronization request to the SMF, as described herein. The WTRU may use these two options concurrently, for example, transmitting one or more synchronization requests to the application server and one or more synchronization requests to the SMF.

[0178] As about Figure 7 As described, at 706a, the WTRU may transmit a NAS-SM message to the SMF serving the PDU session for the first flow. The NAS-SM message may indicate that the first flow is not synchronized with one or more other flows. The message may identify the flow (e.g., using a synchronization group identifier, a PDU set flow identifier, an IP 5-tuple, or a QoS flow ID to identify the flow) and may indicate a delay value or a range of delay values ​​that can be applied to the service to synchronize the flow. The message may indicate whether a delay can be introduced on the downlink service, the uplink service, or both. The message may include information from Table 1 (e.g., any of the information) (e.g., so that the SMF can use the information from Table 1 to determine what delay value to apply and which flows the delay value should be applied to).

[0179] In an example, a message indicating that the first data stream and the second data stream are asynchronous (eg, not synchronized) may be transmitted to the network node. The message may indicate a correction factor (eg, how to adjust the first data stream and / or the second data stream).

[0180] As about Figure 7 As described, at 706b, the SMF may respond to the WTRU by transmitting a synchronization acknowledgement indicating whether the requested delay may be applied. If the SMF indicates that the delay may not be applied, the MT portion of the WTRU may provide an indication to the WTRU-hosted application. The WTRU-hosted application may attempt to take different actions (e.g., in addition to applying the requested delay) to improve the quality of experience (e.g., adjusting codec settings, frame rate, delaying flows, and / or providing QoS rules).

[0181] As about Figure 7 As described, at 708, the SMF may transmit an N4 message to the UPF to configure the UPF to introduce delays into one or more flows. The N4 message may be an N4 session modification request enhanced to allow the SMF to identify one or more flows and the expected delay or delay range of the identified flows. These flows may be identified by IP 5-tuples.

[0182] As about Figure 7 As described, at 710, the UPF may apply a delay to the identified stream requested via the synchronization request.

[0183] As about Figure 7As described, at 712, the WTRU-hosted application may measure (eg, remeasure) how the first flow is synchronized with one or more other flows (eg, recheck the synchronization status of the flows) and determine whether to transmit another request to the network to synchronize the flows.

[0184] As described herein, the UPF may perform procedures to obtain information about the synchronization status of a flow and use this information to determine whether to apply a delay to a PDU set. These procedures may also be performed by a base station such as a gNB.

[0185] Features associated with synchronizing flows at the UPF via UPF derived delays are provided. In an example, the system can improve the synchronization of flows by configuring the UPF to synchronize one or more flows via the SMF, such as Figure 8 shown. Figure 8 An example of synchronizing a stream at the UPF via a delay provided by the SMF is illustrated. The SMF may transmit an N4 message to the UPF to request the UPF to synchronize one or more streams. The N4 message may be an N4 session modification request transmitted from the SMF to the UPF. The N4 message may be enhanced to allow the SMF to identify two or more streams and the desired synchronization threshold of the identified streams. The UPF may detect which PDUs of the identified streams are to be synchronized (e.g., need to be synchronized). When the UPF transmits an uplink or downlink PDU of a first stream, the UPF may detect or measure the degree of synchronization of the PDU of the first stream with the PDU of the second stream. In an example, the UPF may perform detection or measurement on a PDU set. For example, the UPF may detect or measure the degree of synchronization of the PDU set of the first stream and the PDU set of the second stream (e.g., on average). In an example, the UPF may measure the degree of synchronization of the last PDU in the PDU set of the first stream and the last PDU in the PDU set of the second stream.

[0186] In an example, a PDU in a PDU set may include header information used by the UPF to detect that the PDU is part of the same PDU set or a different PDU set. A PDU set may include header information that the UPF may use to detect that the PDU set may be synchronized. For example, a PDU in a PDU set may include a synchronization group identifier field. The UPF may use the synchronization group identifier to detect that a first PDU set may be synchronized with a second PDU set. The first PDU set and the second PDU set may be associated with a stream of the same WTRU or a different WTRU. Other PDU sets (e.g., other than the first PDU set and the second PDU set) may be part of a different stream and may not need to be synchronized with any particular service. The synchronization group identifier field may be encoded in the PDUs in the PDU set (e.g., only one PDU in each PDU set). When the UPF detects that two or more PDU sets have the same synchronization group identifier, the UPF may measure the difference in the arrival time or the transmission time of the associated PDUs and use the measurement as a synchronization measurement. The measurement may be the difference between a PDU from the first PDU set and a PDU from the second PDU set. For example, the difference measurement may be between the arrival time or the transmission time of the first PDU in two PDU sets.For example, the difference measurement may be between the arrival time or the transmission time of the last PDU in two PDU sets or PDU set bursts.

[0187] If the UPF detects that the flows are not synchronized, the UPF may introduce a delay in one or more flows to make the flows more synchronized.

[0188] If the UPF detects that the flow is not synchronized, the UPF may transmit an N4 message to the SMF to notify the SMF of the measurement results and to notify the SMF of the introduced delay (eg, any delay).

[0189] The UPF may periodically transmit N4 messages to the SMF to report the synchronization level between flows (eg, synchronization measurements).

[0190] As about Figure 8 As described, at 802, one or more WTRUs may be configured with the same XRM session identifier, correlation identifier, and / or synchronization group identifier.

[0191] As about Figure 8As described, at 804a, a first WTRU (labeled "WTRU1") may establish a PDU session. The first WTRU may transmit a NAS-SM PDU session establishment request to a first SMF (labeled "SMF1"). The NAS-SM PDU session establishment request may include an XRM session identifier. The first SMF may use the XRM session identifier during UPF selection to ensure that flows associated with the PDU session pass through a common UPF with other PDU sessions associated with the same XRM session identifier (e.g., PDU sessions of the same WTRU or other WTRUs). The first SMF may transmit an N4 session establishment (or modification) request to the UPF. The N4 session establishment (or modification) request may include an XRM session identifier. The UPF may use the XRM session identifier to determine which flows can be synchronized. The first SMF may include a synchronization threshold in the N4 session establishment (or modification) request to the UPF.

[0192] As about Figure 8 As described, the first WTRU may include multiple XRM session identifiers in a NAS-SM PDU session establishment (or modification) request to the SMF. The XRM session identifier (e.g., each XRM session identifier) ​​may be associated with one or more streams (e.g., IP 5-tuples). The NAS-SM PDU session establishment (or modification) request may indicate which streams are associated with the XRM session identifier (e.g., each XRM session identifier). The SMF may provide the XRM session identifier and the associated stream identifier to the UPF. The NAS-SM PDU session establishment (or modification) request may include a synchronization threshold for the stream (e.g., each stream).

[0193] As about Figure 8 As described, at 804db, a second WTRU (labeled "WTRU2") may establish a PDU session. The second WTRU may transmit a NAS-SM PDU session establishment request to a second SMF (labeled "SMF2"). The NAS-SM PDU session establishment request may include an XRM session identifier. Similar to the PDU session establishment described with respect to 804a, at 804b, a second SMF (e.g., SMF2) associated with the PDU session may use the XRM session identifier to select a UPF (e.g., the same UPF selected for the PDU session of the first WTRU). The SMF associated with this PDU session may provide the XRM session identifier in an N4 session establishment (or modification) request to the UPF.

[0194] As described herein, a NAS-SM PDU session establishment (or modification) request may include an XRM session identifier. An XRM session identifier (eg, each XRM session identifier) ​​may be associated with one or more flows.

[0195] As about Figure 8 As described, at 806a, the first WTRU may begin generating uplink traffic. When the WTRU generates uplink traffic, the NAS layer may create a PDU from the traffic. The PDU may be associated with a PDU set, and the PDU (e.g., each PDU) may be sent. The PDU (e.g., each PDU) may include a header indicating the PDU set associated with the PDU. The header may include a synchronization group identifier that indicates other PDU sets that may be synchronized with the PDU set. The synchronization group identifier may be provided by the application layer when the application layer provides a packet (e.g., an information unit) for transmission.

[0196] As about Figure 8 As described, at 806b, the second WTRU may generate uplink traffic. A PDU set may be generated and the PDU may be transmitted with a header (eg, the header may include a synchronization group identifier to indicate the PDU set associated with the PDU).

[0197] As about Figure 8 As described, at 808, packets transmitted to the uplink service process described herein (e.g., at 806a and 806b) may arrive at the UPF. When the UPF sends an uplink packet on the N6 interface or receives an uplink packet on the N3 / N9 interface, the UPF may measure the time difference between the time when two PDUs are sent or received. The UPF may measure the time difference when two packets belong to a stream associated with the same XRM session identifier and the same correlation identifier. When the measurement result is greater than the synchronization threshold received from the SMF, the UPF may apply a delay to one or more streams to change the results of subsequent measurements (e.g., to synchronize the streams).

[0198] As about Figure 8 As described, at 810, a downlink packet may arrive at the UPF. When the UPF sends a downlink packet on the N3 / N9 interface (e.g., to the first WTRU or the second WTRU) or receives a downlink packet on the N6 interface (e.g., from the DN), the UPF may measure the time difference between the times when the two PDUs are sent or received. The UPF may measure the time difference when the two packets belong to flows associated with the same XRM session identifier and the same synchronization group identifier. When the measurement result is greater than the synchronization threshold received from the SMF, the UPF may apply a delay to one or more flows to change the results of subsequent measurements (e.g., to synchronize the flows).

[0199] As about Figure 8As described, the uplink traffic process, measurement synchronization and introduction delay process, and downlink traffic process (e.g., at 806a, 806b, 808, and / or 810) described herein may be continuous and may occur simultaneously. They may represent a WTRU transmitting multiple PDUs to the UPF.

[0200] As about Figure 8 As described, the streams of the XRM session can use a common UPF, which measures whether the streams are synchronized and the degree to which the streams are synchronized, and takes action to synchronize the streams. In the example where different UPFs serve the streams of the XR session, the UPF can transmit packet arrival information to the network function. The network function may be referred to as a coordination function (CoF). The packet arrival information may include PDU send time, PDU receive time, XR session ID, and / or synchronization group identifier. The CoF can use packet arrival information from multiple UPFs to determine how the streams are synchronized. If the CoF determines that one or more streams do not meet the synchronization threshold, the CoF may request one or more UPFs to delay certain streams by an amount determined by the CoF.

[0201] Features associated with synchronization at a WTRU based on a PDU header are provided herein.When a WTRU receives a downlink PDU, the WTRU may detect which PDU sets of a PDU session are to be synchronized (eg, need to be synchronized).

[0202] The WTRU may use information (e.g., UPF added to the header of the PDUs in a PDU set) to detect which flows are to be synchronized (e.g., need to be synchronized). For example, the WTRU may determine that PDU sets associated with the same synchronization group identifier are to be synchronized (e.g., need to be synchronized). In an example, the PDU set association and processing rules (e.g., synchronization information) described herein may indicate to the WTRU which PDU set flows are to be synchronized (e.g., need to be synchronized). The PDU set flows may be identified by a PDU set identifier.

[0203] The WTRU may measure the synchronization level between the PDU set flows and compare it to the synchronization threshold provided to the WTRU in the PDU set association and processing rules (e.g., synchronization information). If the WTRU detects that the downlink PDU set flow is not within the synchronization threshold (e.g., is asynchronous), the access stratum portion of the WTRU may apply a delay to one or more PDU sets before transmitting the information to higher layers. In an example, the NAS layer of the WTRU may apply a delay to one or more PDU sets before transmitting the information to higher layers. This delay may improve the perceived synchronization of the flows at the application layer.

[0204] In an example, PDU set association and processing rules (e.g., synchronization information) may indicate to the WTRU that certain PDU set flows may be delayed (e.g., always delayed) before the associated information is delivered to the application layer. The SMF may use measurement information from the UPF to determine how much delay to instruct the WTRU to apply.

[0205] Measuring the synchronization level between the PDU collection flows may involve measuring a time difference between when a set of PDUs of a first PDU collection flow is available for presentation to the application layer and when a set of PDUs of a second PDU collection flow is available for presentation to the application layer.

[0206] Synchronization at the UPF based on the PDU header may be provided.When the UPF receives uplink PDUs, the UPF may detect which PDU sets to synchronize (eg, need to be synchronized).

[0207] The UPF may use information (e.g., the WTRU added to the headers of the PDUs in the PDU Set) to detect which flows are to be synchronized (e.g., need to be synchronized). For example, the UPF may determine that PDU Sets associated with the same synchronization group identifier are to be synchronized (e.g., need to be synchronized). In an example, the PDR configured in the UPF may indicate which PDU Set flows are to be synchronized (e.g., need to be synchronized). PDU Set flows may be identified by a PDU Set identifier.

[0208] The UPF may measure the synchronization level between the PDU sets and compare it to the synchronization threshold provided to the UPF in the PDR. If the UPF detects that the uplink PDU set or the downlink PDU set is not within the synchronization threshold, the UPF may delay one or more PDU sets before transmitting the information to the WTRU. This delay may improve the perceived synchronization of the flows at the application layer.

[0209] In an example, an N4 message from the SMF may indicate to the UPF that a PDU aggregate flow (e.g., certain PDU aggregate flows) may be delayed (e.g., always delayed) before the associated information is transmitted to the data network. The SMF may use measurement information from the WTRU to determine how much delay to instruct the UPF to apply. The SMF may receive measurement information (e.g., synchronization information) from the WTRU via a NAS-SM message.

[0210] Correction jitter may be provided. Techniques described herein may be used to correct jitter in a flow. For example, the synchronization state information in Table 1 and provided to the WTRU and / or UPF may be enhanced to include a jitter parameter (e.g., a requirement). The jitter parameter (e.g., a requirement) may be associated with a flow. The flow may be identified by a PDU set flow identifier, an IP 5-tuple, or a QFI. The jitter parameter (e.g., a requirement) may be expressed as a minimum amount of time between PDU sets within a flow.

[0211] When the WTRU delivers a PDU set to the application layer, the WTRU may delay delivering a second PDU set of the same flow to the application layer until a minimum amount of time has passed. After the UPF sends the last PDU in the first PDU set in the downlink (e.g., or uplink), the UPF may determine to delay the sending of the first PDU in the second PDU set until after the minimum amount of time has passed.

[0212] The jitter parameters (e.g., requirements) may include a maximum time between PDU sets within a flow. When the WTRU determines that a first PDU set is ready to be delivered to the application layer and the amount of time that has elapsed since the last PDU set was presented to the application layer is greater than the maximum time between PDU sets, the WTRU may present the first PDU set to the application layer and may choose not to delay the second PDU set before presenting it to the application layer (e.g., even if the second PDU set is ready to be presented to the application before a minimum amount of time has elapsed since the presentation of the first PDU set). By not delaying the second PDU set, the WTRU may avoid a situation where packets in the flow are delayed due to packets (e.g., a single packet) that experience network delays. The jitter parameters (e.g., requirements) may include a maximum time between PDU sets within a flow. When the UPF determines that the first PDU in a PDU set is ready to be sent and the amount of time that has elapsed since the last PDU in another PDU set was sent is greater than the maximum time between PDU sets, the WTRU may send the first PDU in the PDU set and may choose not to delay the first PDU in the second PDU set before sending the first PDU in the second PDU set (e.g., even if the first PDU in the second PDU set is ready to be sent before the minimum amount of time has elapsed from presentation of the first PDU set). By not delaying the second PDU set, the UPF may avoid a situation where packets in a flow are delayed (e.g., are always delayed) due to packets (e.g., a single packet) experiencing network delays.

[0213] Synchronization and jitter correction can be provided at the application layer and the network layer. Synchronization between streams and jitter in a stream can be corrected using application protocols such as RTP and IDMS. In one or more deployments, the application layer protocol and network layer protocol correction methods described herein can be used. For example, application protocols such as RTP and IDMS can be used to solve large synchronization and jitter problems (e.g., while network layer protocol corrections described herein can be used to solve small synchronization and jitter problems). Large and small can refer to a time measure of a synchronization or jitter problem (e.g., a length of time).

[0214] The WTRU application may determine that the synchronization or jitter level achieved with the application layer protocol is insufficient and may transmit an indication to the WTRU that the network-based procedures described herein may be enabled. The WTRU may transmit a NAS-SM message to the SMF to indicate that the feature may be enabled.

[0215] A network application (e.g., AS) may determine that the synchronization or jitter level achieved using the application layer protocol is insufficient and may transmit an indication to the PCF via the NEF that the network-based process described herein may be enabled. The PCF may transmit data to the SMF serving the associated PDU session to indicate that a feature may be enabled.

[0216] Although the above features and elements are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without the other features and elements.

[0217] Although the implementations described herein may consider 3GPP specific protocols, it should be understood that the implementations described herein are not limited to such scenarios and are applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it should be understood that the solutions described herein are not limited to such scenarios and are also applicable to other wireless systems.

[0218] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or a processor. Examples of computer-readable media include, but are not limited to, electronic signals (sent via a wired or wireless connection) and / or 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, but not limited to, built-in hard disks and removable disks), magneto-optical media, and optical media (such as compact disk (CD)-ROM disks and / or digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU include: A processor, the processor being configured to: receiving synchronization information associated with a protocol data unit (PDU) session, wherein the synchronization information indicates a first flow classifier, a second flow classifier, and a synchronization threshold; determining a first data flow based on the first flow classifier and determining a second data flow based on the second flow classifier, wherein the first data flow and the second data flow are associated with the PDU session; determining a synchronization measurement based on the synchronization information, wherein the synchronization measurement indicates a synchronization value, the synchronization value indicating synchronization between the first data stream and the second data stream; determining that the first data stream and the second data stream are asynchronous based on the synchronization measure being at or above the synchronization threshold; and A message is transmitted to a network node, the message indicating that the first data flow and the second data flow are asynchronous.

2. The WTRU of claim 1 , wherein the synchronization value is based at least in part on a time duration between a first time value associated with the first data stream and a second time value associated with the second data stream.

3. The WTRU of claim 1 , wherein the synchronization value is based at least in part on a time difference, and wherein the processor is configured to determine the synchronization measurement comprises the processor being configured to: determining a first time value associated with arrival of data of the first data stream and a second time value associated with arrival of data of the second data stream; and The time difference is determined using the first time value and the second time value, wherein the time difference indicates a duration of time between the first time value and the second time value.

4. The WTRU of claim 3, wherein the message further indicates the time difference, wherein the time difference is used to synchronize the first data stream and the second data stream.

5. The WTRU of claim 4, wherein the message further indicates a request to synchronize the first data stream and the second data stream based on the time difference.

6. The WTRU of claim 1 , wherein the first flow classifier comprises a packet filter, and wherein the processor is configured to determine the first data flow based on the first flow classifier comprises the processor being configured to: A first plurality of PDU sets is determined to be associated with a first data type based on the packet filter, wherein the first data flow includes the first plurality of PDU sets.

7. The WTRU of claim 1 , wherein the first flow classifier comprises a flow identifier, and wherein the processor is configured to determine the first data flow based on the first flow classifier comprises the processor being configured to: Determining a plurality of PDU sets comprises an indication of the flow identifier, wherein the first data flow comprises the plurality of PDU sets.

8. The WTRU of claim 7, wherein the indication of the flow identifier is included in a header of the plurality of PDU sets.

9. The WTRU of claim 1 , wherein the message is a non-access stratum session management (NAS-SM) message, and wherein the network node is a session management function (SMF).

10. The WTRU of claim 1 wherein the message further indicates a request to synchronize the first data stream and the second data stream.

11. A method performed by a wireless transmission / reception unit, the method include: receiving synchronization information associated with a protocol data unit (PDU) session, wherein the synchronization information indicates a first flow classifier, a second flow classifier, and a synchronization threshold; determining a first data flow based on the first flow classifier and determining a second data flow based on the second flow classifier, wherein the first data flow and the second data flow are associated with the PDU session; determining a synchronization measurement based on the synchronization information, wherein the synchronization measurement indicates a synchronization value, the synchronization value indicating synchronization between the first data stream and the second data stream; determining that the first data stream and the second data stream are asynchronous based on the synchronization measure being at or above the synchronization threshold; and A message is transmitted to a network node, the message indicating that the first data flow and the second data flow are asynchronous.

12. The method of claim 11, wherein the synchronization value is based at least in part on a duration of time between a first time value associated with the first data stream and a second time value associated with the second data stream.

13. The method of claim 11, wherein the synchronization value is based at least in part on a time difference, and wherein determining the synchronization measurement include: determining a first time value associated with arrival of data of the first data stream and a second time value associated with arrival of data of the second data stream; as well as The time difference is determined using the first time value and the second time value, wherein the time difference indicates a duration of time between the first time value and the second time value.

14. The method of claim 13, wherein the message further indicates the time difference, wherein the time difference is used to synchronize the first data stream and the second data stream.

15. The method of claim 14, wherein the message further indicates a request to synchronize the first data stream and the second data stream based on the time difference.

16. The method of claim 11, wherein the first flow classifier comprises a packet filter, and wherein the first data flow is determined based on the first flow classifier. include: A first plurality of PDU sets is determined to be associated with a first data type based on the packet filter, wherein the first data flow includes the first plurality of PDU sets.

17. The method of claim 11, wherein the first flow classifier comprises a flow identifier, and wherein the first data flow is determined based on the first flow classifier. include: Determining a plurality of PDU sets comprises an indication of the flow identifier, wherein the first data flow comprises the plurality of PDU sets.

18. The method of claim 17, wherein the indication of the flow identifier is included in headers of the plurality of PDU sets.

19. The method of claim 11, wherein the message is a Non-Access Stratum Session Management (NAS-SM) message, and wherein the network node is a Session Management Function (SMF).

20. The method of claim 11, wherein the message further indicates a request to synchronize the first data stream and the second data stream.

Images