Synchronized transmission of multi-modal traffic

Abstract

A user equipment (UE) is configured to: decode, from signaling received from a base station, an uplink (UL) grant comprising an indication of uplink (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 flow includes one of a quality of service (QoS) flow, a logical channel (LCH), or a data radio bearer (DRB); and configuring the transceiver circuitry to transmit the data unit using the UL radio resource.

Description

Technical Field

[0001] This application relates in general to wireless communication systems, and more specifically to the synchronous transmission of multimodal services. Background Technology

[0002] Cellular networks can support multimodal communication services for a variety of use cases, including extended reality (XR) services. For example, XR applications should be able to receive input from more than one source and / or output to more than one destination to convey information more effectively. Summary of the Invention

[0003] Some exemplary embodiments relate to an apparatus for a user equipment (UE) having processing circuitry configured to: decode signaling received from a base station, including UL grants for indications of uplink (UL) radio resources and mode groups; generate data units based on data from multiple traffic flows corresponding to the mode groups, wherein the IP flows include one of a Quality of Service (QoS) flow, a Logical Channel (LCH), or a Data Radio Bearer (DRB); and configure transceiver circuitry to transmit the data units using UL radio resources.

[0004] Other exemplary embodiments relate to a processor configured to: decode signaling received from a base station, including UL grants for indications of uplink (UL) radio resources and mode groups; generate data units based on data from multiple traffic flows corresponding to the mode groups, wherein the IP flows include one of a Quality of Service (QoS) flow, a Logical Channel (LCH), or a Data Radio Bearer (DRB); and configure transceiver circuitry to transmit the data units using UL radio resources.

[0005] Another exemplary embodiment relates to an apparatus for a base station having processing circuitry configured to: configure transceiver circuitry to transmit to a user equipment (UE) a UL grant including an indication of uplink (UL) radio resources and a mode group, wherein the mode group includes one or more traffic flows, wherein the traffic flows include one of a Quality of Service (QoS) flow, a Logical Channel (LCH), or a Data Radio Bearer (DRB); and decode data units generated from data from the traffic flows included in the mode group from signals received from the UE on the UL radio resources.

[0006] Additional exemplary embodiments relate to a processor configured to: configure transceiver circuitry to: transmit to a user equipment (UE) a UL grant including indications of uplink (UL) radio resources and mode groups, wherein the mode groups include one or more traffic flows, wherein the traffic flows include one of a Quality of Service (QoS) flow, a Logical Channel (LCH), or a Data Radio Bearer (DRB); and decode data units generated from data from the traffic flows included in the mode groups from signals received from the UE on the UL radio resources. Attached Figure Description

[0007] Figure 1 Exemplary network arrangements according to various exemplary implementations are shown.

[0008] Figure 2 Exemplary user equipment (UE) according to various exemplary embodiments are shown.

[0009] Figure 3 An exemplary base station according to various exemplary embodiments is shown.

[0010] Figure 4 Examples of multimodal services according to various exemplary implementation schemes are shown.

[0011] Figure 5 Examples of logical channels (LCHs) for multiple modes being multiplexed into the same Media Access Control (MAC) Protocol Data Unit (PDU) are shown according to various exemplary embodiments.

[0012] Figure 6 A call flow for identifying a set of IP streams corresponding to a modality that should be delivered synchronously, according to various exemplary embodiments, is illustrated.

[0013] Figure 7 An exemplary call flow for modality group-specific uplink scheduling is shown according to various exemplary implementations.

[0014] Figure 8 Exemplary methods for adjusting the configuration of business flows according to various exemplary implementations are shown.

[0015] Figure 9 Exemplary methods for balancing multimodal services when a UE selects an LCH during a Logical Channel Priority (LCP) process are illustrated, according to various exemplary embodiments. Detailed Implementation

[0016] The exemplary embodiments can be further understood with reference to the following description and related figures, wherein the same elements are given the same reference numerals. The exemplary embodiments relate to synchronous data streams for multimodal services.

[0017] Exemplary embodiments are described with reference to a UE. However, references to the UE are provided for illustrative purposes only. Exemplary embodiments can be used with any electronic component capable of establishing a connection to a network and configured with hardware, software, and / or firmware for exchanging information and data with the network. Therefore, the UE as described herein is used to represent any suitable type of electronic component.

[0018] Exemplary implementations are also described with reference to 5G NR networks supporting Extended Reality (XR). Those skilled in the art will understand that XR is an umbrella term for different types of reality and generally refers to a combination of real and virtual environments and associated human-computer interactions generated through computer technology and wearable devices. For the sake of illustration, the term XR may encompass Augmented Reality (AR), Mixed Reality (MR), and Virtual Reality (VR). While exemplary implementations are described with reference to XR, it should be understood that these exemplary implementations can be applied to any supplemental dynamic downlink resource allocation mechanisms that can be utilized during UE power-saving modes. That is, the exemplary implementations are not limited to scenarios where the UE participates in XR operations.

[0019] XR services can utilize multiple data streams in the uplink and / or downlink. For example, in the downlink, there may be video streams, audio streams, and / or data streams. In the uplink, there may be control streams and / or pose streams. From a physical channel perspective, there may be different control channels and shared channels for each stream, or multiple streams may share a single 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 mentioned above, XR applications should be able to receive input 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 crucial for optimizing the user experience. Synchronization thresholds can be defined between two media components. To support synchronization requirements between multiple data streams from different sources, the network can provide service requirements for each media including multimodal services. This can include multimodal service IDs and quality of service (QoS) monitoring requirements for multiple Internet Protocol (IP) data streams (e.g., service streams) associated with a multimodal service. This information can be used to derive rules and apply QoS policies for data streams that are part of a specific multimodal application, and to generate authorized QoS monitoring policies for these service data streams.

[0021] Previous implementations of synchronizing different media components have attempted to align permission (CG) resources across multiple configurations associated with different service flows. However, this approach has limitations, such as its assumption that QoS flows have dedicated CG configurations, which may not be true, as the network may prefer dynamic scheduling. Furthermore, changes to resource allocation by the UE can complicate the issue of ensuring the network is also aware of how resources are reallocated. Finally, when different service flows are transmitted on different resources, there may be no guarantee that synchronization thresholds will be met.

[0022] In an exemplary implementation, to ensure that two or more media components can be transmitted synchronously, from the air interface perspective, data from corresponding logical channels (LCHs) for two or more media components can be delivered in the same Physical Uplink Shared Channel (PUSCH), for example, multiplexed into the same Media Access Control (MAC) Protocol Data Unit (PDU). This can eliminate transmission delays between multiple modes. However, existing Logical Channel Priority (LCP) mechanisms cannot guarantee that data from different traffic flows that should be synchronized are mapped to the same uplink permission, because these LCHs may have different priority levels and other LCP settings.

[0023] Exemplary implementations introduce enhanced uplink (UL) scheduling mechanisms to ensure that data from multiple service flows that should be synchronized are transmitted together. These techniques include, but are not limited to, notifying the UE and RAN of synchronization, grouping flows into mode groups, generating mode group-specific uplink grants, generating MAC PDUs based on mode groups, adaptively adjusting flows based on mode groups, and selecting data to be included in the MAC PDU based on mode groups. Operations related to these techniques are described in more detail below.

[0024] Figure 1 An exemplary network arrangement 100 according to various exemplary embodiments is illustrated. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will understand that the UE 110 can be any type of electronic component configured to communicate via a network, such as a mobile phone, tablet computer, desktop computer, smartphone, phablet, embedded device, wearable device (e.g., head-mounted display (HMD), AR glasses, etc.), Internet of Things (IoT) device, etc. It should also be understood that a practical network arrangement can include any number of UEs used by any number of users. Therefore, the example of a single UE 110 is provided for illustrative purposes only.

[0025] UE 110 can be configured to communicate with one or more networks. In the example of network deployment 100, the network with which UE 110 can wirelessly communicate is the 5G NR radio access network (RAN) 120. However, UE 110 can also communicate with other types of networks (e.g., 5G cloud RAN, next-generation RAN (NG-RAN), LTE RAN, legacy cellular networks, wireless local area networks (WLANs), etc.), and UE 110 can also communicate with the network via a wired connection. Referring to an exemplary implementation, UE 110 can establish a connection with at least 5G NR RAN 120. Therefore, UE 110 may have a 5G NR chipset to communicate with NRRAN 120.

[0026] 5G NR RAN 120 can be part of a cellular network that can be deployed by network operators (e.g., Verizon, AT&T, T-Mobile, etc.). 5G NR RAN 120 may include, for example, cells or base stations (Node B, eNodeB, HeNB, eNB, gNB, gNodeB, macro cells, micro cells, small cells, femtocells, etc.) configured to transmit and receive services from UEs equipped with appropriate cellular chipsets.

[0027] In network deployment 100, UE 110 can connect to 5G NR-RAN 120 via gNB 120A. Those skilled in the art will understand that any association process can be performed to connect UE 110 to 5G NR-RAN 120. For example, as described above, 5G NR-RAN 120 can be associated with a specific cellular provider where UE 110 and / or its user have protocol and credential information (e.g., stored on a SIM card). Upon detecting the presence of 5G NR-RAN 120, UE 110 can send the corresponding credential information to associate with 5G NR-RAN 120. More specifically, UE 110 can be associated with a specific base station (e.g., gNB 120A). However, as described above, the reference to 5G NR-RAN 120 is for illustrative purposes only, and any suitable type of RAN can be used.

[0028] Network deployment 100 also includes a cellular core network 130, an Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 can be viewed as a set of interconnected components managing the operation and services of the cellular network. The cellular core network 130 also manages traffic flowing between the cellular network and the Internet 140. The IMS 150 can generally be described as an architecture for delivering multimedia services to the UE 110 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to the UE 110. The network services backbone 160 communicates directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 can generally be described as a set of components (e.g., servers, network storage deployments, etc.) that implement a set of services that can be used to extend the functionality of the UE 110 in communicating with various networks.

[0029] Figure 2 An exemplary UE 110 according to various exemplary embodiments is shown. Reference will be made to... Figure 1 The network layout 100 is used to describe UE 110. UE 110 may include a processor 205, a memory layout 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. Other components 230 may include, for example, audio input devices, audio output devices, power supplies, data acquisition devices, ports for electrically connecting UE 110 to other electronic devices, etc.

[0030] Processor 205 may be configured to execute multiple engines of UE 110. For example, an engine may include multimodal service engine 235. Multimodal service engine 235 may perform various operations to synchronize uplink data for multimodal services. These operations may include, but are not limited to: receiving uplink grants associated with multimodal services, and generating MACPDUs for multimodal services to deliver data synchronously. These and other operations are described in more detail below.

[0031] The aforementioned engine is provided as an application (e.g., a program) executed by processor 205 for illustrative purposes only. The functionality associated with the multimodal service engine 235 may also be represented as a separately incorporated component of UE 110, or it may be a modular component coupled to UE 110, such as an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. The engine may also be embodied as one application or multiple separate applications. Furthermore, in some UEs, the functionality described for processor 205 is split among two or more processors, such as a baseband processor and an application processor. Exemplary implementations may be implemented according to any of these or other configurations of the UE.

[0032] Memory arrangement 210 may be a hardware component configured to store data related to operations performed by UE 110. Display device 215 may be a hardware component configured to display data to a user, while I / O device 220 may be a hardware component enabling a user to input data. Display device 215 and I / O device 220 may be separate components or may be integrated together (such as a touchscreen).

[0033] Transceiver 225 may be a hardware component configured to establish a connection with 5G NR-RAN 120 and / or any other suitable type of network. Therefore, transceiver 225 may operate on a variety of different frequencies or channels (e.g., a continuous set of frequencies). Transceiver 225 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals). Such signals may be encoded using information used to implement any of the methods described herein. Processor 205 may be operatively coupled to transceiver 225 and configured to receive signals from and / or transmit signals to transceiver 225. Processor 205 may be configured to encode and / or decode signals (e.g., signaling from a base station in the network) for use in implementing any of the methods described herein.

[0034] Figure 3 An exemplary base station 300 according to various exemplary embodiments is shown. Base station 300 may represent any access node (e.g., gNB 120A, etc.) that UE 110 can use to establish connections and manage network operations.

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

[0036] Processor 305 may be configured to execute multiple engines of base station 300. For example, an engine may include multimodal service engine 330. Multimodal service engine 330 may perform various operations related to synchronizing data used for multimodal services. These operations may include, but are not limited to, grouping data streams into mode groups based on synchronization requirements, and transmitting uplink permission identifying mode groups to the UE. These and other operations are described in more detail below.

[0037] The engine described above, as an application (e.g., a program) executed by processor 305, is merely exemplary. The functionality associated with the multimodal service engine 330 can also be represented as a separately incorporated component of base station 300, or as a modular component coupled to base station 300, such as an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. Furthermore, in some base stations, the functionality described for processor 305 is split among multiple processors (e.g., baseband processor, application processor, etc.). Exemplary implementations can be implemented according to any of these or other configurations of the 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 port that enables a user to interact with the base station 300.

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

[0040] Figure 4 Examples of multimodal services 400 according to various exemplary implementations are shown. Figure 4In the example, user 405 has a UE 410 that collects various inputs, such as user input and / or environmental input. Some examples of these inputs are described below. It should be understood that UE 410 may represent more than one UE. For example, user 405 may have a wearable device (e.g., a watch, glasses, etc.) attached to a mobile device (e.g., a mobile phone). In other examples, UE 410 may receive input from multiple Internet of Things (IoT) devices (e.g., smart appliances, etc.).

[0041] Figure 4 Examples of multimodal input 430 that can be collected by UE 410 are shown. These examples include voice biometrics, text, and voice emotion that can be collected by, for example, a microphone of UE 410. Other examples include facial biometrics, facial emotion, and lip movements that can be collected by, for example, a camera of UE 410. Additional examples include emotions from wearable devices (e.g., based on the user's temperature), gestures or relative positions from the same or different cameras of UE 410, environmental information from sensors of UE 410 (such as temperature, pressure, altitude, etc.), and haptic information from haptic I / O of UE 410.

[0042] exist Figure 4 The example illustrates three services (e.g., XR applications): biometric recognition 435, intent awareness 440, and service presence 445. As described above, each of services 435 to 445 may receive more than one multimodal input from the multimodal inputs 430. For example, the biometric recognition service 435 may receive voice biometrics and voice emotion from the microphone of the UE 410, and facial emotion from the camera of the UE 410. As described above, these multimodal inputs 430 should be synchronized when received by the biometric recognition service 435. An exemplary manner of achieving this synchronization will be described below.

[0043] exist Figure 4 In the example, the output of the biometric recognition service 435 is fed into the intent-aware service 440, and the output of the intent-aware service 440 is fed into the service presence 445, which can then output a multimodal output 450. However, this is not necessary, as the output of each of the individual services 435-445 can also be a multimodal output 450.

[0044] Figure 4 Examples of multimodal outputs 450 are also shown. These examples include audio, video, temperature, brightness, and haptic outputs. Figure 4 As shown, the multimodal output 450 can output to various controllable components 415 to 425. The controllable components 415 to 425 can be UE 410, or other devices such as IoT devices.

[0045] Figure 5 Examples of logical channels (LCHs) for multiplexing multiple modes into the same Media Access Control (MAC) Protocol Data Unit (PDU) 500 are shown according to various exemplary embodiments. In exemplary embodiments, to ensure that two or more media components can be transmitted synchronously, data from corresponding LCHs of two or more media components can be delivered in the same PUSCH, for example, by multiplexing into the same MAC PDU 500 using a Logical Channel Priority (LCP) process 500.

[0046] For reference Figure 4 For example, the Biometrics 435 service may receive voice biometrics and voice emotion from the microphone of the UE 410, and facial emotion from the camera of the UE 410. Data for each of these inputs may be transmitted by the UE 410 on a different uplink data radio bearer (DRB), and therefore on a different LCH; for example, voice biometrics may be associated with logical channel #0, voice emotion with logical channel #1, and facial emotion with logical channel #2. The Biometrics 435 service may expect to receive these multimodal inputs from the UE 410 synchronously. Therefore, to ensure this synchronization, the LCP procedure 510 is used to construct a MAC PDU 500 that includes data from the appropriate LCH.

[0047] As described above, in some cases, different LCHs (e.g., logical channel #0, logical channel #1, and logical channel #2) may have different priority levels and other LCP settings. Exemplary implementations introduce techniques to enhance uplink (UL) scheduling mechanisms to ensure that data from multiple traffic flows that should be synchronized are transmitted together; for example, LCP procedure 500 constructs MAC PDU 500 in a manner that data from different LCHs are properly synchronized.

[0048] Figure 6 A call flow 600, according to various exemplary embodiments, is shown for identifying a set of IP flows corresponding to a modality that should be delivered synchronously. Figure 6 The call flow occurs between various functions of UE 110 (which could also be UE 410), gNB 120A which can be considered to represent NR-RAN 120, and core network 130 (e.g., 5GC). In this case, the functions of core network 130 include User Plane Function (UPF) 610, Session Management Function (SMF) 620, and Policy Control Function (PCF) 630.

[0049] Generally speaking, the UPF 610 acts as an external PDU session point for interconnection to the DN and can perform packet routing and forwarding, perform packet inspection, enforce the user plane portion of policy rules, legally intercept packets (UP collection), perform service usage reporting, perform QoS processing on the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink service verification (e.g., SDF to QoS flow mapping), transport-level packet marking in uplink and downlink, and perform downlink packet buffering and downlink data notification triggering.

[0050] Generally, the SMF 620 can perform operations related to session management, such as, but not limited to, session establishment, session release, IP address allocation, policy and QoS enforcement. Generally, the PCF 630 can provide control plane functions with policy rules to be enforced and can also support a unified policy framework to manage network behavior.

[0051] In 640, a multimodal service ID shared by multiple IP flows (e.g., service flows) is defined in PCF 630, and this multimodal service ID can be used for policy decisions such as admission control. The multimodal service ID identifies a set of IP flows corresponding to a modality that should be delivered synchronously.

[0052] In 645, PCF 630 can transmit multimodal service ID messages to SMF 620 to provide an association between multimodal service IDs and corresponding IP flows. In 650 and 655, SMF 620 can transmit multimodal service ID messages to UPF 610 and RAN (e.g., gNB 120A) to provide an association between multimodal service IDs and corresponding IP flows, respectively.

[0053] Similarly, in 660, the association between the multimodal service ID and the IP flow can be provided to UE 110 by SMF 620 in the multimodal service ID message. Session management (SM) signaling can also be used to notify UE 110 when establishing relevant QoS flows.

[0054] UE routing policy (URSP) rules can be defined to ensure that the traffic flows to be synchronized target the same data network name (DNN) or single network slice selection aid information (S-NSSAI), for example, the traffic flows to be synchronized are grouped into the same network slice.

[0055] In some exemplary embodiments, the core network 130 may also define priority ordering rules among different multimodal services. For example, each multimodal service ID may be associated with a priority level. Priority level information for each multimodal service may also be provided to the RAN (e.g., gNB 120A) and / or UE 110. This priority level information may be used for radio resource allocation and / or priority ordering.

[0056] Figure 6 This illustration shows an example of how UE 110 and RAN (e.g., gNB 120A) can obtain the association between a multimodal service ID and its corresponding IP flow. The exemplary implementation is not limited to UE 110 and RAN obtaining this information in this manner; for example, UE 110 and RAN can obtain this information in other ways. The following exemplary implementation assumes that UE 110 and / or RAN have already obtained the association between the multimodal service ID and its corresponding IP flow, but again, it is not limited to UE 110 and / or RAN for reference only. Figure 6 The exemplary method described is used to obtain information.

[0057] Once the RAN (e.g., gNB 120A) and / or UE 110 have obtained information on the synchronization requirements and associated service flows, the corresponding QoS flows or data radio bearers (DRBs) / LCHs can be mapped to one or more groups. Throughout this disclosure, each of these groups will be described as a "modal group." However, other entities may use different terms to refer to such groups. Modal groups can be used by the RAN for appropriate configuration, such as resource allocation. Mapping can be determined based on information on the synchronization requirements and associated service flows.

[0058] In the first example, modal groups can be based on QoS flow-based packets. For example, QoS flows corresponding to IP flows to be synchronized are mapped to the same modal group. Each modal group can be associated with a modal group ID.

[0059] In some exemplary implementations, a QoS flow may be associated with two or more modal groups. Alternatively, it is not required that a QoS flow be associated with any modal group, for example, for IP flows that do not need to be synchronized with any other data flows. QoS flows within a modal group are not necessarily mapped to the same DRB by the Service Data Adaptation Protocol (SDAP). For example, synchronized IP flows may not have the same QoS requirements and therefore may not be mapped to the same DRB. However, in one option, all QoS flows mapped to the same modal group may be mapped to the same DRB.

[0060] In the second example, modal groups can be based on DRB / LCH-based packets. The DRB / LCH corresponding to the IP flow to be synchronized is mapped to the same modal group. Each modal group can have at least one DRB / LCH. Each modal group is also associated with a modal group ID.

[0061] In some exemplary implementations, the DRB / LCH may be associated with two or more mode groups. Similar to QoS-based packetization, the DRB / LCH does not need to be associated with any single mode group. Furthermore, the LCH / DRB within a mode group are not necessarily in the same Logical Channel Group (LCG) defined for Buffer State Report (BSR) reports. However, in one option, all LCHs mapped to the same mode group can be mapped to the same LCG (e.g., the LCG mechanism is directly reused for mode group mapping).

[0062] Once a mode group has been defined, an uplink clearance can be issued to accommodate buffered data from all QoS flows / DRB / LCH belonging to the same mode group, ensuring that data from these QoS flows / DRB / LCH are multiplexed into the same MACPDU and thus delivered simultaneously.

[0063] Figure 7 An exemplary call flow 700 for modality group-specific uplink scheduling is illustrated according to various exemplary embodiments. Call flow 700 is executed between the RAN (e.g., gNB 120A) and the UE 110. As described above, modality groups can be defined based on QoS flows, DRBs, or LCHs. Therefore, throughout this description of call flow 700, it can be assumed that the exemplary modality group may have been defined using any of these methods. Therefore, specific references to QoS flows, DRBs, or LCHs should also be understood as references to any other methods (e.g., QoS flows, DRBs, or LCHs) that can define modality groups.

[0064] In 730, gNB 120A configures a mode group for UE 110. An exemplary method for configuring a mode group has been described above. In... Figure 7 In the example shown, there may be two modal groups: modal group #0710, which includes LCH #0, LCH #1 and LCH #2, and modal group #1720, which includes LCH #3, LCH #4 and LCH #5.

[0065] In 735, the gNB 120A dynamically schedules mode group #0 710 for UL transmission. The gNB 120A can signal the scheduling of mode group #0 710 in several ways. In a first example, the gNB 120A can transmit an uplink grant with an explicit indication of the mode group ID (e.g., mode group #0 710). In one example providing an explicit indication, when the UL grant is a dynamic grant, a new field indicating the target mode group ID can be included in the downlink control information (DCI) used for dynamic scheduling. In another example providing an explicit indication, when the UL grant is a configured grant, a new parameter indicating the target mode group ID can be included in the configured grant configuration information element (IE) (e.g., a ConfiguredGrantConfig IE).

[0066] In the second example, the gNB 120A can transmit uplink grants 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 configured grant configuration can be used to indicate the target modality group ID. For example, the HARQ process ID can be used to implicitly indicate the modality group ID.

[0067] In step 740, UE 110 receives UL approval for mode group #0 710 and applies the LCP procedure to generate a MAC PDU based on the LCHs for mode group #0 710 (e.g., LCH #0, LCH #1, and LCH #2). If needed, mode group-related information (e.g., LCHs belonging to the indicated mode group) can be provided to the MAC layer by the upper layer. When generating the MAC PDU using the LCP procedure, UE 110 can have multiple options for the data included in the MAC PDU.

[0068] In the first option, UE 110 can map only data from all QoS flows, DRBs, or LCHs from the indicated modality group (e.g., modality group #0 710) to the scheduled UL-SCH. Data from other LCHs is not allowed. In this option, any spare resources can be filled by padding.

[0069] In the second option, UE 110 can prioritize data from all QoS flows, DRBs, or LCHs from the indicated modality group for the scheduled UL-SCH. Data from other LCHs can only be reused if spare resources are available.

[0070] When constructing a MAC PDU, UE 110 can also obtain LCH buffer delay information for use in intra-modal LCP procedure MAC PDU generation or inter-modal LCP procedure MAC PDU generation. To provide an example relevant to intra-modal situations, if UE 110 is considered to be generating a MAC PDU for modal group #0 710, and the total amount of data in the buffers of LCH #0, LCH #1, and LCH #2 exceeds the amount of data that can be included in the MAC PDU, the LCP procedure can consider how long the data has been in the buffers of each of LCH #0, LCH #1, and LCH #2 when generating the MAC PDU, for example, omitting older data, omitting newer data, etc. To provide an example relating to modal groups, if UE 110 is considered to be generating a MAC PDU for modal group #0710, and the total amount of data in the buffers of LCH #0, LCH #1, and LCH #2 is less than the total size of the MAC PDU, then UE 110 may consider how long the data has been in the buffers of each of 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 UE 110 receives a special grant (e.g., a grant indicating a mode group), the LCP settings for the LCHs in the mode group may not apply. For example, UE 110 may ignore the LCP settings when processing a special grant (e.g., generating a MAC PDU using an LCP procedure).

[0072] In some cases, UE 110 may have conflicts between mode group-specific uplink grants and general uplink grants. For example, UE 110 may have received both mode group-specific uplink grants (e.g., grants indicating the mode group) and general grants, and the radio resources of these grants overlap at least partially in time. In other cases, UE 110 may have conflicts between multiple mode group-specific uplink grants. For example, UE 110 may have received two or more mode group-specific uplink grants whose radio resources overlap at least partially in time. When such conflicts occur, UE 110 may apply various rules to prioritize or select grants used for MAC PDU generation. In one example of a grant priority prioritization rule, UE 110 may always prioritize mode group-specific uplink grants over general grants, regardless of LCH priority. For example, a lower-priority LCH included in a mode group-specific uplink grant may be prioritized over a higher-priority LCH scheduled using a general uplink grant. When conflicts arise between uplink grants for multiple modal groups, UE 110 can prioritize grants based on the priority level associated with each multimodal service ID. The priority levels associated with each multimodal service ID are described above.

[0073] In 745, UE 110 uses the MAC PDU generated for mode group #0 710 to perform PUSCH transmission.

[0074] To complete call procedure 700, in 750, gNB 120A dynamically schedules mode group #1 720 for UL transmission. In 755, UE 110 receives UL approval for mode group #1 720 and applies the LCP procedure to generate a MAC PDU based on the LCHs (e.g., LCH #3, LCH #4, and LCH #5) for mode group #1 720. In 760, UE 110 uses the MAC PDU generated for mode group #1 720 to perform PUSCH transmission.

[0075] Figure 8 An exemplary method 800 for adjusting the configuration of a service flow according to various exemplary embodiments is illustrated. The exemplary method 800 involves adaptively adjusting the configuration, parameters, or behavior (e.g., settings) for transmitting a service flow based on conditions related to another service flow in the same modal group. The exemplary method 800 is performed by UE 110, and UE 110 can be considered to have been previously configured with modal group #0 810 consisting of LCH #0, LCH #1, and LCH #2.

[0076] In 820, UE 110, for example, in response to receiving UL approval from gNB 120A, uses the associated LCP procedure to process UL data packets from LCH #0. It should be understood that using data packets from LCH #0 is merely an example, and method 800 can also be used for data packets processed from LCH #1 or LCH #2.

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

[0078] If UE 110 determines that no conditions related to LCH #1 or LCH #2 are met, the method continues to 840, where UE 110 uses the default (or pre-configured) LCP procedure to process the data packets of LCH #0 to construct the MAC PDU.

[0079] On the other hand, if UE 110 determines that one or more of the conditions associated with LCH #1 or LCH #2 are met, the method continues to step 850, where UE 110 changes the LCP setting of LCH #0 to process data packets. Some examples of changing the LCP setting may include changing the LCH priority, priority bit rate (PBR), or LCH mapping restrictions for LCH #0. In other examples, changes may include voluntarily activating replication, discarding buffered packets before the discard timer expires, changing the discard timer value, etc.

[0080] In some example implementations, a DRB may be associated with two radio link control (RLC) entities, and the UE 110 may switch RLC branches based on conditions associated with another DRB / LCH in the same mode group.

[0081] Figure 9 An exemplary method 900 is illustrated for a UE to consider the synchronization of multimodal services when selecting an LCH during an LCP procedure, according to various exemplary embodiments. When the MAC selects an LCH for data multiplexing to uplink permission via the LCP procedure, the MAC selects the LCH based on whether the LCH is allowed to use that uplink permission (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. Figure 9In the example, when selecting an LCH during the LCP procedure, the UE may consider the synchronization of multimodal services. Exemplary method 900 is performed by UE 110, and it can be assumed that UE 110 has previously been configured with modal group #0 consisting of LCH #0, LCH #1, and LCH #2 910.

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

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

[0084] If UE 110 determines that any condition related to LCH #1 or LCH #2 is not met, the method continues to 940, where UE 110 uses the default (or pre-configured) LCP procedure to process LCH #0 to construct the MAC PDU.

[0085] On the other hand, if UE 110 determines that one or more of the conditions associated with LCH #1 or LCH #2 are met, the method continues to 950, where UE 110 selects LCH #1 or LCH #2 to perform the LCP procedure for UL grant based on which LCH meets the condition. Various options may exist for selecting an LCH for the LCP procedure. In a first option, UE 110 will select LCH #1 or LCH #2, even if the LCH may not be allowed to use that uplink grant by default. In a second option, UE 110 may also allocate data from LCH #1 or LCH #2 for the MAC PDU, even if the Bj value maintained by the LCH is not greater than 0. It should also be understood that the above options can be used individually or together; for example, these options are not mutually exclusive.

[0086] Example In a first embodiment, a method is performed by a user equipment (UE), the method comprising: decoding from signaling received from a base station a UL grant including indications of uplink (UL) radio resources and mode groups; generating a data unit based on data from multiple traffic flows corresponding to the mode groups, wherein the IP flows include one of a Quality of Service (QoS) flow, a Logical Channel (LCH), or a Data Radio Bearer (DRB); and configuring transceiver circuitry to transmit the data unit using the UL radio resources.

[0087] In a second embodiment, according to the method of the first embodiment, the UL grant includes dynamic grant, wherein the indication of the mode group includes an explicit indication of the mode group in downlink control information (DCI) associated with the dynamic grant.

[0088] In a third embodiment, according to the method of the first embodiment, the UL grant includes a configured grant, wherein the indication of the modality group includes an explicit indication of the modality group in a configuration information element (IE) associated with the configured grant.

[0089] In a fourth embodiment, according to the method of the first embodiment, the UL grant includes dynamic grant, wherein the indication of the mode group includes an implicit indication of the mode group based on parameters in the downlink control information (DCI) associated with the dynamic grant.

[0090] In a fifth embodiment, according to the method of the first embodiment, wherein the UL grant includes a configured grant, wherein the indication to the modal group includes an implicit indication to the modal group based on parameters in a configuration information element (IE) associated with the configured grant.

[0091] In a sixth embodiment, according to the method of the first embodiment, data from only the service flow corresponding to the modality group is included in the data unit.

[0092] In the seventh embodiment, according to the method of the first embodiment, data from the service flow corresponding to the modality group is preferentially considered to be included in the data unit, wherein when the data from the service flow corresponding to the modality group does not fill the data unit, data from other service flows is included in the data unit.

[0093] In the eighth embodiment, according to the method of the first embodiment, buffer delay information for each IP stream in the IP stream is used to generate the data unit.

[0094] In the ninth embodiment, the method described in the first embodiment is used, wherein when the UL grants indication of the modal group, the LCP setting for each LCH is ignored.

[0095] In the tenth embodiment, according to the method of the first embodiment, the method further includes decoding a second UL grant from signaling received from the base station, wherein the second UL grant does not include an indication of a mode group, and wherein the UE uses the UL grant in priority over the second UL grant for data unit generation.

[0096] In the eleventh embodiment, according to the method of the first embodiment, the method further includes decoding a second UL grant from signaling received from the base station, including an indication of a second mode group, wherein the UE grants the UL grant or the second UL grant preferentially for data unit generation based on the priority level of the mode group and a second priority level of the second mode group.

[0097] In the twelfth embodiment, according to the method of the first embodiment, the method further includes a signaling decoding instruction received from the core network indicating the service flow corresponding to the multimodal service identifier, wherein the service flow corresponding to the multimodal service identifier will be synchronized in the uplink transmission.

[0098] In the thirteenth embodiment, according to the method of the twelfth embodiment, the message further includes a priority level associated with the multimodal service identifier.

[0099] In the fourteenth embodiment, according to the method of the first embodiment, the method further includes decoding a message received from the base station indicating the QoS stream, the LCH, or the DRB corresponding to the mode group.

[0100] In the fifteenth embodiment, according to the method of the first embodiment, generating the data unit includes: selecting data from one of the service flows of the modality group, and determining whether a condition related to another service flow of the service flows of the modality group is met.

[0101] In the sixteenth embodiment, according to the method of the fifteenth embodiment, wherein when the condition is not met, generating the data unit includes processing the data from one of the service flows to include it in the data unit.

[0102] In the seventeenth embodiment, according to the method of the fifteenth embodiment, generating the data unit when the condition is met includes: changing the settings associated with the one service flow in the service flow, and processing the data based on the changed settings of the one service flow in the service flow.

[0103] In the eighteenth embodiment, according to the method of the seventeenth embodiment, the settings include logical channel (LCH) priority, priority bit rate (PBR), or LCH mapping limit.

[0104] In the nineteenth embodiment, according to the method of the seventeenth embodiment, processing the data based on the changed settings includes autonomously activating the replication of the data, discarding buffered packets of the data before the discard timer expires, or changing the timer value of the discard timer.

[0105] In the twentieth embodiment, according to the method of the fifteenth embodiment, wherein the conditions include: (i) buffering data for the other service flow in the service flow, (ii) the buffered data for the other service flow in the service flow has a remaining time below a threshold, or (iii) the buffered data for the other service flow in the service flow is discarded.

[0106] In the twenty-first embodiment, according to the method of the first embodiment, generating the data unit includes: selecting a service flow in the service flow of the modality group, and determining whether a condition related to another service flow in the service flow of the modality group is met.

[0107] In the twenty-second embodiment, according to the method of the twenty-first embodiment, generating the data unit when the condition is not met includes processing data from one of the service flows to include in the data unit.

[0108] In the twenty-third embodiment, according to the method of the twenty-first embodiment, generating the data unit when the condition is met includes: processing data from one of the service flows to include in the data unit, and processing data from the other service flow to include in the data unit.

[0109] In the twenty-fourth embodiment, according to the method of the twenty-third embodiment, data from the other IP stream in the IP stream is processed when the default setting of another IP stream in the IP stream indicates that the data is not allowed to use the UL permission.

[0110] In the twenty-fifth embodiment, according to the method of the twenty-third embodiment, data from the other IP stream is processed when the variable associated with the other IP stream in the IP stream is not greater than 0.

[0111] In the twenty-sixth embodiment, according to the method of the first embodiment, the data unit is a Media Access Control (MAC) Protocol Data Unit (PDU).

[0112] In the twenty-seventh embodiment, a processor is configured to perform any of the methods described according to the first to twenty-sixth embodiments.

[0113] In the twenty-eighth embodiment, a user equipment includes a transceiver configured to communicate with a network and a processor communicatively coupled to the transceiver and configured to perform any of the methods described in the first to twenty-sixth embodiments.

[0114] In a twenty-ninth embodiment, a method is performed by a base station, the method comprising: configuring transceiver circuitry to transmit to a user equipment (UE) a UL grant including an indication of uplink (UL) radio resources and a mode group, wherein the mode group includes one or more traffic flows, wherein the traffic flows include one of a Quality of Service (QoS) flow, a Logical Channel (LCH), or a Data Radio Bearer (DRB); and decoding data units generated from data from the traffic flows included in the mode group from signals received from the UE on the UL radio resources.

[0115] In the thirtieth embodiment, according to the method of the twenty-ninth embodiment, wherein the UL grant includes dynamic grant, wherein the indication of the mode group includes an explicit indication of the mode group in downlink control information (DCI) associated with the dynamic grant.

[0116] In the thirty-first embodiment, according to the method of the twenty-ninth embodiment, the UL grant includes a configured grant, wherein the indication of the modality group includes an explicit indication of the modality group in a configuration information element (IE) associated with the configured grant.

[0117] In the thirty-second embodiment, according to the method of the twenty-ninth embodiment, the UL grant includes dynamic grant, wherein the indication of the mode group includes an implicit indication of the mode group based on parameters in the downlink control information (DCI) associated with the dynamic grant.

[0118] In the thirty-third embodiment, according to the method of the twenty-ninth embodiment, wherein the UL grant includes a configured grant, wherein the indication to the modal group includes an implicit indication to the modal group based on parameters in a configuration information element (IE) associated with the configured grant.

[0119] In the thirty-fourth embodiment, according to the method of the twenty-ninth embodiment, the method further includes receiving a signaling decoding indication message from the core network corresponding to the service flow of the multimodal service identifier, wherein the service flow corresponding to the multimodal service identifier will be synchronized in the uplink transmission.

[0120] In the thirty-fifth embodiment, according to the method of the thirty-fourth embodiment, the message further includes a priority level associated with the multimodal service identifier.

[0121] In the thirty-sixth embodiment, according to the method of the thirty-fifth embodiment, the method further includes: grouping the QoS flow of the service flow corresponding to the multimodal service identifier into the modal group, wherein the modal group includes a modal group identifier; and configuring transceiver circuitry to transmit an indication of the QoS flow of the modal group.

[0122] In the thirty-seventh embodiment, according to the method of the thirty-fifth embodiment, the method further includes: grouping the DRB of the service flow corresponding to the multimodal service identifier into the modal group, wherein the modal group includes a modal group identifier; and configuring transceiver circuitry to transmit an indication of the DRB of the modal group.

[0123] In the thirty-eighth embodiment, according to the method of the thirty-fifth embodiment, the method further includes: grouping the LCH of the service flow corresponding to the multimodal service identifier into the modal group, wherein the modal group includes a modal group identifier; and configuring transceiver circuitry to send an indication of the LCH of the modal group.

[0124] In the thirty-ninth embodiment, according to the method of the twenty-ninth embodiment, the data unit is a Media Access Control (MAC) Protocol Data Unit (PDU).

[0125] In the fortieth embodiment, a processor is configured to perform any of the methods described according to the twenty-ninth to thirty-ninth embodiments.

[0126] In the forty-first embodiment, a base station includes a transceiver configured to communicate with user equipment and a processor communicatively coupled to the transceiver and configured to perform any of the methods described according to the twenty-ninth to thirty-ninth embodiments.

[0127] Those skilled in the art will understand that the exemplary embodiments described above can be implemented with any suitable software or hardware configuration or combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, and mobile devices with operating systems such as iOS, Android, etc. Exemplary embodiments of the methods described above may be embodied as programs containing lines of code stored on a non-transitory computer-readable storage medium, which, when compiled, can be executed on a processor or microprocessor.

[0128] Although this application describes various embodiments that have different features in various combinations, those skilled in the art will understand that any feature of one embodiment can be combined with features of other embodiments in any way that is not expressly denied or that is not functionally or logically inconsistent with the operation of the device or the specified function of the disclosed embodiment.

[0129] As is widely recognized, the use of personally identifiable information should comply with privacy policies and measures that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of permitted use should be clearly explained to users.

[0130] It will be apparent to those skilled in the art that various modifications can be made to this disclosure without departing from its spirit or scope. Therefore, this disclosure is intended to cover modifications and variations thereof, provided they fall within the scope of the appended claims and their equivalents.

Claims

1. An apparatus for a user equipment (UE), the apparatus comprising processing circuitry configured to: Decoding signaling received from the base station includes UL authorization for indications of uplink (UL) radio resources and mode groups; Data units are generated based on data from multiple service flows corresponding to the modality group, wherein the IP flows include one of Quality of Service (QoS) flows, Logical Channel (LCH) flows, or Data Radio Bearer (DRB) flows; and The transceiver circuitry is configured to use the UL radio resources to transmit the data unit.

2. The apparatus of claim 1, wherein the UL grant includes dynamic grant, wherein the indication of the mode group includes an explicit indication of the mode group in downlink control information (DCI) associated with the dynamic grant.

3. The apparatus of claim 1, wherein the UL grant includes a configured grant, wherein the indication of the modal group includes an explicit indication of the modal group in a configuration information element (IE) associated with the configured grant.

4. The apparatus of claim 1, wherein the UL grant includes dynamic grant, wherein the indication of the mode group includes an implicit indication of the mode group based on parameters in downlink control information (DCI) associated with the dynamic grant.

5. The apparatus of claim 1, wherein the UL grant includes a configured grant, wherein the indication to the modal group includes, wherein the indication to the modal group includes an implicit indication to the modal group based on parameters in a configuration information element (IE) associated with the configured grant.

6. The apparatus of claim 1, wherein only data from the service flow corresponding to the mode group is included in the data unit.

7. The apparatus of claim 1, wherein data from the service flow corresponding to the modality group is preferentially included in the data unit, wherein when data from the service flow corresponding to the modality group does not fill the data unit, data from other service flows is included in the data unit.

8. The apparatus of claim 1, wherein buffer delay information for each IP stream in the IP stream is used to generate the data unit.

9. The apparatus of claim 1, wherein when the UL grants indication of the mode group, the LCP setting for each LCH is ignored.

10. The apparatus of claim 1, wherein the processing circuit is further configured to: Decode a second UL grant from signaling received from the base station, wherein the second UL grant does not include an indication of a mode group, and wherein the UE uses the UL grant in priority over the second UL grant for data unit generation.

11. The apparatus of claim 1, wherein the processing circuit is further configured to: Decoding the signaling received from the base station includes a second UL grant for an indication of a second mode group, wherein the UE grants the UL grant or the second UL grant preferentially for data unit generation based on the priority level of the mode group and a second priority level of the second mode group.

12. The apparatus of claim 1, wherein the processing circuit is further configured to: The signaling decoding instruction received from the core network indicates the service flow corresponding to the multimodal service identifier, wherein the service flow corresponding to the multimodal service identifier will be synchronized during uplink transmission.

13. The apparatus of claim 12, wherein the message further includes a priority level associated with the multimodal service identifier.

14. The apparatus of claim 1, wherein the processing circuit is further configured to: The signaling received from the base station is decoded to indicate the QoS stream, LCH, or DRB corresponding to the mode group.

15. The apparatus of claim 1, wherein, in order to generate the data unit, the processing circuit is configured to: Select data from one of the service flows in the modal group; and Determine whether the conditions associated with another service flow in the service flow of the modality group are met.

16. The apparatus according to claim 15, wherein, When the conditions are not met, in order to generate the data unit, the processing circuit is configured as follows: The data from one of the service flows is processed to be included in the data unit.

17. The apparatus according to claim 15, wherein, When the aforementioned conditions are met, in order to generate the data unit, the processing circuit is configured as follows: Change the settings associated with one of the service flows in the service flow; and The data is processed based on the changed settings of one of the business flows in the business flow.

18. The apparatus of claim 17, wherein the settings include logical channel (LCH) priority, priority bit rate (PBR), or LCH mapping limitation.

19. The apparatus of claim 17, wherein processing the data based on the altered settings includes autonomously activating the replication of the data, discarding a buffered packet of the data before the discard timer expires, or changing the timer value of the discard timer.

20. An apparatus for a base station, the apparatus comprising processing circuitry configured to: The transceiver circuitry is configured to send a UL grant to the user equipment (UE) including an indication of uplink (UL) radio resources and a mode group, wherein the mode group includes one or more traffic flows, wherein the traffic flows include one of a Quality of Service (QoS) flow, a Logical Channel (LCH), or a Data Radio Bearer (DRB); and Data units generated from data of service flows included in the mode group are decoded from signals received from the UE on the UL radio resources.

Images