Methods, architectures, apparatuses and systems for formation and assertion of data unit groups in 3GPP and time sensitive networking (TSN)-enabled 3GPP networks

Abstract

Procedures, methods, architectures, apparatuses, systems, devices, and computer program products to enable at least the usage of protocol data unit (PDU) Sets in 3GPP and TSN-enabled 3GPP networks, for example, using provided extensions and / or improvements to the internet protocol (IP) header are described.

Description

METHODS, ARCHITECTURES, APPARATUSES AND SYSTEMS FOR FORMATION AND ASSERTION OF DATA UNIT GROUPS IN 3GPP AND TIME SENSITIVE NETWORKING (TSN)-ENABLED 3GPP NETWORKS CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No.63 / 603,431 filed November 28, 2023, which is incorporated herein by reference in its entirety. FIELD

[0002] The present disclosure is generally directed to the fields of communications, software and encoding, including, for example, to methods, architectures, apparatuses, systems related to the formation and assertion of data unit groups in 3GPP and time sensitive networking (TSN)-enabled 3GPP networks. SUMMARY

[0003] Some embodiments may be directed to a method implemented in a wireless transmit / receive unit (WTRU). The method may include receiving data unit group (DUG) rules including (i) information for detecting data unit groups (DUGs) in protocol headers of one or more packets and (ii) information indicating at least one action to perform on the packets upon detection of the data unit groups (DUGs) in the protocol headers of the packets. The method may include receiving a packet and determining an internet protocol (IP) version of the packet. Based on the determined IP version of the packet and the information for detecting the DUGs, the method may include (i) determining that data unit group (DUG) type length values (TLVs) are present in a field of the packet or determining that a hop-by-hop header extension is present in the packet, and (ii) determining a value associated with DUG information in the packet. The method may then include performing the at least one action on the packet in accordance with the DUG rules and sending the packet to a network node.

[0004] Some embodiments may be directed to a method implemented in a network element. The method may include receiving data unit group (DUG) rules including an indication to remove a DUG header of internet protocol (IP) packets associated with a GTP-U flow, receiving an IP packet associated with the GTP-U flow, the IP packet having a protocol data unit (PDU) set GTP-U header extension, and determining the DUG rules associated with the IP packet. Based on the indication included in the DUG rules and an IP version of the IP packet, the method may include removing the DUG header from the IP packet. The method may further include sending the IP packet to a network node.BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be had from the detailed description below, given by way of example in conjunction with drawings appended hereto. Figures in such drawings, like the detailed description, are examples. As such, the Figures (FIGs.) and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Furthermore, like reference numerals ("ref.") in the FIGs. indicate like elements, and wherein:

[0006] FIG.1A is a system diagram illustrating an example communications system;

[0007] FIG. 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG.1A;

[0008] FIG.1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG.1A;

[0009] FIG.1D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG.1A;

[0010] FIG.2 illustrates an example of a TSN switch internal workflow, in accordance with an embodiment;

[0011] FIG. 3 illustrates an example of a 3GPP system architecture with TSN support, in accordance with an embodiment; and

[0012] FIG.4 illustrates an example packet data unit (PDU) set diagram, in accordance with an embodiment;

[0013] FIG.5 illustrates an example Application Data Unit (ADU) that may be fragmented into a smaller chunks, according to an embodiment;

[0014] FIG. 6 illustrates IPv6 header protocol extension for data unit groups (DUGs), in accordance with some example embodiments;

[0015] FIG. 7 illustrates an example of the IPv4 header extension to signal DUG information, according to an embodiment;

[0016] FIG. 8 illustrates an example representation of DUG Detection Rules, according to an embodiment;

[0017] FIG. 9 illustrates an example signaling diagram for setting up a DUG, according to an embodiment;

[0018] FIG. 10 illustrates an example signaling diagram depicting uplink procedures for DUG IP packets, according to an embodiment;

[0019] FIG.11 illustrates an example signaling diagram depicting downlink procedures for DUG IP packets, according to an embodiment;

[0020] FIG. 12 illustrates an example of TSN switch flow operations, according to an embodiment;

[0021] FIG. 13 illustrates an example topology of a TSN-enabled 3GPP network with a TSN domain, according to an embodiment;

[0022] FIG. 14 illustrates an example signaling diagram for registering DUG-enabled TSN switches and / or TSN-capable UEs and / or UPFs with the CNC, according to an example embodiment; and

[0023] FIG.15 illustrates an example signaling diagram for establishing a new end-to-end flow with the DUG feature enabled across domains, according to an example embodiment. DETAILED DESCRIPTION

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

[0025] Example Communications System

[0026] The methods, apparatuses and systems provided herein are well-suited for communications involving both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with respect to FIGs. 1A-1D, where various elements of the network may utilize, perform, be arranged in accordance with and / or be adapted and / or configured for the methods, apparatuses and systems provided herein.

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

[0028] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated 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 a "STA", may be configured to transmit and / or receive wireless signals and may include (or be) a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, 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, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d, or any other WTRU mentioned or described herein, may be interchangeably referred to as a UE.

[0029] The communications systems 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 configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d, e.g., to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the networks 112. By way of example, the base stations 114a, 114b may be any of a base transceiver station (BTS), a Node-B (NB), an eNode-B (eNB), a Home Node-B (HNB), a Home eNode-B (HeNB), a gNode-B (gNB), a NR Node-B (NR NB), 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.

[0030] 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), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, i.e., one 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 or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0031] 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).

[0032] More specifically, as noted above, the communications 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, and the like. 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 establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0033] 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), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0034] 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).

[0035] 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 implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

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

[0037] The base station 114b in FIG.1A may be a wireless router, Home Node-B, Home eNode- B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In an 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 an embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of a small cell, picocell or femtocell. As shown in FIG.1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0038] 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 varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc.,and / or perform high-level security functions, such as user authentication. Although not shown in FIG.1A, 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 be utilizing an NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing any of a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi radio technology.

[0039] 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 circuit-switched telephone networks that provide 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), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications 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 / 114 or a different RAT.

[0040] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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 over different wireless links). For example, the WTRU 102c shown in FIG.1A 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.

[0041] FIG.1B is a system diagram illustrating an example WTRU 102. As shown in FIG.1B, the WTRU 102 may include 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 elements / peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0042] 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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, anyother type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, 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. While FIG.1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together, e.g., in an electronic package or chip.

[0043] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in an embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In an embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0044] Although the transmit / receive element 122 is depicted in FIG.1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. For example, the WTRU 102 may employ MIMO technology. Thus, in an 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.

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

[0046] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or 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 the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read- only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital(SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0047] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the 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, and the like.

[0048] 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 over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0049] The processor 118 may further be coupled to other elements / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality and / or wired or wireless connectivity. For example, the elements / peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (e.g., for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (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, and the like. The elements / peripherals 138 may include one or more sensors, the sensors may be one or more of 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.

[0050] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the uplink (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., aseparate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the uplink (e.g., for transmission) or the downlink (e.g., for reception)).

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

[0052] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-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 an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0053] Each of the eNode-Bs 160a, 160b, and 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 the uplink (UL) and / or downlink (DL), and the like. As shown in FIG.1C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0054] The CN 106 shown in FIG.1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the CN operator.

[0055] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c 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, and the like. 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.

[0056] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the 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 user planes during inter-eNode-B handovers, triggering paging when DL data is available for theWTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0057] 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.

[0058] 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 communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves 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 the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0059] Although the WTRU is described in FIGs. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0060] In representative embodiments, the other network 112 may be a WLAN.

[0061] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad-hoc" mode of communication.

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

[0063] High throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0064] Very high throughput (VHT) STAs may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse fast fourier transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above-described operation for the 80+80 configuration may be reversed, and the combined data may be sent to a medium access control (MAC) layer, entity, etc.

[0065] Sub 1 GHz modes of operation are supported by 802.11af and 802.11ah. The 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 5 MHz, 10 MHz and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine-type communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0066] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel which may be designated as theprimary channel. The primary channel may have a bandwidth equal to the largest 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, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0067] In the United States, the available frequency bands, which may be used by 802.11ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz depending on the country code.

[0068] FIG.1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an 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.

[0069] 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 an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the WTRUs 102a, 102b, 102c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the 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).

[0070] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. 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 gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., including a varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0071] 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 the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0072] 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 the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and the like. As shown in FIG.1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0073] The CN 115 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and at least one Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0074] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b, e.g., to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 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 massive mobile broadband (eMBB) access, services for MTC access, and / or the like. 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 Wi- Fi.

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

[0076] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, e.g., 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, and the like.

[0077] 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 serves 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 the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c may be connected to a local DataNetwork (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

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

[0079] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the one or more, 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. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or may performing testing using over-the-air wireless communications.

[0080] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0081] Embodiments disclosed herein are representative and do not limit the applicability of the apparatus, procedures, functions and / or methods to any particular wireless technology, any particular communication technology and / or other technologies. The term network in this disclosure may generally refer to one or more base stations or gNBs or other network entity which in turn may be associated with one or more Transmission / Reception Points (TRPs), or to any other node in the radio access network.

[0082] It is noted that, throughout example embodiments described herein, the terms “serving base station”, “base station”, “gNB”, collectively “gNB” may be used interchangeably to designate any network element such as, e.g., a network element acting as a serving base station. Embodiments described herein are not limited to gNBs and are applicable to any other type of base stations.

[0083] Introduction

[0084] Time Sensitive Networking

[0085] Industrial applications usually have rather stringent timing requirements for inter- machine or machine to human (and vice versa) interactions. Hence, IEEE standardised a set of specifications under the umbrella term “Time-Sensitive Networking (TSN)”. TSN provides a vendor-independent and open solution for time-sensitive communication.

[0086] TSN Operations

[0087] TSN is a collection of IEEE 802.1 and 802.3 standards enabling time-sensitive (e.g., deterministic) communications for compute nodes, e.g., network switches. In order to achieve timely delivery of data in a packet-switched network, IEEE demands that all TSN-enabled switches are time synchronised, as defined in 802.1AS. All operations within a switch are cycle- based where each cycle has the exact same length with a minimum cycle time of 30µs up to several milliseconds (defined in 802.1Qbv). FIG.2 illustrates the internal workflow of a TSN switch with a detailed description of each component and the related IEEE standard discussed below.

[0088] As illustrated in FIG.2, Port 1, Port 2, Port 3, … Port n are the switch ports implementing IEEE’s 802.3 standard to handle Ethernet frames. A multiplexer, Mux In 205, serialises the incoming packet(s) based on their arrival time and hands them over to a priority filter 210. This priority filter 210 follows IEEE’s 802.1cb specification and aims to identify the priority of packets by identifying to which stream of packets they belong to. IEEE defines a range of headers to be looked at to make these decisions, i.e., destination / source MAC address, VLAN tag, source / destination IP addresses, transport protocols (UDP / TCP), or source / destination port numbers. Based on this configurable prioritisation, the TSN switch places a packet into a set of queues, denoted as {Q1, Q2, Q3, …, Qn} in FIG. 2. Each queue represents a different level of configurable priority allowing the re-ordering / pre-emption engine 215 to change the position of each packet within a queue in respect to other packets in other queues. This allows for more important / time-critical packets to be delivered and – if needed – less important packets to be dropped. The last step in this chain is another multiplexer 220 to place the packets out on the respective ports of the switch.

[0089] As mentioned above, TSN switches offer flexibility on the chosen priorities, how they are determined and what is placed in which queue. The required configuration can be either done by hand directly on the switch or through programmable methods. IEEE leverages well-established methods and technologies to achieve that, i.e., YANG models combined with NETCONF or RESTCONF frameworks. The result is IEEE’s own YANG model implementing possible identification rules for TSN switches in 802.1cb. To logically centralise the control and management of a TSN network, a Central Network Controller (CNC) is defined in IEEE 802.1Qcc to obtain TSN bridge capabilities and to enable the configuration of TSN switches in a more automated fashion.

[0090] TSN Support in 3GPP Networks

[0091] In Rel.16 and Rel.17, 3GPP has standardised the support for IEEE 802.1 TSN networks and centres the integration around IEEE’s 802.1Q standard (3GPP TS 23.501), which defines the use of VLAN Identifiers to allow switches to perform port-switching based on the Layer 2 identifiers. FIG.3 illustrates 3GPP’s support for TSN from a system architecture point of view and depicts the entire 3GPP network exposed as a single TSN bridge 300 with two ports, the Device- Side Translator (DS-TT) 305 and the Network-Side Translator (NW-TT) 315. Furthermore, 3GPP also defines a dedicated TSN Application Function (AF) 320 responsible for the exposed 5GS bridge management and the port management for DS-TT 305 and NW-TT 315. Furthermore, 3GPP supports the Link-Layer Discovery Protocol (LLDP) defined by IEEE (e.g., in 802.1ab) to discover the topology of a TSN network.

[0092] To support TSN traffic, 3GPP relies on Ethernet protocol data unit (PDU) session types to carry VLAN-tagged packets on its User Plane (UP) and the illustrated 3GPP UP components, i.e., DS-TT 305, UE 307, (R)AN 310, UPF 317, NW-TT 315, are sychronised to the same 5G Grand Master Clock. This allows the support of the Generic Precision Time Protocol (gPTP), e.g., as defined in IEEE 802.1AS, whereby NW-TT 315 and DS-TT 305 can generate ingress gPTP timestamps on the 5GS reference time. Once the gPTP packet leaves the 3GPP system, an egress time is added allowing to determine the residence time of packets in the 5GS. To automate the control and management of TSN bridges, e.g., the 5GS, the TSN AF 320 may interface with a CNC to expose TSN bridge capabilities and properties as well as receiving requests from the CNC to configure rules in a TSN bridge.

[0093] Packet Data Unit Sets in 3GPP

[0094] 3GPP Rel.18 introduced support for XR sessions and PDU sets allowing the system to serve different QoS-sensitive service flows to a single or multiple UEs that are collectively participating in a single application. For instance, sensing data (e.g., sensing data formats) canrange from pure text-based periodic short bursts of numeric values to actual video streams for machine-based processing. The sensing data collectively forms the input to the algorithm that determines the sensing result, while the core network is chartered with processing the sensing data. A sensing data type (e.g., numeric vs video) will have its own QoS Flow with different QoS requirements (e.g., 5QIs) and the set of these QoS Flows form the sensing service. This Rel.18 feature is bundled with an underlying TSN-enabled Ethernet PDU session which implements a deterministic networking (DetNet)-compliant Data Plane.

[0095] FIG.4 is a diagram that illustrates the features of PDU Sets and Multi-Modal Data Flows, e.g., as described in 3GPP TS 23.700-60. PDU Sets can give the 5G network (e.g., 5GS) 400 the ability to understand which PDUs belong to an application-related data unit which can only be used for further processing (e.g., by the application) if received in full. For instance, if the PDU Set forms a video frame or a sensing data result, the 5GS 400 can ensure the correct delivery of the PDU Set and apply potential re-delivery of PDUs within a PDU Set within the RAN via hybrid automatic repeat request (HARQ) retransmissions. In some cases, e.g., if for any reasons the 5GS must drop packets to deliver on the indicated 5QIs, it may be advisable if entire PDU Sets are dropped to free up resources for other PDU Sets to be delivered in their entirety.

[0096] Moreover, 3GPP TS 23.700-60 also introduces the concept of Multi-Modal Data Flows, which allows the 5GS 400 to identify inter-related QoS flows distributed across multiple UEs that are serving the same application. For instance, if QoS Flow 1 is radar sensing data and QoS Flow 3 video sensing data, the 5GS can ensure that both flows are treated as a Multi-Modal Data Flow, e.g., for combined consumption of an ML-based analytics engine that processes the sensing data.

[0097] Table 1 below provides the PDU set markings for identifying RTP header fields to fill out PDU set markers, as specified in 3GPP TS 26.522. TABLE 1

[0098] To mark packets as a PDU Set, may include the detection of packet streams using header information. 3GPP studied the dominant protocols used to stream media content, e.g., in section 6.7 of TS 23.700-60, and covered protocols such as RTP and HTTP. For RTP, the actual RTP header is extensively analysed to derive the PDU Set Markings; For HTTP, the underlying transport protocols UDP and TCP are considered to track streams of packets for the same PDU Set. However, the actual specification work, e.g., in 3GPP TS 26.522, does not mention any HTTP- based PDU Set markings.

[0099] UDP Header Extensions for Wireless Networks

[0100] There has been an effort in the Transport Services Working Group (TSVWG) to define a User Datagram Protocol (UDP) solution to convey PDU Set information for application layer protocols that rely on UDP, e.g., HTTP / 3 or QUIC. The IETF Internet Draft, TSVWG, 2023 (J. Kaippallimalil, S. Gundavelli, and S. Dawkins, “Media Header Extensions for Wireless Networks”) defines a group of packets that should be handled similarly (e.g., all packets of a video I-frame) as a Media Data Unit (MDU). A range of meta parameters are proposed as an extension header to UDP. These include: ^ Profile: A profile for added metadata, allowing the proposed extension to enable more metadata profiles then the one covered in this draft ^ Importance: the importance of the packet (delay tolerance, inter-MDU dependency or a priority level) ^ Burst Size: The number of bytes of data in a continuous stream of packets. ^ Delay Budget: An upper bound in milliseconds between the reception of the first packet of the MDU pot the last packet of the MDU. ^ MDU Sequence: A cyclical counter that has the same value for an MDU.^ Packet Counter: A counter for the packets within an MDU that increments for each subsequent packet. ^ Timestamp: An absolute data and time as defined in RFC5905 used for network jitter calculations.

[0101] The sending application is foreseen to inject or include the UDP header extension.

[0102] Overview

[0103] In today’s networks, QoS treatments and scheduling are performed primarily at the granularity of the packet. While there are advantages to this, the lack of knowledge and / or the consideration of information carried in packets, prevents today’s networks from optimizing procedures for application layer data / information units (e.g., treating packets that belong to the same video frame collectively, may allow networks to avoid retransmissions due to packet loss, end-to-end).

[0104] A primary candidate for the identification of PDU sets is RTP header fields, e.g., focussing on carrying media content (audio or video) across compute networks. However, the focus on RTP-based communication makes it unsuitable for other (non-RTP based) applications that could greatly benefit from the approach, e.g., industrial applications with the requirement to rather get the full application data unit to the receiving end.Industrial applications usually utilise JSON / XML / Protobuf application formats over HTTP or plain TCP / UDP with the possibility of enabling encryption, e.g., TLS in case of HTTP. It is noted that HTTP has been assessed during the study phase in 3GPP. But as a result of the usage of encryption techniques, such as the usage of TLS, any intermediate network node would not be able to access information in the application data unit header, e.g., HTTP header, to retrieve information about the length of the application data unit in order to determine which underlying Layer 2, 3 or 4 packets carry the single application data unit. Consequently, a problem arises on how to enable protocol-independent identification of fragmented application data in a 3GPP network to map it to a PDU Set in both up- and downlink allowing the RAN to schedule its radio resources more accurately for any IPv4 / v6-based communication.

[0105] The ability to extend existing protocol headers allows for a more versatile and programmable behaviour of compute nodes, such as switches and / or routers. For instance, one of the advantages of IPv6 over IPv4 is the requirement of routers to only check mandatory IPv6 header fields. Extension headers must follow a specific sequence in the header but are recommended to be ignored if not needed allowing the router to operate at higher speeds. On the contrary, IPv4 header fields must all be parsed by a router making it slower when adding more information to the header. For security reasons, packets with unknown (but optional) headers canbe treated as a thread and rejected. Therefore, when introducing new header fields, special care must be taken to ensure that the added fields do not interfere with the normal operations of the protocols when traversing two or more computer networks.

[0106] In Rel. 16 and 17, 3GPP specified the support of TSN by defining functionalities and procedures of a TSN AF and the support of Device-Side and Network-Side Translators acting as TSN switches, as described above. TSN follows the concept of identifying and classifying continuous streams of incoming packets and applying traffic engineering methods for time- sensitive applications. However, the applicability of the PDU Sets functionality is limited to the 3GPP domain only and does extend to the TSN domain. Thus, a problem arises of how to extend the concept of PDU Sets to the TSN domain, enabling the computer networks to offer application- layer protocol independent grouping of packets carrying an application data unit.

[0107] Overview of Example Embodiments

[0108] Some example embodiments, as described herein, can enable at least the usage of protocol data unit (PDU) Sets in 3GPP and TSN-enabled 3GPP networks, for example, using proposed extensions to the internet protocol (IP) header. This can provide for a more universal approach, e.g., compared to real-time transport protocol (RTP) or hypertext transfer protocol (HTTP)-only solutions that are currently in focus in 3GPP. An embodiment includes the introduction of a Data Unit Group (DUG) to describe and / or include the entirety of an Application Data Unit (ADU) and its fragmentation into individual IP packets to be delivered over a packet-switched network. For example, certain example embodiments define and / or provide DUG Rules to communicate packet header detection rules and additional action rules, e.g., to write PDU Set Markings on the UE (e.g., WTRU) and UPF. Some example embodiments may also provide a detailed description of how IPv4 and IPv6 headers are extended in order to allow the DUG Rules to take effect.

[0109] Certain example embodiments, as discussed herein, may include one or more processes or procedures in the UE (e.g., WTRU) and / or network, for example, to enable the extension of the PDU Set construct to a TSN-based computer network, in addition to providing solutions for application layer-independent identification of PDU Sets.

[0110] Uplink User Plane Procedures

[0111] According to some embodiments, a WTRU may receive rules for detecting DUGs in incoming protocol headers and may receive information on what action is to be performed upon the detection of the headers. The WTRU may receive one or more packets. For example, a packet may be received from an application or via a local network interface other than the data port of the modem.

[0112] In an embodiment, the WTRU may check the DUG rules to determine which protocol to watch out for and the header field. If an IP protocol is present in the packet, the WTRU may detect that it is an IPv4 packet or may detect that it is an IPv6.

[0113] In an embodiment, on condition that IPv4 is detected, the WTRU may check and / or determine whether the Options field has type length values (TLVs) to be read. If the WTRU determines that the Options field has TLVs to be read, the WTRU may check or determine that the DUG TLV type is present and read (e.g., determine the contents of) the DUG Sequence and DUG flags. The WTRU may also read or determine the IPv4 Identification header value.

[0114] In an embodiment, on condition that IPv6 is detected, the WTRU may check and / or determine whether the Hop-by-Hop header extension is present. If the WTRU determines that the Hop-by-Hop header extension is present, the WTRU may check for (e.g., may determine) the DUG Sequence and DUG Flags TLV in the header extension and read or determine their values. Alternatively, the WTRU may check (e.g., may determine) the values from the DUG Sequence and DUG Flags TLV from a single DUG TLV, for example, which may carry all the values described in FIG.6. The WTRU may also read or determine the IPv6 flow label.

[0115] In an embodiment, the WTRU may identify (e.g., may determine or locate) the PDU Set Markers using (e.g., based on) the obtained DUG information. Thisallows the RAN to schedule the radio resources more accurately as well as N3 endpoints when applying QoS differentiation to its packet forwarding scheduler.

[0116] According to certain embodiments, a network element, such as a UPF, may receive DUG rules indicating to remove the DUG header of an IP packet for a specific GTP-U flow. One or more GTP-U packets may be received, e.g., via N3 or other interface, with a PDU Set GTP-U header extension. The network element (e.g., UPF) may check or determine what DUG rules (e.g., packet detection rules (PDRs)) have been received for this uplink flow. In one embodiment, the network element (e.g., UPF) may find the instructions to remove the DUG header field. For IPv4, the DUG options header is removed from the packet. Once done, the IPv4 header checksum may be re-calculated and placed in the respective IPv4 header field. For IPv6, the DUG header extension is removed from the packet. Once done, the IPv6 header checksum may be re-calculated and placed in the respective IPv6 header field. The network element (e.g., UPF) may release the IP packet according to its flow configurations.

[0117] Downlink Data Unit Group Handling Procedures

[0118] According to certain embodiments, a first network element, such as a UPF, may receive (e.g., may receive information indicating) DUG rules that may indicate (e.g., may include an indication or rule) to inspect incoming traffic (e.g., N6 and / or N9 traffic) based on DUGinformation in IP packets. For instance, the DUG rules may be received from another network element, such as a SMF.

[0119] In an embodiment, the first network element (e.g., UPF) may receive at least one packet. For example, one or more of the packet(s) may be received on a network port of the network element, such as its N6 or N9 network port. The first network element (e.g., UPF) may check if (e.g., may determine that) the packet is an IP packet and, if so, may determine which IP version using the IP header.

[0120] In an embodiment, on condition that (e.g., it is determined that) the received packet is an IPv4 packet, the first network element (e.g., UPF) may check for the existence of the IP header options and, if present, may check for DUG TLVs. If DUG TLVs are present, the first network element (e.g., UPF) may read (e.g., may determine the contents or value of) the DUG Sequence and DUG Flags TLVs fields. The first network element (e.g., UPF) may read (e.g., may determine the contents or value of) the identification IPv4 header field.

[0121] In an embodiment, on condition that (e.g., it is determined that) the packet is an IPv6 packet, the first network element (e.g., UPF) may check for the existence of (e.g., determine the presence of) the hop-by-hop header extension. On condition that the hop-by-hop header extension is present, the first network element (e.g., UPF) may read (e.g., may determine the contents or value of) the DUG Sequence and DUG Flags TLVs fields. The DUG values can also be included in a single DUG TLV, instead of two TLVs (i.e. DUG Sequence and DUG Flags).The first network element (e.g., UPF) may read (e.g., may determine the contents or value of) the Flow Label IPv6 header field. The first network element (e.g., UPF) may create the GTP-U header and identify the PDU Set header extension for GTP-U by reading the DUG IP header information.

[0122] According to certain embodiments, a WTRU may receive DUG rules indicating (e.g., including information about how) to manipulate a protocol header. For example, the DUG rules may indicate to detect a protocol header, e.g. IPv4 or IPv6, and to identify a specific header field and / or value (or any value) to watch out for (e.g., to identify). In addition, the DUG rules may indicate an action to take. For example, one of the actions may include to remove the header field. In an embodiment, the WTRU may receive a packet from a network (e.g., the AN). The WTRU may check and / or determine whether it has matching packet header manipulation rules for the incoming packet. The WTRU may find and / or identify matching packet header manipulation rules for IP headers and, if present, remove DUG extension headers. For example, if IPv4, the WTRU may remove the DUG TLVs from the options header and may re-calculate the IPv4 header checksum. As another example, if IPv6, the WTRU may remove the DUG TLVs from the hop- by-hop IPv6 extension header and may re-calculate the IPv6 header checksum. The WTRU mayrelease the packet allowing its remaining URSPs to decide where the packet will be sent to (local application or local network port).

[0123] Data Unit Group-Based Packet Prioritisation, Re-Ordering and / or Pre-Emption in Time- Sensitive Networking Compute Nodes

[0124] According to certain embodiments, a node may have received a set of DUG rules to detect a packet and an action to place it into a specific priority queue. In addition, the node may receives instructions and / or rules on how to treat identified DUGs in a specific queue. For example, in some embodiments, the node may be a TSN switch, DS-TT (e.g., at WTRU), and / or NW-TT (e.g., at UPF).

[0125] In an embodiment, a node may receive one or more packets on one of its network ports. The node may read and / or determine the protocol headers of the packet and finds IPv4, IPv6 or UDP, for example. The node may use the received DUG rules to match them against one, all, or a mix of DUG-related information from the IP header and may place the packet into a priority queue. The node may apply the desired timing behaviour to the identified DUG in any queue.

[0126] Detailed Description of Representative Example Embodiments

[0127] As introduced above, certain example embodiments may provide solutions for 3GPP and / or TSN-over-3GPP computer networks that extend and / or apply a PDU set approach to the application-layer protocols and across the TSN and / or 3GPP computer networks.

[0128] Modern applications often send data which does not fit into a single packet on Layer 2 or 3. As a result, a single Application Data Unit (ADU) may be fragmented into smaller chunks with a maximum length of each chuck determined by the underlying computer network and its Maximum Transmission Unit (MTU), as illustrated in the example of FIG. 5. As shown in the example of FIG.5, an ADU 505 may be fragmented into three IP packets 510 each comprising an IP header and payload. It should be noted that, although FIG. 5 shows an example in which an ADU is fragmented or divided into three packets, an ADU could be divided into any number of packets. As one non-limiting example, a UHD video frame, for instance, may be carried by more than one IP packet. The set of packets that carry the entirety of a single ADU may be defined or referred to herein as a Data Unit Group (DUG).

[0129] Consequently, when the entire DUG is successfully exchanged between the sender and receiver, the receiving application will be able to retrieve the ADU as provided by the sender. In contrast, if a single packet went missing between the sender and receiver, the receiving application will not be able to read the ADU in its entirety.

[0130] While the usage of unreliable transport protocols, e.g., UDP, does not fundamentally change the illustration above by which each IP packet can carry a fragment of the ADU, whenusing reliable protocols, such as TCP, the resulting IP stream defining the DUG is split into control packets that carry the necessary Layer 4 control information and the actual data frames. As these control frames are equally important to allow the sender and receiver to complete their exchange of the Application Data Unit (ADU), special considerations should be taken in order to not interfere with the semantics of reliable transport protocols.

[0131] Over recent decades, packet-switched networks in combination with the IP protocol suite have become the norm in enabling a digital communication across a range of computer networks including mobile networks. Also, Internet Protocol (IP) in its both versions (Version 4 and Version 6) are seen as the common lowest OSI layer denominator across a wide range of computer networks, making this protocol suite – and the IP protocol itself – an important component.

[0132] When looking at suitable protocol candidates for possible extension or improvement to support Data Unit Groups (DUGs) and to allow the signalling of DUG information from generic internet applications to lower layers, some constraints were identified. For example, it is desirable that the chosen protocol: (1) allows extension by IETF without demanding backwards compatibility challenges for devices that do not support any proposed extension, (2) is supported by the majority of communication devices, and / or (3) does not prevent information access by switches and routers using encryption.

[0133] Some example embodiments provide for the introduction of DUG as an extension to the IP header for both dominant IP versions, i.e. IPv4 and IPv6. As extending IPv4 and IPv6 headers follow different procedures set out in IETF, certain example embodiments may be based on which version of IP is being used.

[0134] IPv6 addresses the challenge of allowing routers to perform faster in comparison to the earlier IPv4. IPv6 achieves this by allowing network nodes to parse (e.g., only parse) the IPv6 headers it requires to check to perform its actions. In order to comply with this requirement and to follow the guidelines on how to design IPv6 header extensions, i.e. using Type Length Values (TLVs), new IPv6 TLVs are defined, as illustrated in the example of FIG.6. In particular, FIG.6 shows the proposed IPv6 header protocol extension for DUGs, in accordance with some example embodiments. Alternatively, the illustrated two DUG TLVs can also be a single TLV which carries all the DUG information, as illustrated in FIG.6.

[0135] In an embodiment, as the order of extension headers are fixed in IPv6, the DUG-related information may be added to an appropriate IPv6 header. One purpose of the proposed DUG TLVs is for an intermediate node to read the values and perform any sort of traffic engineering upon them. Thus, the “Hop-by-Hop” options header is identified as an appropriate option, since intermediate nodes – such as 3GPP UEs / UPFs or TSN switches – can process the DUG-relatedinformation. The two new DUG TLVs defined are described in detail in Table 2 below. More specifically, Table 2 shows the TLVs for the DUG IPv6 extension header, according to certain embodiments. TABLE 2

[0136] The Flags TLV has a set of values that are presented and described in Table 3 below. More specifically, Table 3 illustrates the details of the TLV flag for the DUG IPv6 header extension, according to some example embodiments. Table 3

[0137] With respect to IPv4, the IP modules that receive an IPv4 packet are to implement the ability to read each field, which may make it less versatile to extend it with new header information as compared to IPv6. The Options field in the IPv4 header allows the addition of information to the IPv4 header and is variable in length with a maximum possible length of 40 bytes. Adding a new option may require to define the option by a 1 octet-long “option-type”, an “option-length” octet and the actual data in a multiple of 8 bits (1 octet) again. Furthermore, the “option-type” field comes in a pre-defined three-field octet indicating: ^ 1 bit: Will the option be copied into all fragments in case IP fragmentation takes place. ^ 2 bits: Identification of the classes the value represents (0: control; 1: reserved for future use; 2: debugging and measurement; 3: reserved for future use). ^ 5 bits: The option number helps IP modules that read the header to interpret the meaning and implement a certain usage based on it. The known option-type values are defined as IPv4 parameters (e.g., by IANA, “Internet Protocol Version 4 Parameters”, 2018).

[0138] To extend the IPv4 header with DUG-related information, a single 2 octet-long option may be used. For example, the option-type may be set to: ^ Copy: 1 ^ Class: 0 ^ Value: To be decided (e.g., based on IANA)

[0139] FIG. 7 illustrates an example of the IPv4 header extension to signal DUG information, according to an embodiment. The option-length field may indicate 16 bits with the structure of the option-value field, as illustrated in the example of FIG. 7. The meaning of each field may correspond to (e.g., may be similar to) the IPv6 fields, as provided in Table 2 above. To indicate the end of the options list, a 1 octet of 0s may be added to the end of the options list.

[0140] In an embodiment, a network element, such as a PCF (or other control node or function), may send Policy and Charging Control (PCC) Rules for a PDU Session to another network element, such as the SMF (or other session management node or function). The PCC Rules mayindicate, e.g., to the SMF, that one or more IP Flows of the PDU Session are expected to carry packets with the DUG extension header.

[0141] According to an embodiment, the network element, e.g., the SMF, may provide DUG Rules to the UE. For example, the DUG rules may be provided to the UE during a PDU Session Establishment or PDU Session Modification procedure. However, the DUG rules could be provided at other times or instances. For example, the DUG Rules may include an indication of which IP / UDP Flows of the PDU Session are expected to carry packets with the DUG extension header. The DUG Rules may be sent to the UE in one or more messages, such as a PDU Session Establishment Accept message and / or a PDU Session Modification Command message. The DUG Rules may be part of the QoS Rules or they may be part of any other rule, such as a rule that lists IP Flows and allows the SMF it indicate for which flows the DUG extension header is enabled.

[0142] Alternatively, the DUG Rules may be sent to the UE by another network element, such as the PCF, as part of a URSP Rule. For example, the indication maybe part of a traffic descriptor of a URSP Rule. In other words, the PCF may indicate that any traffic that matches the traffic descriptor has the extension header is enabled.

[0143] The DUG Rules may indicate certain actions that the UE should take when it detects a packet that matches the rule. One example action is whether to forward the matching packet to a local application or a local network port. Another example action is to determine PDU Set information from the packet header and forward the PDU Set Information to the upper-layer (e.g., SDAP or PDCP layer) of the RAN protocol stack. Another example action is to remove the DUG header option before forwarding the packet. Other actions are also possible and may be indicated to the UE.

[0144] DUG Rules can be categorised into detection and action rules for processing packets. DUG Detection Rules may indicate the protocol header to check for, e.g. IPv4, IPv6 or UDP, and / or the exact header field, e.g. DUG header extension. The action may then define what to do with the packet once a Detection Rule found the referred header. Example actions may include, but are not limited to, “drop” or “remove DUG header”. FIG. 8 illustrates an example representation of DUG Detection Rules using JSON, in accordance with one example embodiment.

[0145] As discussed in the following, some example embodiments include a DUG flow-set up in a 3GPP system and the enforcement of the rules in network entities, such as the UE and / or UPF (or other similar entities), which can allow the 3GPP system to utilise the PDU Set feature across all IP traffic. FIG. 9 illustrates an example signal or message sequence diagram showing the procedures or operations to set up a DUG within a 3GPP system following the procedures for AFsto influence traffic of an individual UE. It is noted that the operations discussed below may also apply to cases where the AF aims to influence traffic routing not identified by a UE address. In both cases, it may be assumed that the UE has already established a PDU session for these procedures to be permitted. It is noted that certain embodiments may include any one or more of the procedures or operations illustrated in the example of FIG.9. In other words, one or more of the procedures or operations may be omitted, replaced or executed in a different order or between different entities than what is illustrated in the example of FIG.9. Thus, FIG.9 is provided as one example of a process according to an embodiment, and variations and modifications thereto are contemplated according to other embodiments discussed elsewhere herein.

[0146] As illustrated in the example of FIG.9, at 1, the AF may signal a request towards the NEF for a new application flow to be set up. The request may indicate that the new application flow will use the newly proposed IP header extension for a Data Unit Group and / or the UDP header extension described in IETF Internet Draft, TSVWG, 2023 (J. Kaippallimalil, S. Gundavelli, and S. Dawkins, “Media Header Extensions for Wireless Networks”). Using the standardised fields in the request allowing the UE and / or UPF to detect traffic (e.g., IP version, transport protocol, destination port number, destination IP address), the AF may indicate whether the DUG header extension is present. The AF may also indicate that the UE and / or UPF are to remove any IP extension header to allow better compatibility with non-DUG-supportive switching and routing equipment in the DN or beyond the UE (e.g., when tethered or connected to a TSN network via a DS-TT).

[0147] As also illustrated in the example of FIG.9, at 2, the NEF may communicate (e.g., send or transmit) the received information from the AF to the PCF allowing it to perform the required policy-related checks on the request; in this communication, the NEF may include the information that the AF requested to influence traffic for a DUG-enabled service. In case the AF did not address a specific UE, the PCF may communicate with the UDR to store and / or update information including the information that the AF requested to influence traffic for a DUG-enabled service. As a result, the UDR may notify the PCF about the AF update.

[0148] In the example of FIG.9, at 3, the PCF may determine the PDU sessions that are impacted by the AF’s request and may inform the SMF with new policy information about the PDU Session for a DUG-enabled application. At 4, the SMF may perform the UPF selection procedures (e.g., as defined in TS 23.501). In addition to the currently standardised steps, the SMF may take the DUG-support of UPFs into account to determine which UPFs would be selected for handling this flow. The SMF may generate session management parameters for UPF for supporting DUGs. For example, the SMF may enhance Packet Detection Rules (PDR), QoS Enforcement Rules (QER)and / or Forward Action Rules (FAR) to detect DUG related header information in traffic and perform various actions at the packet group level (e.g., use DUG information when creating PDU and PDU sets, buffer, and forward packets that are in the same group together, apply same QoS treatments to packets belong to the same group).

[0149] As illustrated in the example of FIG.9, at 5, the SMF may request the establishment of a new session or modification of an existing one towards the selected UPF(s). This message may include the enhanced session management parameters which comprises DUG-related information. At 6, the UPF may optionally store the new / updated session management parameters which includes the information to identify DUG-based traffic. At 7, the UPF may confirm the session establishment or modification request to the SMF.

[0150] In the example of FIG. 9, at 8, to create the required communication resources in the RAN, the SMF may request the transfer of N1 and N2 information to the AMF. At 9, the AMF may identify the gNB to be addressed and may send a request to modify the necessary RAN resources. At 10, e.g., as a result of the request message to modify the necessary RAN resources, a RAN node (e.g., gNB or similar node) may configure the required radio resources and may communicate (e.g., send information related to) various radio- and network-related configurations to the UE in question.

[0151] As further illustrated in the example of FIG.9, at 11, based on the received radio and / or network-related configurations, the UE may install, implement and / or use the provided DUG Rules which allow it to identify the IP stream with the DUG extension header (as will be discussed in further detail below, e.g., with respect to FIG.10). Detecting the DUG extension header in uplink traffic may trigger the UE (e.g., the NAS layer of the UE) to send PDU Set-related information to an upper-layer (e.g., SDAP or PDCP layer) of the RAN protocol stack. At 12, the AN may confirm (e.g., send a confirmation of), e.g., to the AMF, the request to modify the RAN resources.

[0152] It is noted that FIG.9 is provided as one example of a process according to an embodiment, and that variations and modifications thereto according to other embodiments discussed herein are contemplated.

[0153] As discussed in the following, certain example embodiments provide procedures for identifying a DUG using the provided IP header extensions with the outcome to map it to PDU Set Markings, e.g., thereby allowing the 3GPP User Plane to take advantage of the PDU Set capabilities. FIG. 10 illustrates an example signal or message flow diagram depicting uplink procedures for DUG IPv4 and IPv6 packets, according to an embodiment. It is noted that certain embodiments may include any one or more of the procedures or operations illustrated in the example of FIG.10. In other words, one or more of the procedures or operations may be omitted,replaced or executed in a different order or between different entities than what is illustrated in the example of FIG. 10. As an example, it is contemplated that one or more of the procedures or operations illustrated in the example of FIG. 10 may be combined with one or more of the operations depicted in FIG.9. Thus, FIG.10 is provided as one example of a process according to an embodiment, and variations and modifications thereto are contemplated according to other embodiments discussed elsewhere herein.

[0154] As illustrated in the example of FIG.10, at 1, the UE may receive an IP packet from an application (e.g., a local application) with the DUG IP header extension being used. At 2, the UE may check for and / or determine the IP version of the received packet based on the configured DUG Rules. For example, the UE may identify or determine the packet as an IP Version 4 or IP Version 6 packet.

[0155] In the example of FIG. 10, if the IP packet is identified as Version 4, at 3, the UE may check for and / or determine the existence of the IPv4 DUG TLVs in the options field, following its definition discussed above (e.g., as shown in FIG.7 discussed above). If the IPv4 DUG TLVs are found, then the UE may map or associate DUG information to PDU Set Markings as shown at 4. If the UE identified the IP packet as Version 6, at 3, the UE may check for and / or determine the hop-by-hop header extension and the presence of DUG TLVs, as discussed above with respect to IPv6 (e.g., as shown in FIG.6 discussed above). If the IPv6 DUG TLVs are found, then the UE may map or associate DUG information to PDU Set Markings as shown at 4. If the UE, at 3, cannot find any DUG-related header information, the packet is not identified as a member of a DUG and no further steps apply under this set of DUG Rules.

[0156] As shown in the example of FIG.10, at 4, the UE identifies the DUG extension header information as discussed above and may write, provide and / or insert the PDU Set Markings, as indicated in Table 4 for IPv4 and in Table 5 for IPv6. In particular, Table 4 below shows the mapping of the IPv4 DUG header extension fields to PDU set marking, and Table 5 below shows the mapping of the IPv6 DUG header extension fields to PDU set marking. It is noted that the PDU Set Markings are currently standardised in 3GPP (e.g., TS 26.522) and the tables below merely serve as an example on the DUG to PDU Set Markings mapping based on the current information.Table 5

[0157] Continuing with the example of FIG.10, as shown at 5, the UE may send the IP packet to the AN where the GTP-U information is written and / or included so that the AN can send the IP packet to the UPF. The AN may forward the packet to the UPF via GTP-U signalling, for example. At 6, e.g., in order to increase the compatibility with routers in the DN that do not implement the proposed DUG IPv4 or IPv6 header extension, the UPF may have received a configuration from the AF (e.g., as discussed above with respect to and shown in FIG.9) that indicates that the UPF should remove this extension header for an uplink packet (e.g., for each uplink packet) that arrived via N3 before it leaves on N6. Also, if the packet traverses to another UPF via N9, the UPF may remove the DUG header extension (for IPv6) / option (for IPv4) or UDP. As shown in the example of FIG.10, at 7, the UPF may forward and / or send the IP packet towards the DN or alternatively to another UPF, for example.

[0158] In addition to the disclosed IPv4 / IPv6 header extensions, a UDP header extension, such as that described in described in IETF Internet Draft, TSVWG, 2023 (J. Kaippallimalil, S.Gundavelli, and S. Dawkins, “Media Header Extensions for Wireless Networks”), can be also used to write the PDU Set Markings, as illustrated in Table 6. Table 6

[0159] In an embodiment, using the UDP header extension, the end of the PDU Set and the end of a data burst within a set might not be distinguished from another and by counting the bytes sent within an MDU sequence, the UE can determine (e.g., only determine) either the end of the PDU Set or the end of the data burst using the burst size provided in the UDP header.

[0160] It is noted that FIG. 10 is provided as one example of a process according to an embodiment, and that variations and modifications thereto according to other embodiments discussed herein are contemplated.

[0161] As discussed in the following, certain example embodiments provide downlink procedures for a 5GS for DUG-enabled IP headers. FIG. 11 illustrates an example signal or message sequence diagram which covers both IPv4 and IPv6, according to some example embodiments. It is noted that certain embodiments may include any one or more of the procedures or operations illustrated in the example of FIG.11. In other words, one or more of the procedures or operations may be omitted, replaced or executed in a different order or between different entities than what is illustrated in the example of FIG.11. As an example, it is contemplated that one or more of the procedures or operations illustrated in the example of FIG.11 may be combined with one or more of the operations depicted in FIG.9. Thus, FIG.11 is provided as one example of a process according to an embodiment, and variations and modifications thereto are contemplated according to other embodiments discussed elsewhere herein.

[0162] As illustrated in the example of FIG.11, at 1, the UPF may receive a packet, for example, from the data network (DN). Alternatively, the packet can also arrive from another UPF, for example, via N9. The UPF may walk through (e.g., parse) its packet detection rules (PDRs) and may find rules for detecting packets belonging to a DUG. At 2, the UPF may check for and / ordetermine the IP version, i.e., IP Version 4 or IP Version 6. In an embodiment, if the packet is identified as IPv4, the UPF may use its session management rules (e.g., PDRs) instructing the UPF to check the options header field for the DUG TLVs and – once found – may read their values, as shown at 3, e.g., following the IPv4 Options header definition discussed above (e.g., as shown in FIG.7 discussed above). In an embodiment, If the UPF identified the packet as IPv6, the UPF may check for and / or determine the hop-by-hop header extension and may find the DUG-related TLVs, e.g., following the definition discussed above (e.g., as shown in FIG.6 discussed above).

[0163] In the example of FIG.11, at 4, the UPF may use and / or identify the DUG-related values from the incoming IP packet to write, insert and / or provide the PDU Set information of the GTP- U header. At 5, the UPF may send the packet to the UE. For example, in this embodiment, the packet may be sent to the UE via the AN. The UE may then take an action with respect to the packet according to any received DUG Rules. For example, as shown at 6 in FIG. 11, if the UE has received DUG Rules to remove the IPv4 DUG header option or IPv6 header extension, the UE may remove the DUG IP header fields as indicated in the DUG Rules. It is noted that the removing of the DUG IP header fields is provided as one example action that may be taken by the UE, and that other actions are contemplated according to other embodiments. At 7, the UE may send the IP packet to the application (e.g., to a local application); alternatively, or additionally, the UE may send the packet out on a local network port depending on the configured DUG Rules. As for the uplink procedures, in one example embodiment, the UPF may also receive DUG rules to write, insert and / or provide PDU Set Markings using UDP header information.

[0164] It is noted that FIG. 11 is provided as one example of a process according to an embodiment, and that variations and modifications thereto according to other embodiments discussed herein are contemplated.

[0165] Some example embodiments may provide alternative DUG signalling through existing IP headers, for example. Both IP versions, IPv4 and IPv6, offer built-in support for packet fragmentation in case the incoming IP packet does not fit into the outgoing port. The Maximum Transmission Unit (MTU) defines the total possible length of the Layer 2 packet that can be sent out on a network port. IP fragmentation for both IP versions use header fields to signal whether a packet has been fragmented and is to be reassembled at the receivers end before being processed further. This is done by fragmentation fields indicating the last fragmented packet in the stream of fragmented packets and the offset each packet represents in the fragmentation process. Thus, the packet which is larger than the MTU can be seen as a Data Unit Group with the fragmented packets as the individual packets that form the DUG. Moreover, analysing the offset values, the DUG Sequence field can be determined and when the last fragmented IP packet has arrived, as well asthe End of DUG field. What is not possible to derive from the fragmentation procedures are burst or importance information.

[0166] Thus, for the uplink and downlink procedures described in the foregoing (e.g., in FIGs. 9-11), IP fragmentation procedures implemented in the UE and UPF could be also utilised to implement the DUG concept on IP level for an IP-based PDU Set identification. However, the involved nodes that perform IP routing should be fully aware of the re-use of the fragmentation techniques and header information defined by IETF for IPv4 and IPV6 to avoid malfunction behaviour.

[0167] As introduced and discussed above, certain example embodiments provide for DUG operations in TSN and / or TSN-enabled 3GPP networks. In the following, the functionality of a TSN switch is described when operating upon DUG information to perform its time-sensitive switching tasks, according to some example embodiments. Considerations for TSN-over-3GPP network considerations are also provided herein.

[0168] The extension or application of the DUG approach to the TSN domain will now be described. In 802.1cb, IEEE defines how packet streams can be identified and besides Layer 2- related header fields, e.g., source / destination MAC address or VLAN identifiers, IP header fields are considered already (e.g., section 9.1.5 of IEEE 802.1cb. DUG-related configuration of TSN switches to identify packets belonging to the same information stream may be understood as an extension to IEEE 802.1cb.

[0169] As described above (e.g., with respect to FIGs.2 and 3 discussed above), a TSN switch first assess the priority of incoming packets before performing packet (re)scheduling tasks across its priority queues. FIG.12, which is similar to FIG. 2 discussed above, provides a diagram that visualises in which part of the TSN operations the DUG information could be used to perform appropriate scheduling tasks and, in case of timing constraints or time-related congestion, make decisions which packets have priority based on the knowledge of multiple packets belonging to a DUG. For example, the impacted components may include the priority filter 1210 and the re- ordering / pre-emption engine 1215, as will be discussed in more detail below.

[0170] In the example of FIG.12, Port 1, Port 2, Port 3, … Port n are the switch ports for handling Ethernet frames, Mux In 1205, is a multiplexer that serialises the incoming packet(s) based on their arrival time and hands them over to priority filter 1210. The priority filter 1210 is configured to identify the priority of packets by identifying to which stream of packets they belong to. In an embodiment, the priority filter 1210 may be configured which DUG flags TLV value is used to place a packet into which queue. For example, depending on how many queues are available and what algorithms are available in the re-ordering and pre-emption engine 1215, the mapping ofDUG packets may be a 1:1 to a queue based on the importance field; alternatively, the CTRL bit or start / end of burst fields might be used to prioritise packets of the same DUG differently.

[0171] Based on the prioritization, the TSN switch places a packet into a set of queues, denoted as {Q1, Q2, Q3, …, Qn} in FIG.12. Each queue represents a different level of configurable priority allowing the re-ordering / pre-emption engine 1215 to change the position of each packet within a queue in respect to other packets in other queues. As the information is available as to which packets belong to a DUG and their respective importance, the TSN engine may re-schedule or pre- empt the DUG packets (e.g., all DUG packets) within the cycle, or if deemed possible drop an entire DUG to free up resources. Another multiplexer 1220 can then place the packets out on the respective ports of the switch.

[0172] Certain example embodiments may provide an end-to-end flow setup in a TSN-enabled 3GPP network. It may be assumed that the network is one where the TSN-Enabled 3GPP UE and / or UPF might be connected to a TSN domain in the DN and one at the UE. The set-up of the flow and DUG-related rules in each TSN-enabled node is described in the following. FIG. 13 illustrates an example topology of a TSN-enabled 3GPP network with a TSN domain (TSN UE domain 1305, TSN DN domain 1315) at either end of the 3GPP network, e.g., one connected to the UE’s DS-TT 1307 and one connected the UPF’s NW-TT 1317. The TSN AF 1320 has access to the PCF of the 5GC 1325 and the CNC 1330 has management access to both TSN switches (TSN Switch 1, TSN Switch 2) as well as the TSN AF 1320.

[0173] FIG. 14 illustrates an example signal or message flow diagram for how DUG-enabled TSN switches and TSN-capable UEs (DS-TT) and UPFs (NW-TT) may register with the CNC, according to an example embodiment. It is noted that certain embodiments may include any one or more of the procedures or operations illustrated in the example of FIG.14. In other words, one or more of the procedures or operations may be omitted, replaced or executed in a different order or between different entities than what is illustrated in the example of FIG.14. Thus, FIG.14 is provided as one example of a process according to an embodiment, and variations and modifications thereto are contemplated according to other embodiments discussed elsewhere herein.

[0174] As illustrated in the example of FIG.14, at 1, the UPF’s NW-TT (e.g., bridge and / or its ports) may be pre-configured and when the UPF registers with the SMF it may communicate (e.g., send an indication of) its port management capabilities. This may include an indication of the availability of DUG-related operations. At 2, the DS-TT and / or UE may be pre-configured when requesting a new PDU session, and the UE may include port management information of the DS- TT in the request. The SMF may receive the port management capabilities of the DS-TT whichincludes the availability of DUG-related operations in the DS-TT and / or the UE. At 3, once the SMF has completed its steps as part of the PDU session establishment, it may communicate (e.g., send or other provide an indication of) the bridge and its capabilities to the PCF which relays it to the TSN AF. The CNC has a direct management connectivity to the TSN domains, i.e., TSN UE, TSN DN and TSN AF. At 4, one or more of the domains (e.g., each domain) may communicate with the CNC and register its bridge, ports and general and port-specific capabilities with the CNC. This may include DUG-related capabilities. At 5, the CNC may start discovering the network topology to make end-to-end flow set-up decisions at a later stage. The CNC can achieve this, for example, by requesting from each TSN domain to discovery their link-local connections on each port reported. One option for this operation is to use the Link-Level Discover Protocol (LLDP). With the steps above, the TSN domains (e.g., all TSN domains) have been registered with the CNC including the ability to support DUGs.

[0175] FIG.15 depicts a signal flow or message sequence diagram for establishing a new end- to-end flow with the DUG feature enabled across domains (e.g., all domains), according to an example embodiment. It is noted that certain embodiments may include any one or more of the procedures or operations illustrated in the example of FIG.15. In other words, one or more of the procedures or operations may be omitted, replaced or executed in a different order or between different entities than what is illustrated in the example of FIG.15. Thus, FIG.15 is provided as one example of a process according to an embodiment, and variations and modifications thereto are contemplated according to other embodiments discussed elsewhere herein.

[0176] As illustrated in the example of FIG.15, at 1, the CNC may receive the request to set up a TSN flow across the TSN-enabled domains (e.g., all TSN-enabled domains) depicted in FIG.13, e.g., TSN UE, TSN DN and TSN AF (representing the 3GPP domain towards the CNC). At 2, the CNC may determine the path traversing TSN Domain TSN UE <> UE(DS-TT) <> UPF / NW-TT <> TSN DN. For example, the CNC may determine the path based on the topology information and capabilities obtained in step of FIG. 14 discussed above. At 3, the CNC may communicate (e.g., send an indication of) the configurations for each TSN bridge and its ports based in the outcome of the determined path at 2. This includes the CNC communicating DUG-related flow identification and DUG-based queuing, rescheduling and pre-emotion rules, as described above in connection with FIG. 12. At 4, the TSN AF may translate the request from the CNC into 3GPP procedures and may communicate the information, e.g., via the PCF to the SMF. The SMF may determine the appropriate UE and / or UPF rules to map DUG-related information of the IP packets to PDU Set markers, as described above.

[0177] It is noted that FIG. 14 and FIG. 15 are provided as examples of a process according to some embodiments, and that variations and modifications thereto according to other embodiments discussed herein are contemplated.

[0178] As discussed in detail above, some example embodiments may include a method for handling uplink DUG. In an embodiment, the method may be performed by a device or apparatus, such as a WTRU or UPF. According to an embodiment, the method may include receiving data unit group (DUG) rules including (i) information for detecting data unit groups (DUGs) in protocol headers of one or more packets and (ii) information indicating at least one action to perform on the packets upon detection of the data unit groups (DUGs) in the protocol headers of the packets. The method may also include receiving a packet and determining an internet protocol (IP) version of the packet. Based on the determined IP version of the packet and the information for detecting the DUGs, the method may include (i) determining that data unit group (DUG) type length values (TLVs) are present in a field of the packet or determining that a hop-by-hop header extension is present in the packet, and (ii) determining a value associated with DUG information in the packet. The method may include performing the at least one action on the packet in accordance with the DUG rules, and then sending the packet to a network node (e.g., a data network node or RAN node or the like).

[0179] In an embodiment, performing the at least one action may include associating the DUG information (included in a header of the packet) to protocol data unit (PDU) set markings and, based on the association, writing or inserting (or otherwise including or incorporating) the PDU set markings to the packet prior to sending the packet to the network node.

[0180] In an embodiment, on condition that the determined IP version of the packet is IPv4, the method may include determining that data unit group (DUG) type length values (TLVs) are present in an options field of the packet, determining the value associated with DUG information in the header of the packet, and determining an IPv4 identification header value.

[0181] In an embodiment, on condition that the determined IP version of the packet is IPv6, the method may include determining that the hop-by-hop header extension is present in the packet, determining the value associated with DUG information in the header of the packet, and determining an IPv6 flow label.

[0182] In an embodiment, the DUG information (as included in the packet header) may include any of a DUG sequence and / or DUG flags.

[0183] As discussed in detail above, some example embodiments may include a method for handling uplink DUG. In an embodiment, the method may be performed by a device or apparatus, such as a network element or UPF. According to an embodiment, the method may includereceiving data unit group (DUG) rules including an indication to remove a DUG header of internet protocol (IP) packets associated with a GTP-U flow. The method may include receiving an IP packet associated with the GTP-U flow, with the IP packet having a protocol data unit (PDU) set GTP-U header extension. The method may optionally include determining the DUG rules (e.g., packet detection rules) associated with the IP packet. Based on the DUG rules (e.g., according to the indication included in the DUG rules) and / or based on the IP version of the IP packet, the method may include removing the DUG header from the IP packet and / or sending the IP packet to a network node (e.g., a data network node, RAN node, or UPF).

[0184] In an embodiment, on condition that the IP version of the IP packet is IPv4, removing the DUG header may include removing a DUG options header from the IP packet, and the method may include re-calculating an IPv4 header checksum and placing the IPv4 header checksum in a IPv4 header field of the IP packet (e.g., prior to sending the IP packet).

[0185] In an embodiment, on condition that the IP version of the IP packet is IPv6, removing the DUG header may include removing a DUG header extension from the IP packet, and the method may include re-calculating an IPv6 header checksum and placing the IPv6 header checksum in a IPv6 header field of the IP packet (e.g., prior to sending the IP packet).

[0186] As discussed in detail above, some example embodiments may include a method for handling downlink DUG. According to certain embodiments, the method may be performed or implemented by a first network element, such as a UPF. In an embodiment, the first network element may receive information indicating DUG rules that may indicate to inspect incoming traffic (e.g., N6 and / or N9 traffic) based on DUG information in IP packets. For instance, the DUG rules may be received from another network element, such as a SMF.

[0187] In an embodiment, the first network element may receive at least one packet. For example, one or more of the packet(s) may be received on a network port of the network element, such as its N6 or N9 network port. The first network element may determine if the packet is an IP packet and, if so, may determine the IP version of the IP, e.g., using the IP header.

[0188] In an embodiment, on condition that (e.g., it is determined that) the received packet is an IPv4 packet, the first network element may check for the existence of the IP header options and, if present, may check for DUG TLVs. If DUG TLVs are present, the first network element may read (e.g., may determine the contents or value of) the DUG Sequence and DUG Flags TLVs fields. The first network element may determine the contents or value of the identification IPv4 header field.

[0189] In an embodiment, on condition that (e.g., it is determined that) the packet is an IPv6 packet, the first network element may check for the existence of (e.g., determine the presence of)the hop-by-hop header extension. On condition that the hop-by-hop header extension is present, the first network element may determine the contents or value of the DUG Sequence and DUG Flags TLVs fields. The first network element may determine the contents or value of the Flow Label IPv6 header field. The first network element may create the GTP-U header and identify the PDU Set header extension for GTP-U by reading the DUG IP header information.

[0190] According to certain embodiments, a method for handling downlink DUG may be performed or implemented by a WTRU. In an embodiment, a WTRU may receive DUG rules indicating (e.g., including information about how) to manipulate a protocol header. For example, the DUG rules may indicate to detect a protocol header, e.g., IPv4 or IPv6, and to identify a specific header field and / or value (or any value) to watch out for (e.g., to identify). In addition, the DUG rules may indicate an action to take. For example, one of the actions may include to remove the header field.

[0191] In an embodiment, the WTRU may receive a packet from a network (e.g., the AN). The WTRU may check and / or determine whether it has matching packet header manipulation rules for the incoming packet. The WTRU may find and / or identify matching packet header manipulation rules for IP headers and, if present, remove DUG extension headers. For example, if IPv4, the WTRU may remove the DUG TLVs from the options header and may re-calculate the IPv4 header checksum. As another example, if IPv6, the WTRU may remove the DUG TLVs from the hop- by-hop IPv6 extension header and may re-calculate the IPv6 header checksum. The WTRU may release the packet allowing its remaining URSPs to decide where the packet will be sent to (local application or local network port).

[0192] As discussed in detail above, some example embodiments may include a method for DUG-based packet prioritization, re-ordering and / or pre-emption in TSN compute nodes. According to certain embodiments, a node may have received a set of DUG rules to detect a packet and an action to place it into a specific priority queue. In addition, the node may receive instructions and / or rules on how to treat identified DUGs in a specific queue. For example, in some embodiments, the node may be a TSN switch, DS-TT (e.g., at WTRU), and / or NW-TT (e.g., at UPF).

[0193] In an embodiment, a node may receive one or more packets on one of its network ports. The node may read and / or determine the protocol headers of the packet and finds IPv4, IPv6 or UDP, for example. The node may use the received DUG rules to match them against one, all, or a mix of DUG-related information from the IP header and may place the packet into a priority queue. The node may apply the desired timing behaviour to the identified DUG in any queue.

[0194] It is noted that the methods described above are provided as some examples of methods according to certain embodiments, and that variations and modifications thereto are contemplated according to other embodiments discussed herein.

[0195] Conclusion

[0196] Although features and elements are provided above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly provided as such. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that this disclosure is not limited to particular methods or systems.

[0197] In some example embodiments described herein, (e.g., configuration) information may be described as received by a WTRU from the network, for example, through system information or via any kind of protocol message. Although not explicitly mentioned throughout embodiments described herein, the same (e.g., configuration) information may be pre-configured in the WTRU (e.g., via any kind of pre-configuration methods such as e.g., via factory settings), such that this (e.g., configuration) information may be used by the WTRU without being received from the network.

[0198] Any characteristic, variant or embodiment described for a method is compatible with an apparatus device comprising means for processing the disclosed method, such as with a device comprising a processor configured to process the disclosed method, a computer program product comprising program code instructions and a non-transitory computer-readable storage medium storing program instructions.

[0199] The foregoing embodiments are discussed, for simplicity, with regard to the terminology and structure of infrared capable devices, i.e., infrared emitters and receivers. However, the embodiments discussed are not limited to these systems but may be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.

[0200] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, the term "video" or the term "imagery" may mean any of a snapshot, single image and / or multiple images displayed over a time basis. As another example, when referred to herein, the terms "user equipment" and its abbreviation "UE", the term "remote" and / or the terms "head mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of a number of embodiments of a WTRU; (iii) a wireless-capable and / or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU; (iii) a wireless-capable and / or wired-capable device configured with less than all structures and functionality of a WTRU; or (iv) the like. Details of an example WTRU, which may be representative of any WTRU recited herein, are provided herein with respect to FIGs.1A-1D. As another example, various disclosed embodiments herein supra and infra are described as utilizing a head mounted display. Those skilled in the art will recognize that a device other than the head mounted display may be utilized and some or all of the disclosure and various disclosed embodiments can be modified accordingly without undue experimentation. Examples of such other device may include a drone or other device configured to stream information for providing the adapted reality experience.

[0201] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0202] Variations of the method, apparatus and system provided above are possible without departing from the scope of the invention. In view of the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are examples only, and should not be taken as limiting the scope of the following claims. For instance, the embodiments provided herein include handheld devices, which may include or be utilized with any appropriate voltage source, such as a battery and the like, providing any appropriate voltage.

[0203] Moreover, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices that include processors are noted. These devices may include at least one Central Processing Unit ("CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "computer executed" or "CPU executed."

[0204] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.

[0205] The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM)) or non-volatile (e.g., Read-Only Memory (ROM)) mass storage system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the provided methods.

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

[0207] There is little distinction left between hardware and software implementations of aspects of systems. The use of hardware or software is generally (but not always, in that in certain contexts the choice between hardware and software may become significant) a design choice representing cost versus efficiency tradeoffs. There may be various vehicles by which processes and / or systems and / or other technologies described herein may be effected (e.g., hardware, software, and / or firmware), and the preferred vehicle may vary with the context in which the processes and / orsystems and / or other technologies are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may opt for a mainly hardware and / or firmware vehicle. If flexibility is paramount, the implementer may opt for a mainly software implementation. Alternatively, the implementer may opt for some combination of hardware, software, and / or firmware.

[0208] The foregoing detailed description has set forth various embodiments of the devices and / or processes via the use of block diagrams, flowcharts, and / or examples. Insofar as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, it will be understood by those within the art that each function and / or operation within such block diagrams, flowcharts, or examples may be implemented, individually and / or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In an embodiment, several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and / or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and a transmission type medium such as a digital and / or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).

[0209] Those skilled in the art will recognize that it is common within the art to describe devices and / or processes in the fashion set forth herein, and thereafter use engineering practices to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein may be integrated into a data processing system via a reasonable amount of experimentation. Those having skill in the art will recognize that a typicaldata processing system may generally include one or more of a system unit housing, a video display device, a memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices, such as a touch pad or screen, and / or control systems including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0210] The herein described subject matter sometimes illustrates different components included within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures may be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Hence, any two components herein combined to achieve a particular functionality may be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated may also be viewed as being "operably connected", or "operably coupled", to each other to achieve the desired functionality, and any two components capable of being so associated may also be viewed as being "operably couplable" to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0211] With respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0212] It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example,where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and / or the descriptions herein may include usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim including such introduced claim recitation to embodiments including only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In those instances where a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Further, the terms "any of" followed by a listing of a plurality of items and / or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and / or "any combination of multiples of" the items and / or the categories of items, individually or in conjunction with other items and / or other categories of items. Moreover, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero. And the term "multiple", as used herein, is intended to be synonymous with "a plurality".

[0213] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0214] As will be understood by one skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, middle third and upper third, etc. As will also be understood by one skilled in the art all language such as "up to," "at least," "greater than," "less than," and the like includes the number recited and refers to ranges which can be subsequently broken down into subranges as discussed above. Finally, as will be understood by one skilled in the art, a range includes each individual member. Thus, for example, a group having 1-3 cells refers to groups having 1, 2, or 3 cells. Similarly, a group having 1-5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so forth.

[0215] Moreover, the claims should not be read as limited to the provided order or elements unless stated to that effect. In addition, use of the terms "means for" in any claim is intended to invoke 35 U.S.C. §112, ¶ 6 or means-plus-function claim format, and any claim without the terms "means for" is not so intended.

[0216] Although various embodiments have been described in terms of communication systems, it is contemplated that the systems may be implemented in software on microprocessors / general purpose computers (not shown). In certain embodiments, one or more of the functions of the various components may be implemented in software that controls a general-purpose computer.

[0217] In addition, although some example embodiments are illustrated and described herein, the invention is not intended to just be limited to the details shown. Rather, various modifications and variations may be made in the details within the scope and range of equivalents of the claims and without departing from the spirit or scope invention. REFERENCES

[0218] The following references may have been referred to hereinabove, each of which is incorporated herein by reference in its entirety:

[0219] 3GPP, “System architecture for the 5G System (Release 18)”, Technical Specification 23.501, September 2023.

[0220] 3GPP, “Procedures for the 5G System (Release 18)”, Technical Specification 23.502, September 2023.

[0221] 3GPP, “5G Real-time Media Transport Protocol Configurations (Release 18)”, Technical Specification 26.522, August 2023.

[0222] 3GPP, “Study on XR (Extended Reality) and media services (Release 18)”, Technical Report 23.700-60, December 2022.

[0223] S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland and M. Bhatia, “A Uniform Format for IPv6 Extension Headers”, RFC 6564, 2012. DOI: 10.17487 / RFC6564.

[0224] RFC Editors, “INTERNET PROTOCOL”, 1981. DOI: 10.17487 / RFC0791.

[0225] IEEE, “Standard for Local and metropolitan area networks – Station and Media Access Control Connectivity Discovery”, 802.1AB, 2016.

[0226] IEEE, “Standard for Local and Metropolitan Area Networks – Timing and Synchronization for Time-Sensitive Applications”, 802.1AS, 2020.

[0227] IEEE, “Standard for Local and metropolitan area networks – Frame Replication and Elimination for Reliability”, 802.1CB, 2017.

[0228] IEEE, “Standard for Local and Metropolitan Area Networks – Bridges and Bridged Networks – Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements”, 802.1Qcc, 2018.

[0229] S. Deering and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 8200, 2017. DOI: 10.17487 / RFC8200.

[0230] IANA, “Internet Protocol Version 4 Parameters”, 2018. Online: https: / / www.iana.org / assignments / ip-parameters / ip-parameters.xhtml.

[0231] J. Kaippallimalil, S. Gundavelli, and S. Dawkins, “Media Header Extensions for Wireless Networks”, IETF Internet Draft, TSVWG, 2023. Online: https: / / datatracker.ietf.org / doc / html / draft-kaippallimalil-tsvwg-media-hdr-wireless-03.

[0232] IEEE, “YANG Model for Packet Stream Identification”, 802.1cb, 2022. Online: https: / / github.com / YangModels / yang / blob / main / standard / ieee / published / 802.1 / ieee802-dot1cb- stream-identification.yang.

Claims

CLAIMS What is claimed is:

1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: receiving data unit group (DUG) rules including (i) information for detecting data unit groups (DUGs) in protocol headers of one or more packets and (ii) information indicating at least one action to perform on the packets upon detection of the data unit groups (DUGs) in the protocol headers of the packets; receiving a packet; determining an internet protocol (IP) version of the packet; based on the determined IP version of the packet and the information for detecting the DUGs, (i) determining that data unit group (DUG) type length values (TLVs) are present in a field of the packet or determining that a hop-by-hop header extension is present in the packet, and (ii) determining a value associated with DUG information in the packet; performing the at least one action on the packet in accordance with the DUG rules; and sending the packet to a network node.

2. The method of claim 1, wherein performing the at least one action comprises: associating the DUG information to protocol data unit (PDU) set markings; and based on the association, writing the PDU set markings to the packet prior to sending the packet to the network node.

3. The method of claims 1 or 2, wherein, on condition that the determined IP version of the packet is IPv4: determining that data unit group (DUG) type length values (TLVs) are present in an options field of the packet and determining the value associated with DUG information in the header of the packet; and determining an IPv4 identification header value.

4. The method of claims 1 or 2, wherein, on condition that the determined IP version of the packet is IPv6: determining that the hop-by-hop header extension is present in the packet and determining the value associated with DUG information in the header of the packet; and determining an IPv6 flow label.

5. The method of any of claims 1-4, wherein the DUG information comprises any of a DUG sequence and DUG flags.

6. A method implemented by a network element, the method comprising: receiving data unit group (DUG) rules including an indication to remove a DUG header of internet protocol (IP) packets associated with a GTP-U flow; receiving an IP packet associated with the GTP-U flow, the IP packet having a protocol data unit (PDU) set GTP-U header extension; determining the DUG rules associated with the IP packet; based on the indication included in the DUG rules and an IP version of the IP packet, removing the DUG header from the IP packet; and sending the IP packet to a network node.

7. The method of claim 6, wherein, on condition that the IP version of the IP packet is IPv4: removing the DUG header comprises removing a DUG options header from the IP packet; and re-calculating an IPv4 header checksum and placing the IPv4 header checksum in a IPv4 header field of the IP packet.

8. The method of claim 6, wherein, on condition that the IP version of the IP packet is IPv6: removing the DUG header comprises removing a DUG header extension from the IP packet; and re-calculating an IPv6 header checksum and placing the IPv6 header checksum in a IPv6 header field of the IP packet.

9. The method of any of claims 6-8, wherein the network element comprises a user plane function (UPF), and wherein the network node comprises a data network node or another user plane function (UPF).

10. An apparatus comprising: circuitry, including any of a processor, memory, receiver and / or transmitter, configured to receive data unit group (DUG) rules including (i) information for detecting data unit groups (DUGs) in protocol headers of one or more packets and (ii) information indicating at leastone action to perform on the packets upon detection of the data unit groups (DUGs) in the protocol headers of the packets; receive a packet; determine an internet protocol (IP) version of the packet; based on the determined IP version of the packet and the information for detecting the DUGs, (i) determine that data unit group (DUG) type length values (TLVs) are present in a field of the packet or determine that a hop-by-hop header extension is present in the packet, and (ii) determine a value associated with DUG information in the packet; perform the at least one action on the packet in accordance with the DUG rules; send the packet to a network node.

11. An apparatus comprising: circuitry, including any of a processor, memory, receiver and / or transmitter, configured to receive data unit group (DUG) rules including an indication to remove a DUG header of internet protocol (IP) packets associated with a GTP-U flow; receive an IP packet associated with the GTP-U flow, the IP packet having a protocol data unit (PDU) set GTP-U header extension; determine the DUG rules associated with the IP packet; based on the indication included in the DUG rules and an IP version of the IP packet, remove the DUG header from the IP packet; and send the IP packet to a network node.

Images