Configuration and authorization adjustments

Abstract

A user equipment (UE) is configured to: establish a packet data unit (PDU) session with a network, wherein the PDU session includes a quality of service (QoS) stream; receive one or more radio resource control (RRC) messages indicating a configuration grant (CG) assigned to the UE, wherein the QoS stream is mapped to a logical channel (LCH) and wherein the LCH is mapped to the CG; and transmit data on a physical uplink shared channel (PUSCH) using the time and frequency resources of the CG.

Description

Technical Field

[0001] This application generally relates to wireless communication, and specifically to configuration authorization adjustments. Background Technology

[0002] Networks can allocate resources in various ways, including but not limited to allocation based on Configuration Grant (CG) and Dynamic Grant (DG). Under normal circumstances, a User Equipment (UE) can request a DG even when it has already been allocated CG resources. For example, a UE can be configured to use resources allocated to the UE via a set of CGs to transmit data generated by a specific application running on the UE through the Physical Uplink Shared Channel (PUSCH). If the CG is insufficient for the data generated by the application, the UE can send a request for a DG to the network. However, it is possible that the UE receives a DG, but that DG is not suitable for the processing timeline required by the application's Quality of Service (QoS). If the DG does not arrive in time, it is not utilized, and therefore, the use of UE and network resources is inefficient. Summary of the Invention

[0003] Some exemplary embodiments relate to a processor of a user equipment (UE) configured to perform operations. These operations include: establishing a Packet Data Unit (PDU) session with a network, wherein the PDU session includes a Quality of Service (QoS) stream; receiving one or more Radio Resource Control (RRC) messages indicating a Configuration Grant (CG) assigned to the UE, wherein the QoS stream is mapped to a Logical Channel (LCH), and wherein the LCH is mapped to the CG; and transmitting data on a Physical Uplink Shared Channel (PUSCH) using the time and frequency resources of the CG.

[0004] Other exemplary embodiments relate to a processor of a base station configured to perform operations. These operations include: establishing a connection with a user equipment (UE), wherein the UE is configured with a packet data unit (PDU) session, the PDU session including a quality of service (QoS) stream; transmitting one or more radio resource control (RRC) messages indicating a configuration grant (CG) assigned to the UE, wherein the QoS stream is mapped to a logical channel (LCH), and wherein the LCH is mapped to the CG; and receiving data transmitted by the UE using time and frequency resources of the CG on a physical uplink shared channel (PUSCH). Attached Figure Description

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

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

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

[0008] Figure 4 Signaling diagrams illustrating configuration-based authorization (CG) allocations according to various exemplary embodiments are shown.

[0009] Figure 5 Methods for adjusting CG according to various exemplary embodiments are shown.

[0010] Figure 6a An exemplary mapping is shown, in which multiple Quality of Service (QoS) flows are each mapped to a different Logical Channel (LCH) according to various exemplary implementations.

[0011] Figure 6b An exemplary mapping is shown, in which multiple QoS flows are each mapped to the same LCH according to various exemplary implementations.

[0012] Figure 7 A table showing index values ​​and corresponding recommended bit rate values ​​according to various exemplary implementations is presented. Detailed Implementation

[0013] The exemplary embodiments can be further understood with reference to the following description and related figures, wherein similar elements have the same reference numerals. The exemplary embodiments introduce techniques for adjusting the timing of configuration authorization (CG).

[0014] Exemplary embodiments are described with reference to user equipment (UE). However, the reference to the term "UE" is provided for illustrative purposes only. Exemplary embodiments can be used with any electronic component configured with hardware, software, and / or firmware for exchanging information (e.g., control information) and / or data with a network. Therefore, the UE described herein is used to represent any suitable electronic device.

[0015] Exemplary implementations are also described with reference to Quality of Service (QoS). Those skilled in the art will understand that QoS refers to a quantitative measure of the overall performance of a service experienced by a user of the network. In fifth-generation (5G) New Radio (NR), QoS is enforced at the QoS flow level. Each QoS flow can be identified by a QoS Flow Identifier (QFI) and corresponds to a Packet Data Unit (PDU) session. For example, network services such as, but not limited to, Extended Reality (XR) can utilize multiple QoS flows in the uplink and / or downlink. However, the reference to the term "QoS flow" is provided merely for illustrative purposes. Different entities may refer to similar concepts using different terms (e.g., flow, data stream, etc.).

[0016] Furthermore, exemplary embodiments are described with reference to logical channels (LCHs). Those skilled in the art will understand that an LCH is defined by the type of information it is configured to carry and can be further characterized as a control channel or a traffic channel. However, exemplary embodiments are not limited to any particular type of LCH and are applicable to any suitable type of LCH.

[0017] Exemplary embodiments are also described with reference to CG-based allocation. Those skilled in the art will understand that a CG generally refers to a set of resources allocated by the network to a UE for transmission on the Physical Uplink Shared Channel (PUSCH). A CG may be further characterized by type, such as Type 1, Type 2, etc. A Type 1 CG may refer to a set of time and frequency resources configured and activated using Radio Resource Control (RRC) signaling. A Type 2 CG may refer to a set of time and frequency resources configured by RRC but activated using Physical Downlink Control Channel (PDCCH) signaling. However, any reference to a particular type of CG is provided for illustrative purposes only. Exemplary embodiments can be applied to any type of CG or similar resource allocation mechanism.

[0018] Applications running on the UE can generate data for one or more QoS flows. Multiple QoS flows can be mapped to different LCHs or the same LCH. In 3GPP Release 16 (Rel-16), multiple CGs and / or LCHs can be configured and activated simultaneously. LCH-CG mapping can be implemented as a 1:N mapping or an N:1 mapping, for example, multiple LCHs mapped to a single CG or vice versa. During operation, if a conflict occurs between dynamic grant and CG, the UE selects either dynamic grant or CG for uplink transmission based on the corresponding LCH priority.

[0019] As indicated above, data generated by an application running on the UE can be mapped to one or more QoS flows, each QoS flow can be mapped to one or more LCHs, and each LCH can be mapped to one or more CGs. Throughout this specification, each QoS flow may be numbered (e.g., QoS flow 1, QoS flow 2, etc.) to distinguish it. Similarly, each LCH and CG may be numbered (e.g., LCH 1, LCH 2, CG 1, CG 2, etc.). The numbering of these components is not intended to indicate any preference for components of the same type, nor is it intended to indicate the relationship between components of different types. For example, neither is it required that QoS flow 1 take precedence over QoS flow 2, nor is it required that QoS flow 1 be mapped to LCH 1 and / or CG 1. Rather, any reference to a numbered QoS flow is only intended to distinguish QoS flows, any reference to a numbered LCH is only intended to distinguish LCHs, and any reference to a numbered CG is only intended to distinguish CGs.

[0020] The network can also utilize dynamic grant (DG)-based allocation. For example, a base station may allocate resources to a UE for PUSCH transmission in response to a buffer status report (BSR) (e.g., a scheduling request). The DG may be indicated to the UE via downlink control information (DCI) or any other appropriate means.

[0021] Under normal circumstances, even if a UE has already been allocated CG resources, it can still request DG. For example, a UE can be configured to use resources allocated to the UE via a set of CGs to transmit data generated by an application running on the UE through the Physical Uplink Shared Channel (PUSCH). If the CGs are insufficient to process the application-generated data, the UE can transmit a BSR (Browser Request) for DG resources to the network. However, it is possible that the UE receives a DG, but the DG is not compatible with the processing timeline of the application's QoS requirements. When the DG does not arrive in time, it is not utilized. Therefore, resources used on both the UE and network sides for requesting, configuring, and transmitting DGs are wasted because the UE does not actually utilize the DG resources.

[0022] As will be described in more detail below, exemplary embodiments introduce techniques for adjusting the timing of the CG. These exemplary techniques allow the UE and network to avoid inefficient use of the DG as in the scenario described above. However, the exemplary techniques used to replace the use of the DG are not required, and the techniques can provide benefits to any CG-based allocation mechanism. Exemplary embodiments can be used in conjunction with currently implemented CG mechanisms, in conjunction with future specific implementations of CG mechanisms, or independently of other CG mechanisms. Specific examples of each of the exemplary techniques are provided in detail below.

[0023] Figure 1An 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, desktop computer, smartphone, phablet, embedded device, wearable device, 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, for illustrative purposes, only an example with a single UE 110 is provided.

[0024] UE 110 can be configured to communicate with one or more networks. In the example of network configuration 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, WLAN, etc.), and UE 110 can also communicate with the network via a wired connection. Regarding an exemplary implementation, UE 110 can establish a connection with 5G NR RAN 120. Therefore, UE 110 may have a 5G NR chipset to communicate with 5G NR RAN 120.

[0025] 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, nodes, cells, or base stations (e.g., Node B, eNodeB, HeNB, eNB, gNB, gNodeB, macrocell base station, microcell base station, small cell base station, femtocell base station, etc.) configured to send and receive communication services from UEs equipped with appropriate cellular chipsets.

[0026] Those skilled in the art will understand that any relevant procedures can be performed for UE 110 to connect to 5G NR-RAN 120. For example, as described above, 5G NR-RAN 120 can be associated with a specific cellular provider, at which 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 transmit the corresponding credential information to associate with 5G NR-RAN 120. More specifically, for example, UE 110 can be associated with a specific base station (e.g., Next Generation Node B (gNB) 120A).

[0027] 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 an interconnected set of components that manage the operation and traffic of the cellular network. It may include an evolved packet core (EPC) and / or a 5G core (5GC). The cellular core network 130 also manages the 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 to communicate with various networks.

[0028] 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 sources, data acquisition devices, ports for electrically connecting UE 110 to other electronic devices, etc.

[0029] Processor 205 can be configured to execute multiple engines of UE 110. For example, the engines may include CG adjustment engine 235 and recommended bit rate engine 240. CG adjustment engine 235 can perform various operations related to adjusting the timing of CG, such as, but not limited to, identifying misalignment between the timing of data generated for QoS flows and the corresponding CG, providing the network with information indicating how to adjust the CG, and adjusting the CG configuration. Recommended bit rate engine 240 can perform various operations related to applying a recommended bit rate to QoS flows.

[0030] The engines 235 and 240 described above, as applications (e.g., programs) executed by processor 205, are provided for illustrative purposes only. The functionality associated with engines 235 and 240 may also be represented as separate integrated components of UE 110, or as modular components coupled to UE 110, such as integrated circuits 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 engines may also be embodied as a single application or multiple separate applications. Furthermore, in some UEs, the functionality described for processor 205 is distributed 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.

[0031] 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 user input. Display device 215 and I / O device 220 may be separate components or may be integrated together (such as a touchscreen). Transceiver 225 may be a hardware component configured to establish connections with 5G NR-RAN 120, LTE-RAN (not shown), legacy RAN (not shown), WLAN (not shown), etc. Therefore, transceiver 225 may operate on multiple different frequencies or channels (e.g., a set of consecutive frequencies).

[0032] Figure 3 An exemplary base station 300 according to various exemplary embodiments is shown. Base station 300 may represent a gNB 120A or any other type of access node that UE 110 can use to establish connections and manage network operations.

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

[0034] Processor 305 may be configured to execute multiple engines of base station 105. For example, the engines may include CG adjustment engine 330 and recommended bit rate engine 335. CG adjustment engine 330 may perform various operations related to adjusting the timing of the CG, such as, but not limited to, receiving information from UE 110 indicating that the timing of the CG should be adjusted to better align with the timing of QoS processing requirements, and adjusting the CG configuration of UE 110. Recommended bit rate engine 335 sends a recommended bit rate for the QoS flow to UE 110.

[0035] The engines 330 and 335 described above, as applications (e.g., programs) executed by processor 305, are merely exemplary. The functions associated with engines 330 and 335 may also be represented as separate integrated components of base station 300, or as modular components coupled to base station 300, such as integrated circuits 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 functions described for processor 305 are 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.

[0036] Memory arrangement 310 may be a hardware component configured to store data related to operations performed by base station 300. I / O device 315 may be a hardware component or port enabling a user to interact with base station 105. 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 set of consecutive frequencies). Therefore, transceiver 320 may include one or more components (e.g., radio components) to enable data exchange with various networks and UEs.

[0037] Figure 4 Signaling diagram 400 illustrating CG-based allocation according to various exemplary embodiments is shown. Signaling diagram 400 includes UE 110 and gNB 120A of network arrangement 100. Signaling diagram 400 is provided as a general example of CG-based allocation. However, the manner in which the CG is configured at UE 110 is beyond the scope of the exemplary embodiments. Instead, the exemplary embodiments involve adjusting the timing of the CG. The exemplary techniques described herein for adjusting the CG can be applied to CGs that have already been configured in any suitable manner.

[0038] In step 410, a PDU session is established between UE 110 and the 5G NR network. In step 415, UE 110 transmits QoS configuration information to gNB120A. For example, the QoS configuration information may include the 5G QoS identifier (5QI), QoS flow identifier (QFI), logical channel ID (LCID), etc.

[0039] In step 420, the gNB 120A transmits one or more RRC messages to configure the UE 110 with a CG for a specific QoS flow. For example, the gNB 120A may utilize the QoS configuration information received in step 415 to establish a CG profile by converting 5QI information into Logical Channel Groups (LCGs). The RRC message may establish a Dedicated Radio Bearer (DRB) for the QoS flow, the DRB having features such as, but not limited to, one or more LCGs, Packet Data Convergence Protocol (PDCP) replication, Modulation and Coding Scheme (MCS) tables, and Channel State Reports with Block Error Rate (BLER).

[0040] The network assigns CGs 425 to 428 to UE 110 for QoS flows. Therefore, UE 110 is configured to perform PUSCH transmissions using the time and frequency resources represented by CGs 425 to 428. The reference to the four CGs is provided for illustrative purposes only. In actual QoS flow configurations, the duration of the QoS flow can vary, and any appropriate number of CGs can be configured.

[0041] There may be scenarios where the CG (Current Access Request) is insufficient for the amount and / or type of data to be transmitted according to applicable QoS requirements. Under normal circumstances, UE 110 transmits a BSR (Background Request) to request DG (Data Transfer Request) to meet its data requirements. Alternatively, when the network determines that UE 110 is likely to require additional uplink resources to meet its data requirements, the network may proactively provide DG to UE 110. Regardless of the method, it has been identified that in real-world scenarios, DG is wasted because it is not provided at the appropriate time.

[0042] To provide an example within the context of signaling diagram 400, UE 110 may transmit BSR 450 to gNB 120A. If DG 455 is allocated at time 456, UE 110 can utilize DG for PUSCH transmission. However, if DG 455 is allocated at time 457, UE 110 may not be able to use DG 455 because it is not compatible with the processing timeline required by QoS. Therefore, in this type of scenario, the processing and power resources that UE 110 uses to transmit BSR 450 and receive DG 455 are wasted because DG 455 is not actually used for PUSCH transmission. Even if DG 455 is allocated at the appropriate time (e.g., time 456), the request / authorization mechanism introduces latency and places an additional burden on the processing capacity of gNB 120A and the 5G NR network (especially in multi-UE scenarios). As will be described in detail below, the exemplary implementation introduces techniques for adjusting the timing of CG to accommodate the data generation of the QoS stream.

[0043] Figure 5A method 500 for adjusting a CG according to various exemplary embodiments is shown. The method 500 is described from the perspective of the UE 110.

[0044] Method 500 involves mapping between one or more QoS flows, one or more LCHs, and one or more CGs. Before discussing exemplary techniques, Figures 6a to 6b Examples of different mappings are shown. However, the exemplary implementation is not limited to any particular QoS flow to LCH mapping or any particular LCH to CG mapping. The exemplary implementation can be applied to any appropriate mapping between QoS flows, LCH, and CG.

[0045] Figure 6a An exemplary mapping is shown where multiple QoS flows are each mapped to a different LCH. Here, application 605 running on UE 110 is configured with three QoS flows 1 to 3, each QoS flow mapped to a different LCH 1 to 3. Each LCH 1 to 3 can be mapped to a different CG 1 to 3. In other configurations where multiple QoS flows are mapped to multiple LCHs, each LCH can be mapped to the same CG; for example, LCH 1 to 3 can all be mapped to the same CG.

[0046] In this example, the data generated for each QoS stream 1 to 3 is not time-aligned with its corresponding CG 1 to 3. The misaligned timing of CG 1 and the data generated for QoS stream 1 are shown by timeline 610, the misaligned timing of CG 2 and the data generated for QoS stream 2 are shown by timeline 620, and the misaligned timing of CG 3 and the data generated for QoS stream 3 are shown by timeline 630. As described in more detail below with reference to method 510, in some embodiments, UE 110 may provide gNB 120A with an offset of 640 to 660, which indicates that the timing of CG 1 to 3 should be adjusted to align with the timing of QoS streams 1 to 3.

[0047] Figure 6b An exemplary mapping is shown where multiple QoS flows are each mapped to the same LCH. Here, application 605 running on UE 110 is configured with three QoS flows 1 to 3, each mapped to the same LCH 1. In this example, LCH 1 is mapped to CG 1. In other configurations where multiple QoS flows are mapped to the same LCH, the LCH may be mapped to multiple different CGs. Although Figure 6b It is not shown in the figure, but the data generated for one or more QoS flows in the QoS flow may not be time-aligned with the timing of CG 1.

[0048] Return to Figure 5In method 500, and in method 505, UE 110 identifies that data generated for one or more QoS flows is not time-aligned with the corresponding CG. An example of this situation is provided by... Figure 6a The timeline from 610 to 630 is shown.

[0049] In 510, UE 110 transmits CG adjustment information to gNB 120A. CG adjustment information may be provided as a Media Access Control (MAC) control element (CE), an information element (IE) in an RRC message, or in any other suitable manner.

[0050] As will be described below, CG adjustment information can indicate to the gNB 120A that adjustments to CG timing may be beneficial to QoS flows. For example, timing adjustments can allow the UE 110 and the network to avoid immediately following CG requests and DG configuration.

[0051] In some implementations, CG adjustment information may include an indication of a recommended CG allocation based on the timing of data generated for the QoS flow. This recommended allocation may trigger a change in the start symbol if the current start symbol, indicated by the "timeDomainAllocation" parameter, requires alignment. Those skilled in the art will understand that the "timeDomainAllocation" parameter is part of the "rrc-ConfiguredUplinkGrant" message and indicates a combination of start symbol, length, and PUSCH mapping type. Therefore, information provided by UE 110 can replace the configured integer value of the "timeDomainAllocation" parameter.

[0052] In some implementations, CG adjustment information may include an indication of a recommended time-domain offset based on the timing of data generated for the QoS stream. This recommended time-domain offset corresponding to the reference subframe number (SFN) may be indicated by the "timeDomainOffset" parameter. Those skilled in the art will understand that the "timeDomainOffset" parameter is part of the "rrc-ConfiguredUplinkGrant" message and indicates the offset associated with the reference SFN indicated by the parameter "timeReferenceSFN" in the same RRC message. Therefore, the information provided by UE 110 may replace the configured integer value of the "timeDomainOffset" parameter.

[0053] CG adjustment information can also be called UE auxiliary information. UE auxiliary information may correspond to a specific QoS flow and include information such as, but not limited to, flow ID (e.g., QFI), periodicity, minimum packet size, maximum packet size, and timing offset value aligned with the CG.

[0054] In 515, UE 110 transmits on the PUSCH using the adjusted CG timing. In some implementations, UE 110 may receive an explicit indication from gNB 120A that the CG has been adjusted based on information provided by UE 110. In other implementations, UE 110 may implicitly determine that the network has adjusted the CG based on information provided by UE 110.

[0055] On the other hand, exemplary embodiments introduce recommended bitrate parameters adapted to XR services. Those skilled in the art will understand that XR is an umbrella term for different types of reality and can generally refer 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). However, any references to XR specific to a particular traffic use case or type are provided for illustrative purposes only.

[0056] Those skilled in the art will understand that the recommended bit rate parameter is a parameter signaled by gNB 120A to UE 110, indicating the recommended bit rate in the uplink and / or downlink. Within the context of signaling diagram 400, this parameter may be provided to UE 110 before or during the allocation of CGs 425 to 428.

[0057] In one approach, a recommended bitrate parameter can be signaled to the UE 110, indicating the recommended bitrate for the QoS flow of an XR application or any other type of application that generates periodically consistent data patterns. For XR services, it may be beneficial to increase the maximum possible bitrate value from the conventional 8000 kilobytes per second (kb / s). For example, the maximum recommended bitrate that can be signaled by the recommended bitrate parameter could be 20 megabytes per second (Mb / s), 1 gigabyte per second (Gb / s), 2 Gb / s, etc. However, references to these values ​​are provided as examples, and exemplary embodiments are not limited to any particular maximum bitrate value.

[0058] In another approach, the recommended bit rate concept can be applied at the QoS flow level. In one option, the MAC CE can be configured to indicate at the QoS flow level. In some implementations, QFI can be used instead of LCID. This allows UE 110 to apply the recommended bit rate at the QoS level rather than the LCH level. In another implementation, a combination of the LCI and QoS flow ID bitmap can be used in conjunction with a bit rate list. This allows UE 110 to apply the recommended bit rate at the QoS level when there are multiple QoS flows to manage.

[0059] In some implementations, the MAC CE may include an index value mapped to the recommended NR bit rate value, as specified in Table 6.1.3.20-1 of 3GPP TS38.321. Currently, index values ​​57 to 63 are reserved. Exemplary implementations introduce values ​​for these reserved fields to accommodate XR services or any other suitable type of service generated in a periodic and consistent manner. As indicated above, the current maximum value of 8000kb / s may not be suitable for XR services.

[0060] Figure 7 Table 700, which includes index values ​​and corresponding recommended bit rate values, is shown. In this example, these index values ​​57 to 63 are no longer retained and have been updated to rates up to 2 Gb / s. In some implementations, a multiplication factor may be implemented to exceed 2 Gb / s in order to exceed the recommended bit rate in the table.

[0061] In another option, the recommended bit rate can be indicated by the Data Adaptation Protocol (SDAP) control PDU. For example, the end-mark control PDU can be configured to include the QFI and the bit rate.

[0062] Example

[0063] In a first embodiment, a user equipment (UE) includes: a transceiver configured to communicate with a network; and a processor communicatively coupled to the transceiver and configured to perform operations including: establishing a packet data unit (PDU) session with the network, wherein the PDU session includes a quality of service (QoS) stream; receiving one or more radio resource control (RRC) messages indicating a configuration grant (CG) allocated to the UE, wherein the QoS stream is mapped to a logical channel (LCH) and wherein the LCH is mapped to the CG; and transmitting data on a physical uplink shared channel (PUSCH) using the time and frequency resources of the CG.

[0064] In the second embodiment, the UE of the first embodiment further includes: identifying that data generated by an application running on the UE for the QoS stream is not time-aligned with the time resource of the CG; and transmitting CG adjustment information to the network, wherein the CG adjustment information is configured to cause the network to adjust the time resource of the CG.

[0065] In the third embodiment, the UE of the second embodiment, wherein the CG adjustment information includes a recommended allocation that triggers a change in the start symbol previously indicated to the UE via time-domain allocation parameters.

[0066] In the fourth embodiment, the UE of the third embodiment, wherein the recommended allocation is provided via a Media Access Control (MAC) control element (CE).

[0067] In the fifth embodiment, the UE of the third embodiment, wherein the recommended allocation is provided via an information element (IE) in an RRC message.

[0068] In the sixth embodiment, the UE of the second embodiment, wherein the CG adjustment information includes a recommended time-domain offset, which corresponds to the reference subframe number (SFN) previously indicated to the UE by the time reference SFN parameter.

[0069] In the seventh embodiment, the UE of the sixth embodiment, wherein the recommended time-domain offset is provided via a Media Access Control (MAC) control element (CE).

[0070] In the eighth embodiment, the UE of the sixth embodiment, wherein the recommended time-domain offset is provided via an information element (IE) in the RRC message.

[0071] In the ninth embodiment, the UE of the second embodiment, wherein the CG adjustment information includes at least one of QoS Flow ID (QFI), periodicity, minimum packet size, maximum packet size, and timing offset value aligned with the CG.

[0072] In the tenth embodiment, the UE of the first embodiment further includes receiving a recommended bit rate from the network to be applied to the QoS flow.

[0073] In the eleventh embodiment, the UE of the tenth embodiment, wherein the QoS stream is associated with an extended reality (XR) application.

[0074] In the twelfth embodiment, the UE of the tenth embodiment, wherein the recommended bit rate is greater than 8000 kilobytes per second (kb / s).

[0075] In the thirteenth embodiment, the UE of the tenth embodiment, wherein the recommended bit rate is provided in a media access control (MAC) control element (CE) configured to indicate the bit rate per QoS stream.

[0076] In the fourteenth embodiment, the UE of the thirteenth embodiment includes a QoS Flow Identifier (QFI) but does not include a Logical Channel ID (LCID).

[0077] In the fifteenth embodiment, the UE of the thirteenth embodiment includes a QoS flow ID bitmap in the MAC CE.

[0078] In the sixteenth embodiment, the UE of the tenth embodiment, wherein the recommended bit rate is provided in the Service Data Application Protocol (SDAP) control PDU.

[0079] In a seventeenth embodiment, a base station includes: a transceiver configured to communicate with a user equipment (UE); and a processor communicatively coupled to the transceiver and configured to perform operations including: establishing a connection with the UE, wherein the UE is configured with a packet data unit (PDU) session, the PDU session including a quality of service (QoS) stream; transmitting one or more radio resource control (RRC) messages indicating a configuration grant (CG) assigned to the UE, wherein the QoS stream is mapped to a logical channel (LCH), and wherein the LCH is mapped to the CG; and receiving data transmitted by the UE using time and frequency resources of the CG on a physical uplink shared channel (PUSCH).

[0080] In the eighteenth embodiment, the base station of the seventeenth embodiment further includes receiving CG adjustment information from the UE, wherein the CG adjustment information is configured to cause the base station to adjust the time resource of the CG.

[0081] In the nineteenth embodiment, the base station of the eighteenth embodiment, wherein the CG adjustment information includes a recommended allocation that triggers a change in the start symbol previously indicated to the UE via time-domain allocation parameters.

[0082] In the twentieth embodiment, the base station of the eighteenth embodiment, wherein the CG adjustment information includes a recommended time-domain offset, the recommended time-domain offset corresponding to the reference subframe number (SFN) previously indicated to the UE by the time reference SFN parameter.

[0083] In the twenty-first embodiment, the base station of the eighteenth embodiment, wherein the CG adjustment information includes at least one of QoS Flow ID (QFI), periodicity, minimum packet size, maximum packet size, and timing offset value aligned with the CG.

[0084] In the twenty-second embodiment, the base station of the seventeenth embodiment further includes transmitting a recommended bit rate to be applied to the QoS stream.

[0085] In the twenty-third embodiment, the base station of the twenty-second embodiment is used, wherein the QoS stream is associated with an extended reality (XR) application.

[0086] In the twenty-fourth embodiment, the base station of the twenty-second embodiment, wherein the recommended bit rate is greater than 8000 kilobytes per second (kb / s).

[0087] In the twenty-fifth embodiment, the base station of the twenty-second embodiment, wherein the recommended bit rate is provided in a Media Access Control (MAC) control element (CE) configured to indicate the bit rate per QoS stream.

[0088] In the twenty-sixth embodiment, the base station of the twenty-fifth embodiment, wherein the MAC CE includes a QoS Flow Identifier (QFI) and does not include a Logical Channel ID (LCID).

[0089] In the twenty-seventh embodiment, the base station of the twenty-fifth embodiment includes a QoS flow ID bitmap in the MAC CE.

[0090] In the twenty-eighth embodiment, the base station of the twenty-fifth embodiment, wherein the recommended bit rate is provided in the Service Data Application Protocol (SDAP) control PDU.

[0091] 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 comprising lines of code stored on a non-transitory computer-readable storage medium, which, at compile time, can be executed on a processor or microprocessor.

[0092] Although this patent application describes various combinations of various embodiments, each with different features, those skilled in the art will understand that any feature of an embodiment can be combined with features of other embodiments or features that are not functionally or logically inconsistent with the operation or function of the device of the disclosed embodiment of the invention in any manner not explicitly denied.

[0093] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices 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 authorized use should be clearly explained to users.

[0094] 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 all modifications and variations thereof, provided that such modifications and variations are within the scope of the appended claims and their equivalents.

Claims

1. A user equipment (UE) including a processor configured to perform operations, the operations including: Establish a Packet Data Unit (PDU) session with the network, wherein the PDU session includes a Quality of Service (QoS) stream; Receive one or more Radio Resource Control (RRC) messages indicating a Configuration Grant CG assigned to the UE, wherein the QoS flow is mapped to a Logical Channel (LCH), and wherein the LCH is mapped to the CG; Data is generated for transmission on the Physical Uplink Shared Channel (PUSCH) using the time and frequency resources of the CG; and UE assistance information corresponding to the QoS flow is generated and transmitted to the network, wherein the UE assistance information includes at least periodic information.

2. The UE according to claim 1, further comprising: It was identified that the data generated by the application running on the UE for the QoS stream was not time-aligned with the time resources of the CG; as well as Transmit CG adjustment information to the network, wherein the CG adjustment information is configured to cause the network to adjust the time resources of the CG.

3. The UE of claim 2, wherein the CG adjustment information includes a recommended allocation that triggers a change in the start symbol previously indicated to the UE via a time-domain allocation parameter.

4. The UE of claim 3, wherein the recommended allocation is provided via a Media Access Control (MAC) control element (CE).

5. The UE of claim 3, wherein the recommended allocation is provided via an information element (IE) in an RRC message.

6. The UE of claim 2, wherein the CG adjustment information includes a recommended time-domain offset, the recommended time-domain offset corresponding to a reference subframe number SFN previously indicated to the UE via a time reference SFN parameter.

7. The UE of claim 6, wherein the recommended time-domain offset is provided via a Media Access Control (MAC) control element (CE).

8. The UE of claim 6, wherein the recommended time-domain offset is provided via an information element (IE) in an RRC message.

9. The UE of claim 2, wherein the CG adjustment information includes at least one of QoS Flow ID (QFI), periodicity, minimum packet size, maximum packet size, and timing offset value aligned with the CG.

10. The UE according to claim 1, further comprising: Receive the recommended bit rate to be applied to the QoS flow from the network.

11. The UE of claim 10, wherein the QoS flow is associated with an extended reality (XR) application.

12. The UE of claim 10, wherein the recommended bit rate is greater than 8000 kilobytes per second (kb / s).

13. The UE of claim 10, wherein the recommended bit rate is provided in a Media Access Control (MAC) control element (CE) configured to indicate the bit rate per QoS stream.

14. The UE of claim 13, wherein the MAC CE includes a QoS Flow Identifier (QFI) and does not include a Logical Channel ID (LCID).

15. The UE of claim 13, wherein the MAC CE includes a QoS flow ID bitmap.

16. The UE of claim 10, wherein the recommended bit rate is provided in the Service Data Application Protocol (SDAP) control PDU.

17. A base station, comprising a processor configured to perform operations, the operations including: Establish a connection with a user equipment (UE), wherein the UE is configured with a packet data unit (PDU) session including a quality of service (QoS) stream; Transmit one or more Radio Resource Control (RRC) messages that indicate the configuration grant CG assigned to the UE, wherein the QoS flow is mapped to the logical channel (LCH), and wherein the LCH is mapped to the CG; The UE receives data transmitted using the time and frequency resources of the CG on the Physical Uplink Shared Channel (PUSCH). as well as Receive UE assistance information corresponding to the QoS flow, wherein the UE assistance information includes at least periodic information.

18. The base station according to claim 17, further comprising: The UE receives CG adjustment information, wherein the CG adjustment information is configured to cause the base station to adjust the time resources of the CG.

19. The base station of claim 18, wherein the CG adjustment information includes a recommended allocation that triggers a change in the start symbol previously indicated to the UE via time-domain allocation parameters.

20. The base station of claim 18, wherein the CG adjustment information includes a recommended time-domain offset, the recommended time-domain offset corresponding to a reference subframe number SFN previously indicated to the UE via a time reference SFN parameter.

21. The base station of claim 18, wherein the CG adjustment information includes at least one of QoS Flow ID (QFI), periodicity, minimum packet size, maximum packet size, and timing offset value aligned with the CG.

22. The base station according to claim 17, further comprising: The transmission should be performed at the recommended bit rate for the QoS stream.

23. The base station of claim 22, wherein the QoS stream is associated with an extended reality (XR) application.

24. The base station according to claim 22, wherein the recommended bit rate is greater than 8000 kilobytes per second (kb / s).

25. The base station of claim 22, wherein the recommended bit rate is provided in a media access control (MAC) control element (CE) configured to indicate the bit rate per QoS stream.

26. The base station of claim 25, wherein the MAC CE includes a QoS Flow Identifier (QFI) and does not include a Logical Channel ID (LCID).

27. The base station of claim 25, wherein the MAC CE includes a QoS flow ID bitmap.

28. The base station of claim 25, wherein the recommended bit rate is provided in the Service Data Application Protocol (SDAP) control PDU.

Images