Synchronized transmission of multi-modal traffic

EP4740658A1Pending Publication Date: 2026-05-13APPLE INC
View PDF 0 Cites -1 Cited by

Patent Information

Authority / Receiving Office
EP · EP
Patent Type
Applications
Current Assignee / Owner
APPLE INC
Filing Date
2023-08-07
Publication Date
2026-05-13

Smart Images

  • Figure CN2023111522_13022025_PF_FP_ABST
    Figure CN2023111522_13022025_PF_FP_ABST
Patent Text Reader

Abstract

A user equipment (UE) configured to decode, from signaling received from a base station, an uplink (UL) grant comprising an indication of UL radio resources and a modality group, generate a data unit based on data from a plurality of traffic flows corresponding to the modality group, wherein the IP flows comprise one of Quality of Service (QoS) flows, logical channel (LCH) or data radio bearer (DRB) and configure transceiver circuitry to transmit the data unit using the UL radio resources.
Need to check novelty before this filing date? Find Prior Art

Description

Synchronized Transmission of Multi-Modal TrafficTechnical Field

[0001] This application relates generally to wireless communication systems, and in particular relates to synchronized transmission of multi-modal traffic.Background

[0002] Cellular networks may support multi-modal communication services for various use cases including support of extended reality (XR) services. For example, an XR application should be able to obtain inputs from more than one source and / or output to more than one destination to convey information more effectively.Summary

[0003] Some exemplary embodiments are related to an apparatus of a user equipment (UE) , the apparatus having processing circuitry configured to decode, from signaling received from a base station, an uplink (UL) grant comprising an indication of UL radio resources and a modality group, generate a data unit based on data from a plurality of traffic flows corresponding to the modality group, wherein the IP flows comprise one of Quality of Service (QoS) flows, logical channel (LCH) or data radio bearer (DRB) and configure transceiver circuitry to transmit the data unit using the UL radio resources.

[0004] Other exemplary embodiments are related to a processor configured to decode, from signaling received from a base station, an uplink (UL) grant comprising an indication of UL  radio resources and a modality group, generate a data unit based on data from a plurality of traffic flows corresponding to the modality group, wherein the IP flows comprise one of Quality of Service (QoS) flows, logical channel (LCH) or data radio bearer (DRB) and configure transceiver circuitry to transmit the data unit using the UL radio resources.

[0005] Still further exemplary embodiments are related to an apparatus of a base station, the apparatus having processing circuitry configured to configure transceiver circuitry to transmit an uplink (UL) grant comprising an indication of UL radio resources and a modality group to a user equipment (UE) , wherein the modality group comprises one or more traffic flows, wherein the traffic flows comprise one of Quality of Service (QoS) flows, logical channel (LCH) or data radio bearer (DRB) and decode, from signals received from the UE on the UL radio resources, a data unit generated using data from traffic flows included in the modality group.

[0006] Additional exemplary embodiments are related to a processor configured to configure transceiver circuitry to transmit an uplink (UL) grant comprising an indication of UL radio resources and a modality group to a user equipment (UE) , wherein the modality group comprises one or more traffic flows, wherein the traffic flows comprise one of Quality of Service (QoS) flows, logical channel (LCH) or data radio bearer (DRB) and decode, from signals received from the UE on the UL radio resources, a data unit generated using data from traffic flows included in the modality group.Brief Description of the Drawings

[0007] Fig. 1 shows an exemplary network arrangement according to various exemplary embodiments.

[0008] Fig. 2 shows an exemplary user equipment (UE) according to various exemplary embodiments.

[0009] Fig. 3 shows an exemplary base station according to various exemplary embodiments.

[0010] Fig. 4 shows an example of multi-modal traffic according to various exemplary embodiments.

[0011] Fig. 5 shows an example of logical channels (LCHs) for multiple modalities being multiplexed into the same Medium Access Control (MAC) Protocol Data Unit (PDU) according to various exemplary embodiments.

[0012] Fig. 6 shows a call flow for identifying a set of IP flows corresponding to modalities that should be delivered in a synchronized manner according to various exemplary embodiments.

[0013] Fig. 7 shows an exemplary call flow for modality group specific uplink scheduling according to various exemplary embodiments.

[0014] Fig. 8 shows an exemplary method for adj usting the configuration of a traffic flow according to various exemplary embodiments.

[0015] Fig. 9 shows an exemplary method for a UE to account for synchronization of multi-modal services when selecting LCHs  during a Logical Channel Prioritization (LCP) procedure according to various exemplary embodimentsDetailed Description

[0016] The exemplary embodiments may be further understood with reference to the following description and the related appended drawings, wherein like elements are provided with the same reference numerals. The exemplary embodiments relate to synchronized data flows for multi-modal services.

[0017] The exemplary embodiments are described with regard to a UE. However, reference to a UE is merely provided for illustrative purposes. The exemplary embodiments may be utilized with any electronic component that may establish a connection to a network and is configured with the hardware, software, and / or firmware to exchange information and data with the network. Therefore, the UE as described herein is used to represent any appropriate type of electronic component.

[0018] The exemplary embodiments are also described with regard to a 5G NR network that supports eXtended Reality (XR) . Those skilled in the art will understand that XR is an umbrella term for different types of realities and may generally refer to real-and-virtual combined environments and associated human-machine interactions generated by computer technology and wearables. To provide some examples, the term XR may encompass augmented reality (AR) , mixed reality (MR) and virtual reality (VR) . While the exemplary embodiments are described with reference to XR, it should be understood that the exemplary embodiments may be applied to any supplementary dynamic downlink  resource assignment mechanism that may be utilized during a UE power saving mode. That is, the exemplary embodiments are not limited to scenarios where the UE is engaged in XR operations.

[0019] XR services may utilize multiple data flows in the uplink and / or downlink. For example, in the downlink, there may be a video stream, an audio stream and / or a data stream. In the uplink, there may be a control stream and / or a pose stream. From a physical channel perspective, there may be different control channels and shared channels for each stream or multiple streams may share a control channel and / or shared channel. In some configurations, each stream may have different quality of service (QoS) requirements (e.g., packet error rate (PER) , packet delay budget (PDB) , etc. ) .

[0020] As described above, an XR application should be able to obtain inputs from more than one source and / or output to more than one destination to convey information more effectively. For applications such as immersive virtual reality (VR) , synchronization between different media components is critical for optimization of user experiences. A synchronization threshold can be defined between two media components. To support the synchronization requirement among multiple data flows from different sources, the network may provide service requirements, for each media that comprise the multi-modal service. This may include a Multi-modal Service ID and Quality of Service (QoS) monitoring requirement for multiple Internet Protocol (IP) data flows (e.g., traffic flows) associated to a multi-modal service. This information may be used to derive rules and apply QoS policies for data flows that are part of a  specific multi-modal application, and generate the authorized QoS monitoring policy for these service data flows.

[0021] Previous implementations to synchronize different media components included attempts to align multiple configured grant (CG) resources associated with different traffic flows. However, this scheme has limitations such as that it assumes that QoS flow has a dedicated CG configuration, which may not be true because the network may pre fer to use dynamic scheduling. Furthermore, changing the resource allocation by the UE may lead to complexity about how to ensure that the network also knows how the resources are re-allocated. Finally, when different traffic flows are transmitted on different resources, there may be no way to guarantee that the synchronization threshold can be satisfied.

[0022] In the exemplary embodiments, to ensure that two or more media components can be transmitted in a synchronized manner, the data from the corresponding logical channels (LCHs) for the two or more media components may be delivered in the same Physical Uplink Shared Channel (PUSCH) , e.g., multiplexed into the same Medium Access Control (MAC) Protocol Data Unit (PDU) , from the perspective of the air interface. This may eliminate transmission delays between multiple modalities. However, existing logical channel prioritization (LCP) mechanisms cannot guarantee that data from different traffic flows that should be synchronized are mapped to the same uplink grant, as these LCHs may have different priority levels and other LCP settings.

[0023] The exemplary embodiments introduce techniques that enhance uplink (UL) scheduling mechanisms to guarantee that data from multiple traffic flows that should be synchronized are transmitted together. These techniques include, but are not limited to, informing the UE and the RAN of the synchronization, grouping flows into modality groups, generating modality group specific uplink grants, generating MAC PDUs based on the modality groups, adaptively adj usting flows based on the modality groups and selecting data for inclusion in MAC PDUs based on the modality groups. The operations related to these techniques are described in greater detail below.

[0024] Fig. 1 shows an exemplary network arrangement 100 according to various exemplary embodiments. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will understand that the UE 110 may be any type of electronic component that is configured to communicate via a network, e.g., mobile phones, tablet computers, desktop computers, smartphones, phablets, embedded devices, wearables (e.g., head mounted display (HMD) , AR glasses, etc. ) , Internet of Things (IoT) devices, etc. It should also be understood that an actual network arrangement may include any number of UEs being used by any number of users. Thus, the example of a single UE 110 is merely provided for illustrative purposes.

[0025] The UE 110 may be configured to communicate with one or more networks. In the example of the network arrangement 100, the network with which the UE 110 may wirelessly communicate is a 5G NR radio access network (RAN) 120. However, the UE 110 may also communicate with other types of networks (e.g., 5G cloud RAN, a next generation RAN (NG-RAN) , a long term evolution (LTE)  RAN, a legacy cellular network, a wireless local area network (WLAN) , etc. ) and the UE 110 may also communicate with networks over a wired connection. With regard to the exemplary embodiments, the UE 110 may establish a connection with at least the 5G NR RAN 120. Therefore, the UE 110 may have a 5G NR chipset to communicate with the NR RAN 120.

[0026] The 5G NR RAN 120 may be a portion of a cellular network that may be deployed by a network carrier (e.g., Verizon, AT&T, T-Mobile, etc. ) . The 5G NR RAN 120 may include, for example, cells or base stations (Node Bs, eNodeBs, HeNBs, eNBS, gNBs, gNodeBs, macrocells, microcells, small cells, femtocells, etc. ) that are configured to send and receive traffic from UEs that are equipped with the appropriate cellular chip set.

[0027] In the network arrangement 100, the UE 110 may connect to the 5G NR-RAN 120 via the gNB 120A. Those skilled in the art will understand that any association procedure may be performed for the UE 110 to connect to the 5G NR-RAN 120. For example, as discussed above, the 5G NR-RAN 120 may be associated with a particular cellular provider where the UE 110 and / or the user thereof has a contract and credential information (e.g., stored on a S IM card) . Upon detecting the presence of the 5G NR-RAN 120, the UE 110 may transmit the corresponding credential information to associate with the 5G NR-RAN 120. More specifically, the UE 110 may associate with a specific base station (e.g., gNB 120A) . However, as mentioned above, reference to the 5G NR-RAN 120 is merely for illustrative purposes and any appropriate type of RAN may be used.

[0028] The network arrangement 100 also includes a cellular core network 130, the Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 may be considered to be the interconnected set of components that manages the operation and traffic of the cellular network. The cellular core network 130 also manages the traffic that flows between the cellular network and the Internet 140. The IMS 150 may be generally described as an architecture for delivering multimedia services to the UE 110 using the IP protocol. The IMS 150 may communicate with the cellular core network 130 and the Internet 140 to provide the multimedia services to the UE 110. The network services backbone 160 is in communication either directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 may be generally described as a set of components (e.g., servers, network storage arrangements, etc. ) that implement a suite of services that may be used to extend the functionalities of the UE 110 in communication with the various networks.

[0029] Fig. 2 shows an exemplary UE 110 according to various exemplary embodiments. The UE 110 will be described with regard to the network arrangement 100 of Fig. 1. The UE 110 may include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225 and other components 230. The other components 230 may include, for example, an audio input device, an audio output device, a power supply, a data acquisition device, ports to electrically connect the UE 110 to other electronic devices, etc.

[0030] The processor 205 may be configured to execute multiple engines of the UE 110. For example, the engines may include a multi-modal traffic engine 235. The multi-modal traffic engine 235 may perform a variety of operations for synchronizing uplink data for multi-modal services. The operations may include, but are not limited to, receiving uplink grants related to the multi-modal services and generating MAC PDUs for the multi-modal services to deliver data in a synchronized manner. These and other operations are described in greater detail below.

[0031] The above referenced engine being an application (e.g., a program) executed by the processor 205 is merely provided for illustrative purposes. The functionality associated with the multi-modal traffic engine 235 may also be represented as a separate incorporated component of the UE 110 or may be a modular component coupled to the UE 110, e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry to receive signals and processing circuitry to process the signals and other information. The engines may also be embodied as one application or separate applications. In addition, in some UEs, the functionality described for the processor 205 is split among two or more processors such as a baseband processor and an applications processor. The exemplary embodiments may be implemented in any of these or other configurations of a UE.

[0032] The memory arrangement 210 may be a hardware component configured to store data related to operations performed by the UE 110. The display device 215 may be a hardware component configured to show data to a user while the I / O device 220 may  be a hardware component that enables the user to enter inputs. The display device 215 and the I / O device 220 may be separate components or integrated together such as a touchscreen.

[0033] The transceiver 225 may be a hardware component configured to establish a connection with the 5G NR-RAN 120 and / or any other appropriate type of network. Accordingly, the transceiver 225 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . The transceiver 225 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals) . Such signals may be encoded with information implementing any one of the methods described herein. The processor 205 may be operably coupled to the transceiver 225 and configured to receive from and / or transmit signals to the transceiver 225. The processor 205 may be configured to encode and / or decode signals (e.g., signaling from a base station of a network) for implementing any one of the methods described herein.

[0034] Fig. 3 shows an exemplary base station 300 according to various exemplary embodiments. The base station 300 may represent any access node (e.g., gNB 120A, etc. ) through which the UE 110 may establish a connection and manage network operations.

[0035] The base station 300 may include a processor 305, a memory arrangement 310, an input / output (I / O) device 315, a transceiver 320, and other components 325. The other components 325 may include, for example, a battery, a data acquisition device, ports to electrically connect the base station 300 to other electronic devices, etc.

[0036] The processor 305 may be configured to execute a plurality of engines of the base station 300. For example, the engines may include a multi-modal traffic engine 330. The multi-modal traffic engine 330 may perform a variety of operations related to synchronizing data for multi-modal services. The operations may include, but are not limited to, grouping data flows into modality groups based on synchronization requirements and sending uplink grants identifying modality groups to a UE. These and other operations are described in greater detail below.

[0037] The above noted engine being an application (e.g., a program) executed by the processor 305 is only exemplary. The functionality associated with the multi-modal traffic engine 330 may also be represented as a separate incorporated component of the base station 300 or may be a modular component coupled to the base station 300, e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry to receive signals and processing circuitry to process the signals and other information. In addition, in some base stations, the functionality described for the processor 305 is split among a plurality of processors (e.g., a baseband processor, an applications processor, etc. ) . The exemplary embodiments may be implemented in any of these or other configurations of a base station.

[0038] The memory arrangement 310 may be a hardware component configured to store data related to operations performed by the base station 300. The I / O device 315 may be a hardware  component or ports that enable a user to interact with the base station 300.

[0039] The transceiver 320 may be a hardware component configured to exchange data with the UE 110 and any other UE in the network arrangement 100. The transceiver 320 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . Therefore, the transceiver 320 may include one or more components (e.g., radios) to enable the data exchange with the various networks and UEs. The transceiver 320 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals) . Such signals may be encoded with information implementing any one of the methods described herein. The processor 305 may be operably coupled to the transceiver 320 and configured to receive from and / or transmit signals to the transceiver 320. The processor 305 may be configured to encode and / or decode signals (e.g., signaling from a UE) for implementing any one of the methods described herein.

[0040] Fig. 4 shows an example of multi-modal traffic 400 according to various exemplary embodiments. In the example of Fig. 4, a user 405 has a UE 410 that collects various inputs such as input from the user and / or ambient inputs. Some examples of these inputs are described below. It should be understood that the UE 410 may represent more than one UE. For example, the user 405 may have a wearable (e.g., a watch, glasses, etc. ) tethered to a mobile device (e.g., mobile phone) . In other examples, the UE 410 may be receiving input from multiple Internet of Things (IoT) devices (e.g., smart appliances, etc. ) .

[0041] Fig. 4 shows some examples of the multi-modal inputs 430 that may be collected by the UE 410. These examples include voice biometrics, words and voice emotion that may be collected by, for example, a microphone of the UE 410. Other examples include face biometrics, face emotion and lip movement that may be collected by, for example, a camera of the UE 410. Further examples include emotion from a wearable (e.g., based on temperature of the user) , a gesture or relative location from a same or different camera of the UE 410, ambient information such as temperature, pressure, altitude, etc., from sensors of the UE 410 and haptic information from a haptic I / O of the UE 410.

[0042] In the example of Fig. 4, there are three services shown (e.g., XR applications) , biometric recognition 435, intention perception 440 and service presence 445. As described above, each of the services 435-445 may receive more than one of the multi-modal inputs 430. For example, the biometric recognition 435 service may receive the voice biometric and the voice emotion from the microphone of the UE 410 and the face emotion from the camera of the UE 410. As described above, these multi-modal inputs 430 should be synchronized when received by the biometric recognition 435 service. Exemplary manners of accomplishing this synchronization will be described below.

[0043] In the example of Fig. 4, the output of the biometric recognition 435 service is fed into the intention perception 440 service and the output of the intention perception 440 service is fed into the service presence 445, which may then output the multi-modal outputs 450. However, this is not a requirement as the output of each of the individual services 435-445 may also be multi-modal outputs 450.

[0044] Fig. 4 also shows some examples of the multi-modal outputs 450. These examples include audio, video, temperature, brightness and haptic outputs. As shown in Fig. 4, the multi-modal outputs 450 may be output to various controllable elements 415-425. The controllable elements 415-425 may be the UE 410 or may be other devices such as IoT devices.

[0045] Fig. 5 shows an example of logical channels (LCHs) for multiple modalities being multiplexed into the same Medium Access Control (MAC) Protocol Data Unit (PDU) 500 according to various exemplary embodiments. In the exemplary embodiments, to ensure that two or more media components can be transmitted in a synchronized manner, the data from the corresponding LCHs for the two or more media components may be delivered in the same PUSCH, e.g., multiplexed into the same MAC PDU 500 using a logical channel prioritization (LCP) procedure 500.

[0046] To provide an example with reference to Fig. 4, the biometric recognition 435 service may receive the voice biometric and the voice emotion from the microphone of the UE 410 and the face emotion from the camera of the UE 410. The data of each of these inputs may be transmitted by the UE 410 on different uplink data radio bearers (DRB) and hence different LCHs, e.g., the voice biometric is associated with Logical Channel #0, the voice emotion is associated with Logical Channel #1 and the face emotion is associated with Logical Channel #2. The biometric recognition 435 service may expect to receive these multi-modal inputs from the UE 410 in a synchronized manner. Thus, to ensure that this synchronization occurs, the  LCP procedure 510 is used to construct the MAC PDU 500 that includes the data from the appropriate LCHs.

[0047] As described above, in some instances the different LCHs (e.g., Logical Channel #0, Logical Channel #1 and Logical Channel #2) may have different priority levels and other LCP settings. The exemplary embodiments introduce techniques that enhance uplink (UL) scheduling mechanisms to guarantee that data from multiple traffic flows that should be synchronized are transmitted together, e.g., that the LCP procedure 500 constructs the MAC PDU 500 in a manner that data from different LCHs are appropriately synchronized.

[0048] Fig. 6 shows a call flow 600 for identifying a set of IP flows corresponding to modalities that should be delivered in a synchronized manner according to various exemplary embodiments. The call flow of Fig. 6 occurs between the UE 110 (which may also be the UE 410) , the gNB 120A that may be considered to represent the NR-RAN 120 and various functions of the core network 130 (e.g., 5GC) . In this case, the functions of the core network 130 include a user plane function (UPF) 610. A session management function (SMF) 620 and a policy control function (PCF) 630.

[0049] In general, the UPF 610 acts as an external PDU session point of interconnect to a DN and may perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection) , perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL / DL rate enforcement) , perform Uplink Traffic verification (e.g.,  SDF to QoS flow mapping) , transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering.

[0050] In general, the SMF 620 may perform operations related to session management such as, but not limited to, session establishment, session release, IP address allocation, policy and QoS enforcement, etc. In general, the PCF 630 may provide policy rules to control plane function (s) to enforce and may also support unified policy framework to govern network behavior.

[0051] In 640, a Multi-Modal Service ID that is common to multiple IP flows (e.g., traffic flows) is de fined in the PCF 630 and may be used for policy decisions such as admission control. The Multi-Modal Service ID identifies a set of IP flows corresponding to modalities that should be delivered in a synchronized manner.

[0052] In 645, the PCF 630 may send a multi-modal service I D message to the SMF 620 to provide the association between a Multi-Modal Service ID and the corresponding IP flows. In 650 and 655, the SMF 620 may send multi-modal service ID messages to provide the association between a Multi-Modal Service ID and the corresponding IP flows to the UPF 610 and the RAN (e.g., gNB 120A) , respectively.

[0053] Similarly, in 660, the association between a Multi-Modal Service ID and IP flows can be provided by the SMF 620 to the UE 110 in a multi-modal service ID message. Session  management (SM) signaling may also be used to notify the UE 110 when the relevant QoS flows are set up.

[0054] UE Route Selection Policy (URSP) rules may be defined to ensure the traffic flows that are to be synchronized are targeted at the same Data Network Name (DNN) or Single –Network Slice Selection Assistance Information (S-NSSAI) , e.g., traffic flows that are to be synchronized are grouped into the same network slice.

[0055] In some exemplary embodiments, the core network 130 may further define prioritization rules among different Multi-Modal Services. For instance, each Multi-Modal Service ID may be associated with a priority level. The information of priority level of each Multi-Modal Service can also be provided to the RAN (e.g., gNB 120A) and / or the UE 110. This priority level information may be used for radio resource allocation and / or prioritization.

[0056] Fig. 6 showed one example of how the UE 110 and the RAN (e.g., gNB 120A) may have obtained the association between a Multi-Modal Service ID and corresponding IP flows. The exemplary embodiments are not limited to the UE 110 and RAN obtaining this information in this manner, e.g., the UE 110 and the RAN may obtain this information in other manners. The following exemplary embodiments assume that the UE 110 and / or RAN have obtained the association between a Multi-Modal Service ID and corresponding IP flows but again are not limited to the UE 110 and / or RAN obtaining the information in the exemplary manner described in reference to Fig. 6.

[0057] Once the RAN (e.g., gNB 120A) and / or the UE 110 has obtained the information of the synchronization requirement and the associated traffic flows, the corresponding QoS flows or data radio bearers (DRBs)  / LCHs may be mapped to one or more groups. Throughout this disclosure, each of these groups will be described as a “Modality Group. ” However, other entities may refer to such groupings using different terminology. The modality groups may be used by the RAN for appropriate configuration such as resource allocation. The mapping may be determined based on the information of the synchronization requirement and the associated traffic flows.

[0058] In a first example, the modality groups may be based on a QoS-Flow based grouping. For example, the QoS flows corresponding to the IP flows that are to be synchronized are mapped to the same modality group. Each modality group may be associated with a Modality Group ID.

[0059] In some exemplary embodiments, a QoS flow may be associated with two or more modality groups. In addition, a QoS flow is not required to be associated with any modality group, e.g., for an IP flow that does not need to be synchronized with any other data flows. The QoS flows in one modality group are not necessarily mapped to the same DRB by the Service Data Adaptation Protocol (SDAP) . For example, the synchronized IP flows may not have the same QoS requirement and therefore may not be mapped to the same DRB. However, in one option all the QoS flows mapped to the same modality group may be mapped to the same DRB.

[0060] In a second example, the modality groups may be based on a DRB / LCH based grouping. The DRBs / LCHs corresponding to the IP flows that are to be synchronized are mapped to the same modality group. Each modality group may have at least one DRB / LCH. Each modality group is again associated with a Modality Group ID.

[0061] In some exemplary embodiments, a DRB / LCH may be associated with two or more modality groups. Similar to the QoS based grouping, a DRB / LCH is not required to be associated with any modality groups. Also, the LCHs / DRBs in one modality group are not necessarily in the same Logical Channel Group (LCG) defined for Buffer Status Report (BSR) reporting. However, in one option all the LCHs mapped to the same modality group may be mapped to the same LCG (e.g., the LCG mechanism is directly reused for mapping of modality groups) .

[0062] Once the modality groups have been defined, uplink grant may be issued to accommodate the buffered data from all QoS flows / DRBs / LCHs belonging to the same modality group to make sure the data from these QoS flows / DRBs / LCHs are multiplexed into the same MAC PDU and thereby delivered concurrently.

[0063] Fig. 7 shows an exemplary call flow 700 for modality group specific uplink scheduling according to various exemplary embodiments. The call flow 700 is performed between the RAN (e.g., gNB 120A) and the UE 110. As described above, modality groups may be defined based on QoS Flows, DRBs, or LCHs. Thus, throughout this description of the call flow 700, it may be considered that the example modality groups may have been defined using any of these methods. Thus, specific reference to  a QoS Flow, DRB, or LCH should also be understood to be a reference to any of the other manners by which modality groups may be defined (e.g., QoS Flow, DRB, or LCH) .

[0064] In 730, the gNB 120A configures the modality groups for the UE 110. Exemplary manners of configuring modality groups were described above. In this example as shown in Fig. 7, there may be two modality groups, Modality Group #0 710 comprised of LCH #0, LCH #1 and LCH #2 and Modality Group #1 720 comprised of LCH #3, LCH #4 and LCH #5.

[0065] In 735, the gNB 120A dynamically schedules the Modality Group #0 710 for UL transmission. There may be multiple manners for the gNB 120A to signal the scheduling of the Modality Group #0 710. In a first example, the gNB 120A may send an uplink grant with an explicit indication of the Modality Group ID (e.g., Modality Group #0 710) . In one example of providing an explicit indication, when the UL grant is a dynamic grant, a new field indicating the targeted Modality Group ID may be included in the Downlink Control Information (DCI) for dynamic scheduling. In another example of providing an explicit indication, when the UL grant is a configured grant, a new parameter indicating the targeted Modality Group ID may be included in the configured grant configuration information element (IE) (e.g., ConfiguredGrantConfig IE) .

[0066] In a second example, the gNB 120A may send an uplink grant with an implicit indication of the Modality Group ID (e.g., Modality Group #0 710) . For example, an existing field / parameter in the DCI or the configured grant configuration may be used to indicate the targeted Modality Group ID. For  example, a HARQ process ID may be used to implicitly indicate the Modality-Group ID.

[0067] In 740, the UE 110 received the UL grant for the Modality Group #0 710 and generates the MAC PDU based on applying an LCP procedure for the LCHs of the Modality Group #0 710, e.g., LCH #0, LCH #1 and LCH #2. The information relating to the modality group (e.g., the LCHs belonging to the indicated modality group) may be provided to the MAC layer by the upper layer, if needed. When generating the MAC PDU using the LCP procedure, the UE 110 may have multiple options for the data that is included in the MAC PDU.

[0068] In a first option, the UE 110 may only map the data from all the QoS Flows, DRBs, or LCHs in the indicated modality group (e.g., Modality Group #0 710) to the scheduled UL-SCH. The data from other LCHs are not allowed. In this option, any spare resources may be filled by padding.

[0069] In a second option, the UE 110 may prioritize the data from all the QoS Flows, DRBs, or LCHs in the indicated modality group to the scheduled UL-SCH. The data from other LCHs may be multiplexed only if there are spare resources.

[0070] When constructing the MAC PDU, the UE 110 may further take buffer delay information of the LCHs for either intra-modality group LCP procedure MAC PDU generation or inter-modality group LCP procedure MAC PDU generation. To provide an example related to intra-modality group, if it were considered that the UE 110 is generating a MAC PDU for the Modality Group #0 710 and the total amount of data in the buffers for LCH #0,  LCH #1 and LCH #2 exceeds the amount of data that may be included in the MAC PDU, the LCP procedure may take account of how long data has been in the buffer for each of the LCH #0, LCH #1 and LCH #2 when generating the MAC PDU, e.g., leaving out older data, leaving out newer data, etc. To provide an example of related to inter-modality group, if it were considered that the UE 110 is generating a MAC PDU for the Modality Group #0 710 and the total amount of data in the buffers for LCH #0, LCH #1 and LCH #2 is less than the total size of the MAC PDU, the UE 110 may take account of how long data has been in the buffer for each of the LCH #3, LCH #4 and LCH #5 when filling the spare resources of the MAC PDU.

[0071] Each LCH may have configured LCP settings, such as LCH priority or LCH mapping restrictions. However, when a special grant is received by the UE 110 (e.g., a grant that indicates a modality group) , the LCP settings for the LCHs in the modality group may not be applicable. For example, the UE 110 may ignore the LCP settings when processing the special grant, e.g., generating the MAC PDU using the LCP procedure.

[0072] In some instances, the UE 110 may have a conflict between a modality group specific uplink grant and a normal uplink grant, e.g., the UE 110 has received a modality group specific uplink grant (e.g., a grant that indicates a modality group) and a normal grant, and the radio resources of these grants at least partially overlap in time. In other instances, the UE may have a conflict between multiple modality group specific uplink grants, e.g., the UE 110 has received two or more modality group specific uplink grants whose radio resources at least partially overlap in time. When such conflicts occur,  the UE 110 may apply various rules to prioritize or select a grant for MAC PDU generation. In one example of an grant prioritization rule, the UE 110 may always prioritize the modality group specific uplink grant over the normal grant, regardless of the LCH priority, e.g., LCHs with a lower priority that are included in a modality group specific uplink grant may take precedence over an LCH with a higher priority that is scheduled using a normal uplink grant. When a conflict among multiple modality group specific uplink grants arises, the UE 110 may prioritize the grants based on the priority level associated with each Multi-Modal Service ID. The priority level associated with each Multi-Modal Service ID was described above.

[0073] In 745, the UE 110 performs a PUSCH transmission using the generated MAC PDU for the Modality Group #0 710.

[0074] To complete the call flow 700, in 750, the gNB 120A dynamically schedules the Modality Group #1 720 for UL transmission. In 755, the UE 110 received the UL grant for the Modality Group #1 720 and generates the MAC PDU based on applying an LCP procedure for the LCHs of the Modality Group #1 720, e.g., LCH #3, LCH #4 and LCH #5. In 760, the UE 110 performs a PUSCH transmission using the generated MAC PDU for the Modality Group #1 720.

[0075] Fig. 8 shows an exemplary method 800 for adj usting the configuration of a traffic flow according to various exemplary embodiments. The exemplary method 800 relates to the configuration, parameters or behavior (e.g., a setting) for transmission of a traffic flow being adaptively adj usted based on conditions relating to another traffic flow in the same  modality group. The exemplary method 800 is performed by the UE 110 and it may be considered that the UE 110 has been previously configured with the Modality Group #0 810 comprised of LCH #0, LCH #1 and LCH #2.

[0076] In 820, the UE 110 processes a UL data packet from the LCH #0 using the associated LCP procedure, e.g., in response to receiving a UL grant from the gNB 120A. It should be understood that using a data packet from LCH #0 is only an example and the method 800 may also be used for data packets being processed from LCH #1 or LCH #2.

[0077] In 830, the UE 110 determines whether any conditions relating to LCH #1 or LCH #2 are met, e.g., the other LCHs of the Modality Group #0 810. Examples of conditions relating to another LCH in the same modality group may include, for example, data buffered in another LCH in the same modality group becomes available, data buffered in another LCH in the same modality group has a remaining time lower than a threshold, data buffered in another LCH in the same modality group is discarded.

[0078] I f the UE 110 determines that none of the conditions relating to LCH #1 or LCH #2 are met, the method continues to 840 where the UE 110 processes the data packet for the LCH #0 using the default (or preconfigured) LCP procedure to construct the MAC PDU.

[0079] On the other hand, if the UE 110 determines that one or more of the conditions relating to LCH #1 or LCH #2 are met, the method continues to 850 where the UE 110 changes the LCP settings for the LCH #0 to process the data packet. Some  examples of changes in the LCP settings may include changing an LCH priority, a prioritized bit rate (PBR) , or an LCH mapping restriction for the LCH #0. In other examples, the changes may include activating duplication autonomously, discarding buffered packet (s) before a discard timer is expired, changing the discard timer value, etc.

[0080] In some example embodiments, a DRB may be associated to two radio link control (RLC) entities, and the UE 110 may switch the RLC leg based on the conditions relating to another DRB / LCH in the same modality group.

[0081] Fig. 9 shows an exemplary method 900 for a UE to account for synchronization of multi-modal services when selecting LCHs during an LCP procedure according to various exemplary embodiments. When the MAC is selecting LCHs for data multiplexing into an uplink grant via an LCP procedure, the MAC will select the LCHs based on whether a LCH is allowed to use this uplink grant (based on configured LCH mapping restrictions) , and whether the “Bj” value (e.g., a variable defined for each LCH and maintained by each LCH) is currently greater than 0. In the example of Fig. 9, the UE may take the synchronization of multi-modal services into account when selecting the LCHs during the LCP procedure. The exemplary method 900 is performed by the UE 110 and it may be considered that the UE 110 has been previously configured with the Modality Group #0 910 comprised of LCH #0, LCH #1 and LCH #2.

[0082] In 920, the UE 110 selects the LCH #0 to perform the LCP procedure of the UL grant. It should be understood that selecting the LCH #0 is only an example and the method 900 may  also be used when the UE 110 selects the LCH #1 or LCH #2 for the LCP procedure.

[0083] In 930, the UE 110 determines whether any conditions relating to LCH #1 or LCH #2 are met, e.g., the other LCHs of the Modality Group #0 910 because the UE 110 will understand that the LCH #0, LCH #1 and LCH #2 should be synchronized because they are in the same modality group. Examples of conditions relating to another LCH in the same modality group may include, for example, data buffered in another LCH in the same modality group becomes available, data buffered in another LCH in the same modality group has a remaining time lower than a threshold, data buffered in another LCH in the same modality group is discarded.

[0084] If the UE 110 determines that none of the conditions relating to LCH #1 or LCH #2 are met, the method continues to 940 where the UE 110 processes the LCH #0 using the default (or preconfigured) LCP procedure to construct the MAC PDU.

[0085] On the other hand, if the UE 110 determines that one or more of the conditions relating to LCH #1 or LCH #2 are met, the method continues to 950 where the UE 110 selects the LCH #1 or LCH #2 to perform the LCP procedure for the UL grant depending on which LCH met the condition. There may be various options for selecting the LCH for the LCP procedure. In a first option, the UE 110 will select the LCH #1 or LCH #2 even if by default the LCH may not be allowed to use this uplink grant. In a second option, the UE 110 may also allocate data from the LCH #1 or LCH #2 for the MAC PDU even if the Bj value maintained by LCH is not greater than 0. It should also be understood that the  above options may be used singularly or may be used together, e.g., the options are not mutually exclusive.

[0086] Examples

[0087] In a first example, a method is performed by a user equipment (UE) , comprising decoding, from signaling received from a base station, an uplink (UL) grant comprising an indication of UL radio resources and a modality group, generating a data unit based on data from a plurality of traffic flows corresponding to the modality group, wherein the IP flows comprise one of Quality of Service (QoS) flows, logical channel (LCH) or data radio bearer (DRB) and configuring transceiver circuitry to transmit the data unit using the UL radio resources.

[0088] In a second example, the method of the first example, wherein the UL grant comprises a dynamic grant, wherein the indication of the modality group comprises an explicit indication of the modality group in Downlink Control Information (DCI) related to the dynamic grant.

[0089] In a third example, the method of the first example, wherein the UL grant comprises a configured grant, wherein the indication of the modality group comprises an explicit indication of the modality group in a configuration information element (IE) related to the configured grant.

[0090] In a fourth example, the method of the first example, wherein the UL grant comprises a dynamic grant, wherein the indication of the modality group comprises an implicit  indication of the modality group based on a parameter in Downlink Control Information (DCI) related to the dynamic grant.

[0091] In a fifth example, the method of the first example, wherein the UL grant comprises a configured grant, wherein the indication of the modality group comprises wherein the indication of the modality group comprises an implicit indication of the modality group based on a parameter in a configuration information element (IE) related to the configured grant.

[0092] In a sixth example, the method of the first example, wherein only data from the traffic flows corresponding to the modality group is included in the data unit.

[0093] In a seventh example, the method of the first example, wherein data from the traffic flows corresponding to the modality group is prioritized for inclusion in the data unit, wherein data from other traffic flows is included in the data unit when data from the traffic flows corresponding to the modality group does not fill the data unit.

[0094] In an eighth example, the method of the first example, wherein buffer delay information for each of the IP flows is used to generate the data unit.

[0095] In a ninth example, the method of the first example, wherein LCP settings for individual LCHs are ignored when the UL grant indicates a modality group.

[0096] In a tenth example, the method of the first example, further comprising decoding, from signaling received from the base station, a second UL grant, wherein the second UL grant does not include an indication of a modality group, wherein the UE prioritizes the UL grant over the second UL grant for data unit generation.

[0097] In an eleventh example, the method of the first example, further comprising decoding, from signaling received from the base station, a second UL grant comprising an indication of a second modality group, wherein the UE prioritizes the UL grant or the second UL grant for data unit generation based on a priority level of the modality group and a second priority level of the second modality group.

[0098] In a twel fth example, the method of the first example, further comprising decoding, from signaling received from a core network, a message indicating the traffic flows corresponding to a multi-modal service identification, wherein the traffic flows corresponding to the multi-modal service identification are to be synchronized in uplink transmissions.

[0099] In a thirteenth example, the method of the twelfth example, wherein the message further comprises a priority level associated with the multi-modal service identification.

[0100] In a fourteenth example, the method of the first example, further comprising decoding, from signaling received from a base station, a message indicating the QoS flows, LCH or DRB corresponding to the modality group.

[0101] In a fifteenth example, the method of the first example, wherein generating the data unit, comprises selecting data from one of the traffic flows of the modality group and determining whether a condition related to another one of the traffic flows of the modality group is satisfied.

[0102] In a sixteenth example, the method of the fifteenth example, wherein, when the condition is not satisfied, the generating the data unit comprises processing the data from the one of the traffic flows to be included in the data unit.

[0103] In a seventeenth example, the method of the fifteenth example, wherein, when the condition is satisfied, the generating the data unit comprises changing a setting related to the one of the traffic flows and processing the data based on the changed setting of the one of the traffic flows.

[0104] In an eighteenth example, the method of the seventeenth example, wherein the setting comprises a logical channel (LCH) priority, a prioritized bit rate (PBR) , or a LCH mapping restriction.

[0105] In a nineteenth example, the method of the seventeenth example, wherein the data being processed based on the changed setting includes autonomous activation of duplication for the data, discard of buffered packets of the data before a discard timer is expired or a change in a timer value of the discard timer.

[0106] In a twentieth example, the method of the fifteenth example, wherein the condition comprises (i) data is buffered  for the another one of the traffic flows, (ii) data buffered for the another one of the traffic flows has a remaining time lower than a threshold, or (iii) data buffered for the another one of the traffic flows is discarded.

[0107] In a twenty first example, the method of the first example, wherein generating the data unit comprises selecting one of the traffic flows of the modality group and determining whether a condition related to another one of the traffic flows of the modality group is satisfied.

[0108] In a twenty second example, the method of the twenty first example, wherein, when the condition is not satisfied, the generating the data unit comprises processing data from the one of the traffic flows to be included in the data unit.

[0109] In a twenty third example, the method of the twenty first example, wherein, when the condition is satisfied, the generating the data unit comprises processing data from the one of the traffic flows to be included in the data unit and processing data from the another one of the traffic flows to be included in the data unit.

[0110] In a twenty fourth example, the method of the twenty third example, wherein data from the another one of the IP flows is processed when a default setting of the another one of the IP flows indicates the data is not allowed to use the UL grant.

[0111] In a twenty fifth example, the method of the twenty third example, wherein data from the another one of the IP flows  is processed when a variable related to the another one of the IP flows is not greater than 0.

[0112] In a twenty sixth example, the method of the first example, wherein the data unit is a medium access control (MAC) protocol data unit (PDU) .

[0113] In a twenty seventh example, a processor configured to perform any of the methods of the first through twenty sixth examples.

[0114] In a twenty eighth example, a user equipment comprises a transceiver configured to communicate with a network and a processor communicatively coupled to the transceiver and configured to perform any of the methods of the first through twenty sixth examples.

[0115] In a twenty ninth example, a method is performed by a base station, comprising configuring transceiver circuitry to transmit an uplink (UL) grant comprising an indication of UL radio resources and a modality group to a user equipment (UE) , wherein the modality group comprises one or more traffic flows, wherein the traffic flows comprise one of Quality of Service (QoS) flows, logical channel (LCH) or data radio bearer (DRB) and decoding, from signals received from the UE on the UL radio resources, a data unit generated using data from traffic flows included in the modality group.

[0116] In a thirtieth example, the method of the twenty ninth example, wherein the UL grant comprises a dynamic grant, wherein the indication of the modality group comprises an explicit  indication of the modality group in Downlink Control Information (DCI) related to the dynamic grant.

[0117] In a thirty first example, the method of the twenty ninth example, wherein the UL grant comprises a configured grant, wherein the indication of the modality group comprises an explicit indication of the modality group in a configuration information element (IE) related to the configured grant.

[0118] In a thirty second example, the method of the twenty ninth example, wherein the UL grant comprises a dynamic grant, wherein the indication of the modality group comprises an implicit indication of the modality group based on a parameter in Downlink Control Information (DCI) related to the dynamic grant.

[0119] In a thirty third example, the method of the twenty ninth example, wherein the UL grant comprises a configured grant, wherein the indication of the modality group comprises wherein the indication of the modality group comprises an implicit indication of the modality group based on a parameter in a configuration information element (IE) related to the configured grant.

[0120] In a thirty fourth example, the method of the twenty ninth example, further comprising decoding, from signaling received from a core network, a message indicating the traffic flows corresponding to a multi-modal service identification, wherein the traffic flows corresponding to the multi-modal service identification are to be synchronized in uplink transmissions.

[0121] In a thirty fifth example, the method of the thirty fourth example, wherein the message further comprises a priority level associated with the multi-modal service identification.

[0122] In a thirty sixth example, the method of the thirty fifth example, further comprising grouping the QoS flows of the traffic flows corresponding to the multi-modal service identification into the modality group, wherein the modality group comprises a modality group identification and configuring transceiver circuitry to transmit an indication of the QoS flows of the modality group.

[0123] In a thirty seventh example, the method of the thirty fifth example, further comprising grouping the DRB of the traffic flows corresponding to the multi-modal service identification into the modality group, wherein the modality group comprises a modality group identification and configuring transceiver circuitry to transmit an indication of the DRB of the modality group.

[0124] In a thirty eighth example, the method of the thirty fifth example, further comprising grouping the LCH of the traffic flows corresponding to the multi-modal service identification into the modality group, wherein the modality group comprises a modality group identification and configuring transceiver circuitry to transmit an indication of the LCH of the modality group.

[0125] In a thirty ninth example, the method of the twenty ninth example, wherein the data unit is a medium access control (MAC) protocol data unit (PDU) .

[0126] In a fortieth example, a processor configured to perform any of the methods of the twenty ninth through thirty ninth examples.

[0127] In a forty first example, a base station comprises a transceiver configured to communicate with a user equipment and a processor communicatively coupled to the transceiver and configured to perform any of the methods of the twenty ninth through thirty ninth examples.

[0128] Those skilled in the art will understand that the above-described exemplary embodiments may be implemented in any suitable software or hardware configuration or combination thereof. An exemplary hardware platform for implementing the exemplary embodiments may include, for example, an Intel x86 based platform with compatible operating system, a Windows OS, a Mac platform and MAC OS, a mobile device having an operating system such as iOS, Android, etc. The exemplary embodiments of the above described method may be embodied as a program containing lines of code stored on a non-transitory computer readable storage medium that, when compiled, may be executed on a processor or microprocessor.

[0129] Although this application described various embodiments each having different features in various combinations, those skilled in the art will understand that any of the features of one embodiment may be combined with the  features of the other embodiments in any manner not specifically disclaimed or which is not functionally or logically inconsistent with the operation of the device or the stated functions of the disclosed embodiments.

[0130] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0131] It will be apparent to those skilled in the art that various modifications may be made in the present disclosure, without departing from the spirit or the scope of the disclosure. Thus, it is intended that the present disclosure cover modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalent.

Claims

1.An apparatus of a user equipment (UE) , the apparatus comprising processing circuitry configured to:decode, from signaling received from a base station, an uplink (UL) grant comprising an indication of UL radio resources and a modality group;generate a data unit based on data from a plurality of traffic flows corresponding to the modality group, wherein the IP flows comprise one of Quality of Service (QoS) flows, logical channel (LCH) or data radio bearer (DRB) ; andconfigure transceiver circuitry to transmit the data unit using the UL radio resources.2.The apparatus of claim 1, wherein the UL grant comprises a dynamic grant, wherein the indication of the modality group comprises an explicit indication of the modality group in Downlink Control Information (DCI) related to the dynamic grant.3.The apparatus of claim 1, wherein the UL grant comprises a configured grant, wherein the indication of the modality group comprises an explicit indication of the modality group in a configuration information element (IE) related to the configured grant.4.The apparatus of claim 1, wherein the UL grant comprises a dynamic grant, wherein the indication of the modality group comprises an implicit indication of the modality group based on a parameter in Downlink Control Information (DCI) related to the dynamic grant.5.The apparatus of claim 1, wherein the UL grant comprises a configured grant, wherein the indication of the modality group comprises wherein the indication of the modality group comprises an implicit indication of the modality group based on a parameter in a configuration information element (IE) related to the configured grant.6.The apparatus of claim 1, wherein only data from the traffic flows corresponding to the modality group is included in the data unit.7.The apparatus of claim 1, wherein data from the traffic flows corresponding to the modality group is prioritized for inclusion in the data unit, wherein data from other traffic flows is included in the data unit when data from the traffic flows corresponding to the modality group does not fill the data unit.8.The apparatus of claim 1, wherein buffer delay information for each of the I P flows is used to generate the data unit.9.The apparatus of claim 1, wherein LCP settings for individual LCHs are ignored when the UL grant indicates a modality group.10.The apparatus of claim 1, wherein the processing circuitry is further configured to:decode, from signaling received from the base station, a second UL grant, wherein the second UL grant does not include an indication of a modality group, wherein the UE prioritizes the UL grant over the second UL grant for data unit generation.11.The apparatus of claim 1, wherein the processing circuitry is further configured to:decode, from signaling received from the base station, a second UL grant comprising an indication of a second modality group, wherein the UE prioritizes the UL grant or the second UL grant for data unit generation based on a priority level of the modality group and a second priority level of the second modality group.12.The apparatus of claim 1, wherein the processing circuitry is further configured to:decode, from signaling received from a core network, a message indicating the traffic flows corresponding to a multi-modal service identification, wherein the traffic flows corresponding to the multi-modal service identification are to be synchronized in uplink transmissions.13.The apparatus of claim 12, wherein the message further comprises a priority level associated with the multi-modal service identification.14.The apparatus of claim 1, wherein the processing circuitry is further configured to:decode, from signaling received from a base station, a message indicating the QoS flows, LCH or DRB corresponding to the modality group.15.The apparatus of claim 1, wherein the processing circuitry, to generate the data unit, is configured to:select data from one of the traffic flows of the modality group; anddetermine whether a condition related to another one of the traffic flows of the modality group is satisfied.16.The apparatus of claim 15, wherein, when the condition is not satisfied, the processing circuitry, to generate the data unit, is configured to:process the data from the one of the traffic flows to be included in the data unit.17.The apparatus of claim 15, wherein, when the condition is satisfied, the processing circuitry, to generate the data unit, is configured to:change a setting related to the one of the traffic flows; andprocess the data based on the changed setting of the one of the traffic flows.18.The apparatus of claim 17, wherein the setting comprises a logical channel (LCH) priority, a prioritized bit rate (PBR) , or a LCH mapping restriction.19.The apparatus of claim 17, wherein the data being processed based on the changed setting includes autonomous activation of duplication for the data, discard of buffered packets of the data before a discard timer is expired or a change in a timer value of the discard timer.20.An apparatus of a base station, the apparatus comprising processing circuitry configured to:configure transceiver circuitry to transmit an uplink (UL) grant comprising an indication of UL radio resources and a modality group to a user equipment (UE) , wherein the modality group comprises one or more traffic flows, wherein the traffic flows comprise one of Quality of Service (QoS) flows, logical channel (LCH) or data radio bearer (DRB) ; anddecode, from signals received from the UE on the UL radio resources, a data unit generated using data from traffic flows included in the modality group.