Determining paths for data packets (e.g., PDUs) based on separate bearer configurations and characteristics related to data packets

Abstract

In one embodiment, a WTRU is configured to receive information indicating a separate bearer configuration, the separate bearer configuration being associated with a plurality of 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, a PDU set type, a PDU set delay budget (PSDB), a remaining expiration time of the PSDB, a size of the PDU set, an importance of the PDU, and an importance of the PDU set; after receiving the information indicating the split bearer configuration and determining the at least one characteristic, selecting a path for the PDU from the plurality of paths; and transmitting the PDU through the selected path.

Description

Cross-references to related applications

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

[0002] The term Extended Reality (XR) is an overarching term used for different types of immersive experiences, including Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR), as well as transitional realities that lie between 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 the observer or user as they move within an area defined by the application.

[0004] Augmented reality (AR) presents users with additional information or artificially generated items or content overlaid on their current environment.

[0005] Mixed Reality (MR) is a higher form of AR, in which some virtual elements are inserted into the physical scene to provide the illusion that these elements are part of the real scene. XR can include all combinations of real and virtual environments and human-computer interactions generated by computer technology and wearable devices.

[0006] In the context of XR applications / services, immersion refers to the feeling of being surrounded by a virtual environment, as well as the feeling of being physically and spatially present within that environment. The level of virtuality can range from partial sensory input to fully immersive multisensory input, ultimately achieving virtual reality that is virtually indistinguishable from real reality.

[0007] XR devices can be associated with the ability to provide spatial tracking at various levels. XR devices can be equipped with various sensors for spatial tracking, such as monocular / stereo / depth cameras, radio beacons, GPS, inertial sensors, etc. This spatial tracking can be performed at different levels, such as 3 degrees of freedom (DoF) (i.e., rotational motion along the X, Y, and Z axes) or 6 DoF (i.e., rotational and / or translational motion along the X, Y, and Z axes). Such spatial tracking can trigger interactions to experience some form of virtual content. Users can move and / or interact with components within extended reality (XR) and / or XR environments. For example, movement and / or interaction can involve user movement or posture, eye tracking of the user's eyes, etc. Spatial tracking is a crucial enabling technology for immersive XR experiences. For example, some form of head and / or motion tracking of the user ensures that the simulated visual and audio components from the user's perspective are updated to match the user's movement. Inaccurate and / or delayed spatial tracking can lead to user discomfort and / or motion sickness.

[0008] In one implementation, a WTRU (WTRU may also be referred to as a User Equipment (UE)) can correspond to any XR device / node that can appear in various forms. Typical WTRUs (e.g., XR WTRUs) may include, but are not limited to, head-mounted displays (HMDs), optical see-through glasses and camera-based HMDs for AR and MR, mobile devices and cameras with location tracking, wearable devices, etc. In addition to the above, several different types of XR WTRUs can be envisioned based on XR device functions (e.g., displays, cameras, sensors, sensor processing, wireless connectivity, XR / media processing, and power supply), which are provided by one or more devices, wearable devices, actuators, controllers, and / or accessories. One or more devices / nodes / WTRUs can be grouped into collaborative XR groups to support any XR application / experience / service.

[0009] In current 5GS, QoS flows are typically the finest granular distinction of QoS within a Protocol Data Unit (PDU) session. 5G QoS characteristics are determined by 5QI. This means that each packet in a QoS flow is processed according to the same QoS requirements.

[0010] For XR / media services, a set of packets is used to carry the payload of a PDU set (e.g., frames, video clips / tiles). A PDU set consists of one or more PDUs carrying the payload of a single unit of information (e.g., a frame or video clip) generated at the application layer. At the media layer, packets within such a PDU set are typically decoded / processed as a whole. For example, a frame / video segment can only be decoded if all packets carrying the frame / video segment, or a certain (threshold) number of packets, are successfully transmitted and received. For instance, a frame within a GOP (Group of Pictures) can typically only be decoded by the client if all frames it depends on (e.g., all frames within the GOP used to encode that frame) are successfully transmitted and received. Therefore, groups of packets within a PDU set often have inherent dependencies on each other at the media layer. Without considering these dependencies between packets within a PDU set, 5GS can perform scheduling inefficiently. For example, 5GS might randomly drop one or more packets but attempt to transmit other packets from the same PDU set, a transmission that may be useless to the client and thus waste radio resources.

[0011] Furthermore, if 5GS takes into account the characteristics of PDU sets, audio samples, haptic applications, or remote control operations can benefit. If this dependency between PDU set groups (e.g., frame / video clips) can be considered, efficiency can be improved and the user experience enhanced.

[0012] Therefore, 3GPP is studying enhancements to the current 5GS QoS framework to support different QoS processing for PDU sets. PDU sets can carry different content, such as intra-coded / bidirectional prediction / forward prediction (I / B / P) frames, fragments / tiles within I / B / P frames, etc.

[0013] For example, differentiated QoS processing is being studied, which takes into account different importance levels of PDU sets, such as reducing resource waste by processing packets (i.e., PDUs) belonging to less important PDU sets (one or more) differently.

[0014] A data burst is a set of data PDUs generated and sent by an application within a short period of time. A data burst can consist of multiple PDUs belonging to one or more PDU sets.

[0015] The PDU set delay budget (PSDB) defines the upper limit of the time that a PDU set can be delayed between the WTRU and the N6 endpoint at the User Plane Function (UPF); the N6 endpoint is configured to provide connectivity between the UPF and any other network or service platform, such as the Internet, a public cloud, or one or more private clouds.

[0016] The PDU set error rate (PSER) defines the upper limit of the rate at which a set of PDUs has been processed by the sender of a link layer protocol (e.g., the Radio Link Control (RLC) layer), but in which all PDUs in the set have not been successfully passed to the upper layer (e.g., the Packet Data Convergence Protocol (PDCP) layer) by their corresponding receivers.

[0017] Figure 2 This is a timing diagram of an example of multiple data bursts according to one embodiment, each data burst having multiple sets of PDUs of different types.

[0018] In dual connectivity (DC), a WTRU is typically served by two nodes, each consisting of a set of cells called the primary cell group (MCG) and the secondary cell group (SCG). Radio bearers can be associated with either the MCG or the SCG only, or they can be configured as separate bearers. Figure 3 A protocol view of the decoupled bearer is shown.

[0019] For a split bearer, as with any other bearer, the WTRU has an associated PDCP entity, and the peer PDCP entity on the network side terminates at either (primary or secondary) in the gNB. In the DL, the CN (core network) sends data to the gNB where the PDCP terminates ( Figure 3 In gNB1), the network decides whether to send data directly to the WTRU via the link between the gNB and the WTRU, or to forward PDCP PDUs to gNB2 (e.g. via the Xn interface), and the gNB to which the data is forwarded (e.g., gNB2) sends data to the WTRU via the link between itself and the WTRU.

[0020] In UL, the WTRU is configured to use one of the split bearer paths as the primary path and the other as the secondary path. The network can configure the primary path for a specific bearer as MN or SN. The threshold is called... UL number According to the separation threshold (in the PDCP configuration carried) UL-DataSplitThreshold (Information Element IE). If the UL buffer size of the bearer is less than the threshold, the PDCP will only push data to the RLC associated with the main path (i.e., when UL authorization is available on that path, the data of the bearer will only be sent via the air interface resources of the node associated with the main path). However, if the buffer size becomes greater than the threshold, the WTRU can push data to either path (i.e., as determined by the WTRU implementation).

[0021] Set the separation threshold to infinity Essentially, this disables detached bearer operations (i.e., only the main path is used). On the other hand, it sets the detach threshold to... zero The concept of primary and secondary paths is disabled because WTRUs are typically always able to send UL data for that bearer via one of the two paths.

[0022] As described above, the current split bearer operation in the DC is controlled by a split buffer threshold, where the WTRU is allowed to send UL data for split bearer via either the primary or secondary path. The main intention behind this is to distribute the load between the two paths that the bearer can use (i.e., if the primary path is sufficient for the bearer, the buffer level will remain low and the secondary path will not be needed).

[0023] In the case of an active XR application on the WTRU, this behavior can lead to undesirable actions because the current PDCP path routing operates on a per-packet basis. For example, if the separation threshold is reached while the WTRU is transmitting a PDU set or data burst, the WTRU may send some PDUs from the PDU set or data burst via the primary path while sending others via the secondary path. This can cause problems such as jitter (e.g., packets in the PDU set or data burst experience very different delays), multiple out-of-order deliveries of the PDU set or data burst, and exceeding the PDU set delay budget (PSDB).

[0024] The implementation performs split bearer scheduling in a manner that takes into account the interdependencies and differences of PDUs within an XR service (e.g., a PDU set or a data burst).

[0025] In one embodiment, a PDU or set of PDUs or a data burst is always associated with a certain path.

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

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

[0028] In one embodiment, the WTRU performs the following operations: - Receive one or more configurations for the split bearer, wherein the split bearer configuration contains the 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). - When a packet is received from a higher layer belonging to the bearer, the path of the PDU is determined based on the received configuration (one or more), and the data is sent via the determined path.

[0029] In one embodiment, the same path is maintained for PDUs within a PDU set or data burst.

[0030] In an example of this implementation, the WTRU is configured with a separate bearer and an associated separate buffer threshold, wherein once the separate buffer threshold has been exceeded, the WTRU determines a path (primary path or secondary path) to transmit all UL packets of a particular PDU set and / or data burst.

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

[0032] In one embodiment, the WTRU performs the following operations: - When it is determined that the UL buffer used for the separated bearer has become greater than the separated buffer threshold: Continue sending any remaining ULPDUs belonging to the PDU set or data burst already transmitted on the main path; when the first PDU of the PDU set or data burst arrives, determine whether to use the main path or the secondary path for all PDUs of that PDU set or data burst; use the determined path for all subsequent PDUs of the PDU set or data burst; - when it is determined that the UL buffer used for this bearer has become less than the separation buffer threshold: Continue transmitting any remaining UL PDUs belonging to the PDU set or data burst that has already been transmitted on a path associated with that PDU set or data burst. When the first PDU of the PDU set or data burst arrives (after the UL buffer used for that bearer has become less than the separation buffer threshold), the main path is used for all PDUs of that PDU set or data burst. In one embodiment, the separation buffer threshold takes into account the characteristics of the PDU / PDU set.

[0033] In such an embodiment, the WTRU is configured with a separate bearer and an associated separate buffer threshold to determine when to start using the secondary path, wherein the separate buffer threshold only considers certain conditions (e.g., type, importance, PSDB, etc.). Further details of this embodiment are described below.

[0034] In one implementation, the WTRU configured with a decoupled bearer performs the following operations: - It is configured with a separation buffer threshold, wherein the separation buffer threshold relates to a PDU or set of PDUs with specific characteristics, for example, A specific PSDB's PDUs or PDU set, a specific type of PDUs or PDU set, a PDUs or PDU set with a specific importance level, etc. - The total buffer size to be compared with the separation buffer threshold is determined to be the sum of the UL data to be processed that matches the configured characteristics.

[0035] - If the determined total buffer size is greater than the configured separate buffer threshold, the WTRU can also use secondary paths to send bearer packets.

[0036] In one implementation, the WTRU is configured to associate a set of PDUs or a burst of data in a separate bearer with a primary or secondary path based on characteristics of the PDU, PDU set, and / or PDU data burst (e.g., type, importance, PSDB, and / or size).

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

[0038] In one implementation, the WTRU is configured with a separate bearer and an associated separate buffer threshold to determine when to start using the secondary path, wherein the separate buffer threshold only considers PDUs that meet certain conditions (e.g., type, importance, PSDB, and / or size).

[0039] In one implementation, the WTRU is configured to determine a path for the first PDU based on a separate bearer configuration, and to transmit the first PDU via the determined path.

[0040] In one implementation, the WTRU is configured to receive information indicating a split bearer configuration associated with multiple paths; determine at least one characteristic associated with a Protocol Data Unit (PDU), the determined at least one characteristic being one or more of the following: PDU type, PDU set type, PDU set delay budget (PSDB), remaining expiration time of the PSDB, PDU set size, PDU importance, and PDU set importance; after receiving the information indicating the split bearer configuration and determining at least one characteristic, select a path for the PDU from the multiple paths; and transmit the PDU on the selected path.

[0041] In one implementation, the WTRU is configured to compare a buffer fill level with a buffer threshold; and in response to a fill level greater than the buffer threshold, determine a characteristic of a data packet; in response to the determined characteristic, select a path corresponding to the characteristic from a plurality of paths; and send the data packet through the selected path.

[0042] In one embodiment, the WTRU is configured to determine a buffer size as a mathematical combination of characteristics of the PDU to be processed; compare the buffer size with a separation buffer threshold associated with the characteristics; and, in response to a relationship between the buffer size and the separation buffer threshold, transmit the PDU via at least one path corresponding to the relationship.

[0043] In one implementation, the WTRU is configured to determine the characteristics of a data packet; compare a fill level of a buffer used for the data packet with the determined characteristics to a buffer threshold associated with the determined characteristics; in response to the comparison, select a path from a plurality of paths; and send the data packet through the selected path.

[0044] In one implementation, the WTRU is configured to receive information indicating a split bearer configuration associated with multiple paths; determine characteristics associated with a Protocol Data Unit (PDU); select a path for the PDU from the multiple paths in response to the split bearer configuration and the determined characteristics; and transmit the PDU on the selected path.

[0045] In one implementation, the WTRU is configured to receive indication characteristics, buffer thresholds, and / or configurations of multiple paths; determine characteristics of the data packet from information within the data packet, the determined characteristics being one or more of the following: data packet type, Protocol Data Unit Set Delay Budget (PSDB), size, and importance; compare the fill level of a buffer with the determined characteristics used for the data packet with a buffer threshold associated with the determined characteristics; in response to a fill level less than or equal to the buffer threshold, select a primary path from a plurality of paths including a primary path and secondary paths, each configured for data propagation; in response to a fill level greater than the buffer threshold, select the secondary path from the plurality of paths; and transmit the data packet through the selected path.

[0046] Below are some examples of split-bearer techniques for extended reality (XR) that include split-bearer operations, where the split-bearer comprises two paths. However, it should be understood that these examples, as well as other embodiments herein, can be generalized to split-bearers having more than two paths.

[0047] These examples share a common theme: split bearers are bearers (such as radio bearers) that are divided (e.g., separated) into two or more data transmission and / or data reception paths. Typically, split bearers are not the same as dual connectivity (DC), although they may share some similarities. For example, a DC is a simultaneous connection (e.g., from a WTRU) to two (or more) nodes, while a split bearer can be two (or more) simultaneous (or non-simultaneous) paths between a WTRU and the same node; for example, split bearers can implement carrier aggregation (CA) such that one path of the split bearer (e.g., a “split” or “split bearer path”) uses one set of available subcarriers, and another path of the split bearer (e.g., another “split” or “split bearer path”) uses another set of available subcarriers. Furthermore, DC is often used to improve data throughput, while split bearers are often used to improve data redundancy, e.g., increasing the likelihood that transmitted / received data will not be lost.

[0048] In a first example of a split bearer having two (e.g., primary and secondary) paths, the WTRU is configured to associate data bursts of data packets (e.g., PDUs), data packet sets (e.g., PDU sets), and / or data bursts with the primary or secondary path of the split bearer based on one or more characteristics of the data packets (e.g., PDUs), data packet sets (e.g., PDU sets), and / or data bursts (e.g., type, importance, PDU set delay budget (PSDB), and / or size). In some existing systems, the WTRU determines which split bearer path to transmit and / or receive data through based solely on whether the buffer fill level exceeds a buffer fill level threshold. However, in this example, the WTRU ignores the buffer fill level threshold and determines which split bearer path to transmit and / or receive data through based solely on one or more characteristics of the data packets (e.g., PDUs), data packet sets (e.g., PDU sets), and / or data bursts (e.g., PDU sets) (e.g., type, importance, PSDB, and / or size). In addition, the WTRU can determine which separate bearer path to transmit and / or receive data through based on one or more characteristics of one or more separate bearer paths (e.g., latency, and / or throughput).

[0049] In the second example, where the split bearer has two (e.g., primary and secondary) paths, the WTRU is configured with a split bearer and an associated split buffer threshold. In response to a buffer fill level below or equal to the split buffer threshold, the WTRU is configured to transmit / receive data via one (e.g., primary or secondary) split bearer path. In response to a buffer fill level exceeding the split buffer threshold, the WTRU is configured to determine which path (primary or secondary path) to transmit data packet (e.g., PDU), data packet set (e.g., PDU set), and / or data packet set (e.g., PDU set) data burst via 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. In other words, some existing WTRUs determine which separate bearer path to use solely based on whether the buffer fill level exceeds the separate buffer threshold; however, in this example, the WTRU is configured to operate in a normal manner until the buffer fill level exceeds the separate buffer threshold, and thereafter transmit / receive data through multiple separate bearer paths, determining which separate bearer path to transmit / receive a particular data packet, data packet set, and / or data packet set burst through 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 separate buffer threshold, the WTRU is configured to revert to normal operation.

[0050] In a third example where the split bearer has two (e.g., primary and secondary) paths, the WTRU is configured with a split bearer and associated split buffer thresholds, and its determination of when to begin using the secondary path is based on a buffer fill level. However, the buffer fill level is "counted" only for data packets (e.g., PDUs), sets of data packets (e.g., PDU sets), and / or bursts of data packets (e.g., PDU set bursts) that meet one or more specific conditions and / or have one or more characteristics (e.g., type, importance, PDU set delay budget (PSDB), and / or size). Furthermore, the WTRU can be configured to have multiple split buffer thresholds, each for its respective condition and / or characteristic. In contrast, a regular WTRU can be configured to determine which split bearer path it uses based solely on whether the buffer fill level exceeds a single buffer fill level threshold, independent of the conditions and / or characteristics of the data carried by the data packets. As described 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. The higher the importance level, the lower the buffer level threshold, in order to increase the chance of transmitting / receiving data packets of a specific importance level (especially high importance level) through the same separate bearer path. Attached Figure Description

[0051] The invention can be understood in more detail from the following description given by way of example in conjunction with the accompanying drawings, wherein like reference numerals denote like elements, and wherein: Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments; Figure 1B It is shown that, according to the embodiment, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown; Figure 1C It is shown that, according to the embodiment, it is possible to Figure 1A System diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown; Figure 1D It is shown that, according to the embodiment, it is possible to Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the communication system shown; Figure 2It is a timing diagram of multiple data bursts according to one embodiment, each data burst having multiple PDU sets of different types.

[0052] Figure 3 This is a protocol view of the separate bearer according to an embodiment.

[0053] Figures 4(a)–4(f) are diagrams of various forwarding configurations according to embodiments, which include a combination of DRB and / or LCH during UL transmission, and the WTRU maps data units received from one or more QoS streams to the forwarding configuration.

[0054] Figures 5(a)–5(f) are schematic diagrams illustrating how the WTRU selects and / or uses the forwarding configuration at the AS layer according to the embodiment to map XR data units during UL transmission using (a) configuration 1, (b) configuration 2, (c) configuration 3, (d) configuration 4, (e) configuration 5 and / or (f) configuration 6.

[0055] Figure 6 This is a flowchart of the process that the WTRU can execute according to the embodiment.

[0056] Figure 7 This is a flowchart of a process that can be performed by a WTRU according to another embodiment.

[0057] Figure 8 This is a flowchart of a process that can be performed by a WTRU according to yet another embodiment.

[0058] Figure 9 This is a flowchart 900 of a process that can be executed by a WTRU according to yet another embodiment.

[0059] Figure 10 This is a flowchart of a process that can be performed by a WTRU according to another embodiment.

[0060] Figure 11 This is a flowchart of a process that can be performed by a WTRU according to another embodiment. Detailed Implementation

[0061] For the purposes of this disclosure, the following abbreviations may be used:

[0062]

[0063]

[0064] Figure 1AThis diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0065] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Any of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 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 User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or MiFi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the wireless transmission / reception units 102a, 102b, 102c, and 102d may be interchangeably referred to as UEs.

[0066] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly connect to at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, the Internet 110, and / or other networks 112. As examples, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs (gNBs), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0068] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

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

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

[0071] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0072] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0073] In other embodiments, base station 114a and wireless transmission / reception units 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA 2000, CDMA 2000 1X, CDMA 2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0074] Figure 1A Base station 114b can be, for example, a wireless router, a home NodeB, a home eNodeB, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA 2000, GSM, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106.

[0075] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions (such as user authentication). Although in Figure 1AAlthough not shown, it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0076] CN 106 can also serve as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

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

[0078] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It is understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

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

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

[0081] Although the transmitting / receiving element 122 is in Figure 1B While described as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may use MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0082] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via various RATs, such as NR and IEEE 802.11.

[0083] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Additionally, the processor 118 may access information from any suitable type of memory and store data in said memory, such as non-removable memory 130 and / or removable memory 132. 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. Removable memory 132 may include a user identification module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory that is not physically located on WTRU 102 and store data in said memory (e.g., located on a server or home computer (not shown)).

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

[0085] 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) about the current location of the WTRU 102. In addition to, or alternatively to, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on the timing of signals received from two or more neighboring base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the embodiments.

[0086] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. These sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0087] WTRU 102 may include a full-duplex radio for which transmission and reception of some or all of the signals (e.g., signals associated with a specific subframe for 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 through hardware (e.g., chokes) or through signal processing by a processor (e.g., a separate processor (not shown) or processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., signals associated with a specific subframe for UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0088] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 may employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0089] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

[0090] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160C can communicate with each other via the X2 interface.

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

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

[0093] The SGW 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during handover between eNode Bs, triggering paging when DL data is available to WTRUs 102a, 102B, and 102c, managing and storing the context of WTRUs 102a, 102B, and 102c, etc.

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

[0095] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or can communicate with an IP gateway that serves as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0096] Although WTRU is Figure 1A-1D While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may use a wired communication interface with a communication network (e.g., temporary or permanent).

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

[0098] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or interfaces to a distributed system (DS) or another type of wired / wireless network carrying traffic entering and / or leaving the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. This peer-to-peer traffic can be sent between the source and destination STAs (e.g., directly between the source and destination STAs) using a direct link setup (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). WLANs using Standalone BSS (IBSS) mode cannot have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0099] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0100] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0101] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segmented parser that divides the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0102] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities including support for certain and / or limited bandwidths (e.g., only support). MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0103] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to STAs (which only support the 1 MHz operating mode) transmitting to the AP, then the entire available band can be considered busy even if most of the available band remains idle.

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

[0105] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR wireless technology. RAN 104 can also communicate with CN 106.

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

[0107] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with Scalable Digital Numerology (SDN). For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or Transmission Time Intervals (TTIs) of varying lengths or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying lengths of absolute time).

[0108] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without needing to access other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, and also with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate essentially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can serve as mobility anchors for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0109] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network fragmentation support, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, and routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0110] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include data networks (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0111] AMF 182a and 182b can connect to one or more of gNB 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being used by WTRU 102a, 102b, and 102c. For example, different network slices can 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, and services for MTC access. AMF 162 can provide control plane functions for handover between 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)).

[0112] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure them to route traffic through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0113] UPF 184a and 184b can connect to one or more of gNB 180a, 180b, and 180c in RAN 104 via the N3 interface. The N3 interface can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

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

[0115] Given Figure 1A-1D and Figure 1A-1D As described herein, one or more of the functions described with respect to one or more of the following can be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

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

[0117] One or more simulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices can be used in test scenarios within a test laboratory and / or an undeployed (e.g., tested) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices can be test equipment. Simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0118] Figure 2 This is a timing diagram of examples of multiple data bursts (data burst 1 and data burst 2) according to an embodiment, each data burst having multiple PDU sets 202, 204, and 206, and 208 and 210 of different types. Each PDU set represents a component of a group of pictures (GOP), including start and end times, and includes a corresponding number of PDUs. For example, PDU set 202 represents a portion of an I-frame and includes seven PDUs, PDU set 204 represents another portion of an I-frame and includes eight PDUs, ..., PDU set 210 represents a portion of a B-frame and includes six PDUs.

[0119] In dual connectivity (DC), the WTRU is served by two nodes, each consisting of a set of cells called the primary cell group (MCG) and the secondary cell group (SCG). Radio bearers can be associated with only the MCG or only the SCG, or radio bearers can be configured as separate bearers.

[0120] Figure 3 This is a protocol view of the separate bearer system 300 according to an embodiment.

[0121] The separate bearer system 300 includes WTRU 302, node 304 (gNB 1) and node 306 (gNB2) that are coupled to each other.

[0122] WTRU 302 includes, is configured with or implements a Packet Data Convergence Protocol (PDCP) 310, a first Radio Link Control (RLC) 312, a first Media Access Control (MAC) 314, and a first Physical Layer (PHY) 316, which may be internally coupled to each other (e.g., as shown in the image). Figure 3 (as shown in the coupling lines), 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 internally coupled to each other and can be internally coupled to PDCP 310, a first RLC 312, a first MAC 314, and a first PHY 316 (e.g., as shown in the coupling lines in the diagram), 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 internally coupled to each other and can be internally coupled to PDCP 310, a first RLC 312, a first MAC 314, and a first PHY 316 (e.g., as shown in the diagram). Figure 3 (The coupling lines are shown in the diagram).

[0123] gNB 1 node 304 includes, is configured with or implements Packet Data Convergence Protocol (PDCP) 330, Radio Link Control (RLC) 332, Media Access Control (MAC) 334 and Physical Layer (PHY) 336, which may be internally coupled to each other and / or mutually coupled to corresponding components of WTRU 300 (e.g., such as...). Figure 3 The coupling line between WTRU and gNB 1 node 304 is shown.

[0124] The gNB2 node 306 includes, is configured with or implements Radio Link Control (RLC) 340, Media Access Control (MAC) 342, and Physical Layer (PHY) 344, which may be internally coupled to each other and / or mutually coupled to corresponding components of the WTRU 300 and / or to corresponding components of the gNB1 node 304 (e.g., as...). Figure 3 The coupling lines between gNB2 and WTRU and between gNB2 and gNB1 are shown.

[0125] For a split bearer (like any other bearer), WTRU 302 has an associated PDCP 310 entity, and the network-side peer PDCP 330 entity terminates at either gNB 304 or 306 (e.g., primary or secondary gNB, where whether the gNB is the primary or secondary node is typically assigned during the configuration of System 300 as a split bearer system). In DL, the CN (core network) sends data to the gNB 330 terminated by PDCP 310 ( Figure 3 The network decides whether to send data directly to WTRU 302 via the link between gNB (gNB 304) and WTRU, or to forward PDCPPDU to node 306 (gNB2) (e.g. via the Xn interface), and gNB2 node 306 sends data to WTRU via the link between gNB2 and WTRU (e.g., interconnection).

[0126] In UL, WTRU 302 is configured with one path (e.g., one of the links between WTRU and node 304 and / or node 306) as the primary path, and the other path (e.g., the other of the links between WTRU and node 304 and / or node 306) as the secondary path. The network can configure the primary path for a specific bearer as MN or SN. The threshold is referred to as... UL data separation threshold (in the PDCP configuration carried) UL-DataSplitThreshold (Information Element IE). If the UL buffer size of the bearer is less than the threshold, the PDCP will only push data to the RLC associated with the main path (i.e., when UL authorization is available on that path, the data of the bearer will only be sent via the air interface resources of the node associated with the main path (e.g., node 304 or node 306)). However, if the buffer size becomes greater than the threshold, the WTRU can push data to either path (i.e., determine which data to push to the path determined by the WTRU implementation (e.g., configuration)).

[0127] Set the separation threshold to infinity Essentially, this disables detached bearer operations (i.e., only the main path is used). On the other hand, it sets the detach threshold to... zero The concept of primary and secondary paths is disabled because WTRUs are typically always able to send the bearer's UL data via one of the two paths (e.g., the secondary path).

[0128] As described above, the current split bearer operation in dual connectivity (DC) is controlled by a split buffer threshold, which allows WTRU 302 to send UL data for split bearer via a primary path (e.g., a path to one of nodes 304 and 306) or a secondary path (e.g., a path to the other of nodes 304 and 306). The primary intention behind this is to distribute the load between the two paths that the bearer can use (i.e., if the primary path is sufficient for the bearer, the buffer level will remain low).

[0129] In the case of an active XR application on the WTRU 302, this behavior can lead to undesirable actions because the current PDCP path routing operates on a per-packet basis. For example, if the WTRU 302 reaches a separation threshold while transmitting a PDU set or data burst, the WTRU may send some PDUs from the PDU set or data burst via the primary path while sending others via the secondary path. This can result in problems such as jitter (e.g., packets within the PDU set or data burst experiencing significantly different delays), multiple out-of-order deliveries within the PDU set or data burst, and exceeding the PDU set delay budget (PSDB).

[0130] In all embodiments described herein, the network may include, for example, any of the following: base stations (e.g., gNBs, such as gNB1 304 or gNB2 306), TRPs, RAN nodes, access nodes, core network functions (e.g., AMF), and application functions (e.g., edge server functions, remote server functions).

[0131] In the various embodiments described herein, the terminology PDU and Grouping They can be used interchangeably.

[0132] In the various embodiments disclosed herein, flow This can correspond to any of the following: QoS flow or data flow (e.g., a data flow consisting of one or more PDUs or ADUs that may be associated with one or more QoS requirements (e.g., latency, data rate, reliability)). Different flows that may originate from a common application / experience source and / or are intended to go to a common destination device / WTRU or associated device / WTRU group can be referred to as associated flows or related flows.

[0133] In the various embodiments disclosed herein, Forwarding configuration This can 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 various layers within the AS protocol stack (e.g., SDP, PDCP, RLC, MAC, PHY, other new protocol layers), parameters associated with logical channel priorities (LCPs) (e.g., priority, PBR, BSD), BWPs, carriers, radio links / interfaces (Uu links, SLs), and radio resources (e.g., a collection of one or more frequency / time / space resources, such as time slots, subcarriers, or beams. Radio resources can also be associated with configured licenses, dynamic licenses, and / or any other licensed or unlicensed resources).

[0134] In the various embodiments described herein, Mapping configuration This can correspond to any of the following: parameters and / or configurations associated with the following mappings: ○ Mapping from one or more application data (e.g., PDU sets) streams, QoS streams (e.g., associated or unassociated) to criteria One or more radio bearers, SDAP, PDCP, LCH, carrier or component carrier (e.g., CC in CA configuration), BWP, and radio link / interface (e.g., Uu link or side link) that can be used to transmit PDUs in, for example, the UL direction or DL ​​direction.

[0135] In the various embodiments described herein, XR / Application-Aware Data Transmission / Reception or XR / Application-Aware QoS ProcessingIt can correspond to any of the following: ○ PDU Set Processing: A PDU set (e.g., a media unit, video frame) may include one or more PDUs. A PDU set may be associated with QoS requirements (e.g., data rate, latency, reliability) at the PDU set level, which may apply to one or more or all PDUs associated with the PDU set. Different PDUs in a PDU set may be associated with QoS requirements at their respective PDU levels. Such associations and interdependencies may be visible to the AS layer (e.g., with associated IDs), and / or processed at the AS layer if the associations are known during data transmission and reception. ○ Application / Higher-Level Importance / Priority: Different PDUs or all PDUs in a PDU set can be associated with different application / higher-level importance / priority values. Such importance values ​​can correspond to spatial importance (e.g., the spatial location of video frames carrying data in a PDU / PDU set, where a PDU / PDU set carrying a FoV spatial location can be associated with higher spatial importance compared to a non-FoV spatial location) or temporal importance (e.g., the temporal sequence of video frames carrying data in a PDU / PDU set, where a PDU / PDU set carrying a basic video frame such as an I-frame can be associated with higher temporal importance compared to differential video frames such as P-frames / B-frames). During data transmission and reception, this importance value is visible to the AS layer (e.g., with associated ID / tag / indicator) and can be enabled by application awareness. ○ QoS Flow Processing: The application's PDU / PDU set can be encoded and passed by the application to the WTRU (in the UL) or network (in the DL) via one or more QoS / data flows. At this point, different QoS flows carrying the PDU / PDU set associated with the XR application / experience are visible to the AS layer (e.g., with associated IDs) and / or processed at the AS layer if the association is known during data transmission and reception. In various embodiments of this document, the phrase "WTRU is in the process of transmitting / receiving packets belonging to a specific PDU set or data burst" refers to a situation where a specific PDU in the PDU set or data burst has been transmitted / received or is being transmitted / received, while other PDUs are still pending transmission in the WTRU / gNB buffer. The term "in progress PDU set or data burst" is also used to refer to PDUs in progress within a PDU set or data burst (i.e., for the UL case, PDUs that have not yet been successfully transmitted by the WTRU, and for the DL case, PDUs that have not yet been successfully received by the WTRU). The above phrases and terms can also be applied to situations where certain packets associated with any of the PDU sets, data bursts, and / or QoS flows are pending transmission at the application / higher layer and / or have not yet arrived at the lower-layer buffer at the WTRU / gNB for UL / DL transmission. The WTRU / gNB can identify such packets pending transmission at the application / higher layer based, for example, application / NAS layer indications and / or markers in previously received packet headers. The above phrases and terms can also be applied to non-XR services, which can consist of one or more independent PDUs in any QoS stream, without any association with PDU sets, media / video frames and / or data bursts.

[0136] WTRU can receive configuration information to support any of the processes, mechanisms, rules, actions, etc., related to the decoupled bearer processing discussed in this paper.

[0137] When the WTRU is in connected mode, or when the WTRU resumes connection from a suspended state, establishes connection from an idle state, or re-establishes connection after a failure, the WTRU can receive configuration information to support any procedures, mechanisms, rules, actions, etc. discussed below.

[0138] The configuration can be part of a separate bearer configuration or provided separately from a given bearer information element (e.g., a common configuration that can be applied to multiple bearers provided in addition to a single bearer configuration).

[0139] WTRU can receive configuration information from any of the following, for example: - Broadcast signaling (e.g., SIB) -Dedicated signaling ○RRC signaling and / or messages (e.g., RRC reconfiguration, HO commands, RRC release, RRC recovery) - Bearer-level signaling / configuration when a bearer is 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., PDU session establishment response or PDU session modification command) - Application layer signaling / messages.

[0140] WTRU can obtain information about the size of PDU sets / data bursts (e.g., the size of frames and / or PDU sets and / or PDU group sizes) and other information (e.g., PDU set type, importance, etc.) through several methods, including: -WTRU can receive an indication of the PDU set size from the application / higher layer. In one example, this indication could come from the packet header of the first packet / PDU in the PDU set.

[0141] - The WTRU can receive indications from the application that it can use to infer the size of the PDU set. In one example, the WTRU can receive indications about the first and last packets in the PDU set, for example, these indications can be found in the headers of the first and last packets.

[0142] - The WTRU can receive size information at a finer granular level. In one example, the WTRU can receive from the application an indication of the typical size of different frames (e.g., I-frames, P-frames, B-frames). The first / last packet in the PDU set may contain information indicating its type (e.g., corresponding to an I-frame or P-frame) and indicating that it is the first / last packet in the PDU set. Based on this information, the WTRU can be able to estimate the size of the PDU set.

[0143] In encoding schemes where different types of frames are encoded into different traffic streams (e.g., based on GOP encoding schemes, where a single video frame is an I-frame or a P-frame), the WTRU can receive an instruction to link the data stream to the frame type only once at the start of the session.

[0144] In one example, the indication from the application to WTRU can be a bit type, where "0" can correspond to a data stream with I-frames and "1" can correspond to a data stream with P-frames. - The WTRU can receive information about the PDU set size at the PDU set granularity and / or at the stream granularity (e.g., in a GOP-based coding scheme). This exchange can occur at the start of an XR session. The WTRU can receive regular updates periodically or only throughout the XR session when there are changes in the information (e.g., changes in the PDU set size).

[0145] -WTRU can receive information about multiple PDU sets (i.e., a set of PDU sets at a granular level) from the application layer / higher layers. Applications can group PDU sets based on similarity between them (e.g., same size, type, importance / priority, etc.).

[0146] The importance of data can be indicated to WTRU in the application at different data unit granularities, i.e., importance on a per-frame and / or per-PDU and / or per-PDU set basis, etc.

[0147] The importance indicator can be given for each data unit, or it can be given for the first data unit and no indicator is given for subsequent data units until / unless the importance changes.

[0148] The importance indicator can be simplified to, for example, a bitwise binary indicator or flag, which indicates whether the data is important enough to require special handling. Importance can be indicated by mapping different QoS levels in a traditional QoS framework to tables with different importance levels. In one example, the four most important QoS levels from the QoS framework can be marked as important, allowing the WTRU to determine that any data mapped to a radio bearer carrying the corresponding QoS flow from the four most important QoS levels may need to be transmitted before switching to another cell / gNB. Any data mapped to a radio bearer with QoS flows from the remaining QoS levels can wait until the HO (Hosting Request) is complete before being transmitted. - In some cases (e.g., if data in the buffer is about to expire), the importance indicator can take precedence over the QoS level from the traditional QoS framework.

[0149] The configuration information that WTRU can receive from the network may include one or more of the following, or a combination or sub-combination: -Mapping / forwarding / resource configuration and / or parameters For example, the WTRU can receive one or more sets of configuration and / or configuration parameters to be applied to different layers of the protocol stack (e.g., SDAP, PDCP, RLC, MAC, PHY, or any new layer). Configuration parameters may include: ■SDAP: 1-to-1, 1-to-M, or N-to-M mapping configuration; tags / indicators / IDs to be applied (e.g., associated with QoS flows, PDU sets, data bursts); association information such as indications of the association between PDUs, PDU sets, and / or data bursts; and / or the range of values ​​associated with the importance / priority of PDUs, PDU sets, and / or data bursts. ■PDCP: ● Rules / guidelines for mapping PDUs, PDU sets, and / or data bursts to two or more RLC entities / LCHs / branches ● Rules / standards for assigning sequence numbers (e.g., COUNT range, HFN range, and / or SN range) to PDUs, PDU sets, and / or data bursts. ● ROHC configuration applied to branches associated with the source and / or target ● Security / encryption parameters applied to branches associated with the source and / or target. ●Instructions / flags regarding whether to apply any grouped replication ● Rules / guidelines for discarding PDU sets and / or data bursts (e.g., discarding timers) ● Rules / guidelines for ensuring the orderly delivery of PDUs, PDU sets, and / or data bursts ■RLC: Modes (AM / UM / TM) and parameters applied to branches associated with the source and / or target. ■MAC: Rules / standards applied to LCH / MAC entities in branches associated with the source and / or destination include: ●LCH parameters (e.g., priority, PBR, BSD), ●LCP (e.g., rules / constraints for handling PDU sets and / or data bursts, durations that vary between different LCP rules), ● Configuration for multiplexing PDU sets / data bursts to TB ■PHY: HARQ configuration (e.g., allowed retransmission count ReTx) For example, the WTRU can receive one or more resource configurations to be used before, during, and / or after the HO (House of Ownership) process, including... ■ Configured authorization resources / configurations for UL data transmission. For example, parameters associated with CG resources / configurations may include any of the following: period, start offset, duration, BWP, parameter configuration / SCS value, number of PRBs, number of timings, number of PUSCH slots per timing, maximum number / duration / length of PUSCHs, one or more MSC values ​​for authorization, antenna ports, etc. ■ Semi-persistent scheduling (SPS) resources / configuration for DL ​​data reception. Parameters associated with SPS resources / configuration may include, for example, periodicity, start offset, duration, BWP, digital / SCS value, number of PRBs, number of timings, number of PDSCH slots per timing, maximum number / duration / length of PDSCHs, one or more MCS values ​​for the antenna port, etc. ■ Dynamic licensing resources for UL data transmission ■ Dynamic scheduling resources for DL ​​data reception The WTRU can receive at least one set of configuration parameters associated with a default configuration, which, for example, can be activated and / or used during normal scenarios of data transmission / reception during a HO (House of Origin) period. The WTRU can also receive another set of configuration parameters that can be associated with exceptional operations, such as being activated and / or used when any of the triggering events / conditions are detected during a HO period. - Validity information For example, the WTRU can receive validity information associated with forwarding / resource configuration, which indicates whether / when the configuration is considered valid or invalid based on one or more triggering events / conditions. ○WTRU can also receive information about whether the configuration should be deactivated and / or released when it is determined that the configuration is invalid. -Threshold: ○ Buffer occupancy threshold: ■ For example, a buffer occupancy threshold associated with any forwarding configuration can indicate the maximum / minimum amount of data units included in a buffer (e.g., SDP buffer, PDCP buffer, LCH buffer), which takes one or more granularities / types, including PDUs, PDU sets, and / or data bursts (e.g., in terms of total payload size / capacity). ○PDU set payload size threshold ■ For example, a payload size threshold may be associated with one or more upper and / or lower limits that correspond to the total payload size (e.g., in bits or bytes) of one or more PDUs, PDU sets, and / or data bursts. ■ In another example, the payload size threshold can be associated with one or more upper and / or lower limits, which correspond to the total number of PDUs in the PDU set and / or the total number of PDU sets in the data burst. ○ Delay threshold ■ The delay threshold may be associated with one or more upper and / or lower limits, which correspond to the maximum / minimum delay values ​​associated with the reception, buffering, and / or transmission of any data unit or group of data units (data units such as PDUs, PDU sets, data bursts). ■ This latency threshold can be used to identify and / or determine the maximum / minimum latency allowed by the network, application, and / or WTRU, such as latency caused by HO, processing, jitter, transmission, congestion, etc.

[0150] The following describes an embodiment relating to the mapping of PDU sets and bearers, logical channels, etc.

[0151] A PDU set may include one or more PDUs.

[0152] A PDU set may include PDUs corresponding to only one type of video frame (e.g., I-frame) or PDUs corresponding to different types of video frames (I-frame, P-frame, B-frame, etc.). The size of a PDU set can be variable from one PDU set to another.

[0153] PSDB (PDU Set Delay Budget) is the time from receiving the first PDU (e.g., data packet and / or PDU data packet) of the PDU set at the WTRU (e.g., from the application layer) until receiving the last PDU (e.g., data packet and / or PDU data packet) of the PDU set at the network (e.g., base station or UPF) and / or at the application server (e.g., after the WTRU transmission).

[0154] The TTL (Time to Live) or remaining delay / PSDB of a PDU set is considered equal to PSDB minus the total time elapsed since the first PDU (e.g., data packet and / or PDU data packet) of the PDU set arrived at the WTRU's transport buffer.

[0155] In some cases, PDUs within a given PDU set may have different characteristics (e.g., type, importance), and it may be desirable to determine the path of PDUs for the PDU set based on combinations of these characteristics (e.g., type, importance, etc.). To achieve this, the WTRU may need to be able to determine or estimate the characteristics of different PDUs within the PDU set at the beginning of the first PDU (e.g., based on information from the application layer, and / or based on information from the headers of the first or first few PDUs at the beginning of the first PDU set, information in the headers, and / or information from the headers).

[0156] Data bursts may sometimes contain sets of PDUs with different characteristics (e.g., different types, sizes, importance levels, PSDBs), and it may be desirable to determine the path for the data burst based on a combination of the characteristics of the PDU sets. To achieve this, WTRU can determine or estimate the characteristics of different PDU sets within the data burst at the beginning of the first PDU set within the data burst (e.g., based on information from the application layer, and / or based on information in the headers of the first or first few PDUs at the beginning of the first PDU set, information in the headers, and / or information from the headers).

[0157] During UL transmission, WTRU execution maps data units (e.g., PDUs, PDU sets, and / or PDU data bursts) received from the upper layer / application in one or more QoS streams (e.g., QFIs) to certain forwarding configurations that include combinations of different DRBs and / or LCHs.

[0158] Figures 4(a)–4(f) illustrate, according to embodiments, different WTRU transmission paths for PDUs and / or PDU sets in different non-separate bearer scenarios. Typically, Figures 4(a)–4(f) show various ways in which XR services can be mapped to non-separate radio bearers (e.g., addressing aspects, such as whether a single bearer (e.g., PDCP) can be used to transmit multiple PDU sets or whether multiple bearers are needed to transmit different PDU sets). Therefore, in the embodiments described in conjunction with Figures 4(a)–4(f), there is still one path for packets, rather than two or more paths (e.g., as can be seen in a single MAC and PHY, with…). Figure 3 Comparing two MAC and PHY paths on different routes.

[0159] Referring to Figures 4(a)-4(f), according to an embodiment, WTRU 402 selects and / or uses one or more forwarding configurations at the AS layer to map XR data units during UL transmission using configuration 1 of Figure 4(a), configuration 2 of Figure 4(b), configuration 3 of Figure 4(c), configuration 4 of Figure 4(d), configuration 5 of Figure 4(e), and / or configuration 6 of Figure 4(f).

[0160] In the example associated with configuration 1 shown in Figure 4(a), WTRU 402 can receive one or more PDUs associated with PDU set 1 and PDU set 2 in a QoS flow identified by QoS flow identifier 1 (QFI1) and QoS flow identifier 2 (QFI2), respectively. PDU set 1 includes PDUs P1, P2, ..., Pm, and PDU set 2 includes PDUs P1, P2, ..., Pn, where... m It can be equal to or not equal to n The received PDU sets 1 and 2 can be mapped at the SDP sublayer / entity to Data Radio Bearer 1 (DRB1) (e.g., PDCP1) and DRB2 (e.g., PDCP2) (DRB1 and DRB2 are part of the corresponding separate bearer paths). Each PDCP entity (e.g., PDCP1 and PCDP2) can be configured to support the ordered delivery of PDUs P1–Pm in PDU set 1 and PDUP1–Pn in PDU set 2, respectively. The PDUs of PDU sets 1 and 2 can be mapped to LCH1 and LCH2 (LCH1 and LCH2 are part of the corresponding separate bearer paths), possibly corresponding to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets into one or more TBs for UL transmission, the MAC entity / sublayer may ensure that QoS parameters (e.g., PSDB) specified for PDU sets 1 and 2 in the corresponding LCHs are met based on PDU set parameters (e.g., priority) and / or using LCP procedures.

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

[0162] In the example associated with configuration 3 shown in Figure 4(c), 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. PDUs of PDU set 1 and PDU set 2 may be mapped to LCH1 and LCH2, which may correspond to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets into one or more TBs for UL transmission, the MAC entity / sublayer may ensure that QoS parameters (e.g., PSDB) specified for the PDU sets in each LCH are met based on PDU set parameters (e.g., priority) and / or using the LCP procedure.

[0163] In the example associated with configuration 4 shown in Figure 4(d), WTRU 402 can 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 can be mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. The PDUs of PDU sets 1 and 2 can be mapped to LCH1, which may correspond to RLC1. For example, during the scheduling and / or multiplexing of PDU sets 1 and 2 into one or more TBs for UL transmission, the MAC entity / sublayer may ensure that the QoS parameters (e.g., PSDB) specified for the PDU sets in LCH1 are satisfied based on PDU set parameters (e.g., priority) and / or using the LCP procedure.

[0164] In the example associated with configuration 5 shown in Figure 4(e), WTRU 402 can receive one or more PDUs P1–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 can be mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. The PDUs of PDU sets 1 and 2 can be mapped to LCH1 and LCH2, which may correspond to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets into one or more TBs for UL transmission, the MAC entity / sublayer may, based on PDU set parameters (e.g., priority) and / or using the LCP procedure, ensure that the QoS parameters (e.g., PSDB) specified for the PDU sets in the corresponding LCH are satisfied.

[0165] In the example associated with configuration 6 shown in Figure 4(f), WTRU 402 can 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 can 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) can be configured to support the ordered delivery of PDUs in PDU set 1 and PDU set 2, respectively. The PDUs of PDU set 1 and PDU set 2 can be mapped to LCH1 and LCH2, possibly corresponding to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets into one or more TBs for UL transmission, the MAC entity / sublayer may ensure that QoS parameters (e.g., PSDB) specified for PDU sets 1 and 2 in the corresponding LCH are met based on PDU set parameters (e.g., priority) and / or using the LCP procedure.

[0166] The following describes an embodiment related to the mapping of PDU sets, bearers, logical channels, etc., with reference to Figure 5.

[0167] Figures 5(a)–5(f) illustrate different WTRU transmission paths for PDUs and / or PDU sets in different non-split bearer scenarios according to embodiments. Generally, similar to Figures 4(a)–4(f), Figures 5(a)–5(f) show the corresponding ways in which XR services can be mapped to non-split radio bearers (e.g., whether addressing such as a single bearer (e.g., PDCP) can be used to transmit multiple PDU sets or whether multiple bearers are needed to transmit different PDU sets). Therefore, in the embodiments described in conjunction with Figures 4(a)–4(f), there is still one path for packets, rather than two or more paths (e.g., as shown in a single MAC and PHY, with…). Figure 3 Comparing two MAC and PHY paths on different routes.

[0168] Referring to Figure 5, the WTRU 502 performs a mapping during UL transmission of data units (e.g., PDUs, PDU sets, and / or data bursts) received from the upper layer / application in one or more QoS streams (e.g., QFIs) to a specific forwarding configuration that includes combinations of different DRBs and / or LCHs.

[0169] Figures 5(a)–5(f) are diagrams illustrating how a WTRU 502, according to one embodiment, selects and / or uses configured forwarding configurations at the AS layer to map XR data units during uplink transmission using configuration 1 of Figure 5(a), configuration 2 of Figure 5(b), configuration 3 of Figure 5(c), configuration 4 of Figure 5(d), configuration 5 of Figure 5(e), and / or configuration 6 of Figure 5(f).

[0170] In the example related to configuration 1 shown in Figure 5(a), WTRU 502 can 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 be equal to or may not be equal to the corresponding Pn. m It can be equal to or not equal to nThe received PDU sets 1 and 2 can 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) can be configured to support the ordered delivery of PDUs in PDU sets 1 and 2, respectively. PDUs in PDU set 1 and PDUs in PDU set 2 can be mapped to LCH1 and LCH2, which may correspond to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets into one or more TBs for UL transmission, the MAC entity / sublayer may ensure that QoS parameters (e.g., PSDB) specified for the PDU sets in each LCH are met based on PDU set parameters (e.g., priority) and / or using the LCP procedure.

[0171] In the example related to configuration 2 shown in Figure 5(b), WTRU 502 can 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 be equal to the corresponding Pn, and m It can be equal to or not equal to n The received PDU sets 1 and 2 can be multiplexed / mapped to DRB1 (e.g., PDCP1) at the SDP sublayer / entity. The PDUs of PDU sets 1 and 2 can be mapped to LCH1, which may correspond to RLC1. For example, during scheduling and / or multiplexing PDU sets into one or more TBs for UL transmission, the MAC entity / sublayer may, based on PDU set parameters (e.g., priority, secondary node (SN)) and / or using the LCP procedure, ensure that the QoS parameters (e.g., PSDB) specified for PDU sets 1 and 2 in LCH1 are satisfied.

[0172] In the example related to configuration 3 shown in Figure 5(c), WTRU 502 can 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 be equal to the corresponding Pn. m It can be equal to or not equal to nReceived PDU sets 1 and 2 can be mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. PDUs from PDU sets 1 and 2 can be mapped to LCH1 and LCH2, which may correspond to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets into one or more TBs for UL transmission, the MAC entity / sublayer may ensure that QoS parameters (e.g., PSDB) specified for PDU sets 1 and 2 in the corresponding LCHs are met based on PDU set parameters (e.g., priority) and / or using the LCP procedure.

[0173] In the example related to configuration 4 shown in Figure 5(d), WTRU 502 can 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 be equal to or not equal to the corresponding Pn, and m It can be equal to or not equal to n The received PDU sets 1 and 2 can be mapped to DRB1 (e.g., PDCP1) at the SDP sublayer / entity. The PDUs of PDU sets 1 and 2 can be mapped to LCH1, which may correspond to RLC1. For example, during the scheduling and / or multiplexing of PDU sets into one or more TBs for UL transmission, the MAC entity / sublayer may ensure that the QoS parameters (e.g., PSDB) specified for PDU sets 1 and 2 are satisfied in LCH1 based on PDU set parameters (e.g., priority) and / or using the LCP procedure.

[0174] In the example related to configuration 5 shown in Figure 5(e), WTRU 502 can 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 be equal to or not equal to the corresponding Pn, and m It can be equal to or not equal to n The received PDU sets can be mapped to DRB1 (e.g., PDCP1) at the SDAP sublayer / entity. PDUs from PDU sets 1 and 2 can be mapped to LCH1 and LCH2, which may correspond to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets 1 and 2 into one or more TBs for UL transmission, the MAC entity / sublayer may enable the satisfaction of QoS parameters (e.g., PSDB) specified for PDU sets 1 and 2 in the respective LCHs, possibly based on PDU set parameters (e.g., priority) and / or using the LCP procedure.

[0175] In the example related to configuration 6 shown in Figure 5(f), WTRU 502 can 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 be equal to or not equal to the corresponding Pn, and m It can be equal to or not equal to n The received PDU sets 1 and 2 can 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) can be configured to support the ordered delivery of PDUs in PDU sets 1 and 2, respectively. PDUs in PDU set 1 and PDUs in PDU set 2 can be mapped to LCH1 and LCH2, which may correspond to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets into one or more TBs for UL transmission, the MAC entity / sublayer may ensure that QoS parameters (e.g., PSDB) specified for PDU sets 1 and 2 in the corresponding LCHs are met based on PDU set parameters (e.g., priority) and / or using the LCP procedure.

[0176] WTRU can be configured to have behavior that depends on the active bearer / application type. For example, WTRU can be configured to apply any of the above or below proposed embodiments / behaviors if an active VR application is present, otherwise apply the traditional behavior. As another example, WTRU can be configured to apply a new behavior / solution if any active XR service (e.g., AR, VR, MR) is present. In yet another example, WTRU can be configured to consider only PDU sets or data bursts belonging to a certain bearer(s) / LCH(s) or application type(s) (e.g., AR, VR, MR).

[0177] The embodiments described below primarily focus on enhancements related to XR applications / bearers. However, all embodiments are equally applicable to any kind of service / application in which there are interdependencies between PDUs, where PDUs of a given bearer can have different types / importances, where bursts of interrelated PDUs can arrive in burst or half-cycle manner, and so on. Thus, the disclosed behavior is described based on PDU sets, data bursts, frames, etc., and can be easily mapped to the behavior of this type of service / application / service.

[0178] In one implementation, the WTRU associates a PDU set or data burst with a specific path. For example, the WTRU is configured with a split bearer, wherein a PDU, PDU set, or PDU data burst is associated with a primary split bearer path and / or a secondary split bearer path based on the characteristics of the PDU, PDU set, or PDU database.

[0179] In one embodiment, the WTRU performs the following operations: - Receive configuration information about the split bearer, where the split bearer configuration includes the 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). - When a packet is received at a higher layer belonging to a separate bearer, a path for the data (e.g., PDU, PDU set, and / or PDU data burst) is determined based on the received configuration, and the data is sent via the determined separate bearer path.

[0180] In one implementation, the WTRU can be configured to determine the UL path at the PDU level. For example, the WTRU can be configured with split bearers (e.g., bearers having two or more data paths for transmitting and / or receiving data), wherein the UL path for the PDU is determined based on the PDU type. For example, the WTRU can be configured to always transmit type 1 PDUs via the primary split bearer path and type 2 PDUs via the secondary split bearer path, and so on.

[0181] In one embodiment, the WTRU can be configured with separate bearers, wherein the UL path for the PDU is determined based on the importance level of the PDU set. For example, the WTRU can be configured to always transmit importance level 1 PDUs via the primary separate bearer path and importance level 2 PDUs via the secondary separate bearer path, and so on.

[0182] In one embodiment, the WTRU can be configured to alternately use different split bearer paths for each PDU. For example, the WTRU can be configured to use the primary path of the split bearer for the first PDU, then the secondary path of the split bearer for the second PDU, then the primary path of the split bearer for the third PDU, and so on.

[0183] In one implementation, the WTRU can be configured to have an alternating pattern of using different paths for separate bearers for each PDU. For example, the WTRU can be configured to use the primary path of the separate bearer for the front end. n Each PDU, then the secondary path carrying the separate bearer will be used for the next... m One PDU, then use the main path for the next n PDUs, etc. (among others)n It can be different m ).

[0184] Combinations or sub-combinations of the above embodiments are also possible. For example, the WTRU can be configured to use the primary decoupled bearer path for PDUs if the PDUs with an importance level greater than a are type 1 PDUs.

[0185] In one implementation, the WTRU can be configured to determine the UL path at the PDU set level. For example, the WTRU can be configured with a split bearer, wherein the UL path for the PDU is determined based on the PDU set type. For example, the WTRU can be configured to always transmit PDUs belonging to a type 1 PDU set via the primary path of the split bearer, and PDUs belonging to a type 2 PDU set via the secondary path of the split bearer, and so on.

[0186] In one embodiment, the WTRU can be configured with a separate bearer, wherein the UL path for the PDU is determined based on the importance level of the PDU set. For example, the WTRU can be configured to always transmit PDUs belonging to the importance level 1 PDU set via the primary path of the separate bearer, and always transmit PDUs belonging to the importance level 2 PDU set via the secondary path of the separate bearer, and so on. In another example, the WTRU can be configured to transmit PDUs belonging to the PDU set with an importance lower than a certain level via the secondary path of the separate bearer, and transmit other PDU sets via the primary path of the separate bearer.

[0187] In one implementation, the WTRU can be configured with a split bearer, wherein the UL path for the PDU is determined based on the PDU set size. For example, the WTRU can be configured to always transmit PDUs belonging to a PDU set with a size greater than XK bytes via the primary path of the split bearer, and PDUs belonging to a PDU set with a size of XK bytes or less via the secondary path of the split bearer. For example, the WTRU can determine the size of the PDU set upon receiving the first PDU of the PDU set (e.g., information from the application layer and / or information from the packet header), and can determine the path of the split bearer for the first PDU of the PDU set based on the determined size and a configured size threshold, and can transmit the first PDU of the PDU set and all subsequent PDUs of the PDU set via the determined (i.e., the same) path.

[0188] In one implementation, the WTRU can be configured with a decoupled bearer, where the UL path of the PDU is determined based on the PDU set delay budget (PSDB). For example, the WTRU can be configured to always transmit data belonging to a PDU set with a delay less than [specified value] via the primary decoupled bearer path. nThe PDU set of the PSDB in milliseconds, and always transmitted via the secondary split bearer path, belongs to a set of PDUs with a value equal to or greater than 1000 milliseconds. n The PDU set of the PSDB in milliseconds, and vice versa.

[0189] In one embodiment, the WTRU can be configured to alternately use different paths for each PDU set. For example, the WTRU can be configured to use the primary path of the split bearer for a first PDU set, then use the secondary path of the split bearer for a second PDU set, then use the primary path of the split bearer for a third PDU set, and so on.

[0190] In one embodiment, the WTRU can be configured to have an alternating pattern of using different paths for separate bearers for each PDU set. For example, the WTRU can be configured to use the main path of the separate bearer for the front end. n A set of PDUs, then the secondary path of the separate bearer is used for the next step. m A set of PDUs, then the main path of the separate bearer is used for the next step. n A set of PDUs, etc. (among others) n It can be different m ).

[0191] In one embodiment, the WTRU can be configured to select a primary or secondary path for a separate bearer based on the PDUs in the WTRU implementation as a PDU set, as long as all PDUs in the WTRU as a PDU set maintain the same path.

[0192] Combinations or sub-combinations of the above embodiments are also possible. For example, the WTRU can be configured to use the primary path of the decoupled bearer for importance levels greater than […]. a PDU set, size smaller than b And PSDB is less than c PDU sets, etc.

[0193] In one embodiment, if the PDUs within a PDU set have different characteristics, the UL path determination for all PDUs in the PDU set may depend on the importance level of the PDUs within the PDU set (e.g., lowest importance level, highest importance level, intermediate importance level, mean importance level, and / or mode importance level). For example, the WTRU may be configured to select a primary path with a separate bearer for the PDUs in the PDU set if the average importance level of the PDUs in the PDU set is below a certain threshold, otherwise using a secondary path with a separate bearer. For example, if there are one or more PDUs in the PDU set with importance levels higher than a certain level, lower than a certain level, etc., the WTRU may be configured to select a primary path for the PDUs in the PDU set.

[0194] In one embodiment, the determination of the UL path for all PDUs in a PDU set depends on the type of PDUs in the PDU set. For example, if the PDU set includes one or more PDUs of a specific type, or if the PDU set does not contain PDUs of a specific type, the WTRU can be configured to select the primary path for the separate bearer of the PDUs in the PDU set, and so on.

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

[0196] In one embodiment, the UL path for all PDUs in a data burst is determined based on the total size of the data burst. For example, a WTRU can be configured to select the primary path of a split bearer if the total size of the data burst is below a certain threshold, and otherwise select the secondary path of a split bearer.

[0197] In one embodiment, the UL path determination for all PDUs in a data burst depends on the PSDB of the PDU set within that data burst (e.g., the lowest PSDB, highest PSDB, median PSDB, mean PSDB, mode PSDB, and / or the sum of PSDBs). For example, the WTRU can be configured to select a primary path for a separate bearer for the data burst if the average PSDB of the PDU set within the data burst is below a certain threshold, otherwise select a secondary path, and vice versa.

[0198] In one embodiment, the UL path determination for all PDUs in a data burst depends on the importance level of the PDU set within that data burst (e.g., minimum importance level, maximum importance level, intermediate importance level, mean importance level, and / or mode importance level). For example, the WTRU can be configured to select a separate bearer primary path for the data burst if the average importance level of the PDU set within the data burst is below or above a certain threshold. Alternatively, if there are one or more PDU sets in the data burst with importance levels above or below a certain threshold, the WTRU can be configured to select a primary path for all PDUs in the data burst.

[0199] In one embodiment, the determination of the UL path for all PDUs in a data burst depends on the type of PDU set in the data burst. For example, if the data burst includes one or more PDU sets of a specific type, or if the data burst does not contain any PDU sets of a specific type, the WTRU can be configured to select a separate bearer primary path for the data burst, and so on.

[0200] Combinations or sub-combinations of all the above embodiments are also possible.

[0201] The WTRU can be configured to maintain the same split bearer path for PDUs within a PDU set or data burst. For example, the WTRU is configured with split bearers and associated split buffer thresholds, where once the split buffer threshold has been exceeded, the WTRU determines a path (primary or secondary path) for the split bearer to deliver all UL packets of a particular PDU set or / and data burst.

[0202] In one embodiment, the WTRU performs the following operations: - When it is determined that the UL buffer used for the separated bearer has become greater than the separated buffer threshold: ○ Continue sending any remaining UL PDUs belonging to a PDU set or data burst that has already been transmitted via the main path of the split bearer. When the first PDU of a subsequent PDU set or data burst arrives, determine whether to use a separate bearer primary or secondary path for all PDUs in that PDU set or data burst. ○ Use the determined path (e.g., primary path or secondary path) for the first PDU and all subsequent PDUs in the PDU set or data burst. - When it is determined that the UL buffer used for that bearer (e.g., the determined path) has become smaller than the separation buffer threshold: Continue sending any remaining UL PDUs belonging to a PDU set or data burst that has already been transmitted via a path associated with that PDU set or data burst.

[0203] When the first PDU of a subsequent PDU set or data burst arrives, the main path of the split bearer will be used for all PDUs of that subsequent PDU set or data burst (and can be any additional PDU of a subsequent PDU set or data burst).

[0204] In one embodiment, the WTRU performs UL path determination at the PDU set level. Several examples are provided here, which primarily involve enabling the WTRU to determine whether it can switch the path used to send PDUs in an ongoing PDU set based on a separation buffer level threshold.

[0205] In one embodiment, the WTRU can be configured with a split bearer and a split buffer threshold, wherein if the WTRU determines a split buffer threshold for the bearer (e.g., the path of the split bearer currently used by the WTRU) when a UL PDU is received at the WTRU, the following is passed: - If the current PDU set is of a specific type (e.g., type 1), then the WTRU applies conventional processing to the remaining PDUs in the PDU set (i.e., based on the WTRU implementation, it can select either a primary decoupled bearer path or a secondary decoupled bearer path to schedule PDUs). - If the current PDU set is of another type (e.g., type 2), then the WTRU sends the remaining PDUs of the PDU set through the same path, i.e. ○ Continue sending the remaining PDUs in this PDU set using the main path. For any subsequent PDU set of this type, conventional processing is applied to the first PDU of the PDU set (i.e., based on the WTRU implementation, the WTRU can choose a primary or secondary path to schedule the PDU), and the same selected path is used for the remaining PDUs in the PDU set.

[0206] In one embodiment, the WTRU can be configured with a separate bearer and a separate buffer threshold, wherein if the WTRU determines that the buffer level is below the separate buffer threshold for that bearer when a UL PDU is received at the WTRU (after it has previously been above the threshold): - If the current PDU set is of a specific type (e.g., type 1), then WTRU applies conventional processing to the remaining PDUs in the PDU set (e.g., selecting a primary split bearer path to schedule PDUs). - If the current PDU set is of another type (e.g., type 2), then the WTRU sends the remaining PDUs of the PDU set through the same path, i.e. If the primary path is used to send PDUs from this PDU set, the WTRU continues to use the primary path to send the remaining PDUs from the PDU set. ○ If a secondary path is used to send PDUs from this PDU set, the WTRU retains the remaining PDUs for which the secondary path was used. ○ For any subsequent PDU set, WTRU uses the main path. In one embodiment, the WTRU can be configured with a separate bearer and a separate buffer threshold, wherein if the WTRU determines that a separate buffer threshold for the bearer (one of the bearer paths currently used by the WTRU) is passed when a UL PDU is received at the WTRU: - If the current PDU set has a specific importance (e.g., importance level 1), then the WTRU applies conventional processing to the remaining PDUs in the PDU set (i.e., the WTRU can select a primary or secondary path to schedule PDUs based on the WTRU implementation). - If the current PDU set has another importance level (e.g., importance level 2), then the WTRU sends the remaining PDUs of the PDU set through the same path, i.e. ○WTRU maintains the use of the primary path to send the remaining PDUs in the PDU set. For any subsequent PDU set of this type, the WTRU applies conventional processing to the first PDU in the set (i.e., the WTRU can select a primary or secondary path to schedule the PDU based on the WTRU implementation), and maintains the same path selection for the remaining PDUs in the set. In one embodiment, the WTRU can be configured with a separate bearer and a separate buffer threshold, wherein if the WTRU determines that the buffer level is below the separate buffer threshold for that bearer when a UL PDU is received at the WTRU (after it has previously been above the threshold): - If the current PDU set has a specific importance level (e.g., importance level 1), then WTRU applies conventional processing to the remaining PDUs in the PDU set (e.g., selecting a primary decoupled bearer path to schedule the PDUs). - If the current PDU set has another importance level (e.g., importance level 2), then the WTRU sends the remaining PDUs of the PDU set through the same path, i.e. If the primary decoupled bearer path is used to send PDUs from this PDU set, the WTRU will continue to use the primary path to send the remaining PDUs from the PDU set. If a secondary path is used to send PDUs from this PDU set, the WTRU retains the remaining PDUs from the PDU set that were sent using the secondary path. ○ For any subsequent PDU set, WTRU uses the main path. In one embodiment, the WTRU may be configured with a separate bearer and a separate buffer threshold, wherein if the WTRU determines, when a UL PDU is received at the WTRU, a separate buffer threshold for the bearer (the bearer is currently being used by the WTRU) is passed: -If the amount of data to be sent is within the PDU set to which the PDU belongs. Greater than If a specific quantity (e.g., greater than a specific number of K bytes, greater than a specific number of PDUs, and / or greater than a specific percentage of the PDU set size) is specified, the WTRU will apply conventional processing to the remaining PDUs in the PDU set (e.g., the WTRU can select a primary or secondary split bearer path to schedule PDUs based on the WTRU implementation). -If the amount of data to be sent is within the PDU set to which the PDU belongs. Less than If a specific amount (e.g., less than a specific number of K bytes, less than a specific number of PDUs, and / or less than a specific percentage of the PDU set size) is detected, the WTRU will send the remaining PDUs of the PDU set through the same path. ○ Continue using the primary split bearer path to send the remaining PDUs in the PDU set. For any subsequent PDU set of this type, the first PDU in the set is processed using conventional methods (i.e., based on a WTRU implementation, where the WTRU can choose a primary or secondary path to schedule the PDU), and the remaining PDUs in the set continue to use the same path selection. In one embodiment, the WTRU can be configured with a separate bearer and a separate buffer threshold, wherein if the WTRU determines that the buffer level is lower than the separate buffer threshold for the bearer (the bearer / path currently being used by the WTRU after the buffer level was already higher than the threshold before the buffer level): -If the amount of data to be sent is within the PDU set to which the PDU belongs. Greater than For specific quantities (e.g., greater than a specific number of K bytes, greater than a specific number of PDUs, and / or greater than a specific percentage of the PDU set size), WTRU applies conventional processing to the remaining PDUs in the PDU set (e.g., scheduling PDUs using the primary path of a split bearer). -If the amount of data to be sent is within the PDU set to which the PDU belongs. Less than If a specific amount (e.g., less than a specific number of K bytes, less than a specific number of PDUs, and / or less than a specific percentage of the PDU set size) is specified, the WTRU will send the remaining PDUs of the PDU set via the same path before the switchover. If the primary path is used to send PDUs from this PDU set, the WTRU continues to use the primary path to send the remaining PDUs from the PDU set. ○ If a secondary path is used to send PDUs from this PDU set, the WTRU retains the remaining PDUs for which the secondary path was used. ○ For any subsequent PDU set, WTRU uses the main path.

[0207] In one embodiment, the WTRU can be configured with a separate bearer and a separate buffer threshold, wherein if the WTRU determines a separate buffer threshold for the currently used bearer when a UL PDU is received at the WTRU, the following is passed: - If the PSDB of the PDU set to which the PDU belongs is greater than a certain value, the WTRU applies conventional processing to the remaining PDUs in the PDU set (i.e., the WTRU can select the primary or secondary path of the split bearer configuration to schedule PDUs based on the WTRU implementation method). - If the PSDB of the PDU set to which the PDU belongs is less than a specific value, then the WTRU sends the remaining PDUs in the PDU set through the same path, i.e., the WTRU... ○ Continue to use the main path to transmit the remaining PDUs in the PDU set. For any subsequent PDU set of this type, conventional processing is applied to the first PDU in the PDU set (i.e., the WTRU can select a primary or secondary path to schedule the PDU based on the WTRU implementation), and the same selected path is used for the remaining PDUs in the PDU set.

[0208] In one embodiment, the WTRU can be configured with a separate bearer and a separate buffer threshold, wherein if, when a UL PDU is received at the WTRU, the WTRU determines that the buffer level is lower than the separate buffer threshold for that (current) bearer (after it had previously been higher than the threshold): - If the PSDB of the PDU set to which the PDU belongs is greater than a certain value, then WTRU applies conventional processing to the remaining PDUs in the PDU set (i.e., using the primary path to schedule and / or transport PDUs). - If the PSDB of the PDU set to which the PDU belongs is less than a specific value, then the WTRU sends the remaining PDUs of the PDU set through the same path, that is, If the primary decoupled bearer path is used to send PDUs from this PDU set, the WTRU will continue to use the primary path to send the remaining PDUs from the PDU set. ○ If the secondary split bearer path is used to transmit PDUs of this PDU set, the WTRU retains the remaining PDUs for which the secondary path was used. ○ For any subsequent PDU set, WTRU uses the main path.

[0209] In one or more variations of the above embodiments, the direct possibility of switching the separate bearer path within the PDU set (e.g., from the primary path to the secondary path or from the secondary path to the primary path) can be configured for a PDU set with a PSDB having a value less than a specific value.

[0210] In one or more variations of the above embodiments, instead of PSDB, the remaining time-to-live (TTL) of the PDU set can be used as a determining factor. For example, WTRU makes a decision based on whether the TTL is less than or greater than a threshold, so that it can switch the separate bearer path during the transmission of the PDU set.

[0211] In one embodiment, if the PDUs within a PDU set have different characteristics, the UL path for all PDUs in the PDU set is determined based on the importance level of the PDUs within the PDU set (e.g., minimum importance level, maximum importance level, intermediate importance level, average importance level, and / or mode importance level). For example, if the average importance level of the PDUs in the PDU set is below a certain level, the WTRU can be configured to switch the UL path for the ongoing PDU set, but if the average importance level is greater than or equal to that certain level, the WTRU clears the remaining PDUs in the PDU set before the WTRU can switch the UL path. For example, the WTRU can be configured to switch the UL path for the ongoing PDU set if there are one or more PDUs in the PDU set with importance levels higher than a certain level, lower than a certain level, etc.

[0212] In one embodiment, the UL path for all PDUs in a PDU set is determined based on the type of PDUs in the PDU set. For example, the WTRU can be configured to switch the UL path for the ongoing PDU set if one or more PDUs of a specific type are present in the PDU set, or if a specific type of PDU is not present in the PDU set, etc.

[0213] In one embodiment, the WTRU performs UL path determination at the data burst level. For example, the embodiment described above for determining UL paths at the PDU set level can also be configured to determine UL paths at the data burst level.

[0214] In one embodiment, when a separation buffer threshold is exceeded, the UL path determination for a PDU within a separated bearer depends on the type of PDU set within the data burst. For example, the WTRU can be configured to switch the UL path for an ongoing data burst if one or more specific types of PDU sets to be transmitted are present in the data burst, if no specific type of PDU set is present in the data burst, and so on, when the separation buffer threshold is exceeded.

[0215] In one embodiment, when a separation buffer threshold is exceeded, the UL path for a PDU within a separated bearer is determined based on the importance level of the PDU set in the data burst (e.g., minimum importance level, maximum importance level, intermediate importance level, mean importance level, and / or mode importance level, etc.). For example, the WTRU can be configured to switch the UL path for an ongoing data burst when the separation buffer threshold is exceeded if the average importance level of the PDU set to be transmitted / in progress within the data burst is below a certain level, above a certain level, etc. For example, the WTRU can be configured to switch the UL path for an ongoing data burst when the separation buffer threshold is exceeded if one or more PDU sets to be transmitted with a specific importance level exist in the data burst, or if no PDU set with a specific importance level exists in the data burst, etc.

[0216] In an embodiment, when a separation buffer threshold is exceeded, the UL path determination for a PDU within a separated bearer depends on the remaining size of the data burst. For example, the WTRU can be configured to switch the UL path for an ongoing data burst if the size of the remaining / to-transmit data of the data burst (e.g., the sum of buffered data belonging to the data burst and the remaining expected data belonging to the data burst) is higher than a certain threshold.

[0217] In one embodiment, when a separation buffer threshold is exceeded, the UL path determination for a PDU within a data burst within the separation bearer depends on the PSDB or TTL of the set of PDUs in progress / to be transmitted within the data burst (e.g., lowest PSDB, highest PSDB, median PSDB, mean PSDB, mode PSDB, and / or the sum of PSDBs). For example, the WTRU can be configured to switch the UL path for an in progress data burst when the separation buffer threshold is exceeded if the PSDB or TTL of the remaining set of PDUs in the data burst is higher or lower than a certain threshold, etc.

[0218] Combinations or sub-combinations of all the above embodiments are also possible.

[0219] In an embodiment, the separation buffer threshold for separating the bearer may have two values, a high value (v1) and a low value (v2), where v1 is used to determine the possibility of switching from using only the primary path to using both the primary path and the secondary path, and v2 is used to determine the possibility of switching back from being able to use both the primary path and the secondary path to using only the primary path.

[0220] In this embodiment, instead of comparing the separation buffer threshold with the buffer level currently in use for separating bearer paths, the separation buffer threshold is compared with the total UL buffer level on the main path (i.e., the decision is made based on how much data needs to be sent through the main path regardless of which bearer the data belongs to).

[0221] In one embodiment, the separation buffer threshold takes into account the characteristics of the PDU / PDU set.

[0222] In one embodiment, the WTRU is configured with a separate bearer and an associated separate buffer threshold to determine when to start using the secondary path, wherein the buffer threshold only considers PDUs that meet specific conditions (e.g., type, importance, and / or PSDB).

[0223] In one embodiment, the WTRU is configured with a decoupled bearer to perform the following operations: -WTRU is configured with a separation buffer threshold, where the separation buffer threshold relates to a PDU or set of PDUs with certain characteristics, such as, ○ A specific PSDB's PDUs or PDU set, ○ Specific types of PDUs or PDU sets, ○ PDUs or sets of PDUs with specific importance levels, etc. -WTRU determines the total buffer size to be compared with the separation buffer threshold as the sum of the UL data to be transmitted that matches the characteristics of the configuration.

[0224] - If the determined total buffer size is greater than the configured separation buffer threshold, the WTRU can also use secondary paths to send bearer packets. A “bearer packet” can be considered as follows: A bearer is a logical “tunnel” used to send and / or receive data (or other) packets. For example, in a UL, data (or other) packets originate from an application (e.g., a web browser, a streaming application), and the WTRU maps the packets to bearers configured for those packets (e.g., based on QoS flow identifiers) or bearers configured for those packets.

[0225] This document provides several embodiments that, compared to the conventional approach of considering all data to be transmitted on the separate bearer on the main path, primarily involve configuring the WTRU in a way that uses different buffer sizes to be compared with the separation buffer threshold.

[0226] In one embodiment, the buffer size calculation takes into account the characteristics of the PDU or set of PDUs.

[0227] In one implementation, the WTRU is configured to consider only one or more specific types of PDUs or sets of PDUs in the UL buffer of a given separate bearer when calculating the buffer size to be compared with a bearer separate buffer threshold to determine whether only the primary path can be used or both the primary and secondary paths can be used. For example, if the WTRU has 10 PDUs of a given separate bearer to be transmitted in the transport buffer of the primary path, and five PDUs are type 1, three PDUs are type 2, and two PDUs are type 3, then the WTRU can consider the buffer size based on one or more PDU types that the WTRU is configured to consider in the buffer size calculation (assuming the PDUs have equal sizes). n ) 5n, 3n, 2n, (5n +3n), (5n +2n), (2n + 3n) or (5n + 2n + 3n) An alternative approach is to configure the WTRU with a PDU type that is not considered in the total buffer size calculation.

[0228] In one embodiment, the WTRU is configured to consider only PDUs or sets of PDUs with one or more importance levels in the UL buffer of a given separate bearer when calculating the buffer size to be compared with a separate buffer threshold of the bearer to determine whether to use only the primary path or both the primary and secondary paths. For example, if the WTRU has ten PDUs of a given separate bearer to be transmitted in the transport buffer of the primary path, and five PDUs have importance level 1, three PDUs have importance level 2, and two PDUs have importance level 3, then the WTRU can consider the buffer size based on the one or more importance levels that the WTRU is configured to consider in the buffer size calculation (assuming the PDUs have an equal size n). 5n, 3n, 2n, (5n +3n), (5n +2n), (2n +3n) or (5n + 2n + 3n) An alternative approach is to configure the WTRU with an importance level that is not considered in the total buffer size calculation.

[0229] In one embodiment, the WTRU is configured to consider only the PDU set of a specific PSDB (e.g., less than a specific threshold) in the UL buffer of a given separable bearer when calculating the buffer size to be compared with a bearer separable buffer threshold to determine whether to use only the primary path or both the primary and secondary paths. For example, if the WTRU has ten PDUs of a given separable bearer to be transmitted in the transport buffer of the primary path, and five PDUs belong to the PDU set of PSDB1, three PDUs belong to the PDU set of PSDB2, and two PDUs belong to the PDU set of PSDB3 (where PSDB1 < PSDB2 < PSDB3), if the WTRU is configured to consider only the PDU set where PSDB is less than x, where x is between PSDB2 and PSDB3, then it is assumed that the PDU size is equal to x. n(in n (This refers to the number of bits, bytes, words, or packets in a PDU). WTRU considers the buffer size as... 5n+3n .

[0230] In one embodiment, the WTRU is configured to consider only PDUs in a specific TTL (e.g., less than a specific threshold) set of PDUs in the UL buffer of the separate bearer when calculating the buffer size to be compared with a bearer's separation buffer threshold to determine whether to use only the primary path or both the primary and secondary paths. That is, if the TTL of the PDU set is below the configured threshold, the WTRU will begin adding PDUs in the buffer to the total buffer size calculation (e.g., PDUs that have been in the buffer for a longer time but belong to a PDU set with a larger PSDB cannot be added to the buffer size calculation, while PDUs that have only been in the buffer for a shorter time but belong to a PDU set with a shorter PSDB can be added to the buffer calculation).

[0231] Combinations or sub-combinations of all the above embodiments are also possible. For example, the WTRU can be configured to take into account a value greater than n Importance level, type x and y The PDU, which has a smaller value in the total buffer size calculation than t1 PSDB.

[0232] In one embodiment, different separation buffer thresholds can be used for different PDU or PDU set characteristics.

[0233] In one embodiment, the WTRU is configured to consider several separation buffer thresholds, where each separation buffer threshold is associated with a different characteristic of a PDU or set of PDUs. For example, this could be: - Threshold related to PDU type ○T1: Used for type 1 ○T2: Used for type 2 ○T3: Used for type 3, etc. - Threshold related to the importance level of PDU / PDU set ○L1: Used for Level 1 ○L2: Used for Level 2 ○L3: Used for level 3 - Thresholds related to PSDB ○P1: Used for PSDB < psdb_1 ○P1: Used for psdb_1 ≤ psdb_2 ○… ○Pn: Used for PSDB > psdb_n-1, etc. - Thresholds related to TTL ○TTL1: Used for TTL < TTL_1 ○TTL2: Used for TTL_1 ≤ TTL_2 ○… ○TTLn: Used for TTL > TTL_ n -1 etc.

[0234] In other words, WTRU keeps calculating the total buffer size for each category of PDUs and compares the number of PDUs in each category with the corresponding threshold.

[0235] 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 a correspondingly configured threshold to determine whether the WTRU continues to use only the primary path or is also able to use the secondary path to send a specific type of PDU.

[0236] In one embodiment, the WTRU can determine at the bearer level whether to use only the primary path or also the secondary path, but this determination is based on one or more of the conditions associated with each category as in the previous solutions. For example, the WTRU can be configured to begin using the secondary path of the separate bearer for any new PDU if the buffer level of a type 1 PDU is higher than T1 or the buffer level of an importance level 1 PDU is higher than L1, etc. (i.e., regardless of the characteristics of the PDU or PDU set). In another example, the WTRU can be configured to begin using the secondary path of the separate bearer for any new PDU if the buffer level of a type 1 PDU is higher than T1 and the buffer level of an importance level 1 PDU is higher than L1, etc. (i.e., regardless of the characteristics of the PDU or PDU set).

[0237] In one embodiment, the buffer size (e.g., buffer level) threshold according to any of the above embodiments is calculated based on the number of PDUs in progress rather than the total bytes (and a corresponding threshold also specified based on the number of PDUs).

[0238] In this embodiment, instead of calculating the buffer size threshold according to any of the above embodiments only for a single separate bearer, the threshold is calculated across all separate bearers having the same main path. For example, suppose there are four separate bearers, and bearers #1 and #2 have main paths set as MCG, while bearers #3 and #4 have main paths set as SCG.

[0239] Therefore, the WTRU maintains buffer sizes for different configuration classes of PDUs or sets of PDUs for both the MCG and SCG paths (since each path is the primary path for some bearers), where the total buffer size (level) for each class of PDUs is summed across bearers. For example, the total buffer value of 1 for importance level 1 PDUs on the MCG path would be the sum of the importance level 1 PDUs to be transmitted on separate bearers #1 and #2, and so on, and the corresponding threshold for importance level 1 PDUs is compared to this total value to determine whether the WTRU can still use the secondary path (i.e., in this case, SCG) to transmit importance level 1 PDUs, and so on. Similarly, the total buffer size on the SCG path is calculated for different classes of PDUs or sets of PDUs and compared with the corresponding separate buffer thresholds for those bearers using SCG as the primary path to determine whether the WTRU can still use the secondary path (i.e., in this case, MCG) to transmit PDUs of the relevant class, and so on.

[0240] In embodiments, the buffer size (e.g., buffer level) threshold according to any embodiment herein considers not only all separate bearers with the same primary path, but also non-separate bearers on that same path. For example, when calculating the total buffer size (level) on an MCG path based on PDU type, importance, PSDB, etc. for a certain category, WTRU not only sums up PDUs of the same category with separate bearers using MCG as the primary path, but also includes other PDUs using MCG bearers (i.e., bearers associated only with the MCG path) in the sum. Similarly, when calculating the total buffer size (level) on an SCG path based on PDU type, importance, PSDB, etc. for a certain category, WTRU not only sums up PDUs of the same category with separate bearers using SCG as the primary path, but also includes other PDUs using SCG bearers (i.e., bearers associated only with the SCG path) in the sum.

[0241] Figure 6 This is a flowchart 600 of a process that can be executed by a WTRU according to an embodiment.

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

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

[0244] Figure 7 This is a flowchart 700 of a process that can be performed by a WTRU according to another embodiment.

[0245] At 702, the WTRU (e.g., the WTRU's processor circuitry) determines that the UL buffer used for separating the bearer has a relationship with the separation buffer threshold.

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

[0247] At 706, in response to the WTRU (e.g., a transceiver) receiving a first other PDU, the WTRU (e.g., a processor circuit) determines the path (e.g., a split bearer path) through which the first other PDU is transmitted (e.g., using the transceiver).

[0248] At 708, the WTRU (e.g., a transceiver) transmits the first other PDU via the determined path.

[0249] Figure 8 This is a flowchart 800 of a process that can be executed by a WTRU according to yet another embodiment.

[0250] At 802, the WTRU (e.g., the processor circuitry of the WTRU) determines the buffer size as a mathematical combination (e.g., sum, difference, product, and / or quotient) of the PDUs to be transmitted that have characteristics (such as the same importance level).

[0251] At 804, the WTRU (e.g., processor circuitry) compares the buffer size (i.e., the size of the buffer contents, the buffer fill level) with a separate buffer threshold associated with the characteristic.

[0252] And at 806, in response to a relationship between the buffer size and the separation buffer threshold (e.g., greater than, less than, equal to), the WTRU (e.g., the transceiver of the WTRU) transmits the PDU via at least one path (e.g., a separation bearer path) corresponding to the relationship.

[0253] Figure 9 This is a flowchart 900 of a process that can be executed by a WTRU according to yet another embodiment.

[0254] At 902, the WTRU (e.g., the transceiver circuitry of the WTRU) receives information indicating a split bearer configuration associated with multiple paths (e.g., multiple data communication paths of the bearer that enable bearer splitting).

[0255] At 904, the WTRU (e.g., the processor circuitry of the WTRU) determines at least one characteristic associated with a Protocol Data Unit (PDU). For example, the determined at least one characteristic may be one or more of the following: PDU type, PDU set type, PDU set delay budget (PSDB), remaining expiration time of the PSDB, PDU set size, PDU importance, and PDU set importance.

[0256] At point 906, after receiving the information indicating the split bearer configuration and determining the at least one characteristic, the WTRU (e.g., the processor circuitry of the WTRU) selects a path for the PDU from the plurality of paths. For example, the WTRU selects a path for the PDU from the plurality of paths based on the split bearer configuration and the determined at least one characteristic; At 908, the WTRU (e.g., the transceiver circuitry of the WTRU) transmits the PDU via the selected path.

[0257] Figure 10 This is a flowchart 1000 of a process that can be performed by a WTRU according to another implementation.

[0258] At 1002, the WTRU (e.g., the transceiver circuitry of the WTRU) receives a configuration indicating a buffer threshold, at least one characteristic of a data packet, and one or more of a plurality of paths.

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

[0260] At 1006, in response to the padding level being greater than the buffer threshold, the WTRU (e.g., the processor circuitry of the WTRU) determines one or more of the at least one characteristic of the data packet. For example, the determined one or more characteristics of the at least one characteristic of the data packet may be one or more of the following: data packet type, Protocol Data Unit Set Delay Budget (PSDB), size, or importance.

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

[0262] At 1010, the WTRU (e.g., the WTRU transceiver) sends (e.g., transmits) the data packets via the selected path.

[0263] Figure 11This is a flowchart 1100 of a process that can be performed by a WTRU according to another implementation.

[0264] At 1102, the WTRU (e.g., the processor circuitry of the WTRU) receives a configuration indicating characteristics, buffer thresholds, and / or multiple paths.

[0265] At 1104, the WTRU (e.g., the processor circuitry of the WTRU) determines the characteristics of the data packet from the information within the data packet. For example, the determined characteristics may be one or more of the following: data packet type, Protocol Data Unit Set Delay Budget (PSDB), size, and importance.

[0266] At 1106, the WTRU (e.g., the processor circuitry of the WTRU) compares the fill level of the buffer used for data packets with the determined characteristics with the buffer threshold associated with the determined characteristics.

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

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

[0269] Furthermore, at 1112, the WTRU (e.g., the WTRU transceiver) transmits the data packets via the selected path.

[0270] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMs and digital multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method executed by a WTRU, the method comprising: Receive information indicating a separate bearer configuration, which is associated with multiple paths; Determine at least one characteristic associated with a Protocol Data Unit (PDU), wherein the determined at least one characteristic is one or more of the following: PDU type, PDU set type, PDU set delay budget (PSDB), remaining expiration time of said PSDB, size of PDU set, importance of PDU, and importance of PDU set. After receiving the information indicating the separate bearer configuration and determining the at least one characteristic, a path for the PDU is selected from the plurality of paths; as well as The PDU is transmitted via the selected path.

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

3. The method according to any one of claims 1-2, wherein the PDU belongs to a protocol data unit set (PDU set).

4. The method according to any one of claims 1-3, wherein the separate bearer configuration is configured as a radio bearer, and the plurality of paths includes paths configured for transmitting and receiving data associated with the radio bearer.

5. The method according to any one of claims 1-4, wherein the determination includes: The at least one characteristic is determined based on the information within the PDU.

6. The method according to any one of claims 1-5, wherein the plurality of paths includes a primary path and a secondary path.

7. The method according to any one of claims 1-6, wherein the selection includes: The path is selected from the plurality of paths based on at least one characteristic associated with the path.

8. The method of claim 7, wherein the at least one characteristic associated with the path includes the path's latency and / or the path's throughput.

9. The method according to any one of claims 1-8, wherein the selection includes: The path is selected based on at least one characteristic of another path among the plurality of paths.

10. The method according to any one of claims 1-9, wherein the separate bearer configuration indicates that the at least one feature is related to the protocol data unit and / or the plurality of paths.

11. The method according to any one of claims 1-10, further comprising receiving the PDU from the application layer.

12. A WTRU, comprising: A transceiver circuit is configured to receive information indicating a split bearer configuration associated with multiple paths; The processing circuit is configured as follows: Determine at least one characteristic associated with a Protocol Data Unit (PDU), wherein the determined at least one characteristic is one or more of the following: PDU type, PDU set type, PDU set delay budget (PSDB), remaining expiration time of said PSDB, size of the PDU set, importance of the PDU, and importance of the PDU set. After the transceiver circuit receives the information indicating the separate bearer configuration and the processor circuit determines the at least one characteristic, a path for the PDU is selected from the plurality of paths; as well as The transceiver circuit is configured to transmit the PDU via a selected path.

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

14. The WTRU according to any one of claims 12-13, wherein the PDU belongs to a protocol data unit set (PDU set).

15. The WTRU according to any one of claims 12-14, wherein the separate bearer configuration is configured as a radio bearer, and the plurality of paths includes a path configured for the radio bearer.

16. The WTRU according to any one of claims 12-15, wherein the processor circuitry 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 according to any one of claims 12-16, wherein the plurality of paths includes a primary path and a secondary path.

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

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

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

21. The WTRU according to any one of claims 12-20, wherein the separate bearer configuration indicates the at least one feature and / or the plurality of paths.

22. The WTRU according to any one of claims 12-21, wherein the processing circuitry is configured to receive the PDU from the application layer.

23. The WTRU according to any one of claims 12-21, wherein each of the plurality of paths is configured for data propagation.

Images