Subpackaging and configuration of logical channel id spaces for mac ce / sdu

Abstract

A medium access control (MAC) layer instance of a user equipment (UE) or a base station is configured to: determine to transmit a first MAC control element (MAC CE); constructing an MAC (Media Access Control) sub-protocol data unit (sub-PDU), wherein the MAC sub-PDU comprises an MAC sub-header and a payload comprising the first MAC CE; indicating, in the MAC sub-header, a logical channel identifier (LCID) value identifying a first set of MAC CEs classified based on a feature, the first set of MAC CEs including the first MAC CE; and mapping the MAC sub-PDU to a transport block (TB) for transmission on a physical (PHY) layer.

Description

Technical Field

[0001] The present disclosure relates to wireless communications, and in particular to sub-grouping and configuration of logical channel ID space for MAC CE / SDUs. Background Art

[0002] The medium access control (MAC) layer of the radio access network (RAN) protocol stack can send / receive MAC service data units (SDUs), MAC control elements (CEs) and / or padding in MAC sub-protocol data units (sub-PDUs). Each MAC sub-PDU includes a MAC sub-header indicating a logical channel identifier (LCID) value, which identifies a logical channel for a payload such as a MAC SDU or a MAC CE. The LCID field includes 6 bits and 64 LCID values ​​are established in the LCID space. In addition, an 8-bit or 16-bit extended LCID (eLCID) field can be added to the MAC sub-header to extend the LCID space. Generally speaking, less frequent and / or low-priority MAC CEs are assigned to LCID indexes in the eLCID space, while more frequent and / or high-priority MAC CEs are assigned to LCID indexes in the LCID space. Some traditional MAC CEs defined in earlier 3GPP versions are also defined in the LCID space. The mapping between LCID / eLCID code points and logical channels or MAC CEs is defined in 3GPP specification TS 38.321.

[0003] Many new MAC CEs have been introduced in recent 3GPP releases, and it is expected that the number of new MAC CEs will continue to increase in future releases of 5GNR (including Rel-17, Rel-18, etc.) and potentially in future wireless standards (e.g., 6G). In addition, more control functions may be moved from the radio resource control (RRC) domain to the MAC domain, requiring more new MAC CEs. The current LCID allocation framework may need to be modified or redesigned to accommodate these additional MAC CEs while ensuring performance. Summary of the invention

[0004] Some exemplary embodiments relate to a medium access control (MAC) layer instance configured to perform operations. The operations include: determining to send a first MAC control element (MAC CE); constructing a MAC sub-protocol data unit (sub-PDU), the MAC sub-protocol data unit (sub-PDU) including a MAC sub-header and a payload including the first MAC CE; indicating in the MAC sub-header a logical channel identifier (LCID) value identifying a first group of MAC CEs classified based on features, the first group of MAC CEs including the first MAC CE; and mapping the MAC sub-PDU to a transport block (TB) for transmission on a physical (PHY) layer.

[0005] Other exemplary embodiments relate to a medium access control (MAC) layer instance configured to perform operations. The operations include: determining to send a first MAC control element (MAC CE); constructing a MAC sub-protocol data unit (sub-PDU), the MAC sub-protocol data unit (sub-PDU) including a MAC sub-header and a payload including a first MAC CE; indicating a value of a reserved (R) bit in the MAC sub-header, the reserved (R) bit identifying a first logical channel identifier (LCID) table set or a second LCID table set for determining a logical channel or MAC CE identifier from an LCID value included in the MAC sub-header; and mapping the MAC sub-PDU to a transport block (TB) for transmission on a physical (PHY) layer.

[0006] Additional exemplary embodiments relate to a medium access control (MAC) layer instance configured to perform operations including: determining to send a first MAC control element (MAC CE); constructing a MAC sub-protocol data unit (sub-PDU) including a MAC sub-header and a payload including the first MAC CE; indicating in the MAC sub-header a group identifier (group ID) identifying a first group of MAC CEs in an extended LCID (eLCID) space, the first group of MAC CEs including the first MAC CE; and mapping the MAC sub-PDU to a transport block (TB) for transmission on a physical (PHY) layer. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1a An exemplary medium access layer (MAC) sub-header for a MAC sub-protocol data unit (sub-PDU) including a variable-sized MAC control element (CE) payload according to existing specifications is shown.

[0008] Figure 1b An exemplary MAC subheader including a third octet and an extended LCID (eLCID) field (8 bits) according to the existing specification is shown.

[0009] Figure 1c An exemplary MAC subheader including the fourth octet and the eLCID field (16 bits) according to the existing specification is shown.

[0010] Figure 2a An exemplary mapping table of Logical Channel ID (LCID) field code points to LCID values ​​for downlink (DL) (eg, for a DL-SCH transport channel) according to existing specifications is shown.

[0011] Figure 2b An exemplary mapping table of extended logical channel ID (eLCID) field code points to LCID values ​​for downlink (DL) (eg, for DL-SCH transport channel) according to existing specifications is shown.

[0012] Figure 2c An exemplary mapping table of Logical Channel ID (LCID) field code points to LCID values ​​for uplink (UL) (eg, for UL-SCH transport channel) according to existing specifications is shown.

[0013] Figure 2d An exemplary mapping table 230 of extended logical channel ID (eLCID) field code points to LCID values ​​for uplink (UL) (eg, for UL-SCH transport channel) according to existing specifications is shown.

[0014] Figure 3 An exemplary MAC subheader including a group ID field is shown according to various exemplary embodiments.

[0015] Figure 4a Methods for MAC CE transmission according to various exemplary embodiments are shown.

[0016] Figure 4b Methods for MAC CE reception according to various exemplary embodiments are shown.

[0017] Figure 5 Exemplary network arrangements are shown according to various exemplary embodiments.

[0018] Figure 6 An exemplary user equipment (UE) is shown according to various exemplary embodiments.

[0019] Figure 7 An exemplary base station according to various exemplary embodiments is shown.

[0020] Figure 8 Exemplary MAC CE containers are shown according to various exemplary embodiments. DETAILED DESCRIPTION

[0021] The exemplary embodiments may be further understood with reference to the following description and associated drawings, in which like elements are provided with like reference numerals. According to various exemplary embodiments described herein, options for grouping and assigning medium access control (MAC) control elements (MAC CEs) to logical channel identifiers (LCIDs) are proposed. Depending on the specific LCID space and the location in the LCID space selected to signal a specific MAC CE, some MAC CEs may require fewer bytes for signaling, while other MAC CEs use more bytes. By optimizing the allocation of MAC CEs to LCID space, some MAC CEs may require fewer header bytes for sending and / or enable a faster processing path.

[0022] In some aspects of the present disclosure, MAC CEs are classified and grouped according to some characteristics common to the grouped MAC CEs (e.g., functionality, latency requirements, priority, and / or other characteristics described in detail below). In other aspects of the present disclosure, the MAC subheader format can be used in its existing form, or can be modified to facilitate the identification and processing of MAC CEs that may have unique LCID values ​​or may be grouped with other MAC CEs under the same LCID value. In other aspects of the present disclosure, various options for configuring and / or reconfiguring a user equipment (UE) to use different LCID / eLCID mappings for MAC CEs are described.

[0023] The exemplary embodiments are described with respect to UE. However, the use of UE is provided for illustration purposes only. The exemplary embodiments may 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.

[0024] The exemplary embodiments are also described with reference to a 5G New Radio (NR) radio access network (RAN). However, reference to the 5G NR RAN is provided for illustration purposes only. The exemplary embodiments may be used with any network that implements a MAC layer method similar to that described herein. Thus, a 5G NR network as described herein may represent any type of network that implements functionality similar to that of a 5G NR network.

[0025] Layer 1 (L1) generally refers to the physical (PHY) layer of a UE or RAN node (e.g., a base station). Layer 2 (L2) generally refers to the medium access (MAC) layer, the radio link control (RLC) layer, and the packet data convergence protocol (PDCP) layer, and is considered a higher layer than L1. Layer 3 (L3) generally refers to the radio resource control (RRC) layer, and is considered a higher layer than L2.

[0026] The RLC layer can send an RLC protocol data unit (PDU) to the MAC layer. The RLC PDU is called a MAC service data unit (SDU) at the MAC layer. An instance of the MAC layer can send / receive a MAC SDU, a MAC control element (CE), and / or padding in a MAC sub-PDU. The MAC layer adds a sub-header to the MAC SDU to construct a MAC sub-PDU. Each MAC sub-PDU includes a MAC sub-header and a payload. The MAC PDU may include multiple MAC sub-PDUs. An instance of the MAC layer may process requests from an instance of the RLC via one or more MAC service access points (SAPs) and provide instructions to it. These requests and instructions transmitted via the MAC-SAP may include one or more logical channels. The MAC may perform mapping between logical channels and transport channels, multiplex MAC SDUs from one or more logical channels onto transport blocks (TBs) to be delivered to the PHY via transport channels, demultiplex MAC SDUs from TBs delivered from the PHY via transport channels to one or more logical channels, multiplex MAC SDUs onto transport blocks (TBs), schedule information reporting, perform error correction through HARQ, and logical channel prioritization (LCP). When filling a MAC PDU, the LCP usually involves the priorities of certain MAC CEs and logical channels.

[0027] The size of the MAC SDU can vary, and some MAC CEs are fixed in size while other MAC CEs have variable sizes. The MAC subheader, SDU, and CE are arranged in octets. The MAC subheader has a first defined format for variable-sized MAC CEs and MAC SDUs that do not contain an UL common control channel (CCCH), and other defined formats for fixed-size MAC CEs, padding, and MAC SDUs that contain an UL CCCH.

[0028] Figure 1aAn exemplary medium access layer (MAC) subheader 100 for a MAC sub-protocol data unit (sub-PDU) including a variable-size MAC control element (CE) payload according to an existing specification is shown. The first octet 102 includes a reserved field R 110 (1 bit), a format field F112 (1 bit), and an LCID field 114 (6 bits). The second octet 104 includes a length field L116 (8 bits). The third octet (not shown) may include an additional 8 bits (16 bits in total) for the L field 116. In the existing specification, the R field 110 is set to 0. The F field 112 may include a 0 indicating that L is 8 bits or a 1 indicating that L is 16 bits. The L field 116 is not used for fixed-size MAC CEs. The L field 116 indicates the length of the payload (e.g., a MAC SDU or a variable-size MAC CE). The LCID field 114 identifies the logical channel used for the MAC sub-PDU or MAC CE. The value of the LCID field 114 has different meanings for DL ​​transmission and UL transmission.

[0029] The LCID space for both DL MAC CE and UL MAC CE has been extended from Rel-15 to Rel-16 and from Rel-16 to Rel-17. To extend the LCID space for MAC CE, a new MAC subheader with a one octet extended LCID (eLCID) field is introduced. Figure 1b An exemplary MAC subheader 120 including the third octet 106 and an extended LCID (eLCID) field 122 (8 bits) according to the existing specification is shown. In addition, a new MAC subheader having a two-octet eLCID field is introduced. Figure 1c An exemplary MAC subheader 130 including a fourth octet 108 and an eLCID field 132 (16 bits) according to existing specifications is shown. Currently, the two octet eLCID field 132 of the MAC subheader 130 is only used for integrated access and backhaul (IAB) communications. The mapping between LCID / eLCID code points and logical channels or MAC CEs is defined in 3GPP specification TS 38.321.

[0030] Figure 2a An exemplary mapping table 200 of logical channel ID (LCID) field code points to LCID values ​​for downlink (DL) (e.g., for DL-SCH transport channel) according to existing specifications is shown. The 6-bit LCID field in the MAC subheader can indicate 64 different code points (0 to 63). For example, code point 0 indicates a common control channel (CCCH), and code points 1 to 32 indicate logical channel identification. A specific LCID value (e.g., LCID=33) is used to indicate the use of a subheader format including an 8-bit (one octet) eLCID field.

[0031] Figure 2b An exemplary mapping table 210 of extended logical channel ID (eLCID) field code points to LCID values ​​for downlink (DL) (e.g., for DL-SCH transport channels) according to existing specifications is shown. The 8-bit eLCID field in the MAC subheader can indicate 256 different code points (0 to 255). These eLCID code points are mapped to the LCID index range 64 to 319. For example, code points 0 to 244 indicate LCID index values ​​64 to 308 and are reserved, and code points 245 to 255 indicate LCID index values ​​309 to 319 and correspond to various DL MAC CEs.

[0032] Figure 2c An exemplary mapping table 220 of logical channel ID (LCID) field code points to LCID values ​​for uplink (UL) (e.g., for UL-SCH transport channel) according to existing specifications is shown. The 6-bit LCID field in the MAC subheader can indicate 64 different code points (0 to 63). Similar to DL-SCH, a specific LCID value (e.g., LCID=33) is used to indicate the use of a subheader format including an 8-bit (one octet) eLCID field. Figure 2d An exemplary mapping table 230 of extended logical channel ID (eLCID) field code points to LCID values ​​for uplink (UL) (e.g., for UL-SCH transport channel) according to existing specifications is shown. Similar to DL-SCH, the 8-bit eLCID field in the MAC subheader can indicate 256 different code points (0 to 255) mapped to the LCID index range 64 to 319. For example, code points 0 to 249 indicate LCID index values ​​64 to 313 and are reserved, and code points 250 to 255 indicate LCID index values ​​314 to 319 and correspond to various UL MAC CEs.

[0033] As shown above, a MAC subheader format without an eLCID field may indicate LCID index values ​​0 to 63 (set 1), and a MAC subheader format including an octet eLCID field may indicate LCID index values ​​0 to 63 (set 1) and further LCID index values ​​64 to 308 (set 2). Set 1 in the first octet may be processed by the MAC layer faster than set 2 in the second octet. The general principle followed during 5G NR development is that less frequent and low-priority MAC CEs should be assigned to set 2, and more frequent and high-priority MAC CEs (which also require low overhead) may be assigned to set 1. No restriction (e.g., always having an L field) is required to assign new MAC CEs to set 2. In Rel-17, it is confirmed that coverage-limited cases will use set 1 values ​​(LCID values ​​0 to 63), and other cases will use set 2 values ​​(eLCID values ​​0 to 255 corresponding to LCID values ​​64 to 319). Logical Channel Prioritization (LCP) priorities may need to be corrected to achieve consistency.

[0034] Many new MAC CEs have been or will be introduced in Rel-17. To identify logical channels for new MAC CEs, the number of logical channel identifiers (LCIDs) currently available in TS 38.321 is insufficient. However, there are extended LCIDs (eLCIDs) that can be obtained from reserved code points in excess of what is needed. Therefore, similar to Rel-16, it is likely that one octet of eLCID space will be used for new MAC CEs. For various reasons, more frequently used MAC CEs may be optimally allocated in the LCID space.

[0035] In future releases, new 3GPP functions will result in additional MAC CEs. In addition, more control functions may be moved from RRC to MAC and further MAC CEs may be specified. Therefore, the current LCID design may need to be reformulated. It has been proposed that the network may (through network configuration) allocate and move some MAC CEs in the MAC CE to certain locations in the LCID or eLCID space.

[0036] According to various exemplary embodiments described herein, several options for grouping and assigning MAC CEs to logical channel IDs (LCIDs) are proposed. Depending on the specific LCID space and the location in the LCID space selected to signal a specific MAC CE, some MAC CEs may require fewer bytes to signal, while other MAC CEs can afford more bytes. By optimizing the allocation of MAC CEs to LCID space, some MAC CEs may require fewer header bytes for transmission and / or enable a faster processing path.

[0037] According to some aspects of the present disclosure, sub-grouping of MAC CEs is described. Various methods may be considered to make the LCID space more scalable by classifying MAC CEs into groups based on the following considerations. The following options may be used alone or in appropriate combination.

[0038] In the first option, MAC CEs are classified based on their functions. For example, MAC CEs can be classified based on sub-functions within L1 control, L2, or upper layers. In the second option, MAC CEs are classified based on processing / latency (e.g., timeline or deadline) requirements. For example, MAC CEs that require low latency can be grouped separately from MAC CEs that do not require low latency. In the third option, MAC CEs are classified based on LCP / priority. As described above, LCP refers to the prioritization of MAC CEs or logical channels used to fill MAC PDUs.

[0039] In the fourth option, MAC CE is classified based on hierarchical indications (e.g., feature indicators and sub-feature indicators). For example, 3GPP organizes the functions of different work items (WI) into features and feature groups. Different features can be identified by feature indicators or sub-feature indicators defined in the specification. For example, the UE feature list definition mapping described in TR 38.822. Feature groups are further associated via the RRC protocol. New MAC CEs are typically defined based on specific features or sub-features of the WI. If the UE does not support a specific feature or sub-feature set, the corresponding space in the LCID table can be used for other things (e.g., other MAC CEs for features supported by the UE). Since the UE indicates to the network the feature set it supports (and other features are also mandatory or always assumed to be active, depending on the process), the network can use this knowledge of UE features to classify or organize the allocation of MAC CE, LCID or MAC CE priority (during LCP) based on features or sub-features.

[0040] In a fifth option, MAC CEs are classified based on 3GPP release indication, such as root and version.

[0041] Various options may be considered to identify one of these groups or subgroups in the MAC subheader. In one option, one or more top-level LCIDs (e.g., from the LCID values ​​0 to 63 indicated in the LCID field) that may be shared by multiple sub-identifiers within a MAC CE container or within an eLCID group may be allocated. The MAC CE container may be identified by a fast path (e.g., real-time) component with a top-level LCID value and later processed by software (e.g., a non-real-time component) to identify the sub-identifier for a specific MAC CE. The MAC CE container may include a "common" LCID that identifies a group of MAC CEs, and the payload of the MAC CE includes a header to further demultiplex the message in a second step according to the function of the message (e.g., for the actual destination of the MAC CE). One or more MAC CEs may exist in a MAC CE container. Each individual MAC CE in a group may be identified by an ID. The composition of a specific MAC CE container may be based on the classification options discussed above. A top-level container may be created so that all MAC CEs associated with a common modem component (e.g., PHY Tx processing) may be classified. The top-level LCID can also be used by the modem receiver fast path (real-time path) to route the MAC CE container to different destinations. The MAC CE container can also be used to provide additional security to the MAC CE via encryption and integrity protection. Encryption is only applied to the MAC CE content and not to the top-level MAC CE container header. One or more bytes of the MACI can be appended to each container. Figure 8 An exemplary MAC CE container 800 is shown in accordance with various exemplary embodiments.

[0042] In another option, a top-level LCID shared by multiple sub-identifiers can be allocated by acting as a pointer to an eLCID group. For example, in the current specification, LCID values ​​33 or 34 indicate that an eLCID is used. In the currently described option, additional LCID values ​​can point to a specific range of eLCID values.

[0043] The assignment of a top-level LCID (Set 1 LCID) for a MAC CE or a group of MAC CEs that can be indicated without using a one-octet eLCID MAC subheader can be considered a "fast path" for processing LCIDs. That is, given the reduced search space relative to searching the eLCID space, the MAC entity (at the UE or gNB) receiving the transmission can quickly identify the final destination of the MAC CE without having to identify the specific MAC CE included in the transmission. These options include a two-step approach where the LCID value allows the MAC entity to quickly process the first aspect of the transmission and later process the second aspect of the transmission (identifying a specific sub-identifier within a MAC CE container or eLCID group).

[0044] If a specific type of MAC CE is time-sensitive, the MAC CE can be directly allocated in the LCID space (one-step method).

[0045] In view of the above framework, MAC CEs may be allocated into different groups or subgroups based on functionality, time sensitivity, priority, etc., and may be processed quickly, slowly, and / or more efficiently based on the RAN requirements accompanying the MAC CEs.

[0046] According to another aspect of these exemplary embodiments, a framework for reconfiguring or remapping MAC CEs to different groups or subgroups within an LCID or eLCID is described. Specific mechanisms for reconfiguring / remapping MAC CEs are described in more detail further below.

[0047] In one approach, the LCID space may remain fixed or non-reconfigurable such that the LCID space is used only for critical and / or coverage related MAC CEs. That is, the reconfiguration may target subspace mappings (e.g., groupings of eLCIDs) rather than the primary LCID space. The Set 1 LCID space may be considered fixed and the Set 2 LCID space (or MAC CE containers) may be variable (subgroups in Set 2 —> 2.1, 2.2, ..., 2.n). In another approach, at least some of the critical MAC CEs in Set 1 (e.g., MAC CEs sent during a random access procedure) may be non-reconfigurable to ensure minimal operation of communications between the gNB and the UE.

[0048] After reconfiguration, when MAC CE or LCID / eLICD is remapped, the MAC entity needs to be reset (i.e., a MAC reset is to be performed). In addition, RLC or PDCP reconstruction may be required in some cases. From the perspective of implementation complexity, hierarchical (or deeply nested) sub-packets of MAC CE are less preferred, especially in the case of higher throughput. Currently, there are no high throughput scenarios envisioned for MAC CE. However, frequent exchanges of MAC CE may soon become more common in upcoming releases (e.g., MAC CE for FR2 / beamforming, TCI state, etc.). In these cases, overhead reduction will have a more significant effect.

[0049] According to another aspect of these exemplary embodiments, the "R" field in the MAC subheader can be repurposed to define two LCID sets. For example, when R=0, the following can be used: Figure 2a to Figure 2dThe currently specified LCID / eLCID table shown in , and when R = 1, an alternative LCID or eLCID table may be used. Similar to the existing LCID table, an alternative LCID table may be defined in the specification.

[0050] In one option, the alternative LCID table may include a structure similar to the existing LCID table. That is, in this option, the LCID / eLCID space is expanded by doubling the number of available LCIDs. In another option, the alternative LCID table may include a compressed structure relative to the existing LCID table. The compressed table may allocate a reduced number of LCIDs to the MAC CE, so that in this option, the LCID / eLCID space is expanded, but can be searched faster than the existing LCID / eLCID space.

[0051] As described above, the use of the "R" bit may be configured for the UE via RRC signaling.

[0052] In another option, the network can modify the alternative or compressed LCID table via RRC signaling. For example, a completely new LCID table can be sent or the content of certain LCID entries can be updated. Alternatively, the mapping / sub-grouping can be changed. In a further extension, several pre-configurations of alternative mappings can be provided to the UE, whereby each pre-configuration is associated with an ID. Network signaling can later reference this ID in order to switch mappings or even enable additional LCID tables.

[0053] In another aspect of these exemplary embodiments, a group ID pointing to a specific location in the eLCID space may be indicated. For example, each group ID may identify 2 6 = (fixed) amount of 256 available LCIDs x The superscript x can be associated with the corresponding group ID so that the amount of eLCIDs in each group can vary. For example, the first LCID group can include 2 3 = 8 LCIDs, and the second LCID group may include 2 4 = 16 LCIDs. In an alternative embodiment, some group IDs may be linked to the eLCID space, while some other group IDs may be linked to the LCID space.

[0054] In one embodiment, a new MAC subheader format may be defined that includes a group ID field. In one example, the group ID field may include 2 bits repurposed from the LCID field, and a shortened LCID (sLCID) field including 4 bits may be used. In some embodiments, the new MAC subheader format may be enabled through RRC signaling, or may be indicated in the new MAC subheader by repurposing the "R" bit.

[0055] In one embodiment, the new MAC subheader format can be bundled with a RACH (sub-feature indication and allocation) or broadcast indication for mapping. In Rel-17, a method for "RACH indication and allocation" was introduced, which allows a random access resource set to be associated with a feature or sub-feature (such as small data transmission (SDT), coverage enhancement, RAN slicing, reduced capability (RedCap) and the like). In this case, the network can associate a random access resource set with a specific feature that triggers the random access procedure. A random access resource set associated with a feature is only valid for a random access procedure for that feature; and a random access resource set associated with several features is only valid for a random access procedure with all of these features. Therefore, in this embodiment, the new MAC subheader format can be associated with a RACH resource set.

[0056] Figure 3 An exemplary MAC subheader 300 including a group ID field 324 is shown according to various exemplary embodiments. In this example, the first octet 302 includes a first format field F L 310 (1 bit), a second format field F 312 (1 bit), a shortened LCID (sLCID) field 314 (4 bits), and a group ID field 324 (2 bits). The second octet 304 includes an extended LCID (eLCID) field 322 (8 bits), and the third octet 306 includes a length field L 316 (8 bits). The F field 312, the eLCID field 322, and the L field 316 may be associated with Figure 1b The F field 112, eLCID field 122, and L field 116 shown in the MAC subheader 120 of FIG. 110 are similarly formatted. The F field 112, eLCID field 122, and L field 116 may be reset from the R field 110LA. L The purpose of field 310 is to indicate that a new MAC subheader format 300 is used and can be obtained from Figure 1b The LCID field 114 of the MAC subheader 120 of the MAC subheader 120 is used to reconfigure the purpose of the group ID field 324. The sLCID field 314 (4 bits) is relative to Figure 1b The LCID field 114 (6 bits) of the MAC subheader 120 is shortened.

[0057] If the new MAC subheader 300 is used, one disadvantage is that the most basic LCID and logical channel will no longer fit in the first octet 302, since the number of possible LCID values ​​indicated in the sLCID field 314 will be reduced from 64 to 16 LCIDs. In an alternative embodiment, a Figure 1bThe unmodified MAC subheader 120 of the MAC header may be used, and the group ID may be signaled in some other way (e.g., dedicated RRC signaling). In another alternative, the group ID may be signaled using Figure 1b The unmodified MAC subheader 120 of the eLCID space may be used, and the top-level (set 1) LCID may point to a set of LCIDs in the eLCID space. This may enable subgroups of eLCIDs that may be defined in the table. For example, LCID 35 may point to eLCID set 1, LCID 36 may point to eLCID set 2, and so on.

[0058] Based on the group ID, the receiving MAC entity can quickly process and identify some aspects of the MAC CE (e.g., characteristics of the MAC CE inherent to the MAC CE within the group) and process the MAC CE accordingly. For example, a MAC CE from a group of time-sensitive MAC CEs can be processed quickly, while a MAC CE from a group of non-time-sensitive MAC CEs can be processed later.

[0059] According to another aspect of these exemplary embodiments, various options for accommodating multiple MAC CE tables or different layouts / groups are described, wherein each layout / group points to a specific structure or allocation of MAC CE as described above. The UE may store one or more MAC CE / LCID mappings. In some embodiments, an identifier for one of multiple available configurations may be indicated in a reconfiguration from the network.

[0060] In a first aspect, a MAC CE configuration (or multiple MAC CE configurations) including a set of MAC CEs and their allocations may be defined in a specification. There may be different ways to allocate, map, and distribute MAC CEs over, for example, LCID and eLCID specifications. If multiple configurations are specified, each such configuration may be linked to an identifier.

[0061] In a second aspect, if multiple configurations are specified, the identifier of the MAC CE configuration may be broadcast by the network in the SIB. The UE may decode the SIB and determine which MAC CE configuration to use based on the identifier.

[0062] In a third aspect, associations may be defined between UE features and MAC CE tables. For example, a set of sub-features owned by a UE may be linked to a predefined allocation of a MAC CE to a logical channel ID (LCID / eLCID table). A UE that supports a specific feature or a specific set of features may use one of the predefined configurations. Mappings may be defined in the specification for both UE capabilities (e.g., TS 38.306 in 5G) and MAC CE (e.g., TS 38.321 in 5G).

[0063] In addition, a default MAC CE / LCID mapping may be defined. The default mapping may be used until the network knows the full UE capabilities. Furthermore, the default mapping may be used as a fallback in the event of an error (e.g., decoding error, etc.).

[0064] In a fourth aspect, MAC CE mapping may be configured / reconfigured as part of normal RRC reconfiguration (eg, dedicated signaling using a configuration identifier).

[0065] In a fifth aspect, a new downlink MAC CE may be defined to configure / reconfigure the LCID space. In this aspect, in response, the UE may confirm the MAC CE reconfiguration with an uplink MAC CE.

[0066] In a sixth aspect, a new DCI field may be used to dynamically trigger reallocation of MAC CEs for a specific duration.

[0067] In a seventh aspect, a new DCI field may be used to dynamically trigger reallocation of MAC CEs for only a specific feature set.

[0068] In an eighth aspect, for the sixth aspect or the seventh aspect discussed above of using a new DCI field to trigger reallocation of a MAC CE, the UE may respond with a MAC CE in an uplink (UL).

[0069] In a ninth aspect, more generally, reallocation of MAC CE mappings (e.g., by promoting one or more MAC CEs from set 2 to set 1, or to a different, more prominent position in the table) may be applied only to a smaller subset of MAC CEs. The subset may involve only MAC CEs linked to a particular sub-feature. The subset may involve only selected MAC CEs (e.g., certain MAC CEs that may appear more frequently than other MAC CEs). Likewise, the reallocation may be applied only for a limited time (via a timer). Alternatively, the reallocation may be applied to a complete table of all MAC CEs.

[0070] In further aspects of these exemplary embodiments, one or more UE capabilities may be required to indicate that the UE supports multiple LCID tables, reconfigurable LCID tables, etc., for example to ensure desired backward compatibility. In one option, the UE capabilities may enable one or more subsequent corresponding RRC configurations. In addition, explicit RRC parameters may also be required to configure / reconfigure a UE with a specific LCID structure. If the aforementioned MAC CE extension method is applied to a future 5G release or a future generation (6G), the MAC CE extension may be considered mandatory for all UEs supporting the future release to reduce gNB complexity.

[0071] In addition, as part of the MAC logical channel prioritization process, logical channels may be prioritized according to a priority order, which also includes selecting a MAC CE suitable for inclusion in a MAC PDU after granting. In this context, the processing order of the MAC CE itself (e.g., prioritization order or MAC CE / data), which is currently fixed at the end of subclause 5.4.3.1.3 in TS 38.321, may be configured or reconfigured by the network, wherein the prioritization of the MAC CE may follow a similar sub-grouping principle as indicated above.

[0072] Figure 4a A method 400 for MAC CE transmission according to various exemplary embodiments is shown. The method 400 is described from the perspective of a user equipment (UE) transmitting a MAC CE to a base station. It should be understood that certain aspects of the method 400, particularly with respect to constructing a MAC CE by a UE and transmitting the MAC CE on an uplink (UL), can be similarly performed by a base station (e.g., a gNB) that constructs a MAC CE and transmits the MAC CE to a UE on a downlink (DL).

[0073] In method 400, the UE supports one or more extensions of the existing MAC CE / LCID design. For example, as described in the exemplary aspects above, the UE may support: a MAC CE / LCID framework in which multiple MAC CEs are classified into groups based on one or more characteristics common to the grouped MAC CEs; a specified LCID / eLCID table that maps LCID / eLCID code points to multiple MAC CEs in a fixed or variable LCID / eLCID space; multiple available configurations of one or both of the LCID space and the eLCID space that can be configured / reconfigured by the network; a new MAC subheader format including a group ID field; and other feature parts. As described above, these various features can be used alone or in combination in some embodiments. MAC CEs can be grouped according to various characteristics common to the grouped MAC CEs.

[0074] Additionally, in method 400, the UE can be reconfigured between different designated LCID / MAC CE tables / spaces. However, in other embodiments, the UE has a fixed LCID / MAC CE space.

[0075] The UE performs a random access (RACH) procedure and attaches to a network, such as a 5G NR RAN, in 405. During the initial access procedure, and before receiving any dedicated configuration / reconfiguration from the network, the UE MAC layer may use a default configuration for LCID / eLCID.

[0076] In one embodiment, the default LCID / eLCID configuration may correspond to the existing framework specified in TS 38.321. In other embodiments, the default LCID / eLCID configuration may include subgroups of MAC CEs identified by a single LCID and / or eLCID value. These subgroups may be classified in a variety of ways, including: 1) based on functionality; 2) based on timeline / latency; 3) based on LCP / priority; 4) based on layer indication; 5) based on 3GPP version.

[0077] The UE may select a default configuration from a plurality of available LCID / eLCID configurations / tables defined in the UE specification, each configuration being associated with an identifier, or the UE may be designed to have only a single configuration option. The configuration may be selected by the UE from a plurality of configurations defined in the specification based on a set of sub-features supported by the UE.

[0078] In 410, the UE reports one or more UE capabilities to the network. The UE capabilities may relate to support for the various MAC CE / LCID features described above.

[0079] In 415, the UE receives a reconfiguration for a different MAC CE / LCID configuration from the network. The reconfiguration (e.g., identifier) ​​may be broadcast in a SIB; received in an RRC reconfiguration; received in a new DL MAC CE; or received in a new DCI field. The reconfigured MAC CE / LCID configuration may be used by the UE until a subsequent reconfiguration, or the reconfiguration may be applicable for a predetermined duration before reverting to a default configuration. When the reconfiguration is received, the MAC entity of the UE is reset. Additionally, in some embodiments, the UE may send a confirmation of the reconfiguration to the network.

[0080] In 420, the UE determines to send a first MAC CE to the network for any of a variety of reasons.

[0081] In 425, the UE constructs a MAC sub-protocol data unit (sub-PDU) including a MAC sub-header and a payload including a first MAC CE. The MAC sub-PDU is constructed based on the reconfigured LCID / MAC CE space from 415. For example, the LCID value may directly indicate a MAC CE, a MAC CE container, a set of eCLIDs, etc. Additional nesting layers may be used, where the eLCID may indicate another set of eLCIDs. In this example, in the MAC sub-header, the UE indicates an LCID value associated with the first MAC CE, which identifies a first set of MAC CEs classified based on a feature (e.g., function or priority). In some embodiments, the MAC sub-header format may correspond to an existing specification, while in other embodiments, the MAC sub-header may include a new format including, for example, a group ID field and / or an R field, the purpose of which is reset to indicate one of two available LCID / MAC CE configurations.

[0082] In 430, the UE maps the MAC sub-PDU to a transport block (TB) for transmission on the PHY layer.

[0083] Figure 4b A method 450 for MAC CE reception according to various exemplary embodiments is shown. The method 450 is described from the perspective of a user equipment (UE) receiving a MAC CE from a base station. It should be understood that certain aspects of the method 450, particularly with respect to the UE receiving and processing a MAC CE on a downlink (DL), can be similarly performed by a base station (e.g., a gNB) receiving and processing a MAC CE from a UE on an uplink (UL).

[0084] Similar to method 400, in method 450, the UE supports one or more extensions of the existing MAC CE / LCID design. As described above, these various features related to the MAC CE / LCID space can be used alone or in combination in some embodiments. In addition, similar to method 400, in method 450, the UE can be reconfigured between different designated LCID / MAC CE tables / spaces. However, in other embodiments, the UE has a fixed LCID / MAC CE space. Steps 455 to 465 of method 450 can be substantially similar to steps 405 to 415 of method 400.

[0085] In 470, the UE receives a first MAC CE from the network for any of a variety of reasons. The first MAC CE is a payload of a MAC sub-PDU constructed with a MAC sub-header. In some embodiments, the received MAC sub-header may have a format similar to the existing specification, while in other embodiments, the MAC sub-header may include a new format. The MAC sub-header indicates the LCID value in the first octet.

[0086] In 475, the UE processes the first octet of the MAC subheader to determine the group to which the MAC CE belongs from the LCID value. For example, the LCID value may be mapped to a range of eLCID values, etc. Based on the LCID value, the UE may determine whether the MAC CE is time sensitive.

[0087] In 480, the UE decodes the MAC CE.

[0088] Figure 5 An exemplary network arrangement 500 according to various exemplary embodiments is shown. The exemplary network arrangement 500 includes a UE 510. Those skilled in the art will appreciate that the UE 510 may be any type of electronic component configured to communicate via a network, such as a mobile phone, a tablet computer, a desktop computer, a smart phone, a tablet phone, an embedded device, a wearable device (e.g., HMD, AR glasses, etc.), an Internet of Things (IoT) device, etc. It should also be understood that an actual network arrangement may include any number of UEs used by any number of users. Therefore, the example of a single UE 510 is provided for illustrative purposes only.

[0089] UE 510 may be configured to communicate with one or more networks. In the example of network configuration 500, the network with which UE 510 may wirelessly communicate is a 5G NR radio access network (RAN) 520. However, UE 510 may also communicate with other types of networks (e.g., 5G cloud RAN, next generation RAN (NG-RAN), long term evolution (LTE) RAN, traditional cellular networks, WLAN, etc.), and UE 510 may also communicate with the network via a wired connection. With respect to the exemplary embodiment, UE 510 may establish a connection with 5G NR RAN 520. Therefore, UE 510 may have a 5G NR chipset to communicate with NR RAN 520.

[0090] The 5G NR RAN 520 may be part of a cellular network that may be deployed by a network operator (e.g., Verizon, AT&T, T-Mobile, etc.). The 5G NR RAN 520 may include, for example, cells or base stations (Node B, eNodeB, HeNB, eNB, gNB, gNodeB, macro cell, micro cell, small cell, IAB node, femto cell, next generation node (e.g., 6G), etc.) configured to send and receive traffic from UEs equipped with appropriate cellular chipsets.

[0091] UE 510 may connect to 5G NR-RAN 520 via gNB 520A. Those skilled in the art will appreciate that any association process may be performed for UE 510 to connect to 5G NR-RAN 520. For example, as discussed above, 5G NR-RAN 520 may be associated with a specific cellular provider at which UE 510 and / or its user has protocol and credential information (e.g., stored on a SIM card). Upon detecting the presence of 5G NR-RAN 520, UE 510 may transmit corresponding credential information to associate with 5G NR-RAN 520. More particularly, UE 510 may be associated with a specific base station (e.g., gNB 520A). However, as mentioned above, reference to 5G NR-RAN 520 is for illustrative purposes only, and any suitable type of RAN may be used.

[0092] The network arrangement 500 also includes a cellular core network 530, the Internet 540, an IP multimedia subsystem (IMS) 550, and a network service backbone 560. The cellular core network 530 can be viewed as a collection of interconnected components that manage the operation and traffic of the cellular network. The cellular core network 530 also manages the traffic flowing between the cellular network and the Internet 540. The IMS 550 can generally be described as an architecture for delivering multimedia services to the UE 510 using the IP protocol. The IMS 550 can communicate with the cellular core network 530 and the Internet 540 to provide multimedia services to the UE 510. The network service backbone 560 communicates directly or indirectly with the Internet 540 and the cellular core network 530. The network service backbone 560 can generally be described as a collection of components (e.g., servers, network storage arrangements, etc.) that implement a set of services that can be used to extend the functionality of the UE 510 to communicate with various networks.

[0093] Figure 6 An exemplary UE 510 is shown according to various exemplary embodiments. The UE 510 sends information about Figure 5UE 510 may include a processor 605, a memory arrangement 610, a display device 615, an input / output (I / O) device 620, a transceiver 625, and other components 630. Other components 630 may include, for example, an audio input device, an audio output device, a power supply, a data acquisition device, a port for electrically connecting UE 510 to other electronic devices, and the like.

[0094] The processor 605 may be configured to execute multiple engines of the UE 510. For example, these engines may include an LCID mapping engine 635 for performing various operations related to sending / receiving MAC CE in the above framework. The above-mentioned engine 235 is provided for illustrative purposes only as an application (e.g., a program) executed by the processor 605. The functions associated with the engine 635 may also be represented as independent combined components of the UE 510, or may be modular components coupled to the UE 510, for example, an integrated circuit with or without firmware. For example, an integrated circuit may include an input circuit for receiving a signal and a processing circuit for processing a signal and other information. The engine may also be embodied as an application or a separate application. In addition, in some UEs, the functions described for the processor 605 are split between two or more processors (such as a baseband processor and an application processor). The exemplary embodiment may be implemented in any of these or other configurations of the UE.

[0095] The memory arrangement 610 may be a hardware component configured to store data related to operations performed by the UE 510. The display device 615 may be a hardware component configured to display data to a user, and the I / O device 620 may be a hardware component that enables a user to enter input. The display device 615 and the I / O device 620 may be separate components, or may be integrated together (such as a touch screen). The transceiver 625 may be a hardware component configured to establish a connection with the 5G NR-RAN 520 and / or any other appropriate type of network. Thus, the transceiver 625 may operate on a variety of different frequencies or channels (e.g., a set of contiguous frequencies).

[0096] Figure 7 An exemplary base station 520A is shown in accordance with various exemplary embodiments. Base station 520A may represent any access node through which UE 510 may establish a connection and manage network operations.

[0097] Base station 520A may include a processor 705, a memory arrangement 710, an input / output (I / O) device 715, a transceiver 720, and other components 725. Other components 725 may include, for example, a battery, a data acquisition device, ports for electrically connecting base station 700 to other electronic devices, and the like.

[0098] The processor 705 may be configured to execute multiple engines of the base station 520A. For example, these engines may include an LCID mapping engine 730 for performing various operations related to sending / receiving MAC CE in the above framework. The above-mentioned engine 730 is only exemplary as an application (e.g., a program) executed by the processor 705. The functions associated with the engine 730 may also be represented as a separate combined component of the base station 700, or may be a modular component coupled to the base station 700, such as an integrated circuit with or without firmware. For example, an integrated circuit may include an input circuit for receiving a signal and a processing circuit for processing a signal and other information. In addition, in some base stations, the functions described for the processor 705 are split between multiple processors (e.g., a baseband processor, an application processor, etc.). The exemplary embodiments may be implemented in any of these or other configurations of the base station.

[0099] The memory 710 may be a hardware component configured to store data related to operations performed by the base station 700. The I / O device 715 may be a hardware component or port that enables a user to interact with the base station 700. The transceiver 720 may be a hardware component configured to exchange data with the UE 510 and any other UE in the system 500. The transceiver 720 may operate on a variety of different frequencies or channels (e.g., a set of continuous frequencies). Therefore, the transceiver 720 may include one or more components (e.g., radio devices) to enable data exchange with various networks and UEs.

[0100] Example

[0101] In a first embodiment, a medium access control (MAC) layer instance is configured to perform operations including: receiving a first MAC control element (MAC CE) within a MAC sub-protocol data unit (sub-PDU), wherein the MAC sub-protocol data unit (sub-PDU) includes a MAC sub-header and a payload including the first MAC CE; identifying a logical channel identifier (LCID) value in a first octet of the MAC sub-header, wherein the logical channel identifier (LCID) value identifies a first group of MAC CEs classified based on features, wherein the first group of MAC CEs includes the first MAC CE; and decoding the first MAC CE.

[0102] In a second embodiment, according to the MAC layer example of the first embodiment, the feature used to classify the first group of MAC CEs includes functions for the MAC CEs in the first group.

[0103] In a third embodiment, according to the MAC layer example of the second embodiment, the function includes a sub-function within layer 1 (L1) control, layer 2 (L2) or an upper layer.

[0104] In a fourth embodiment, according to the MAC layer example of the first embodiment, the feature used to classify the first group of MAC CEs includes a waiting time requirement for the MAC CEs in the first group.

[0105] In a fifth embodiment, according to the MAC layer example of the first embodiment, the feature used to classify the first group of MAC CEs includes logical channel prioritization (LCP) for the MAC CEs in the first group.

[0106] In a sixth embodiment, according to the MAC layer instance of the first embodiment, the features used to classify the first group of MAC CEs include a feature group of features or sub-features for the MAC CEs in the first group or support for a specific combination of the features or sub-features.

[0107] In a seventh embodiment, according to the MAC layer instance of the first embodiment, the feature used to classify the first group of MAC CEs includes a 3GPP version indication for the MAC CEs in the first group.

[0108] In an eighth embodiment, according to the MAC layer example described in the first embodiment, the first group of MAC CEs is included in a MAC CE container.

[0109] In a ninth embodiment, the MAC layer instance according to the eighth embodiment, wherein the MAC CE container is identified by a top-level LCID value processed by a fast path modem component, wherein a payload of the MAC CE container includes a header to further process the MAC CE according to its function.

[0110] In a tenth embodiment, according to the MAC layer example of the first embodiment, the first group of MAC CEs is included in an extended LCID (eLCID) group.

[0111] In an eleventh embodiment, a medium access control (MAC) layer instance is configured to perform operations including the following: receiving a first MAC control element (MAC CE) within a MAC sub-protocol data unit (sub-PDU), the MAC sub-protocol data unit (sub-PDU) including a MAC sub-header and a payload including the first MAC CE; identifying a value of a reserved (R) bit in a first octet of the MAC sub-header, the reserved (R) bit identifying a first logical channel identifier (LCID) table set or a second LCID table set used to determine a logical channel or MAC CE identifier from an LCID value included in the MAC sub-header; and decoding the first MAC CE based on the first LCID table set or the second LCID table set identified from the R bit.

[0112] In a twelfth embodiment, according to the MAC layer example of the eleventh embodiment, when R=0, the first LCID table set is used, and when R=1, the second LCID table set is used.

[0113] In a thirteenth embodiment, according to the MAC layer instance of the twelfth embodiment, the first LCID table set and the second LCID table set include the same range of LCID values.

[0114] In a fourteenth embodiment, according to the MAC layer instance of the twelfth embodiment, the second LCID table set is compressed relative to the first LCID table set.

[0115] In a fifteenth embodiment, the MAC layer instance according to the fourteenth embodiment, wherein the second extended LCID (eLCID) table set is compressed relative to the first eLCID table set.

[0116] In a sixteenth embodiment, according to the MAC layer instance of the eleventh embodiment, when the MAC layer instance operates at a user equipment (UE), the operation further includes receiving a radio resource control (RRC) configuration that enables use of the R bit.

[0117] In a seventeenth embodiment, the MAC layer instance according to the eleventh embodiment, wherein when the MAC layer instance operates at a user equipment (UE), the operation further includes receiving one or more modified LCID table sets via radio resource control (RRC) signaling.

[0118] In an eighteenth embodiment, a MAC layer instance according to the eleventh embodiment, wherein when the MAC layer instance operates at a user equipment (UE), the UE is pre-configured with an alternative LCID table mapping, wherein each of the pre-configurations is associated with an identifier, and wherein the operation further comprises receiving an identifier for one of the pre-configurations via radio resource control (RRC) signaling.

[0119] In a nineteenth embodiment, according to the MAC layer instance of the eleventh embodiment, when the MAC layer instance operates at a base station, the operation further comprises sending a radio resource control (RRC) configuration that enables use of the R bit.

[0120] In a twentieth embodiment, according to the MAC layer instance of the eleventh embodiment, when the MAC layer instance operates at a base station, the operation further comprises sending one or more modified LCID table sets via radio resource control (RRC) signaling.

[0121] In a twenty-first embodiment, a MAC layer instance according to the eleventh embodiment, wherein when the MAC layer instance operates at a base station, the operation also includes sending an identifier corresponding to one of the LCID table mappings in a preconfigured set of alternative LCID table mappings via radio resource control (RRC) signaling.

[0122] In a twenty-second embodiment, a processor of a user equipment (UE), the processor being configured to perform operations including: selecting a default logical channel identifier (LCID) configuration for a MAC subheader for sending and receiving a MAC control element (MAC CE) and a MAC service data unit (SDU) in a MAC subprotocol data unit (sub-PDU), wherein the default LCID configuration is selected from a plurality of available LCID configurations defined in a UE specification and is linked to a corresponding identifier; and performing an initial access procedure to attach to a network, wherein the default LCID configuration is used at least during the initial access procedure.

[0123] In a twenty-third embodiment, the processor of the twenty-second embodiment, wherein the default LCID configuration is selected based on a sub-feature set supported by the UE.

[0124] In a twenty-fourth embodiment, the processor of the twenty-second embodiment, wherein the operations further comprise receiving a reconfiguration from the network to use a different LCID configuration.

[0125] In a twenty-fifth embodiment, the processor of the twenty-fourth embodiment, wherein the identifiers for the different LCD configurations are received in a system information block (SIB).

[0126] In a twenty-sixth embodiment, the processor of embodiment twenty-four, wherein the reconfiguration comprises dedicated radio resource control (RRC) signaling.

[0127] In a twenty-seventh embodiment, the processor of the twenty-fourth embodiment, wherein the UE is reconfigured using a new downlink (DL) MAC CE or a new downlink control information (DCI) field, wherein the operation further comprises sending an uplink (UL) MAC CE to confirm the reconfiguration.

[0128] In a twenty-eighth embodiment, the processor of the twenty-seventh embodiment, wherein the new DCI field triggers the LCID reconfiguration for a period of time.

[0129] In a twenty-ninth embodiment, the processor of the twenty-seventh embodiment, wherein the new DCI field triggers the LCID reconfiguration for a specific feature set.

[0130] In a thirtieth embodiment, the processor according to the twenty-fourth embodiment, wherein the reconfiguration includes moving one or more MAC CEs from an extended LCID (eLCID) space to an LCID space or moving one or more MAC CEs from the LCID space to an eLCID space.

[0131] In a thirty-first embodiment, the processor of embodiment twenty-four, wherein the reconfiguration comprises reallocating MAC CEs in an extended LCID (eLCID) space, while the LCID space remains fixed and non-configurable.

[0132] In a thirty-second embodiment, the processor of the twenty-fourth embodiment, wherein the reconfiguration comprises reallocating MAC CEs in the LCID space, wherein some LCIDs are reallocated while other LCIDs remain fixed and non-configurable.

[0133] In a thirty-third embodiment, the processor of the twenty-second embodiment, wherein the default LCID configuration is used during the initial access process and during an additional duration after the initial access, wherein the additional duration is defined in a specification.

[0134] In a thirty-fourth embodiment, a processor of a base station is configured to perform operations including: determining a default logical channel identifier (LCID) configuration for a MAC subheader for sending and receiving a MAC control element (MAC CE) and a MAC service data unit (SDU) in a MAC subprotocol data unit (sub-PDU), wherein the default LCID configuration is selected from a plurality of available LCID configurations and is linked to a corresponding identifier; and performing an initial access procedure with a user equipment (UE), wherein the default LCID configuration is used at least during the initial access procedure.

[0135] In a thirty-fifth embodiment, the processor according to the thirty-fourth embodiment, wherein the operation further comprises sending a reconfiguration to the UE to use a different LCID configuration.

[0136] In a thirty-sixth embodiment, the processor of the thirty-fifth embodiment, wherein the identifiers for the different LCD configurations are sent in a system information block (SIB).

[0137] In a thirty-seventh embodiment, the processor of the thirty-fifth embodiment, wherein the reconfiguration comprises dedicated radio resource control (RRC) signaling.

[0138] In a thirty-eighth embodiment, the processor according to the thirty-fifth embodiment, wherein the UE is reconfigured using a new downlink (DL) MAC CE or a new downlink control information (DCI) field, wherein the operation also includes receiving an uplink (UL) MAC CE from the UE to confirm the reconfiguration.

[0139] In a thirty-ninth embodiment, the processor of the thirty-eighth embodiment, wherein the new DCI field triggers the LCID reconfiguration for a period of time.

[0140] In a fortieth embodiment, the processor according to the thirty-eighth embodiment, wherein the new DCI field triggers the LCID reconfiguration for a specific feature set.

[0141] In a forty-first embodiment, the processor according to the thirty-fifth embodiment, wherein the reconfiguration includes moving one or more MAC CEs from an extended LCID (eLCID) space to an LCID space or moving one or more MAC CEs from the LCID space to an eLCID space.

[0142] In a forty-second embodiment, the processor of the thirty-fifth embodiment, wherein the reconfiguration comprises reallocating MAC CEs in an extended LCID (eLCID) space, while the LCID space remains fixed and non-configurable.

[0143] In a forty-third embodiment, the processor according to the thirty-fifth embodiment, wherein the reconfiguration includes reallocating MAC CEs in the LCID space, wherein some LCIDs are reallocated while other LCIDs remain fixed and non-configurable.

[0144] In a forty-fourth embodiment, the processor of the thirty-fourth embodiment, wherein the default LCID configuration is used during the initial access process and during an additional duration after the initial access, wherein the additional duration is defined in a specification.

[0145] In a forty-fifth embodiment, a medium access control (MAC) layer instance is configured to perform operations including the following: receiving a first MAC control element (MAC CE) within a MAC sub-protocol data unit (sub-PDU), wherein the MAC sub-protocol data unit (sub-PDU) includes a MAC sub-header and a payload including the first MACCE; identifying a group identifier (group ID) in a first octet of the MAC sub-header, wherein the group identifier (group ID) identifies a first group of MAC CEs in an extended LCID (eLCID) space, wherein the first group of MAC CEs includes the first MACCE and decoding the first MAC CE.

[0146] In a forty-sixth embodiment, according to the MAC layer instance described in the forty-fifth embodiment, each available group ID identifies a fixed number of 2 x LCIDs.

[0147] In a forty-seventh embodiment, the MAC layer instance according to the forty-fifth embodiment, wherein the number of LCIDs associated with an available group ID can vary across groups.

[0148] In a forty-eighth example, according to the MAC layer example described in the forty-fifth embodiment, the new MAC subheader format is enabled based on radio resource control (RRC) signaling or the new MAC subheader format is indicated in a reserved (R) bit in the MAC subheader.

[0149] In a forty-ninth embodiment, according to the MAC layer example described in the forty-fifth embodiment, the purpose of the group ID is re-set from the LCID field and the size of the LCID field is reduced.

[0150] Those skilled in the art will appreciate that the exemplary embodiments described above can be implemented in any suitable software configuration 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, mobile devices with operating systems such as iOS, Android, etc. In other examples, the exemplary embodiments of the above methods may be embodied as a program including lines of code stored on a non-transitory computer-readable storage medium, which, when compiled, can be executed on a processor or microprocessor.

[0151] Although this application describes various embodiments, each having different features in various combinations, those skilled in the art will understand that any feature of one embodiment may be combined with features of other embodiments in any manner that is not specifically negated or that is not functionally or logically inconsistent with the operation of the device or the prescribed function of the disclosed embodiment.

[0152] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining 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 the authorized use should be clearly stated to users.

[0153] It is obvious to those skilled in the art that various modifications can be made to the present disclosure without departing from the essence or scope of the present disclosure. Therefore, the present disclosure is intended to cover modifications and variations of the present disclosure, but only if these modifications and variations are within the scope of the appended claims and their equivalents.

Claims

1. A medium access control (MAC) layer instance, the medium access control (MAC) layer instance being configured to perform operations including: Determining to send a first MAC control element (MAC CE); Constructing a MAC sub-protocol data unit (sub-PDU), wherein the MAC sub-PDU includes a MAC sub-header and a payload including the first MACCE; indicating, in the MAC subheader, a logical channel identifier (LCID) value identifying a first group of MAC CEs classified based on features, the first group of MAC CEs including the first MAC CE; as well as The MAC sub-PDU is mapped to a transport block (TB) for transmission on a physical (PHY) layer.

2. The MAC layer instance of claim 1, wherein the characteristics used to classify the first group of MAC CEs include functions for the MAC CEs within the first group.

3. The MAC layer instance of claim 2, wherein the function comprises a sub-function within Layer 1 (L1) control, Layer 2 (L2), or an upper layer.

4. The MAC layer instance of claim 1, wherein the characteristics used to classify the first group of MAC CEs include latency requirements for the MAC CEs within the first group.

5. The MAC layer instance of claim 1, wherein the characteristics used to classify the first group of MAC CEs include logical channel prioritization (LCP) for the MAC CEs within the first group.

6. The MAC layer instance of claim 1, wherein the features used to classify the first group of MAC CEs include a feature group of features or sub-features for the MAC CEs within the first group or support for a specific combination of the features or sub-features.

7. The MAC layer instance of claim 1, wherein the feature used to classify the first group of MAC CEs comprises a 3GPP version indication for the MAC CEs within the first group.

8. The MAC layer instance of claim 1, wherein the first set of MAC CEs is included in a MAC CE container.

9. The MAC layer instance of claim 8, wherein the MAC CE container is identified by a top-level LCID value processed by a fast path component, wherein a payload of the MAC CE container includes a header to further process the MAC CE according to its function.

10. The MAC layer instance of claim 1, wherein the first group of MAC CEs is included in an extended LCID (eLCID) group.

11. A medium access control (MAC) layer instance, the medium access control (MAC) layer instance being configured to perform operations comprising: Determining to send a first MAC control element (MAC CE); Constructing a MAC sub-protocol data unit (sub-PDU), wherein the MAC sub-PDU includes a MAC sub-header and a payload including the first MACCE; Indicating a value of a reserved (R) bit in the MAC subheader, the reserved (R) bit identifying a first logical channel identifier (LCID) table set or a second LCID table set for determining a logical channel or a MAC CE identifier from an LCID value included in the MAC subheader; as well as The MAC sub-PDU is mapped to a transport block (TB) for transmission on a physical (PHY) layer.

12. The MAC layer instance of claim 11, wherein when R=0, the first LCID table set is used, and when R=1, the second LCID table set is used.

13. The MAC layer instance of claim 12, wherein the first LCID table set and the second LCID table set include the same range of LCID values.

14. The MAC layer instance of claim 12, wherein the second set of LCID tables is compressed relative to the first set of LCID tables.

15. The MAC layer instance of claim 14, wherein the second set of extended LCID (eLCID) tables is compressed relative to the first set of eLCID tables.

16. The MAC layer instance of claim 11, wherein when the MAC layer instance operates at a user equipment (UE), the operations further comprise: A radio resource control (RRC) configuration is received that enables use of the R bit.

17. The MAC layer instance of claim 11, wherein when the MAC layer instance operates at a user equipment (UE), the operations further comprise: One or more modified LCID table sets are received via radio resource control (RRC) signaling.

18. The MAC layer instance of claim 11, wherein when the MAC layer instance operates at a user equipment (UE), the UE is pre-configured with an alternative LCID table mapping, wherein each of the pre-configurations is associated with an identifier, wherein the operations further comprise: An identifier for one of the preconfigurations is received via radio resource control (RRC) signaling.

19. The MAC layer instance of claim 11, wherein when the MAC layer instance operates at a base station, the operations further comprise: A radio resource control (RRC) configuration enabling use of the R bit is sent.

20. The MAC layer instance of claim 11, wherein when the MAC layer instance operates at a base station, the operations further comprise: One or more modified LCID table sets are sent via radio resource control (RRC) signaling.

21. The MAC layer instance of claim 11, wherein when the MAC layer instance operates at a base station, the operations further comprise: An identifier corresponding to one LCID table mapping in a preconfigured set of alternative LCID table mappings is sent via radio resource control (RRC) signaling.

22. A medium access control (MAC) layer instance, the medium access control (MAC) layer instance configured to perform operations including: Determining to send a first MAC control element (MAC CE); Constructing a MAC sub-protocol data unit (sub-PDU), wherein the MAC sub-PDU includes a MAC sub-header and a payload including the first MACCE; indicating, in the MAC subheader, a group identifier (group ID) identifying a first group of MAC CEs in an extended LCID (eLCID) space, the first group of MAC CEs including the first MAC CE; as well as The MAC sub-PDU is mapped to a transport block (TB) for transmission on a physical (PHY) layer.

23. The MAC layer example according to claim 22, wherein each available group ID identifies a fixed amount of data 2 x LCIDs.

24. The MAC layer instance of claim 22, wherein the number of LCIDs associated with an available group ID can vary across groups.

25. The MAC layer example of claim 22, wherein a new MAC subheader format is enabled based on radio resource control (RRC) signaling or indicated in a reserved (R) bit in the MAC subheader.

26. The MAC layer instance of claim 22, wherein the group ID is repurposed from an LCID field and the size of the LCID field is reduced.

Images