Determining a path for a data packet (PDU) based on a split-bearer configuration and on a characeristic related to the data packet

Abstract

In an embodiment, a WTRU is configured to receive information indicating a split-bearer configuration that is associated with multiple paths, determine at least one characteristic related to a Protocol Data Unit (PDU), the determined at least one characteristic being one or more of a PDU type, PDU Set type, PDU Set Delay Budget (PSDB), remaining time of expiry of the PSDB, size of a PDU Set, importance of a PDU, or importance of a PDU Set, select, from the multiple paths, after receiving the information indicating the split-bearer configuration and determining the at least one characteristic, a path for the PDU, and transmit the PDU over the selected path.

Description

DETERMINING A PATH FOR A DATA PACKET (EG, PDU) BASED ON A SPLIT-BEARER CONFIGURATION AND ON A CHARACERISTIC RELATED TO THE DATA PACKETCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 484,907, filed February 14, 2023, the contents of which are incorporated herein by reference.SUMMARY

[0002] The term extended Reality (XR) is an umbrella term for different types of immersive experiences including Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR) and the realities interpolated among XR, VR, AR, and MR.

[0003] Virtual Reality (VR) is a rendered version of a delivered visual and audio scene. The rendering is designed to mimic the visual (e.g. stereoscopic 3D) and audio sensory stimuli of the real world as naturally as possible to an observer or user as he moves within the limits defined by the application.

[0004] Augmented Reality (AR) is when a user is provided with additional information or artificially generated items or content overlaid upon his current environment.

[0005] Mixed Reality (MR) is an advanced form of AR where some virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene. XR may include all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables.

[0006] The notion of immersion in the context of XR applications / services refers to the sense of being surrounded by the virtual environment as well as the feeling of being physically and spatially located in the virtual environment. The levels of virtuality may range from partial sensory inputs to fully immersive multi- sensory inputs leading to a virtual reality practically indiscernible from actual reality.

[0007] XR devices may be associated with capabilities that offer various degrees of spatial tracking. XR devices may be equipped with various sensors to enable spatial tracking, for example monocular / stereo / depth cameras, radio beacons, GPS, inertial sensors, etc. Such spatial tracking may be performed at different levels, e.g., 3 Degrees of Freedom - DoF (i.e., rotational motion along X, Y and Z axes), 6 DoF (i.e., rotational and / or translational motion along X, Y and Z axes). Such spatial tracking may result in an interaction to experience some form of virtual content The user may act in, and / or interact with the components within, extended reality (XR) and / or within an XR environment. For example, the actions and / or interactions may involve a user’s movements or gestures, eye-tracking of the user’s eyes, etc. Spatial tracking can be an important enabler for an immersive XR experience. For example, some form of head and / or motion tracking of the user may ensurethat the simulated visual and audio components from the user perspective are updated to be consistent with user’s movements. Imprecise and / or delayed spatial tracking may lead to a sensation of discomfort and / or motion sickness for the user.

[0008] In an embodiment, a WTRU (a WTRU also may be referred to as User Equipment (UE)) may correspond to any XR device / node which may come in variety of form factors. A typical WTRU (e.g., XR WTRU) may include, but is not limited to the following: Head Mounted Displays (HMD), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with positional tracking and camera, wearables, etc. In addition to the above, several different types of XR WTRU may be envisioned based on XR device functions, such e.g.as display, camera, sensors, sensor processing, wireless connectivity, XR / Media processing, and power supply, to be provided by one or more devices, wearables, actuators, controllers, and / or accessories. One or more device / nodes / WTRUs may be grouped into a collaborative XR group for supporting any XR applications / experience / services.

[0009] In current 5GS, the QoS Flow typically is the finest granularity of QoS differentiation in the Protocol Data Unit (PDU) Session. The 5G QoS characteristics are determined by the 5QI. This implies that each packet in a QoS flow is treated according to the same QoS requirements.

[0010] For XR / media services, a group of packets are used to carry payloads of a PDU Set (e.g., a frame, video slice / tile). A PDU Set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g., a frame or video slice)

[0011] In a media layer, packets in such a PDU Set typically are decoded / handled as a whole For example, the frame / video slice may be decoded only if all, or a certain (threshold) number of the packets fewer than all of the packets, carrying the frame / video slice are successfully delivered and successfully received. For example, a frame within a GOP (Group of Pictures) typically can be decoded by the client only if all frames on which that frame depends (e.g., all frames within the GOP used to code that frame) are successfully delivered and successfully received. Hence, the groups of packets within the PDU Set typically have inherent dependency on each other in the media layer. Without considering such dependencies between the packets within the PDU set, 5GS may perform a scheduling with low efficiency. For example, the 5GS may randomly drop one or more packets but try to deliver other packets of the same PDU set, which delivery may be useless to the client and thus may waste radio resources.

[0012] Also, audio samples, haptics applications, or remote-control operations may benefit if the 5GS considers the PDU Set characteristics. If such dependency between packets of a PDU Set (e.g., a frame / video slice) can be considered, it may be possible to enhance the efficiency and improve a user’s experience.

[0013] Thus, 3GPP is studying enhancements on the current 5GS QoS framework to support different QoS handling for a PDU Set. PDU Sets can carry different content, e.g., Intra-Coded / Bidirectionally Predicted / Forward Predicted (l / B / P) frames, slices / tiles within an l / B / P frame, etc.

[0014] For example, differentiated QoS handling is being studied where different levels of importance of PDU Sets is considered, e.g., by treating packets (i.e., PDUs) belonging to less-important PDU Set(s) differently to reduce resource wasting.

[0015] A Data Burst is a set of data PDUs generated and sent by an application in a short period of time. A Data Burst can be composed of multiple PDUs belonging to one or multiple PDU Sets.

[0016] PDU-Set Delay Budget (PSDB) defines an upper bound for the time that a PDU-Set may be delayed between the WTRU and the N6 termination point at the User Plane Function (UPF); the N6 termination point is configured to provide connectivity between the UPF and any other networks or service platforms, such as the Internet, the public cloud, or a one or more private clouds.

[0017] A PDU-Set Error Rate (PSER) defines an upper bound for the rate of PDU-Sets that have been processed by the sender of a link layer protocol (e.g., a Radio Link Control (RLC) layer) but where all of the PDUs in the PDU-Set are not successfully delivered by the corresponding receiver to the upper layer (e.g., a Packet Data Convergence Protocol (PDCP) layer).

[0018] FIG. 2 is a timing diagram of an example of multiple data bursts, each with multiple PDU sets of different types, according to an embodiment

[0019] In Dual Connectivity (DC), a WTRU typically is served by two nodes, each comprising a set of cells, known as the Master Cell Group (MCG) and Secondary Cell Group (SCG). A radio bearer can be associated with only the MCG or SCG, or it can be configured to be a split bearer. FIG. 3 shows the protocol view of a split bearer.

[0020] For the split bearer, like for any other bearer, the WTRU has one PDCP entity associated with it and the peer PDCP entity on the network side is terminated at either one of the gNBs (either the master or the secondary). In the DL, the CN (core network) sends the data to the gNB where the PDCP is terminated (gNB 1 in FIG. 3), and it is up to the network to directly send the data to the WTRU via the link between that gNB and the WTRU, or forward the PDCP PDUs to gNB2 (e.g. via an Xn interface), and the gNB (e.g., gNB2) to which the data was forwarded sends the data to the WTRU via the link between itself and the WTRU.

[0021] In the UL, the WTRU is configured with one of the split-bearer paths as the primary path, and the other of the split-bearer paths as a secondary path. The network can configure the primary path for a certain bearer to be the MN or the SN. A threshold is known as the UL Data Split Threshold (UL-DataSplitThreshold information element, IE, in the PDCP configuration of a bearer). If the UL buffer size for that bearer is less than this threshold, the PDCP will push the data only to the RLC associated with the primary path ( / '.e., the data for this bearer will be sent only via the air interface resources of the node associated with the primary path, when UL grants are available on that path) However, if the buffer size becomes larger than the threshold, then the WTRU can push the data to either path ( / .e., left to WTRU implementation).

[0022] Setting the split threshold to infinity basically disables split-bearer operation (r.e., only the primary path is used). On the other hand, setting the split threshold to zero disables the concept of primary and secondary paths, as the WTRU typically always is able to send the UL data for this bearer via one of the two paths.

[0023] As discussed above, the current split-bearer operation in DC is controlled by the split-buffer threshold, where the WTRU is allowed to send the UL data for the split bearer either via the primary path or the secondary path The main intention behind this is to distribute the load among the two paths that the bearer can use (r.e.,if the primary path were sufficient for the bearer, then the buffer level would have remained low and the secondary path would not be needed).

[0024] In scenarios where the WTRU has an active XR application, such a behavior may lead to undesirable behavior, because current PDCP path routing is operating on a per-packet basis. For example, if the split threshold is reached while the WTRU is in the middle of transmitting a PDU set or a data burst, the WTRU may send some PDUs of the PDU set or data burst via the primary path while sending the others via the secondary path, which could create problems such as jitter (e.g., packets within a PDU set or data burst experiencing quite different latencies), multiple out-of-order delivery within a PDU set or data burst, the PDU set delay budget (PSDB) being exceeded, etc.

[0025] An embodiment performs scheduling of a split bearer in a manner that considers the inter-dependency and differences of PDUs (e.g., within a PDU set or data burst) of an XR traffic.

[0026] In an embodiment, PDUs or PDU sets or data bursts are always associated with a certain path.

[0027] In an example of such an embodiment, a WTRU is configured with a split bearer, wherein a PDU, PDU set, or data burst is associated with the primary path or / and secondary path based on one or more characteristics of the PDU, PDU set, or data burst.

[0028] Further details of such an embodiment are described below.

[0029] In an embodiment, a WTRU performs the following operations:Receives one or more configurations about a split bearer, where a split-bearer configuration contains association between PDUs, PDU sets, or data bursts and the paths of the split bearer (e.g., based on PDU set size, type, characteristics, importance, PSDB, TTL)Upon receiving a packet from higher layers that belongs to the bearer, determines the path for the PDU based on the received configuration(s) and sends the data via the determined path.

[0030] In an embodiment, a same path is maintained for PDUs within a PDU set or data burst.

[0031] In an example of such an embodiment, a WTRU is configured with a split bearer, and an associated split-buffer threshold, wherein once the split-buffer threshold has been passed, the WTRU determines one path (primary path or secondary path) to transmit all the UL packets of a certain PDU set and / or data burst.

[0032] Further details of such an embodiment are described below.

[0033] In an embodiment, a WTRU performs the following operations:Upon determining that the UL buffer for the split bearer has become larger than the split-buffer threshold: o Continues to send any remaining UL PDUs belonging to PDU sets or data bursts that are already being transmitted over the primary path; o When the first PDU of a PDU set or data burst arrives, determines whether to use the primary or secondary path for all the PDUs of that PDU set or data burst; o Uses the determined path for all subsequent PDUs of the PDU set or data burst;Upon determining that the UL buffer for that bearer has become smaller than the split-buffer threshold: o Continues to send any remaining UL PDUs belonging to PDU sets or data bursts that are already being transmitted over the path that is already associated with that PDU set or data burst o When the first PDU of a PDU set or data burst arrives (after the UL buffer for that bearer has become smaller than the split-buffer threshold), uses the primary path for all the PDUs of that PDU set or data burst

[0034] In an embodiment, a split buffer threshold considers PDU / PDU set characteristics.

[0035] In such an embodiment, a WTRU is configured with a split bearer and associated split-buffer threshold to decide when to start using the secondary path, where the split-buffer threshold considers only PDUs that fulfill certain conditions (e.g., type, importance, PSDB, etc.)

[0036] Further details of this embodiment are described below.

[0037] In an embodiment, a WTRU, configured with a split bearer, performs the following operations:Is configured with a split-buffer threshold, where the split buffer threshold is concerning PDUs or PDU sets with certain characteristics, e.g., o PDUs or PDU sets of certain PSDB, o PDUs or PDU sets of certain type, o PDUs or PDU sets of certain importance level, efc.Determines the total buffer size to be compared with the split-buffer threshold to be the sum of the pending UL data that matches the configured characteristics.If the determined total buffer size is greater than the configured split-buffer threshold, the WTRU also is able to use the secondary path for sending the packets of the bearer.

[0038] In an embodiment, a WTRU is configured to associate a PDU set or data burst within a split bearer with the primary or the secondary path based on the characteristics of the PDU, the PDU set, and / or the PDU data burst (e.g., type, importance, PSDB, and / or size).

[0039] In an embodiment, a WTRU is configured with a split bearer and associated split-buffer threshold, wherein once the split-buffer threshold has been passed, the WTRU is configured to determine one path (primary or secondary path) to transmit all the PDUs of a certain PDU set or / and data burst (e.g., type, importance, PSDB, and / or size).

[0040] In an embodiment, a WTRU is configured with a split bearer, and associated split-buffer threshold to decide when to start using the secondary path, where the split-buffer threshold considers only PDUs that fulfill certain conditions (e.g., type, importance, PSDB, and / or size).

[0041] In an embodiment, a WTRU is configured to determine a path for a first PDU based on a split-bearer configuration, and to transmit the first PDU via the determined path.

[0042] In an embodiment, a WTRU is configured to receive information indicating a split-bearer configuration that is associated with multiple paths, determine at least one characteristic related to a Protocol Data Unit (PDU), the determined at least one characteristic being one or more of a PDU type, PDU Set type, PDU Set Delay Budget (PSDB), remaining time of expiry of the PSDB, size of a PDU Set, importance of a PDU, or importance of a PDU Set, select, from the multiple paths, after receiving the information indicating the splitbearer configuration and determining the at least one characteristic, a path for the PDU, and transmit the PDU over the selected path.

[0043] In an embodiment, a WTRU is configured to compare a fill level of a buffer with a buffer threshold, and in response to the fill level being greater than the buffer threshold, to determine a characteristic of a data packet, to select, from multiple paths in response to the determined characteristic, a path corresponding to the characteristic, and to send the data packet over the selected path.

[0044] In an embodiment, a WTRU is configured to determine a buffer size as a mathematical combination of pending PDUs having a characteristic, to compare the buffer size to a split buffer threshold related to the characteristic, and, in response to the buffer size having a relationship to the split buffer threshold, to transmit the PDUs via at least one path that corresponds to the relationship.

[0045] In an embodiment, a WTRU is configured to determine a characteristic of a data packet, to compare a fill level of a buffer for data packets having the determined characteristic with a buffer threshold related to the determined characteristic, to select, in response to the comparison, a path from multiple paths, and to send the data packet over the selected path.

[0046] In an embodiment, a WTRU is configured to receive information indicating a split-bearer configuration that is associated with multiple paths, to determine a characteristic related to a Protocol Data Unit (PDU), to select, from the multiple paths, in response to the split-bearer configuration and the determined characteristic, a path for the PDU, and to transmit the PDU over the selected path.

[0047] In an embodiment, a WTRU is configured to receive a configuration that indicates a characteristic, a buffer threshold, and / or multiple paths, determine the characteristic of a data packet from information within the data packet, the determined characteristic being one or more of a type, Protocol Data Unit Set Delay Budget (PSDB), size, or importance of the data packet, compare a fill level of a buffer for data packets having the determined characteristic with a buffer threshold related to the determined characteristic, select, in response to the fill level being less than or equal to the buffer threshold, a primary path from multiple paths that include the primary path and a secondary path and that are each configured for propagation of data; select in response to the fill level being greater than the buffer threshold, the secondary path from the multiple paths; and send the data packet over the selected path

[0048] Following are some examples of split-bearer techniques, including split-bearer operation, for Extended Reality (XR), where the split bearer includes two paths. It is understood, however, that these examples, and other embodiments herein, can be extrapolated to a split bearer having more than two paths.

[0049] Subject matter common to these examples include that a split bearer is a bearer, such as a radio bearer, that is divided (e.g., split) into two or more data-transmission and / or d ata-reception paths. Generally, a split bearer is not the same as Dual-Connectivity (DC), although a split bearer and DC may share some similarities. For example, DC is a simultaneous connection (e.g., from a WTRU) to two (or more) nodes, whereas a split-bearer can be two (or more) simultaneous (or non-simultaneous) paths between a WTRU and the same node; for example, a split bearer can implement carrier aggregation (CA) such that one path (e.g., one “split” or “split-bearer path”) of the split bearer uses one set of available subcarriers and another path (e.g., another “split” or “split-bearer path”) of the split bearer uses another set of the available subcarriers. Furthermore, DC typically is used to improve data throughput, and a split bearer typically is used to improve data redundancy, e.g., to increase the likelihood that transmitted / received data is not lost.

[0050] In a first example where a split bearer has two (e.g., primary and secondary) paths, a WTRU is configured to associate a data packet such as a PDU, a data-packetset such as a PDU set, and / or a data burst of data-packet sets such as PDU sets, with a primary or a secondary path of the split bearer based on one or more characteristics (e.g., type, importance, PDU-Set Delay Budget (PSDB), and / or size) of the data packet (e.g., PDU), data-packet set (e.g., PDU set), and / or data burst. In some existing systems, a WTRU bases its determination of over which split-bearer path to transmit and / or receive data solely on whether a buffer fill level exceeds a buffer-fill-level threshold. But in this example, the WTRU ignores the buffer-fill-level threshold and bases its decision of over which split-bearer path to transmit and / or receive data solely on one or more characteristics (e.g., type, importance, PSDB, and / or size) of the data packet (e.g., PDU), data-packet set (e.g., PDU set), and / or data-packet (e.g., PDU-set) data burst. Furthermore, the WTRU can base its decision of over which split-bearer path to transmit and / or to receive data on one or more characteristics (e.g., latency, and / or throughput) of one or more of the split-bearer paths.

[0051] In a second example where a split bearer has two (e.g., primary and secondary) paths, a WTRU is configured with the split bearer and an associated split-buffer threshold. In response to the buffer fill level being below or equal to the split-buffer threshold, the WTRU is configured to transmit / receive data over one (e.g., primary or secondary) split-bearer path. In response to the buffer fill level exceeding the split-buffer threshold, the WTRU is configured to determine over which path (primary or secondary path) to transmit a data packet (e.g., PDU), data-packet set (e.g., PDU set), and / or data-packet-set (e.g., PDU-set) data burst based on one or more characteristics (e.g., type, importance, PSDB, and / or size) of the data packet (e.g., PDU), data-packet set (e.g., PDU set), and / or data-packet (e.g., PDU-set) data burst. Said another way, some existing WTRUs base their decisions of over which split-bearer path to used solely on whether the buffer fill level exceeds the split-buffer threshold; but in this example, the WTRU is configured to operate in a conventional manner until the buffer fill level exceeds the split-buffer threshold, and thereafter transmits / receives data over multiple splitbearer paths and determines over which of the split-bearer paths to transmit / receive a particular data-packet, data-packet set, and / or data-packet-set data burst based on one or more characteristics (e.g., type, importance, PSDB, and / or size) of the data packet (e.g., PDU), data-packet set (e.g., PDU set), and / or data-packet-set(e.g., PDU-set) data burst. If / when the buffer fill level subsequently becomes less than or equal to the splitbuffer threshold, the WTRU is configured then to return to operating in a conventional manner.

[0052] In a third example where a split bearer has two (e.g., primary and secondary) paths, a WTRU is configured with the split bearer and with an associated split-buffer threshold, and bases its determination as to when to start using the secondary path on the buffer fill level but where the buffer fill level “counts” only data packets (e.g., PDUs), sets of data packets (e.g., PDU sets), and / or data-packet-set data bursts (e.g., PDU-set data bursts) that fulfill one or more certain conditions and / or have one or more characteristics (e.g., type, importance, PDU-Set Delay Budget (PSDB), and / or size). And the WTRU may be configured with multiple split-buffer thresholds each for a respective condition and / or characteristic. In comparison, a conventional WTRU may be configured to base its decision on which split-bearer path to use solely on whether the buffer fill level exceeds a single buffer-fill-level threshold that is independent of the conditions and / or characteristics of data carried by the data packets. As stated above, in this example different split-buffer thresholds can be assigned to data packets (e.g., PDUs) with different conditions, characteristics (e.g., type, PSDB, size), and / or importance levels. For example, importance level 1 can correspond to buffer-level-threshold 1 , importance level 2 can correspond to buffer-level-threshold 2, and so on, and the higher the importance level, the lower is the buffer level threshold to increase the chances that data packets of a particular importance level (particularly of a high importance level) are transmitted / received over the same split-bearer path.BRIEF DESCRIPTION OF THE DRAWINGS

[0053] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

[0054] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

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

[0056] 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 according to an embodiment;

[0057] FIG. 1 D 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 according to an embodiment;

[0058] FIG. 2 is timing diagram of multiple data bursts, each with multiple PDU sets of different types, according to an embodiment.

[0059] FIG. 3 is a protocol view of a split bearer according to an embodiment.

[0060] FIGS. 4(a) - 4(f) are diagrams of respective forward configurations including combinations of DRBs and / or LCHs during UL transmission and to which a WTRU maps data units received from one or more QoS flows, according to an embodiment.

[0061] FIGS. 5(a) - 5(f) are diagrams respective ways that a WTRU selects and / or uses a configured forwarding configurations at AS layers for mapping XR data units during UL transmission using (a) config 1 , (b) config 2, (c) config 3, (d) config 4, (e) config 5, and / or (f) config 6, according to an embodiment.

[0062] FIG. 6 is a flow diagram of a procedure that a WTRU can perform, according to an embodiment.

[0063] FIG. 7 is a flow diagram of a procedure that a WTRU can perform, according to another embodiment.

[0064] FIG. 8 is a flow diagram of a procedure that a WTRU can perform, according to yet another embodiment.

[0065] FIG. 9 is a flow diagram 900 of a procedure that a WTRU can perform, according to still another embodiment.

[0066] FIG. 10 is a flow diagram of a procedure that a WTRU can perform, according to another embodiment.

[0067] FIG. 11 is a flow diagram of a procedure that a WTRU can perform, according to another embodiment.DETAILED DESCRIPTION

[0068] For the purposes of the present disclosure, the following abbreviations may apply:

[0069] 6DOF 6 Degrees of Freedom

[0070] ACK Acknowledgement

[0071] ADU Application Data Unit

[0072] AR Augmented Reality

[0073] AS Access stratum

[0074] BWP Bandwidth Part

[0075] BSR Buffer status report

[0076] CSI Channel State Information

[0077] CG Cloud Gaming

[0078] DC Dual Connectivity

[0079] DL Downlink

[0080] DMRS Dedicated Demodulation Reference Signals

[0081] DRB Data Radio Bearer

[0082] FDD Frequency Division Duplex

[0083] FoV Field of View

[0084] gNB NR Node B

[0085] FPS Frames per second

[0086] HARQ Hybrid Automatic Repeat Request

[0087] HO Hand Over

[0088] iBLER initial Block Error Rate

[0089] LCP Logical control prioritization

[0090] LCH Logical Channel

[0091] MAC Medium access control

[0092] MCS Modulation and Coding Scheme

[0093] MTP Motion-to-photon

[0094] NAS Non-access stratum

[0095] NACK Negative Acknowledgement

[0096] NW Network

[0097] PDB Packet Delay Budget

[0098] PDCCH Physical Downlink Control Channel

[0099] PDCP Packet data convergence protocol

[0100] PDU Packet Data Unit

[0101] PER Packet Error Rate

[0102] PHY Physical layer

[0103] PSG Power Saving Gain

[0104] PSR Packet Success Rate

[0105] PUCCH Physical Uplink Control Channel

[0106] PUSCH Physical Uplink Shared Channel

[0107] PDSCH Physical Downlink Shared Channel

[0108] RLC Radio link control

[0109] RTT Round trip time

[0110] SDAP Service data adaptation protocol

[0111] SR Scheduling Request

[0112] STD Standard Deviation

[0113] TB Transport Block

[0114] TDD Time Division Duplex

[0115] UE User Equipment

[0116] UL Uplink

[0117] VR Virtual Reality

[0118] XR Extended Reality

[0119] WTRU Wireless Transmit-Receive Unit (an example of User Equipment UE)

[0120] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may 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), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0121] 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, a core network (ON) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though itwill 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 (STA), may be configured to transmit and / or receive wireless signals and may include 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 (loT) 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 may be interchangeably referred to as a UE.

[0122] 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 to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, 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.

[0123] The base station 114a may be part of the RAN 104, 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, and the like. 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 one 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 mayutilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

[0125] 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 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 (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).

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

[0127] 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 NR.

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

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

[0130] The base station 114b in FIG. 1 A 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 one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the basestation 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or 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.

[0131] The RAN 104 may be in communication with the CN 106, 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 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 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0132] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the 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 or a different RAT.

[0133] 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. 1 A may be configured to communicate with the base station 114a, which may employ a cellularbased radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0134] FIG. 1 B is a system diagram illustrating an example WTRU 102 As shown in FIG. 1 B, 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 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.

[0135] 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), any other 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. 1 B 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 in an electronic package or chip.

[0136] 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 one 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 yet another 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.

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

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

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

[0140] 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 cellbatteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0141] 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

[0142] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a handsfree 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 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, a humidity sensor and the like.

[0143] 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 UL (e.g., for transmission) and DL (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., a separate 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 UL (e.g., for transmission) or the DL (e.g., for reception)).

[0144] 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, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0145] 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 one 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 / or receive wireless signals from, the WTRU 102a.

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

[0147] 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 the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0148] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, 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

[0149] 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 the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

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

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

[0152] Although the WTRU is described in FIGS. 1A-1 D 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.

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

[0154] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered tothe 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.

[0155] 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. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. 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 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.

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

[0157] Very High Throughput (VHT) STAs may support 20MHz, 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 noncontiguous 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 the Medium Access Control (MAC).

[0158] Sub 1 GHz modes of operation are supported by 802.11af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11 af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine- Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certaincapabilities, 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).

[0159] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802 11n, 802.11ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary 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.11 ah, 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, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

[0160] In the United States, the available frequency bands, which may be used by 802.11 ah, 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.11 ah is 6 MHz to 26 MHz depending on the country code.

[0161] FIG. 1 D 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 NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0162] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. 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).

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

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

[0165] 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, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0166] The CN 106 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 possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0167] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 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 non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order 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 the like The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0168] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 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 DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

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

[0170] The CN 106 may facilitate communications with other networks. 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 In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local 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.

[0171] In view of FIGs. 1A-1D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a- c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation 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.

[0172] 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 performing testing using over-the-air wireless communications.

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

[0174] FIG. 2 is a timing diagram of an example of multiple data bursts, Data Burst 1 and Data Burst 2, each with multiple PDU sets 202, 204, and 206, and 208 and 210 of different types, according to an embodiment. Each PDU set represents a component of a Group of Pictures (GOP), includes a start time and an end time, and includes a respective number of PDUs. For example, the PDU set 202 represents a portion of an l-frame and includes seven PDUs, the PDU set 204 represents another portion of the l-frame and includes eight PDUs, . . ., and the PDU set 210 represents a portion of a B-frame and includes six PDUs.

[0175] In Dual Connectivity (DC), a WTRU is served by two nodes, each comprising a set of cells, known as the Master Cell Group (MCG) and Secondary Cell Group (SCG). A radio bearer can be associated with only the MCG or only the SCG, or the radio bearer can be configured to be a split bearer

[0176] FIG. 3 is a protocol view of a split-bearer system 300, according to an embodiment.

[0177] The spit-bearer system 300 includes a WTRU 302, node 304 (gNB1), and node 306 (gNB2), which are intercoupled with each other.

[0178] The WTRU 302 includes, is configured with, or implements a packet-data-convergence protocol (PDCP) 310, a first radio link control (RLC) 312, a first medium access control (MAC) 314, and a first physical layer (PHY) 316, which can be intracoupled with each other (for example, as shown by the coupling lines in FIG. 3), and a second radio link control (RLC) 318, a second medium access control (MAC) 320, and a second physical layer (PHY) 322, which can be intracoupled to each other and to the PDCP 310, the first RLC 312, the first MAC 314, and the first PHY 316 (for example, as shown by the coupling lines in FIG. 3).

[0179] The gNB1 node 304 includes, is configured with, or implements a packet-data-convergence protocol (PDCP) 330, radio link control (RLC) 332, a medium access control (MAC) 334, and a physical layer (PHY) 336, which can be intracoupled with each other and / or intercoupled with corresponding components of the WTRU 300 (for example, as shown by the coupling lines between the WTRU and the gNB1 node 304 in FIG. 3)

[0180] And the gNB2 node 306 includes, is configured with, or implements a radio link control (RLC) 340, a medium access control (MAC) 342, and a physical layer (PHY) 344, which can be intracoupled with each other and / or can be intercoupled with corresponding components of the WTRU 300 and / or with corresponding components of the gN B 1 node 304 (for example, as shown by the coupling lines in FIG. 3 between gNB2 and the WTRU and the coupling lines between gNB2 and gNB1).

[0181] For the split bearer, like for any other bearer, the WTRU 302 has one PDCP 310 entity associated with it and the peer PDCP 330 entity on the network side is terminated at either one of the gNBs 304 or 306 (e.g., either the master or the secondary gNB, where whether a gNB is a master node or a secondary node typically is assigned during a configuration of the system 300 as a split-bearer system). In the DL, the CN (core network) sends the data to the gNB 330 where the PDCP 310 is terminated (PDCP 330 (gNB1) in FIG. 3), andit is up to the network to send the data directly to the WTRU 302 via the link between that gNB (gNB 304) and the WTRU, or to forward the PDCP PDUs to the node 306 (gNB2) (e.g. via an Xn interface), and the gNB2 node 306 sends the data to the WTRU via the link (e.g., intercoupling) between gNB2 and the WTRU.

[0182] In the UL, the WTRU 302 is configured with one of the paths (e.g., one of the links between the WTRU and the node 304 and / or the node 306) as the primary path, and the other one of the paths (e.g., another one of the links between the WTRU and node 304 and / or the node 306) as a secondary path. The network can configure the primary path for a certain bearer to be the MN or the SN. A threshold is known as the UL Data Split Threshold (UL-DataSplitThreshold information element, IE, in the PDCP configuration of a bearer). If the UL buffer size for that bearer is less this threshold, the PDCP will push the data only to the RLC associated with the primary path ( / .e., the data for this bearer will be sent only via the air interface resources of the node (e.g., node 304 or node 306) associated with the primary path, when UL grants are available on that path). However, if the buffer size becomes larger than the threshold, then the WTRU can push the data to either path ( / .e., determining what data is pushed to what path is left to the WTRU implementation (e.g., configuration)).

[0183] Setting the split threshold to / nffn / 'ty basically disables split-bearer operation ( / .e., onlythe primary path is used). On the other hand, setting the split threshold to zero disables the concept of primary and secondary paths, as the WTRU typically always is able to send the UL data for this bearer via one of the two paths (e.g., the secondary path).

[0184] As discussed above, the current split-bearer operation in Dual Connectivity (DC) is controlled by the split-buffer threshold, where the WTRU 302 is allowed to send the UL data for the split bearer either via the primary path (e.g., the path to one of the nodes 304 and 306) or the secondary path (e.g. , the path to the other one of the nodes 304 and 306). A main intention behind this is to distribute the load among the two paths that the bearer can use ( / .e., if the primary path were sufficient for the bearer, then the buffer level would have remained low).

[0185] In scenarios where the WTRU 302 has an active XR application, such a behavior may lead to undesirable behavior, because current PDCP path routing is operating on a per-packet basis. For example, if the split threshold is reached while the WTRU 302 is in the middle of transmitting a PDU set or a data burst, the WTRU may send some PDUs of the PDU set or data burst via the primary path while sending the others via the secondary path, which could create problems such as jitter (e.g., packets within a PDU set or data burst experiencing significantly different latencies), multiple out-of-order deliveries within a PDU set or data burst, the PDU set delay budget (PSDB) being exceeded, etc.

[0186] Throughout the embodiments described herein, the network may include any of a base station (e.g., gNB such as gNB 1 304 or gNB2306), TRP, RAN node, access node), core network function (e.g., AMF), and application function (e.g., edge server function, remote server function), for example.

[0187] Throughout embodiments described herein, the terms PDU and packet are used interchangeably.

[0188] Throughout embodiments disclosed herein, flows may correspond to any of: QoS flows or data flows (e.g., flow of data consisting of one or more PDUs or ADUs, which may be associated with one or more QoS requirements, e.g. latency, data rate, reliability). Different flows, possibly originating from a common- 72 -application / experience source and / or intended to a common destination device / WTRU or group of associated devices / WTRUs may be referred to associated flows or correlated flows.

[0189] Throughout embodiments disclosed herein, forwarding configuration may correspond to any of the following: radio bearers (e.g. data radio bearers (DRBs) and / or signaling radio bearers (SRBs), logical channels (LCHs), logical channel groups (LCGs), configuration parameters in the individual layers within the AS protocol stack (e.g. SDAP, PDCP, RLC, MAC, PHY, other new protocol layers), parameters associated with logical channel prioritization (LCP) (e.g. priority, PBR, BSD), BWPs, carriers, radio links / interfaces (Uu links, SLs), and radio resources (e.g. a set of one or more frequency / time / spatial resources such as timeslots, subcarriers, or beams Radio resources may also be associated with configurated grants, dynamic grants, and / or any other resource grants or grant-free resources).

[0190] Throughout the embodiments herein, mapping configuration may correspond to any of the following: parameters and / or configurations associated with mapping from:: o one or more application data (e.g., PDU set) flows, QoS flows (e.g., associated or non-associated), to o one or more radio bearers, SDAP, PDCP, LCHs, carriers or component carriers (e.g., CCs in CA configurations), BWPs, and radio links / interfaces (e.g., Uu link or sidelinks), which may be used for delivering the PDUs in a UL direction or a DL direction, for example.

[0191] Throughout the embodiments herein, XR / appiication-aware data transmissions / receptions or XR / appiication-aware QoS handling, may correspond to any of the following: o PDU set handling: A PDU set (e.g., media unit, video frame) may comprise one or more PDUs. A PDU set may be associated with PDU set-level QoS requirements (e.g., data rate, latency, reliability), which may be applicable for one or more or all PDUs associated with a PDU set. The different PDUs in a PDU set may be associated with individual PDU-level QoS requirements. Such associations and inter-dependencies may be visible to the AS-layers (e.g., with associated IDs) and / or handled at the AS layers with the awareness of the association during data transmission and reception. o Application / high-layer importance / priority: different PDUs in a PDU set or all PDUs in a PDU set may be associated with different application / high-layer importance / priority values. Such importance value may correspond to spatial importance (e.g., spatial position of the video frame whose data is carried by the PDU / PDU set, where PDUs / PDU sets carrying FoV spatial positions may be associated with higher spatial importance than non-FoV spatial positions) or temporal importance (e.g., time sequence of the video frame who data is carried by the PDUs / PDU set, where PDUs / PDU sets carrying base video frames such as l-frames may be associated with higher temporal importance than differential video frames such as P-frames / B-frames). Such importance values may be visible to the AS layers (e.g., with associated IDs / markers / indications), possibly enabled by application awareness, during data transmission and reception.o QoS flow handling: The PDUs / PDU sets of an application may be encoded and delivered by the application to a WTRU (in UL) or to a network (in DL) via one or more QoS / data flows. In this regard, the different QoS flows carrying the PDUs / PDU sets associated with an XR application / experience may be visible to the AS layers [e.g. with associated IDs) and / or handled at the AS layers with the awareness of the association during data transmission and reception

[0192] Throughout the embodiments herein, the phrase “the WTRU is in the middle of transmitting / receiving packets belonging to a certain PDU set or data burst” refers to a scenario where certain PDUs of the PDU set or the data burst are already transmitted / received or being transmitted / received, while others are still pending in the WTRU / gNB buffers. The term “ongoing PDU set or data burst” also is used to refer to the outstanding PDUs ( / '.e., PDUs not yet transmitted successfully by the WTRU for the UL case and not yet received successfully by the WTRU for the DL case) within a PDU set or data burst. The above phrases and terms also may apply to the scenario where certain packets associated with any of PDU sets, data bursts, and / or QoS flows are pending at the application / higher layers and / or yet to arrive at the lower layer buffers at the WTRU / gNB for UL / DL transmission. The WTRU / gNB may be aware of such packets pending at the application / higher layers based on application / NAS layer indications and / or markings in the previously received packet headers, for example. The above phrases and terms also may apply for non-XR traffic, which may consist of one or more standalone PDUs in any QoS flows without any association with PDU sets, media / video frames, and / or data bursts.

[0193] The WTRU may receive configuration information for supporting any of the procedures, mechanisms, rules, actions, etc., discussed herein related to split-bearer handling.

[0194] The WTRU may receive configuration information for supporting any of the procedures, mechanisms, rules, actions, etc., discussed below at any time while the WTRU is in CONNECTED mode, or when the WTRU is resuming the connection from a suspended state or establishing the connection from an IDLE state or reestablishing the connection after a failure.

[0195] The configurations may be part of the split-bearer configuration or provided separately from a given bearer-information element [e.g., a common configuration that can be applied to multiple bearers provided outside the individual bearer configurations).

[0196] The WTRU may receive any of the configuration information via any of the following, for example: Broadcast signaling (e.g., SIB)Dedicated signaling o RRC signaling and / or messages (e.g., RRC Reconfiguration, HO Command, RRC Release, RRC Resume)Bearer-level signaling / configuration when bearers are established or modified (e.g., via RRC, MAC CE, control PDUs such as SDAP / PDCP / RLC control PDUs, DCI)Non-AS (NAS) layer signaling (e.g., a PDU Session Establishment Response or a PDU Session Modification Command)Application-layer signaling / messages

[0197] The WTRU may obtain information about the size of PDU sets / data bursts (e.g., size of frame and / or PDU and / or PDU-set and / or group of PDU-sets) and other information such as PDU set type, importance, etc., by several means including the following:- The WTRU may receive indications from the application / higher layers about the size of the PDU-set. In one example, the indication may come in the packet header of the first packet / PDU in the PDU-set.- The WTRU may receive indications from the application that the WTRU may use to infer the size of the PDU-set. In an example, the WTRU may receive indications about the first packet and the last packet in the PDU-set, which may be indicated in the headers of the first packet and the last packet, for example.- The WTRU may receive size information on a more granular level. In an example, the WTRU may receive indications from the application about the typical size of different frames (e.g., l-frames, P-frames, B- frames). The first / last packet in the PDU-set may contain information indicating its type (e.g., corresponding to an l-frame or P-frame) and that it is the first / last packet of the PDU-set. Based on this information, the WTRU may be able to estimate the size of the PDU-set.- In an encoding scheme where different types of frames are encoded into different traffic streams (e.g., GOP-based whereby a single video frame is either an l-frame or P-frame), the WTRU may receive indication linking the data flow to the frame type only once at the start of the session. o In an example, the indication from the application to the WTRU may be bit-type, where “0” may correspond to a data flow with l-frames while “1” may corresponding to a data flow with P-frames.- The WTRU may receive information about the size of the PDU-set on a PDU-set basis and / or on a perflow basis (e.g., in the GOP-based encoding scheme). This exchange may happen at the start of the XR session. The WTRU may receive regular updates throughout the XR session periodically or only if there is a change in the information (e.g., change in size of PDU-set).- The WTRU may receive information from the application / higher layers on multiple PDU-sets ( / .e., granularity of a group of PDU-sets). The application may group PDU-sets based on similarities between individual PDU-sets (e.g., same size, type, importance / priority, etc.)- Importance of data may be indicated to the WTRU from the application on different data-unit granularities, i.e., importance on a per-frame basis and / or per-PDU basis and / or per-PDU-set basis and / or per-group of PDU-sets basis, etc.Indication of importance may be indicated for every data unit or it may be indicated for a first data unit and no indication is sent for the following data units until / un less there is a change in the importance.o Indication of importance may be as simple as a bit-wise binary indication or a flag indicating if the data is important enough to necessitate a special treatment, for example- Indication of importance may be indicated through a table mapping different QoS levels in the legacy QoS framework to different important levels. o In an example, the four most important QoS levels from the QoS framework may be flagged as important such that the WTRU may determine that any data mapped to radio bearers with the corresponding QoS flows from the four most important QoS levels may need to be sent before transitioning to another cell / gNB. Any data mapped to radio bearers with QoS flows from the remaining QoS levels may wait until after HO is completed to be transmitted.- Indication of importance may override QoS levels from the traditional QoS framework in some cases (e.g., if the data in the buffer is about to expire).

[0198] The configuration information that may be received by the WTRU from the network may include a combination or sub-combination of one or more of the following:Mapping / forwarding / resource configurations and / or parameters o For example, the WTRU may receive one or more configurations and / or sets of configuration parameters to be applied at different layers of the protocol stack (e.g., SDAP, PDCP, RLC, MAC, PHY or any new layer). The configurations parameters may include:■ SDAP: 1-to-1 , 1-to-M or N-to-M mapping configurations, markings / indications / IDs to apply (e.g., associated with QoS flows, PDU sets, data bursts), association info such as indication of association between PDUs, PDU sets, and / or data bursts, and / or range of values associated with importance / priority of PDUs, PDU sets, and / or data bursts.■ PDCP:• rules / criteria for mapping PDUs, PDU sets, and / or data bursts to two or more RLC entities / LCHs / legs• rules / criteria for assigning sequence numbers (e.g. COUNT range, HFN range, and / or SN range) for PDUs, PDU sets, and / or data bursts• RoHC configuration to apply to legs associated with source and / or target• security / encryption parameters to apply to legs associated with source and / or target• indication / flag on whether to apply any packet duplication rules / criteria for discarding PDU sets and / or data bursts (e.g., discard timers)rules / criteria for ensuring in-order delivery of PDUs, PDU sets, and / or data bursts■ RLC: mode (AM / UM / TM) and parameters to apply to the legs associated with source and / or target■ MAC: rules / criteria to apply to the LCHs / MAC entities in the legs associated with source and / or target including:• LCH parameters (e.g., priority, PBR, BSD),• LCP (e.g., rules / restrictions for handling PDU sets and / or data bursts, time duration for changing between different LCP rules),• configurations for multiplexing PDU sets / data bursts to TBs■ PHY: HARQ configurations (e.g., number of allowed retransmissions ReTx) o For example, the WTRU may receive one or more resource configurations to be used before, during, and / or after HO, including■ Configured grant resources / configurations for UL data transmissions. The parameters associated with CG resources / configurations may include any of periodicity, start offset, duration, BWPs, numerology / SCS values, number of PRBs, number of occasions, number of PUSCH slots per occasion, maximum number / duration / length of PUSCH, one or more MSC values for the grant, antenna ports, etc., for example.■ Semi-persistent scheduling (SPS) resources / configurations for DL data receptions. The parameters associated with SPS resources / configurations may include any of periodicity, start offset, duration, BWPs, numerology / SCS values, number of PRBs, number of occasions, number of PDSCH slots per occasion, maximum number / duration / length of PDSCH, one or more MCS values for the grant, antenna ports, etc., for example.■ Dynamic grant resources for UL data transmission.■ Dynamic scheduling resources for DL data receptions. o The WTRU may receive at least one set of configuration parameters associated with default configuration, which may be activated and / or used during normal scenarios for transmitting / receiving data during HO, for example. The WTRU may also receive another set of configuration parameters which may be associated with exceptional operation, possibly activated and / or used when detecting any of the triggering events / conditions during HO, for example.Validity informationo For example, the WTRU may receive validity information associated with the forwarding / resource configurations, indicating whether / when the configurations are considered to be valid or invalid, based on one or more of triggering events / conditions. o The WTRU may also receive information on whether the configurations are to be deactivated and / or released when determining them to be invalid.Threshold values: o Buffer-occupancy threshold:■ For example, the buffer-occupancy-threshold values associated with any of forwarding configurations may indicate the maximum / minimum amount of data units in one or more granularities / types including PDUs, PDU sets, and / or data bursts (e.g., in terms of total payload size / volume) that may be included in the buffer (e.g., SDAP buffer, PDCP buffer, LCH buffer). o PDU-set payload-size threshold values■ For example, the payload-size threshold values may be associated with one or more upper- and / or lower-bound values corresponding to the total size of the payload (e.g. in the units of bits or bytes) of one or more PDUs, PDU sets, and / or data bursts.■ In another example, the payload-size threshold values may be associated with one or more upper- and / or lower-bound values corresponding to the total number of PDUs in a PDU set and / or the total number of PDU sets in a data burst. o Delay threshold values■ Delay-threshold values may be associated with one or more upper- and / or lower-bound values corresponding to a maximum / minimum-delay value associated with reception, buffering, and / or transmission of any data units or groups of data units (e.g., PDUs, PDU sets, data bursts)■ Such delay-threshold values may be intended to identify and / or to determine the maximum / minimum latency tolerated by the network, application, and / or WTRU, possibly as a result of delays due to HO, processing, jitter, transmission, congestion, etc., for example

[0199] Following are described embodiments related to mapping of PDU sets and bearers, logical channels, etc.

[0200] A PDU-set may include one more PDUs.

[0201] A PDU-set may include PDUs corresponding to only one type of video frame (e.g., l-frame) or PDUs corresponding to different types of video frames (l-frames, P-frames, B-frames, etc.)

[0202] The size of the PDU-set may be variable from one PDU-set to another.

[0203] PSDB (PDU-set delay budget) is the time from the reception of the first PDU (e.g., data packet and / or PDU data packet) of a PDU set at the WTRU (e.g., from an application layer), until the last PDU (e.g., data packet and / or PDU data packet) of the PDU set is received at the network (e.g., base station or UPF) and / or at the application server (e.g., after transmission by the WTRU).

[0204] TTL (time to live) or remaining delay / PSDB for a PDU set is considered to be equal to PSDB minus total time elapsed since first PDU (e.g., data packet and / or PDU data packet) of the PDU set arrived at the WTRU’s transmission buffer.

[0205] In some cases, the PDUs within a given PDU set can have different characteristics (e.g., type, importance), and it may be desirable to determine the path for the PDUs of the PDU set based on a combination of the characteristics of the PDUs within the PDU set (e.g., type, importance, etc.). To enable this, it may be required that the WTRU is able to determine or to estimate the characteristics of the different PDUs within the PDU set at the start of the first PDU of the PDU set (e.g., based on information from the application layer, and / or based on information regarding, in, and / or from the headers of the first or first few PDUs at the start of the first PDU set).

[0206] A data burst is sometimes likely to contain PDU sets of different characteristics (e.g., different types, size, importance levels, PSDBs), and it may be desirable to determine the path for the data burst based on the combination of the characteristics of the PDU sets. To enable this, it may be required for the WTRU to be able to determine or estimate the characteristics of the different PDU sets within the data burst at the start of the first PDU set within the data burst (e.g., based on information from the application layer, and / or based on information regarding, in, and / or from the headers of the first or first few PDUs at the start of the first PDU set).

[0207] The WTRU performs mapping of the data units (e.g., PDUs, PDU sets, and / or PDU data bursts), received from upper layers / application in one or more QoS flows (e.g., QFIs), to certain forwarding configurations including a combination of different DRBs and / or LCHs, during UL transmission.

[0208] FIGS. 4(a) - 4(f) demonstrate different WTRU transmission paths for PDUs and / or PDU sets in different non-split-bearer scenarios, according to an embodiment. In general, FIGS. 4(a) - 4(f) demonstrate respective ways in which XR traffic can be mapped to non-split radio bearers (e.g., addressing aspects such as whether one bearer, e.g., PDCP, can be used to transport multiple PDU sets or whether multiple bearers are needed to transport different PDU sets). Consequently, in embodiments described in conjunction with FIGS. 4(a) - 4(f), there is still one path, not two or more paths, for the packets (e.g., as can be seen in the one MAC and PHY, as compared to the two MAC and PHYs for the different paths in FIG. 3).

[0209] Referring to FIGs. 4(a)-4(f), the WTRU 402 selects and / or uses one or more configured forwarding configurations at AS layers for mapping XR data units during UL transmission using FIG. 4(a) config 1, FIG. 4(b) config 2, FIG. 4(c) config 3, FIG. 4(d) config 4, FIG. 4(e) config 5, and / or FIG. 4(f) config 6, according to an embodiment.

[0210] In an example related to configuration 1 illustrated in FIG. 4(a), the WTRU 402 may receive one or more PDUs associated with a PDU set 1 and a PDU set 2 in QoS flows identified by QoS Flow Identifier 1 (QFI1) and QoS Flow Identifier 2 (QFI2), respectively. The PDU set 1 includes PDUs P1, P2, . . ., Pm and thePDU set 2 includes PDUs P1, P2, . Pn, where m may or may not equal n The received PDU sets 1 and 2 may be mapped to Data Radio Bearer 1 (DRB1) (e.g., PDCP1) and DRB2 (e.g., PDCP2) (DRB1 and DRB2 are portions of the respective split-bearer paths) at the SDAP sublayer / entity. Each PDCP entity (e.g., PDCP1 and PCDP2) may be configured to support in-order delivery of PDUs P1 - Pm in PDU set 1 and PDUs P1 - Pn in PDU set 2, respectively. The PDUs of PDU set 1 and PDU set 2 may be mapped to LCH1 and LCH2 (LCH1 and LCH2 are portions of the respective split-bearer paths), possibly corresponding to RLC1 and RLC2 respectively. The MAC entity / sublayer may cause the QoS parameters specified for the PDU sets 1 and 2 (e.g., the PSDBs) in the respective LCHs to be met, possibly based on the PDU set parameters (e.g., priority) and / or using a LCP procedure, during scheduling and / or multiplexing of the PDU sets into one or more TBs for UL transmission, for example.

[0211] In one example related to configuration 2 illustrated in FIG. 4(b), the WTRU 402 may receive one or more PDUs P1 - Pm associated with PDU set 1 and P1 - Pn associated with PDU set 2 in QoS flows identified by QFI1 and QFI2, respectively. The received PDU sets may be multiplexed / mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. The PDUs of PDU set 1 and PDU set 2 may be mapped to LCH1 , possibly corresponding to RLC1. The MAC entity / sublayer may cause the QoS parameters specified for the PDU sets (e.g., PSDB) in LCH1 to be met, possibly based on the PDU set parameters (e.g., priority, SNs) and / or using LCP procedure, during scheduling and / or multiplexing of the PDU sets into one or more TBs for UL transmission, for example.

[0212] In an example related to configuration 3 illustrated in FIG 4(c), the WTRU 402 may receive one or more PDUs associated with PDU set 1 and PDU set 2 in QFI1 and QFI2, respectively. The received PDU sets may be mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. The PDUs of PDU set 1 and PDU set 2 may be mapped to LCH1 and LCH2, possibly corresponding to RLC1 and RLC2, respectively. The MAC entity / sublayer may cause the QoS parameters specified for the PDU sets (e.g., PSDB) in the respective LCHs may be met, possibly based on the PDU set parameters (e.g., priority) and / or using LCP procedure, during scheduling and / or multiplexing of the PDU sets into one or more TBs for UL transmission, for example.

[0213] In an example related to configuration 4 illustrated in FIG. 4(d), the WTRU 402 may receive one or more PDUs P1, P2, . . . Pm associated with PDU set 1 and P1 , P2, . . . Pn associated with PDU set 2 in a QoS flow identified by QFI1 . The received PDU sets 1 and 2 may be mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. The PDUs of PDU set 1 and PDU set 2 may be mapped to LCH1 , possibly corresponding to RLC1. The MAC entity / sublayer may cause the QoS parameters specified for the PDU sets (e.g., PSDB) in LCH1 to be met, possibly based on the PDU set parameters (e.g., priority) and / or using LCP procedure, during scheduling and / or multiplexing of the PDU sets 1 and 2 into one or more TBs for UL transmission, for example.

[0214] In an example related to configuration 5 illustrated in FIG. 4(e), the WTRU 402 may receive one or more PDUs PI - Pm associated with PDU set 1 and P1 - Pn associated with PDU set 2 in a QoS flow identified by QFI1. The received PDU sets 1 and 2 may be mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. The PDUs of PDU set 1 and PDU set 2 may be mapped to LCH1 and LCH2, possibly corresponding to RLC1 and RLC2 respectively The MAC entity / sublayer may cause the QoS parameters specified for the PDU sets(e.g., PSDB) in the respective LCHs to be met, possibly based on the PDU-set parameters (e.g., priority) and / or using an LCP procedure, during scheduling and / or multiplexing of the PDU sets into one or more TBs for UL transmission, for example.

[0215] In an example related to configuration 6 illustrated in FIG. 4(f), the WTRU 402 may receive one or more PDUs P1 , P2, . .. Pm associated with PDU set 1 and P1 , P2, . . ., Pn associated with PDU set 2 in a QoS flow identified by QFI1. The received PDU sets 1 and 2 may be mapped to DRB1 [e.g., PDCP1) and DRB2 e.g., PDCP2) at the SDAP sublayer / entity Each PDCP entity [e.g., PDCP1 and PCDP2) may be configured to support in-order delivery of PDUs in PDU set 1 and PDU set 2, respectively. The PDUs of PDU set 1 and PDU set 2 may be mapped to LCH1 and LCH2, possibly corresponding to RLC1 and RLC2, respectively. The MAC entity / subl ayer may cause the QoS parameters specified for the PDU sets 1 and 2 [e.g., PSDB) in the respective LCHs to be met, possibly based on the PDU-set parameters [e.g., priority) and / or using an LCP procedure, during scheduling and / or multiplexing of the PDU sets into one or more TBs for UL transmission, for example.

[0216] Embodiments related to mapping of PDU sets and bearers, logical channels, etc. are described below in conjunction with FIG. 5

[0217] FIGS. 5(a) - 5(f) demonstrate different WTRU transmission paths for PDUs and / or PDU sets in different non-split-bearer scenarios, according to an embodiment. In general, like FIGS. 4(a) - 4(f), FIGS. 5(a) - 5(f) demonstrate respective ways in which XR traffic can be mapped to non-split radio bearers [e.g., addressing aspects such as whether one bearer, e.g., PDCP, can be used to transport multiple PDU sets or whether multiple bearers are needed to transport different PDU sets). Consequently, in embodiments described in conjunction with FIGS. 4(a) - 4(f), there is still one path, not two or more paths, for the packets [e.g., as can be seen in the one MAC and PHY, as compared to the two MAC and PHYs for the different paths in FIG. 3).

[0218] Referring to FIG 5, a WTRU 502 performs mapping of the data units [e.g., PDUs, PDU sets, and / or data bursts), received from upper layers / application(s) in one or more QoS flows [e.g., QFIs), to certain forwarding configurations including a combination of different DRBs and / or LCHs, during UL transmission.

[0219] FIGS. 5(a) - 5(f) are diagrams of how a WTRU 502 selects and / or uses configured forwarding configurations at AS layers for mapping XR data units during UL transmission using FIG. 5(a) config 1, FIG. 5(b) config 2, FIG. 5(c) config 3, FIG. 5(d) config 4, FIG. 5(e) config 5, and / or FIG. 5(f) config 6, according to an embodiment.

[0220] In an example related to configuration 1 illustrated in FIG. 5(a), the WTRU 502 may receive one or more PDUs P1 , P2, . . .. Pm associated with PDU set 1 and P1, P2, . . Pn associated with PDU set 2 in QoS flows identified as QFI1 and QFI2, respectively, where any Pm may or may not equal a corresponding Pn and m may or may not equal n. The received PDU sets 1 and 2 may be mapped to DRB1 (e.g., PDCP1) and DRB2 (e.g., PDCP2) at the SDAP sublayer / entity. Each PDCP entity (e.g., PDCP1 and PCDP2) may be configured to support in-order delivery of PDUs in PDU set 1 and PDU set 2, respectively. The PDUs of PDU set 1 and the PDUs of PDU set 2 may be mapped to LCH1 and LCH2, possibly corresponding to RLC1 and RLC2, respectively. The MAC entity / sublayer may cause the QoS parameters specified for the PDU sets (e.g., PSDB)in the respective LCHs to be met, possibly based on the PDU set parameters (e.g., priority) and / or using LCP procedure, during scheduling and / or multiplexing of the PDU sets into one or more TBs for UL transmission, for example.

[0221] In an example related to configuration 2 illustrated in FIG. 5(b), the WTRU 502 may receive one or more PDUs P1 , P2, . . .. Pm associated with PDU set 1 and P1 , P2, . . ., Pn associated with PDU set 2 in QoS flows identified as QFI1 and QFI2, respectively, where any Pm may or may not equal a corresponding Pn and m may or may not equal n. The received PDU sets 1 and 2 may be multiplexed / mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. The PDUs of PDU set 1 and PDU set 2 may be mapped to LCH1 , possibly corresponding to RLC1. The MAC entity / sublayer may cause the QoS parameters specified for the PDU sets1 and 2 (e.g., PSDB) in LCH1 to be met, possibly based on the PDU-set parameters (e.g., priority, Secondary Nodes (SNs)) and / or using LCP procedure, during scheduling and / or multiplexing of the PDU sets into one or more TBs for UL transmission, for example.

[0222] In an example related to configuration 3 illustrated in FIG 5(c), the WTRU 502 may receive one or more PDUs P1 , P2 Pm associated with PDU set 1 and P1 , P2, . . ., Pn associated with PDU set 2 in QoS flows identified as QFI1 and QFI2, respectively, where any Pm may or may not equal a corresponding Pn and m may or may not equal n. The received PDU sets 1 and 2 may be mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. The PDUs of PDU set 1 and PDU set 2 may be mapped to LCH1 and LCH2, possibly corresponding to RLC1 and RLC2 respectively. The MAC entity / sublayer may cause the QoS parameters specified for the PDU sets 1 and 2 (e.g., PSDB) in the respective LCHs to be met, possibly based on the PDU- set parameters (e.g., priority) and / or using LCP procedure, during scheduling and / or multiplexing of the PDU sets into one or more TBs for UL transmission, for example.

[0223] In an example related to configuration 4 illustrated in FIG. 5(d), the WTRU 502 may receive one or more PDUs P1 , P2, . . , Pm associated with PDU set 1 and P1 , P2, . . ., Pn associated with PDU set 2 in a QoS flow identified as QFI1 , where any Pm may or may not equal a corresponding Pn and m may or may not equal n. The received PDU sets 1 and 2 may be mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. The PDUs of PDU set 1 and PDU set 2 may be mapped to LCH1, possibly corresponding to RLC1. The MAC entity / sublayer may cause the QoS parameters specified for the PDU sets 1 and 2 (e.g., PSDB) in LCH1 to be met, possibly based on the PDU set parameters (e.g., priority) and / or using LCP procedure, during scheduling and / or multiplexing of the PDU sets into one or more TBs for UL transmission, for example.

[0224] In an example related to configuration 5 illustrated in FIG. 5(e), the WTRU 502 may receive one or more PDUs P1 , P2, . .. Pm associated with PDU set 1 and P1 , P2, . . ., Pn associated with PDU set 2 in a QoS flow identified as QFI1 , where any Pm may or may not equal a corresponding Pn and m may or may not equal n. The received PDU sets may be mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. The PDUs of PDU set 1 and PDU set 2 may be mapped to LCH1 and LCH2, possibly corresponding to RLC1 and RLC2, respectively. The MAC entity / sublayer may cause the QoS parameters specified for the PDU sets 1 and2 (e.g., PSDB) in the respective LCHs to be met, possibly based on the PDU-set parameters (e.g., priority)and / or using an LCP procedure, during scheduling and / or multiplexing of the PDU sets 1 and 2 into one or more TBs for UL transmission, for example.

[0225] In an example related to configuration 6 illustrated in FIG. 5(f), the WTRU 502 may receive one or more PDUs P1 , P2, . . .. Pm associated with PDU set 1 and one or more PDUs P1 , P2, Pn associated with PDU set 2 in a QoS flow identified as QFI1 , where any Pm may or may not equal a corresponding Pn and m may or may not equal n. The received PDU sets 1 and 2 may be mapped to DRB1 (e.g., PDCP1) and DRB2 (e.g., PDCP2) at the SDAP sublayer / entity. Each PDCP entity (e.g., PDCP1 and PCDP2) may be configured to support in-order delivery of PDUs in PDU set 1 and PDU set 2, respectively. The PDUs of PDU set 1 and the PDUs of PDU set 2 may be mapped to LCH1 and LCH2, possibly corresponding to RLC1 and RLC2, respectively. The MAC entity / sublayer may cause the QoS parameters specified for the PDU sets 1 and 2 (e.g., PSDB) in the respective LCHs to be met, possibly based on the PDU-set parameters (e.g., priority) and / or using an LCP procedure, during scheduling and / or multiplexing of the PDU sets into one or more TBs for UL transmission, for example.

[0226] A WTRU may be configured with a behavior that is dependent on the active bearer / application type. For example, a WTRU may be configured to apply any of the proposed embodiments / behaviors above or below if there is an active VR application but apply legacy behavior otherwise. As another example, a WTRU may be configured to apply a new behavior / solution if there is any active XR traffic (e.g., AR, VR, MR) In another example, a WTRU may be configured to consider only the PDU sets or data bursts belonging to a certain bearer(s) / LCH(s) or application type(s) (e.g., AR, VR, MR)

[0227] Embodiments described below mainly focus on enhancements related to XR applications / bearers. However, all the embodiments are equally applicable to any kind of service / application where there is interdependence between PDUs, where PDUs of a given bearer may be of different types / importance, where a burst of inter-related PDUs may arrive in a bursty or semi-periodic manner, efc. As such, the behaviors disclosed are described in terms of PDU sets, data bursts, frames, efc., and easily can be mapped to the behavior of such types of services / appl ications / traffic.

[0228] In an embodiment, a WTRU associates PDU sets or data bursts with a certain path. For example, a WTRU is configured with a split bearer, wherein a PDU, PDU set, or PDU data burst is associated with the primary split-bearer path or / and secondary split-bearer path based on the characteristics of the PDU, PDU set, or PDU data base.

[0229] In an embodiment, a WTRU performs the following operations:Receives configurations about a split bearer, where the split bearer configuration contains association between PDUs, PDU sets, or PDU data bursts and the paths of the split bearer (e.g., based on PDU- set size, type, importance, PSDB, and / or TTL)Upon receiving a packet from higher layers that belongs to the split bearer, determines the path for the data, e.g., PDU(s), PDU set(s), and / or PDU data burst(s), based on the received configuration and sends the data via the determined split-bearer path.

[0230] In an embodiment, a WTRU may be configured to determine a UL path at a PDU level. For example, the WTRU may be configured with a split bearer (e.g., a bearer having two or more data paths for transmitting and / or receiving data) where the UL path for the PDUs is determined based on the PDU type. For example, the WTRU may be configured to always transmit the PDUs of type 1 via a primary split-bearer path, and the PDUs of type 2 via a secondary split-bearer path, efc.

[0231] In an embodiment, a WTRU may be configured with a split bearer where the UL path for the PDUs is determined based on the importance level of the PDU set. For example, the WTRU may be configured to always transmit the PDUs of importance level 1 via a primary split-bearer path, and the PDUs of importance level 2 via a secondary split-bearer path, etc.

[0232] In an embodiment, a WTRU may be configured to alternate the usage of the different split-bearer paths for every PDU. For example, the WTRU may be configured to use a primary path for the first PDU of a split bearer, then use a secondary path for the second PDU of the split bearer, then the primary path for the third PDU of the split bearer, and so on.

[0233] In an embodiment, a WTRU may be configured with an alternating pattern for the usage of the different paths of a split bearer for every PDU. For example, the WTRU may be configured to use a primary path for the first n PDUs of a split bearer, then use the secondary path for the next m PDUs of the split bearer, then the primary path for the next n PDUs, and so on (where n can be different from m).

[0234] A combination or sub-combination of the above embodiments is also possible. For example, the WTRU may be configured to use a primary split-bearer path for PDUs of importance level greater than a, if they are of type 1 , efc.

[0235] In an embodiment, a WTRU may be configured to determine a UL path at a PDU-set level. For example, a WTRU may be configured with a split bearer where the UL path for the PDUs is determined based on the PDU-set type For example, the WTRU may be configured to always transmit the PDUs belonging to PDU sets that are of type 1 via a primary path of the split bearer, and the PDUs belonging to PDU sets that are of type 2 via a secondary path of the split bearer, etc.

[0236] In an embodiment, a WTRU may be configured with a split bearer where the UL path for the PDUs is determined based on the importance level of the PDU set. For example, the WTRU may be configured always to transmit the PDUs belonging to PDU sets that are of importance level 1 via a primary path of the split bearer, and always to transmit the PDUs belonging to PDU sets that are of importance level 2 via a secondary path of the split bearer, etc. In another example, the WTRU may be configured to transmit PDUs belonging to PDU sets that are of importance less than a certain level via a secondary path of the split bearer and the other PDU sets via a primary path of the split bearer.

[0237] In an embodiment, a WTRU may be configured with a split bearer where the UL path for the PDUs is determined based on the PDU-set size. For example, the WTRU may be configured always to transmit the PDUs belonging to PDU sets that have a size greater than x Kbytes via a primary path of the split bearer and transmit the PDUs that belong to PDU sets with sizes of X Kbytes or less via a secondary path of the split bearer. For example, the WTRU may determine the size of the PDU set upon the reception of the first PDU ofthe PDU set e.g., information from application layers and / or information from packet headers) and may determine the path of the split bearer for the first PDU of the PDU set based on the determined size and the configured size threshold and may send the first PDU of the PDU set and all subsequent PDUs of the PDU set via the determined ( / .e., the same) path

[0238] In an embodiment, a WTRU may be configured with a split bearer where the UL path for the PDUs is determined based on the PDU-set delay budget, PSDB. For example, the WTRU may be configured always to transmit the PDUs belonging to PDU sets that have PSDBs less than n milliseconds via a primary splitbearer path and always to transmit the PDUs that belong to PDU sets with PSDBs equal or greater than n milliseconds via a secondary split-bearer path, or vice versa.

[0239] In an embodiment, a WTRU may be configured to alternate the usage of the different paths for every PDU set. For example, the WTRU may be configured to use a primary path for the first PDU set of a split bearer, then use a secondary path for the second PDU set of the split bearer, then use the primary path for the third PDU set of the split bearer, and so on.

[0240] In an embodiment, a WTRU may be configured with an alternating pattern for the usage of the different paths of a split bearer for every PDU set. For example, the WTRU may be configured to use a primary path for the first n PDU sets of a split bearer, then use a secondary path for the next m PDU sets of the split bearer, then the primary path for the next n PDU sets of the split bearer, and so on (where n can be different from m).

[0241] In an embodiment, a WTRU may be configured to choose either a primary path or a secondary path of a split bearer for the PDUs of a PDU set based on WTRU implementation, as long as the WTRU maintains the same path for all the PDUs of the PDU set.

[0242] A combination or sub-combination of the above embodiments is also possible. For example, a WTRU may be configured to use a primary path of a split bearer for PDU sets of an importance level greater than a, PDU sets having a size less than b and a PSDB less than c, etc.

[0243] In an embodiment, in case the PDUs within a PDU set have different characteristics, the UL path determination for all the PDUs of a PDU set may be dependent on the importance levels of the PDUs within the PDU set (e.g., lowest importance level, highest importance level, median importance level, mean importance level, and / or mode importance level). For example, a WTRU may be configured to choose a primary path of the split bearer for the PDUs of the PDU set if the average importance level of the PDUs within the PDU set is below a certain threshold but otherwise use a secondary path of the split bearer. For example, the WTRU may be configured to choose the primary path for the PDUs of the PDU set if there are one or more PDUs within the PDU set that have an importance level above a certain level, below a certain level, efc.

[0244] In an embodiment, the UL path determination for all the PDUs of a PDU set is dependent on the type of the PDUs of the PDU set. For example, a WTRU may be configured to choose a primary path of a split bearer for the PDUs of the PDU set if the PDU set includes one or more PDUs of a certain type, or if the PDU set doesn’t contain PDUs of a certain type, efc.

[0245] The above embodiments described for determining the UL path at PDU-set level also can be configured at a data-burst level.

[0246] In an embodiment, the UL path determination for all the PDUs of a data burst is dependent on the total size of the data burst. For example, a WTRU may be configured to choose the primary path of a split bearer if the total size of the data burst is below a certain threshold but otherwise choose a secondary path of the split bearer.

[0247] In an embodiment, the UL path determination for all the PDUs of a data burst is dependent on the PSDBs of the PDU sets of the data burst (e.g., lowest PSDB, highest PSDB, median PSDB, mean PSDB, mode PSDB, and / or sum of the PSDBs). For example, the WTRU may be configured to choose the primary path of a split bearer for the data burst if the average PSDB of all the PDU sets within the data burst is below a certain threshold but otherwise to choose the secondary path, or vice versa.

[0248] In an embodiment, a UL path determination for all the PDUs of a data burst is dependent on the importance levels of the PDU sets of the data burst (e.g., lowest importance level, highest importance level, median importance level, mean importance level, and / or mode importance level). For example, a WTRU may be configured to choose a primary path of a split bearer for the data burst if the average importance level of the PDU sets within the data burst is below a certain threshold or above a certain threshold, etc. For example, the WTRU may be configured to choose the primary path for all the PDUs of the data burst if there are one or more PDU sets within the data burst that have an importance level above a certain level or below a certain level, efc.

[0249] In an embodiment, the UL path determination for all the PDUs of a data burst is dependent on the type of the PDU sets of the data burst. For example, the WTRU may be configured to choose a primary path of a split bearer for the data burst if the data burst includes one or more PDU sets of a certain type, or if the data burst does not contain any PDU sets of a certain type, efc.

[0250] A combination or subcombinaton of all the above embodiments is also possible.

[0251] A WTRU may be configured to keep the same split-bearer path for PDUs within a PDU set or data burst. For example, a WTRU is configured with a split bearer and associated split-buffer threshold, wherein once the split-buffer threshold has been passed, the WTRU determines one path (primary or secondary path) of the split-bearer to transmit all the UL packets of a certain PDU set or / and data burst

[0252] In an embodiment, a WTRU performs the following operations:Upon determining that the UL buffer for the split bearer has become larger than the split-buffer threshold: o Continues to send any remaining UL PDUs belonging to PDU sets or data bursts that are already being transmitted over the primary path of the split bearer o When the first PDU of a subsequent PDU set or data burst arrives, determines to use the primary or secondary path of the split bearer for all the PDUs of that PDU set or data burst o Uses the determined path (e.g., primary path or secondary path) for the first PDU and all subsequent PDUs of the PDU set or data burstUpon determining that the UL buffer for that bearer (e.g., the determined path) has become smaller than the split-buffer threshold: o Continues to send any remaining UL PDUs belonging to PDU sets or data bursts that are already being transmitted over the path that is already associated with that PDU set or data burst o When the first PDU of a subsequent PDU set or data burst arrives, uses the primary path of the split bearer for all the PDUs of that subsequent PDU set or data burst (and maybe the PDUs of any additional subsequent PDU sets or data bursts)

[0253] In an embodiment, a WTRU makes a UL path determination at a PDU set level. Herein several examples are provided that are mainly concerned in enabling the WTRU to make the decision whether it can switch the path being used for sending the PDUs of an ongoing PDU set based on split buffer level thresholds.

[0254] In an embodiment, a WTRU may be configured with a split bearer and a split-buffer threshold, wherein if the WTRU determines that the split-buffer threshold for that bearer (e.g., the path of the split bearer that the WTRU is currently using) is passed when a UL PDU is received at the WTRU: if the current PDU set is of a certain type (e.g., typel), then the WTRU applies legacy handling for the remaining PDUs of the PDU set ( / .e., it could choose the primary split-bearer path or the secondary split-bearer path to schedule the PDUs, based on WTRU implementation) if the current PDU set is of another type (e.g., type2), then the WTRU sends the remaining PDUs of the PDU set over the same path, i.e., o keeps using the primary path to send the remaining PDUs of the PDU set o for any subsequent PDU sets of this type, applies legacy handling for the first PDU of the PDU set (i.e., it could choose the primary path or the secondary path to schedule the PDUs, based on WTRU implementation), and keeps using the same chosen path for the remaining PDUs of the PDU set

[0255] In an embodiment, a WTRU may be configured with a split bearer and a split-buffer threshold, wherein if the WTRU determines that the buffer level is below the split-buffer threshold for that bearer (after it has been above the threshold previously) when an UL PDU is received at the WTRU: if the current PDU set is of a certain type (e.g., typel), then the WTRU applies legacy handling for the remaining PDUs of the PDU set (e.g., chooses the primary split-bearer path to schedule the PDUs) if the current PDU set is of another type (e.g., type2), then the WTRU sends the remaining PDUs of the PDU set over the same path, i.e., o if the primary path was being used to send the PDUs of this PDU set, then the WTRU keeps using the primary path to send the remaining PDUs of the PDU seto if the secondary path was being used to send the PDUs of this PDU set, then the WTRU keeps using the secondary path for the remaining PDUs of the PDU set o for any subsequent PDU sets, the WTRU uses the primary path

[0256] In an embodiment, a WTRU may be configured with a split bearer and a split-buffer threshold, wherein if the WTRU determines that the split-buffer threshold for that bearer (the one of the bearer paths that the WTRU is currently using) is passed when a UL PDU is received at the WTRU: if the current PDU set is of a certain importance (e.g., importance level 1), then the WTRU applies legacy handling for the remaining PDUs of the PDU set (f.e., the WTRU could choose the primary or the secondary path to schedule the PDUs, based on WTRU implementation) if the current PDU set is of another importance level (e.g., importance level 2), then the WTRU sends the remaining PDUs of the PDU set over the same path, i.e., o the WTRU keeps using the primary path to send the remaining PDUs of the PDU set o for any subsequent PDU sets of this type, the WTRU applies legacy handling for the first PDU of the PDU set (i.e., the WTRU could choose the primary or the secondary path to schedule the PDUs, based on WTRU implementation), and keeps using the same chosen path for the remaining PDUs of the PDU set

[0257] In an embodiment, a WTRU may be configured with a split bearer and a split-buffer threshold, wherein if the WTRU determines that the buffer level is below the split-buffer threshold for that bearer (after it has been above the threshold previously) when a UL PDU is received at the WTRU: if the current PDU set is of a certain importance level (e.g., importance level 1), then the WTRU applies legacy handling for the remaining PDUs of the PDU set (e.g., chooses the primary split-bearer path to schedule the PDUs) if the current PDU set is of another importance level (e.g., importance level 2), the WTRU sends the remaining PDUs of the PDU set over the same path, i.e., o if the primary split-bearer path was being used to send the PDUs of this PDU set, then the WTRU keeps using the primary path to send the remaining PDUs of the PDU set o if the secondary path was being used to send the PDUs of this PDU set, then the WTRU keeps using the secondary path for the remaining PDUs of the PDU set o for any subsequent PDU sets, the WTRU uses the primary path

[0258] In an embodiment, a WTRU may be configured with a split bearer and a split-buffer threshold, wherein if the WTRU determines that the split-buffer threshold for that bearer (the bearer current being used by the WTRU) is passed when a UL PDU is received at the WTRU:if the amount of data that remains to be sent for the PDU set to which the PDU belongs is more than a certain amount (e.g., more than a certain number of Kbytes, more than a certain number of PDUs, and / or more than a certain percentage of the PDU-set size), then the WTRU applies legacy handling for the remaining PDUs of the PDU set (e.g., the WTRU could choose the primary split-bearer path or the secondary split-bearer path to schedule the PDUs, based on WTRU implementation) if the amount of data that remains to be sent for the PDU set to which the PDU belongs s less than a certain amount (e.g., less than a certain number of Kbytes, less than a certain number of PDUs, and / or less than a certain percentage of the PDU-set size), then the WTRU sends the remaining PDUs of the PDU set over the same path, i.e., the WTRU o keeps using the primary split-bearer path to send the remaining PDUs of the PDU set o for any subsequent PDU sets of this type, applies legacy handling for the first PDU of the PDU set (i.e., it could choose the primary path or the secondary path to schedule the PDUs, based on the WTRU implementation), and keeps using the same chosen path for the remaining PDUs of the PDU set

[0259] In an embodiment, a WTRU may be configured with a split bearer and a split-buffer threshold, wherein if the WTRU determines that the buffer level is below the split-buffer threshold for that bearer (the bearer / path that the WTRU is currently using after the buffer level has been above the threshold previously) when a UL PDU is received at the WTRU: if the amount of data that remains to be sent for the PDU set to which the PDU belongs is more than a certain amount (e.g., more than a certain number of Kbytes, more than a certain number of PDUs, and / or more than a certain percentage of the PDU-set size), then the WTRU applies legacy handling for the remaining PDUs of the PDU set (e.g., uses the primary path of the split bearer to schedule the PDUs) if the amount of data that remains to be sent for the PDU set to which the PDU belongs is less than a certain amount (e.g., less than a certain number of Kbytes, less than a certain number of PDUs, and / or less than a certain percentage of the PDU set size), then the WTRU sends the remaining PDUs of the PDU set over the same path before switching, i.e., o if the primary path was being used to send the PDUs of this PDU set, then the WTRU keeps using the primary path to send the remaining PDUs of the PDU set o if the secondary path was being used to send the PDUs of this PDU set, then the WTRU keeps using the secondary path for the remaining PDUs of the PDU set o for any subsequent PDU sets, the WTRU uses the primary path.

[0260] In an embodiment, a WTRU may be configured with a split bearer and a split-buffer threshold, wherein if the WTRU determines that the split-buffer threshold for that currently used bearer is passed when an UL PDU is received at the WTRU: if the PSDB of the PDU set to which the PDU belongs is more than a certain value, then the WTRU applies legacy handling for the remaining PDUs of the PDU set ( / '.e., the WTRU could choose the primary path or the secondary path of the split-bearer configuration to schedule the PDUs, based on the WTRU implementation) if the PSDB of the PDU set to which the PDU belongs is less than a certain value, then the WTRU sends the remaining PDUs of the PDU set over the same path, i.e., the WTRU o keeps using the primary path to send the remaining PDUs of the PDU set o for any subsequent PDU sets of this type, applies legacy handling for the first PDU of the PDU set (i.e., the WTRU could choose the primary or the secondary path to schedule the PDUs, based on the WTRU implementation), and keeps using the same chosen path for the remaining PDUs of the PDU set.

[0261] In an embodiment, a WTRU may be configured with a split bearer and a split-buffer threshold, wherein if the WTRU determines that the buffer level is below the split-buffer threshold for that (current) bearer (after it has been above the threshold previously) when a UL PDU is received at the WTRU: if the PSDB of the PDU set to which the PDU belongs is more than a certain value, then the WTRU applies legacy handling for the remaining PDUs of the PDU set (i.e., uses the primary path to schedule and / or transmit the PDUs) if the PSDB of the PDU set to which the PDU belongs is less than a certain value, the the WTRU sends the remaining PDUs of the PDU set over the same path, i.e., o if the primary split-bearer path was being used to send the PDUs of this PDU set, then the WTRU keeps using the primary path to send the remaining PDUs of the PDU set o if the secondary split-bearer path was being used to send the PDUs of this PDU set, then the WTRU keeps using the secondary path for the remaining PDUs of the PDU set o for any subsequent PDU sets, the WTRU uses the primary path

[0262] In a variant of one or more of the above embodiments, the immediate possibility to switch the splitbearer path (e.g., from the primary path to the secondary path or from the secondary path to the primary path) within a PDU set could be configured to be for the PDU sets that have a PSDB less than a certain value.

[0263] In a variant of one or more of the above embodiments, instead of the PSDB, the remaining time for the PDU set, TTL, could be used as the determining factor. For example, the WTRU makes the decision to be able to switch the split-bearer path in the middle of the PDU-set transmission based on whether the TTL is less than or more than a threshold.

[0264] In an embodiment, in case the PDUs within a PDU set have different characteristics, the UL path determination for all the PDUs of a PDU set is dependent on the importance levels of the PDUs within the PDU set (e.g., lowest importance level, highest importance level, median importance level, mean importance level, and / or mode importance level). For example, the WTRU may be configured to be able to switch the UL path for an ongoing PDU set if the average importance level of the PDUs within the PDU set is below a certain level but if the average importance level is greater than or equal to that certain level, then the WTRU flushes the remaining PDUs of the PDU set before the WTRU is able to switch the path. For example, the WTRU may be configured to be able to switch the UL path for an ongoing PDU set if there are one or more pending PDUs within the PDU set that have an importance level above a certain level, below a certain level, etc.

[0265] In an embodiment, the UL path determination for all the PDUs of a PDU set is dependent on the type of the PDUs in the PDU set. For example, the WTRU may be configured to be able to switch the UL path for an ongoing PDU set if there are one or more PDUs of a certain type in the PDU set or if there are no PDUs of a certain type in the PDU set, etc.

[0266] In an embodiment, the WTRU makes the UL path determination at a data-burst level. For example, the above embodiments described for determining the UL path at a PDU-set level can also be configured for determining the UL path at a data-burst level.

[0267] In an embodiment, the UL path determination for the PDUs of a data burst within a split bearer when the split-buffer threshold is exceeded is dependent on the type of the PDU sets within the data burst For example, the WTRU may be configured to be able to switch the UL path for an ongoing data burst when the split-buffer threshold is exceeded if there are one or more pending PDU sets of a certain type in the data bust, if there are no PDU sets of a certain type in the data burst, etc.

[0268] In an embodiment, the UL path determination for the PDUs of a data burst within a split bearer when the split-buffer threshold is exceeded is dependent on the importance levels of the PDU sets of the data burst (e.g., lowest importance level, highest importance level, median importance level, mean importance level, and / or mode importance level, etc.). For example, the WTRU may be configured to be able to switch the UL path for an ongoing data burst when the split-buffer threshold is exceeded if the average importance level of the pending / ongoing PDU sets within the data burst is below a certain level, above a certain level, efc. For example, the WTRU may be configured to be able to switch the UL path for an ongoing data burst when the split-buffer threshold is exceeded if there are one or more pending PDU sets of a certain importance level in the data bust, if there are no PDU sets of a certain importance level in the data burst, efc.

[0269] In an embodiment, the UL path determination for the PDUs of a data burst within a split bearer when the spit-buffer threshold is exceeded is dependent on the remaining size of the data burst. For example, the WTRU may be configured to be able to switch the UL path for an ongoing data burst when the split-buffer threshold is passed if the size of the remaining / pending data of the data burst (e.g., sum of the data already buffered that belongs to the data burst and remaining expected data that belongs to the data burst) is above a certain threshold.

[0270] In an embodiment, the UL path determination for the PDUs of a data burst within a split bearer when the spit-buffer threshold is passed is dependent on the PSDBs or the TTLs of the ongoing / pending PDU sets within the data burst (e.g., lowest PSDB, highest PSDB, median PSDB, mean PSDB, mode PSDB, and / or sum of the PSDBs). For example, the WTRU may be configured to be able to switch the UL path for an ongoing data burst when the split-buffer threshold is exceeded if the PSDB or TTL of the remaining / pending PDU sets within the data burst is above a certain threshold or below a certain threshold, etc.

[0271] A combination or subcombination of all the above embodiments is also possible.

[0272] In an embodiment, the split-buffer threshold for a split bearer can have two values, a high value (v1) and a low value (v2), where v1 is used in determining to switch from using the primary path only to the possibility of using both the primary and secondary paths, and v2 is used in determining to switch from being able to use both the primary and secondary paths back to using only the primary path.

[0273] In an embodiment, the split-buffer threshold is compared not with the buffer level for the split-bearer path currently being used, but with the total UL buffer level on the primary path ( / '.e., decision is made based on how much data is pending to be sent over the primary path, regardless to which bearer the data belongs).

[0274] In an embodiment, a split-buffer threshold considers PDU / PDU set characteristics.

[0275] In an embodiment, a WTRU is configured with a split-bearer and an associated split-buffer threshold to decide when to start using the secondary path, where the buffer threshold considers only PDUs that fulfill certain conditions (e.g., type, importance, and / or PSDB).

[0276] In an embodiment, a WTRU is configured with a split bearer to perform the following operations: the WTRU is configured with a split-buffer threshold, where the split-buffer threshold is concerning PDUs or PDU sets with certain characteristics, e.g., o PDUs or PDU sets of a certain PSDB, o PDUs or PDU sets of a certain type, o PDUs or PDU sets of a certain importance level, etc. the WTRU determines the total buffer size to be compared with the split-buffer threshold to be the sum of the pending UL data that matches the configured characteristics.If the determined total buffer size is greater than the configured split-buffer threshold, then the WTRU is able to use also the secondary path for sending the packets of the bearer. One can think of “packets of the bearer” as follows. A bearer is a logical "tunnel" for sending and / or receiving data (or other) packets. In a UL, for example, data (or other) packets come from applications (e.g., web browsers, streaming apps), and a WTRU maps the packets to the bearer(s) configured for those packets (e.g., based on QoS flow identifiers) or for which the packets are configured.

[0277] Herein several embodiments are provided that are mainly dealing with configuring the WTRU with a different way of calculating the buffer size to be compared with the split-buffer threshold, as compared to the legacy way of considering all the pending data of the split-bearer on the primary path.

[0278] In an embodiment, buffer-size calculations consider PDU or PDU set characteristics.

[0279] In an embodiment, the WTRU is configured to consider only PDUs or PDU sets of a certain type or types that are in the UL buffer of a given split bearer when calculating the buffer size that is to be compared with the split-buffer threshold of the bearer to determine whether to use only the primary path or able to use both the primary and secondary paths. For example, if a WTRU has 10 PDUs of a given split bearer pending in the transmission buffer of the primary path, and five of the PDUs are of type 1 , three of the PDUs are of type 2, and two of the PDUs are of type 3, then the WTRU may be consider the buffer size to be (assuming the PDUs are of equal size n) to be 5n, 3n, 2n, (5n+3n), (5n+2n) , (2n+3n), or (5n+2n+3n) depending on the PDU type or types that the WTRU is configured to consider in the buffer-size calculation. An alternative way is to configure the WTRU with the PDU types that it is not to consider in the total buffer-size calculation.

[0280] In an embodiment, the WTRU is configured to consider only PDUs or PDU sets of a certain importance level or levels that are in the UL buffer of a given split bearer when calculating the buffer size that is to be compared with the split-buffer threshold of the bearer to determine whether to use only the primary path or to use both the primary and secondary paths. For example, if a WTRU has ten PDUs of a given split bearer pending in the transmission buffer of the primary path, and five of the PDUs are of importance level 1 , three PDUs are of importance level 2, and two PDUs are of importance level 3, then the WTRU may consider the buffer size to be (assuming that the PDUs are of equal size n) to be 5n, 3n, In, (5n+3n), (5n+2n), (2n+3n), or (5n+2n+3n) depending on the important level or levels that the WTRU is configured to consider in the buffersize calculation. An alternative way is to configure the WTRU with the importance levels that it is not consider in the total buffer-size calculation.

[0281] In an embodiment, the WTRU is configured to consider only PDUs of PDU sets of a certain PSDB (e.g., less than a certain threshold) that are in the UL buffer of a given split bearer when calculating the buffer size that is to be compared with the split-buffer threshold of the bearer to determine whether to use only the primary path or to use both the primary and secondary paths. For example, if a WTRU has ten PDUs of a given split bearer pending in the transmission buffer of the primary path, and five of the PDUs belong to a PDU set of PSDB1 , three of the PDUs belong to a PDU set of PSDB2, and two of the PDUs belong to a PDU set of PSDB3 (where PSDB1 < PSDB2 < PSDB3), if the WTRU is configured to consider only PDU sets of PSDB less than x, where x is between PSDB2 and PSDB3, then the WTRU will consider the buffer size to be 5n+3n, assuming that the PDUs are of equal size n (where n is the number of, e.g., bits, bytes, words, or packets in a PDU).

[0282] In an embodiment, the WTRU is configured to consider only PDUs of PDU sets of a certain TTL (e.g., less than a certain threshold) that are in the UL buffer of a given split bearer when calculating the buffer size that is to be compared with the split-buffer threshold of the bearer to determine whether to use only the primary path or to use both the primary and secondary paths. That is, the WTRU will start adding PDUs that are in the buffer in the total buffer-size calculation when / if the TTL of the PDU set falls below the configured threshold (e.g., a PDU that has been in the bufferfor a longer time but that belongs to a PDU set that has a larger PSDBmay not be added to the buffer-size calculation, while a PDU that has been in the buffer only for a short time but belongs to a PDU set with a shorter PSDB may be added to the buffer calculation.

[0283] A combination or subcombination of all the above embodiments is also possible. For example, the WTRU can be configured to consider PDUs of types x and y, with importance level more than n, that have PSDBs less than t1 in the total buffer-size calculation.

[0284] In an embodiment, different split-buffer thresholds can be used for different PDU or PDU set characteristics.

[0285] In an embodiment, the WTRU is configured to consider several split-buffer thresholds, where each split-buffer threshold is associated with different characteristics of PDUs or PDU sets. This could, for example, be:Thresholds related to PDU type. o T1 : for type_1 o T2: for type_2 o T3: for type_3, etc.Thresholds related to PDU / PDU-set importance level o L1 : for level_1 o L2: for level_2 o L3: for level_3, etc.Thresholds related to PSDB o P1: for PSDB < psdb_1 o P1 : for psdb_1 £ PSDB s psdb_2 o o Pn: for PSDB > psdb_n-1, etc.Thresholds related to TTL o TTL1: for TTL < TTL_1 o TTL2: for TTL_1 < TTL < TTL_2 o o TTLn: for TTL > TTL_n-1, etc.

[0286] That is, the WTRU keeps the total buffer-size calculation for each categorization of the PDUs and compares the number of PDUs in each category with the corresponding thresholds.

[0287] For example, the WTRU maintains different total buffer-size values for PDUs belonging to types 1, 2 and 3, and compares each total buffer-size value with the corresponding configured threshold to determine whether the WTRU keeps using the primary path only or can also use the secondary path to send the PDUs of the certain type.

[0288] In an embodiment, the WTRU may determine to use the primary path only or also to use the secondary path at a bearer level, but the determination is based on one or more of the conditions associated with each categorization as in the previous solution. For example, the WTRU may be configured to be able to start using the secondary path for any new PDUs of the split bearer ( / '.e., regardless of the characteristics of the PDU or PDU set) if the buffer level for PDUs of type_1 is above T 1 or the buffer level for PDUs of importance level 1 is above L1, etc. In another example, the WTRU may be configured to be able to start using the secondary path for any new PDUs of the split bearer ( / .e., regardless of the characteristics of the PDU or PDU set) if the buffer level for PDUs of type_1 is above T 1 and the buffer level for PDUs of importance level 1 is above L1, etc.

[0289] In an embodiment, buffer-size (e.g., buffer-level) thresholds according to any of the embodiments above are calculated in terms of the number of outstanding PDUs, instead of total bytes (and corresponding thresholds also specified in terms of the number of PDUs).

[0290] In an embodiment, buffer-size thresholds according to any of the embodiments above are calculated across all split bearers that have the same primary path instead of for just one split bearer. For example, assume there are four split bearers, and bearer #1 and bearer #2 have a primary path set to the MCG while bearer #3 and bearer #4 have primary path set to the SCG.

[0291] Thus, the WTRU maintains buffer sizes for the different configured categorizations of PDUs or PDU sets for the MCG path and the SCG path (as each path is a primary path for some bearers), where the total buffer size (level) for each category of PDU is summed across the bearers. For example, total buffer value 1 for PDUs of importance level 1 on the MCG path will be the sum of the pending PDUs of importance level 1 for split bearers #1 and #2, and so on, and the corresponding threshold for the PDUs of importance level 1 is to be compared with this total value, to determine whether the WTRU can also use the secondary path ( / .e., SCG in this case) to send PDUs of importance level 1 , and so on. Similarly, total-buffer-size calculations are made on the SCG size for the different categorizations of the PDUs or PDU sets, and compared with the corresponding split-buffer thresholds for those bearers that have the SCG as the primary path to determine whether the WTRU can also use the secondary path ( / .e., MCG in this case) to send PDUs of the concerned categorization, and so on

[0292] In an embodiment, buffer-size (e.g., buffer-level) thresholds according to any of the embodiments herein not only considers all the split bearers that have the same primary path, but also non split bearers on that same path. For example, when calculating the total buffer sizes (levels) on the MCG path for a certain categorization above according to PDU type, importance, PSDB, etc., the WTRU adds up not only the PDUs of the same categorization of the split bearers that have the MCG as the primary path, but also includes, in the sum, other PDUs that use MCG bearers (i.e., bearers that are associated only with the MCG path). Similarly, when calculating the total buffer sizes (levels) on the SCG path for a certain categorization above according toPDU type, importance, PSDB, etc., the WTRU adds up not only the PDUs of the same categorization of the split bearers that have the SCG as the primary path, but also includes, in the sum, other PDUs that use SCG bearers (i.e., bearers that are associated only with the SCG path).

[0293] FIG. 6 is a flow diagram 600 of a procedure that a WTRU can perform, according to an embodiment.

[0294] At 602, the WTRU determines a path for a first PDU based on a split-bearer configuration.

[0295] And at 604, the WTRU transmits the first PDU via the determined path.

[0296] FIG. 7 is a flow diagram 700 of a procedure that a WTRU can perform, according to another embodiment.

[0297] At 702, the WTRU (e.g., a processor circuit of the WTRU) determines that a UL bufferfor a split bearer has a relationship to a split-buffer threshold.

[0298] At 704, the WTRU (e.g., a transceiver of the WTRU) transmits any remaining PDUs over a path associated with the remaining PDUs.

[0299] At 706, in response to the WTRU (e.g., the transceiver) receiving a first other PDU, the WTRU (e.g., the processor circuit) determines a path (e.g., a split-bearer path) over which to transmit (e.g., with the transceiver) the first other PDU.

[0300] And at 708, the WTRU (e.g., the transceiver) transmits the first other PDU via the determined path.

[0301] FIG. 8 is a flow diagram 800 of a procedure that a WTRU can perform, according to yet another embodiment.

[0302] At 802, the WTRU (e.g., a processor circuit of the WTRU) determines a buffer size as a mathematical combination (e.g., sum, difference, product, and / or quotient) of pending PDUs having a characteristic, such as a same level of importance.

[0303] At 804, the WTRU (e.g., the processor circuit) compares the buffer size i.e., the size of the buffer contents, the buffer-fill level) to a split-buffer threshold that is related to the characteristic

[0304] And at 806, the WTRU (e.g., a transceiver of the WTRU), in response to the buffer size having a relationship (e.g., greater than, less than, equal to) the split-buffer threshold, transmits the PDUs via at least one path (e.g., a split-bearer path) that corresponds to the relationship.

[0305] FIG. 9 is a flow diagram 900 of a procedure that a WTRU can perform, according to still another embodiment.

[0306] At 902, a WTRU (e.g., a transceiver circuit of the WTRU) receives information indicating a split-bearer configuration that is associated with multiple paths (e.g., multiple data-communication paths of a bearer, the multiple paths causing the bearer to be split).

[0307] At 904, the WTRU (e.g., a processor circuit of the WTRU) determines at least one characteristic related to a Protocol Data Unit (PDU). For example, the determined at least one characteristic may be one or more of a PDU type, a PDU Set type, a PDU Set Delay Budget (PSDB), remaining time of expiry of the PSDB, size of a PDU Set, importance of a PDU, or importance of a PDU Set.

[0308] At 906, the WTRU (e.g., a processor circuit of the WTRU) selects, from the multiple paths, after receiving the information indicating the split-bearer configuration and determining the at least onecharacteristic, a path for the PDU. For example, the WTRU selects, from multiple paths, based on the splitbearer configuration and the determined at least one characteristic, a path for the PDU;

[0309] And at 908, the WTRU (e.g., a transceiver circuit of the WTRU) transmits the PDU over the selected path

[0310] FIG. 10 is a flow diagram 1000 of a procedure that a WTRU can perform, according to another embodiment.

[0311] At 1002, a WTRU (e.g., a transceiver circuit of the WTRU) receives a configuration that indicates one or more of a buffer threshold, at least one characteristic of a data packet, or multiple paths.

[0312] At 1004, the WTRU (e.g., a processor circuit of the WTRU) compares a fill level of a buffer with the buffer threshold.

[0313] At 1006, in response to the fill level being greater than the buffer threshold, the WTRU (e.g., a processor circuit of the WTRU) determines one or more of the at least one characteristic of a data packet. For example, the determined one or more of the at least one characteristic of the data packet can be one or more of a type, a Protocol Data Unit Set Delay Budget (PSDB), a size, or an importance of the data packet.

[0314] At 1008, further in response to the fill level being greater than the buffer threshold, the WTRU (e.g., a processor circuit of the WTRU), selects, from the multiple paths based on the determined one or more of the at least one characteristic of the data packet, a path.

[0315] And at 1010, the WTRU (e.g., a transceiver of the WTRU) sends (e.g., transmits) the data packet over the selected path.

[0316] FIG. 11 is a flow diagram 1100 of a procedure that a WTRU can perform, according to another embodiment.

[0317] At 1102, a WTRU (e.g., a processor circuit of the WTRU) receives a configuration that indicates a characteristic, a buffer threshold, and / or multiple paths.

[0318] At 1104, the WTRU (e.g., a processor circuit of the WTRU) determines the characteristic of a data packet from information within the data packet. For example, the determined characteristic can be one or more of a type, Protocol Data Unit Set Delay Budget (PSDB), size, or importance of the data packet.

[0319] At 1106, the WTRU (e.g., a processor circuit of the WTRU) compares a fill level of a buffer for data packets having the determined characteristic with a buffer threshold related to the determined characteristic.

[0320] At 1108, the WTRU (e.g., a processor circuit of the WTRU) selects, in response to the fill level being less than or equal to the buffer threshold, a primary path from the multiple paths that include the primary path and a secondary path and that are configured for propagation of data.

[0321] At 1110, the WTRU (e.g., a processor circuit of the WTRU) selects, in response to the fill level being greater than the buffer threshold, the secondary path from the multiple paths.

[0322] And, at 1112, the WTRU (e.g., a transceiver of the WTRU) sends the data packet over the selected path

[0323] Although features and elements are described 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 otherfeatures and elements. In addition, the methods described 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, magnetooptical 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.

Claims

CLAIMSWhat is Claimed:

1. A method performed by a WTRU, the method comprising: receiving information indicating a split-bearer configuration that is associated with multiple paths; determining at least one characteristic related to a Protocol Data Unit (PDU), the determined at least one characteristic being one or more of a PDU type, PDU Set type, PDU Set Delay Budget (PSDB), remaining time of expiry of the PSDB, size of a PDU Set, importance of a PDU, or importance of a PDU Set; selecting, from the multiple paths, after receiving the information indicating the split-bearer configuration and determining the at least one characteristic, a path for the PDU; and transmitting the PDU over the selected path.

2. The method of claim 1 , further comprising determining the PDU is available for transmission.

3. The method of any of claims 1-2 wherein the PDU belongs to a Protocol Data Unit Set (PDU Set).

4. The method of any of claims 1-3 wherein the split-bearer configuration is configured as a radio bearer and the multiple paths include paths configured for the transmission and reception of data associated with the radio bearer.

5. The method of any of claims 1-4 wherein the determining includes determining the at least one characteristic based on information within the PDU.

6. The method of any of claims 1-5 wherein the multiple paths include primary and secondary paths.

7. The method of any of claims 1-6 wherein the selecting includes selecting the path from the multiple paths based on at least one characteristic related to the path.

8. The method of claim 7 wherein the at least one characteristic related to the path includes a latency of the path and / or a throughput of the path.

9. The method of any of claims 1-8 wherein the selecting includes selecting the path based on at least one characteristic of another path of the multiple paths.

10. The method of any of claims 1-9 wherein the split-bearer configuration indicates that the at least one characteristic is related to a Protocol Data Unit and / or the multiple paths11. The method of and of claims 1-10, further comprising receiving the PDU from an application layer.

12. A WTRU, comprising:a transceiver circuit configured to receive information indicating a split-bearer configuration that is associated with multiple paths; a processing circuit configured to: determine at least one characteristic related to a Protocol Data Unit (PDU), the determined at least one characteristic being one or more of a PDU type, PDU Set type, PDU Set Delay Budget (PSDB), remaining time of expiry of the PSDB, size of a PDU Set, importance of a PDU, or importance of a PDU Set, and select, from the multiple paths, after the transceiver circuit receives the information indicating the splitbearer configuration and the processor circuit determines the at least one characteristic, a path for the PDU; and the transceiver circuit configured to transmit the PDU over the selected path.

13. The WTRU of claim 12 wherein the processing circuit is configured to determine that the PDU is available for transmission.

14. The WTRU of any of claims 12-13 wherein the PDU belongs to a Protocol Data Unit Set (PDU Set).

15. The WTRU of any of claims 12-14 wherein the split-bearer configuration is configured as a radio bearer and the multiple paths include paths configured for the radio bearer.

16. The WTRU of any of claims 12-15 wherein the processor circuit is configured to determine the at least one characteristic by determining the at least one characteristic based on information within the PDU.

17. The WTRU of any of claims 12-16 wherein the multiple paths include primary and secondary paths.

18. The WTRU of any of claims 12-17 wherein the processing circuit is configured to select the path in response to at least one characteristic of the path.

19. The WTRU of any of claims 12-18 wherein the at least one characteristic of the path is a latency of the path and / or a throughput of the path.

20. The WTRU of any of claims 12-19 wherein the processor circuit is configured to select the path based on at least one characteristic of another path of the multiple paths.

21. The WTRU of any of claims 12-20 wherein the split-bearer configuration indicates the at least one characteristic and / or the multiple paths.

22. The WTRU of any of claims 12-21 wherein the processing circuit is configured to receive the PDU from an application layer.

23. The WTRU of any of claims 12-21 wherein each of the multiple paths is configured for propagation of data.

Images