Techniques for configuring and indicating radio resource control (RRC) messages in wireless communications

Abstract

Aspects described herein relate to configuring and indicating radio resource control (RRC) message types in wireless communications to support new UE categories, new operation modes, new use cases, or a combination thereof. Methods of configuration and indication of user equipment (UE) procedures that can support new RRC message types and coexistence with legacy RRC message types and / or for decoding new RRC message types are also described.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to provisional patent application No. 62 / 988,355, filed March 11, 2020, entitled “TECHNIQUES FOR CONFIGURING AND INDICATING RADIO RESOURCE CONTROL (RRC) MESSAGES IN WIRELESS COMMUNICATIONS”, and U.S. patent application No. 17 / 178,602, filed February 18, 2021, entitled “TECHNIQUES FOR CONFIGURING AND INDICATING RADIO RESOURCE CONTROL (RRC) MESSAGES IN WIRELESS COMMUNICATIONS”, which are assigned to the assignee of this application and are expressly incorporated herein by reference for all purposes. Background Technology

[0003] The various aspects of this disclosure generally relate to wireless communication systems, and more specifically, to Radio Resource Control (RRC) messages.

[0004] Wireless communication systems are widely deployed to provide various types of communication content, such as voice, video, packet data, messaging, and broadcasting. These systems can be multiple access systems capable of supporting communication with multiple users by sharing available system resources (e.g., time, frequency, and power). Examples of such multiple access systems include Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, and Single Carrier Frequency Division Multiple Access (SC-FDMA) systems.

[0005] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol enabling different wireless devices to communicate at the municipal, national, regional, and even global levels. For example, fifth-generation (5G) wireless communication technology (which may be called 5G New Radio (5G NR)) is envisioned to expand and support a wide range of use cases and applications relative to current mobile network generations. In one aspect, 5G communication technologies may include: enhanced mobile broadband, which addresses use cases for human-centric access to multimedia content, services, and data; ultra-reliable low-latency communication (URLLC), with specific specifications for latency and reliability; and massive machine-type communication, which allows for the connection of a large number of devices and the transmission of relatively small amounts of non-latency-sensitive information.

[0006] In wireless communication technologies such as 5G NR, radio resource control (RRC) messages can be transmitted to carry signaling information from upper layers (e.g., layers above the physical and medium access control layers), which can include broadcast messages, paging messages, common control messages, system information messages, and the like. RRC message configuration and indication in 5G NR and other wireless communication technologies are fixed to a number of specific message types and configurations. SUMMARY

[0007] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0008] According to one example, a method for wireless communication is provided. The method includes receiving a radio resource control (RRC) message from a base station, and decoding the RRC message based on a new RRC message type in a case that a resource used to receive the RRC message is a resource for the new RRC message type that is different from a legacy RRC message type, or in a case that a message type indication of the RRC message indicates that the RRC message belongs to the new RRC message type.

[0009] In another example, a method for wireless communication is provided. The method includes generating a radio resource control (RRC) message that belongs to a new RRC message type that is different from a legacy RRC message type, wherein generating the RRC message includes at least one of scheduling a resource for transmitting the RRC message to indicate that the RRC message belongs to the new RRC message type, or including a message type indication of the RRC message to indicate that the RRC message belongs to the new RRC message type, and transmitting the RRC message to one or more user equipments (UEs).

[0010] In further examples, an apparatus for wireless communication is provided that includes a transceiver, a memory configured to store instructions, and one or more processors communicatively coupled with the transceiver and the memory. The one or more processors are configured to execute the instructions to perform the operations of the methods described herein. In another aspect, an apparatus for wireless communication is provided that includes means for performing the operations of the methods described herein. In yet another aspect, a computer readable medium is provided that includes code executable by one or more processors to perform the operations of the methods described herein.

[0011] In one example, an apparatus for wireless communication is provided that includes a transceiver, a memory configured to store instructions, and one or more processors communicatively coupled to the memory and the transceiver. The one or more processors are configured to receive, from a base station, a radio resource control (RRC) message and decode the RRC message based on a new RRC message type in a case that a resource used to receive the RRC message is a resource for the new RRC message type that is different from a legacy RRC message type or in a case that a message type indication of the RRC message indicates that the RRC message belongs to the new RRC message type.

[0012] In another example, an apparatus for wireless communication is provided that includes a transceiver, a memory configured to store instructions, and one or more processors communicatively coupled to the memory and the transceiver. The one or more processors are configured to generate a radio resource control (RRC) message that belongs to a new RRC message type that is different from a legacy RRC message type, where generating the RRC message includes at least one of scheduling a resource for transmitting the RRC message to indicate that the RRC message belongs to the new RRC message type or including a message type indication of the RRC message to indicate that the RRC message belongs to the new RRC message type, and transmitting the RRC message to one or more user equipments (UEs).

[0013] To the accomplishment of the foregoing and related ends, one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects can be employed, and this description is intended to include all such aspects and their equivalents. BRIEF DESCRIPTION OF DRAWINGS

[0014] The disclosed aspects will hereinafter be described in conjunction with the appended drawings, provided to illustrate and not to limit the disclosed aspects, wherein like designations denote like elements, and wherein:

[0015] Figure 1 FIG. 1 shows an example of a wireless communication system, in accordance with various aspects of the disclosure;

[0016] Figure 2 FIG. 2 shows an example of a user equipment (UE), in accordance with various aspects of the disclosure;

[0017] Figure 3 FIG. 3 shows an example of a base station, in accordance with various aspects of the disclosure;

[0018] Figure 4 FIG. 4 shows an example of a method for detecting and processing a radio resource control (RRC) message of a new RRC message type, in accordance with various aspects of the disclosure;

[0019] Figure 5 FIG. 4 is a flow diagram illustrating an example of a method for configuring and indicating RRC messages for new RRC message types, in accordance with various aspects of the present disclosure;

[0020] Figure 6 FIG. 5 is a flow diagram illustrating an example of a method for processing RRC messages for new RRC message types, in accordance with various aspects of the present disclosure; and

[0021] Figure 7 FIG. 6 is a block diagram illustrating an example of a MIMO communication system including a base station and a UE, in accordance with various aspects of the present disclosure. DETAILED DESCRIPTION

[0022] Various aspects are now described with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects. It can be evident, however, that such aspect(s) can be practiced without these specific details.

[0023] The described features generally relate to configuring and indicating new radio resource control (RRC) message types for devices in wireless communication technologies without interrupting configuration of legacy devices in the wireless communication technologies. For example, in fifth generation (5G) new radio (NR), new RRC message types can be introduced to support new user equipment (UE) categories, new operation modes, new use cases, etc. The new RRC message types can include broadcast / multicast messages (e.g., master information block (MIB), system information block (SIB), group paging, etc.) and dedicated RRC signaling. The message types can be configured and indicated without disruption using the mechanisms described herein without interrupting operation of legacy UE categories, legacy operation modes, or legacy use cases.

[0024] In 5G NR, for example, there is a message type extension mechanism in the RRC message structure that includes a bit to indicate whether an RRC message belongs to an extended type, and a UE can distinguish a legacy message type by checking this indication bit of the RRC message type. This can apply to the broadcast control channel (BCCH), paging control channel (PCCH), and common control channel (CCCH) in 5G NR. Further, in 5G NR, at least for the PCCH and BCCH, if an encoded RRC message does not fill a transport block, the RRC layer can add padding bits to the encoded RRC message to fill the transport block, where the content of the padding bits is set to zero (0), and / or where the number of padding bits is a multiple of eight. Additionally, generally in 5G NR, a UE can consider a value in an RRC message as not understood when the value is set to: 1) an extension value that is not defined in the transport syntax version supported by the UE; or 2) a spare or reserved value unless the specification defines a specific behavior for the UE to apply when receiving the relevant spare / reserved value. Similarly, generally in 5G NR, a UE can consider a field as not understood when it is defined as spare or reserved unless the specification defines a specific behavior for the UE to apply when receiving the relevant spare / reserved field.

[0025] In this regard, in one example, the indication bit for message type can be used to indicate an RRC message of a new RRC message format, in which case a legacy UE can ignore the RRC message based on the indication of the message type. In another example, the padding bits for an RRC message can be used to indicate a new RRC message type, which can be set to a non-zero value and thus not understood by a legacy UE. In another example, other spare or reserved bits in the RRC message payload can be set to values that indicate a new RRC message type, which are not understood by a legacy UE. In other examples, the cyclic redundancy check (CRC) of an RRC message can be set to indicate a new RRC message type. In another example, configuration parameters used to schedule or indicate an RRC message can be set to indicate a new RRC message type, such as control resource set (CORESET), search space (SS) set, radio network temporary identifier (RNTI), etc., that are not used for legacy RRC messages or can be specific to the new RRC message type. In another example, resources for the new RRC message type can be allocated in time, frequency, spatial, and / or code domain that are not used for legacy RRC messages or can be specific to the new RRC message type. In any case, the new RRC message type can be configured and / or indicated without interrupting legacy RRC message communication.

[0026] Reference will be made to the drawings to describe the described features in more detail. Figures 1 to 7 The described features are presented in more detail.

[0027] As used in this application, the terms "component," "module," "system" and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a computing device and the computing device can be a component. One or more components can reside within a process and / or thread of execution and a component can be localized, both within a single computer and / or distributed across

[0028] The techniques described herein can be used for various wireless communication systems such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other systems. The terms "system" and "network" are often used interchangeably. A CDMA system can implement a radio technology such as CDMA2000, Universal Terrestrial Radio Access (UTRA), etc. CDMA2000 covers IS-2000, IS-95 and IS-856 standards. IS-2000 Versions 0 and A are commonly referred to as CDMA2000 IX, IX, etc. IS-856 (TIA-856) is commonly referred to as CDMA2000 lxEV-DO, High Rate Packet Data (HRPD), etc. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA. A TDMA system can implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA system can implement a radio technology such as Ultra Mobile Broadband (UMB), Evoluted UTRA (E-UTRA), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM TMThe teachings herein can be implemented in hardware and / or in software, including as a computer program product. Some aspects can be implemented in software and other aspects can be implemented in hardware. The disclosure can be implemented on various types of equipment and in connection with various types of systems. Various aspects can be implemented in one or more computer programs or software modules that can be implemented as software or firmware in a programmable control device, such as a microcomputer, personal computer, workstation, image computer, cell phone, PDA, or the like. The various aspects can also be implemented in a computer program product that can be executed by a programmable control device. The computer program product can be embodied in a computer readable medium, which can be a computer readable storage medium (e.g., volatile or non-volatile memory device, floppy diskette, CD ROM, DVD, Blu-ray, hard disk, etc.) or a computer readable signal medium (e.g., a propagating signal wave such as a carrier wave, light wave, etc.).

[0029] The following description provides examples, and is not limiting of the scope, applicability, or examples set forth in the claims. Changes can be made in the function and arrangement of elements discussed without departing from the scope of the disclosure. Various examples can omit, substitute, or add various procedures or components as appropriate. For instance, the methods described can be performed in an order different from that described, and various steps can be added, omitted, or combined. Also, features described with respect to some examples can be combined in other examples.

[0030] Various aspects or features will be presented in terms of systems that can include a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems can include additional devices, components, modules, etc. and / or can not include all of the devices, components, modules etc. discussed in connection with the figures. A combination of these approaches can also be used.

[0031] Figure 1is a diagram illustrating an example of a wireless communications system and an access network 100. The wireless communications system (also referred to as a wireless wide area network (WWAN)) can include base stations 102, UEs 104, an Evolved Packet Core (EPC) 160, and / or a 5G Core (5GC) 190. The base stations 102 can include macro cells (high power cellular base stations) and / or small cells (low power cellular base stations). The macro cells can include base stations. The small cells can include femtocells, picocells, and microcells. In one example, the base stations 102 can also include gNBs 180, as described further herein. In one example, according to aspects described herein, some nodes of the wireless communications system can have a modem 240 and a communication component 242 for configuring, determining an indication of, and / or decoding a new RRC message type, and according to aspects described herein, some nodes can have a modem 340 and a configuration component 342 for indicating or configuring a new RRC message type. Although the UEs 104 are shown to have a modem 240 and a communication component 242, and the base stations 102 / gNBs 180 are shown to have a modem 340 and a configuration component 342, this is one illustrative example, and in substance any node or any type of node can include a modem 240 and a communication component 242 and / or a modem 340 and a configuration component 342 for providing the respective functionality described herein.

[0032] The base stations 102 configured for 4G LTE (which can collectively be referred to as an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) can interface with the EPC 160 through backhaul links 132 (e.g., using an SI interface). The base stations 102 configured for 5G NR (which can collectively be referred to as Next Generation RAN (NG-RAN)) can interface with the 5GC 190 through backhaul links 184. In addition to other functions, the base stations 102 can perform one or more of the following functions: transfer of user data, radio channel ciphering and deciphering, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection setup and release, load balancing, distribution of paging information, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS), user and device configuration, user and device tracking, RAN information management (RIM), paging, positioning, and delivery of warning messages. The base stations 102 can communicate directly or indirectly (e.g., through the EPC 160 or 5GC 190) with each other over backhaul links 134 (e.g., using an X2 interface). The backhaul links 134 can be wired or wireless.

[0033] The base stations 102 can wirelessly communicate with one or more UEs 104. Each of the base stations 102 can provide communication coverage for a respective geographic coverage area 110. There can be overlapping geographic coverage areas 110. For example, a small cell 102' can have a coverage area 110' that overlaps with one or more macrocells 102. A network that includes both small cell and macrocells can be known as a heterogeneous network. A heterogeneous network can also include Home Evolved NodeBs (eNBs) (HeNBs), which can provide service to a restricted group, such as a family or a business, in which case the HeNBs can be configured to

[0034] In another example, certain UEs 104 can communicate with each other using device-to-device (D2D) communication link 158. The D2D communication link 158 can use the DL / UL WWAN spectrum. The D2D communication link 158 can use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH), a physical sidelink discovery channel (PSDCH), a physical sidelink shared channel (PSSCH), and a physical sidelink control channel (PSCCH). D2D communication can be through a variety of wireless D2D communications systems, such as for example, FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi based on the IEEE 802.11 standard, LTE, or NR.

[0035] The wireless communications system can also include a Wi-Fi access point (AP) 150 in communication with Wi-Fi stations (STAs) 152 via communication links 154 in a 5 GHz unlicensed frequency spectrum. When communicating in an unlicensed frequency spectrum, the STAs 152 / AP 150 can perform a clear channel assessment (CCA) prior to communicating in order to determine whether the channel is available.

[0036] The small cells 102' can operate in a licensed and / or an unlicensed frequency spectrum. When operating in an unlicensed frequency spectrum, the small cells 102' can employ NR and use the same 5 GHz unlicensed frequency spectrum as used by the Wi-Fi AP 150. The small cells 102' employing NR in an unlicensed frequency spectrum can boost coverage and / or increase capacity for wireless networks.

[0037] The base stations 102, whether small cell 102' or large cell (e.g., macro base station), can include an eNB, gNodeB (gNB), or other type of base station. Some of the base stations, such as gNB 180, can operate in a traditional sub 6 GHz spectrum, in millimeter wave (mmW) frequencies, and / or near mmW frequencies in communication with the UEs 104. When the gNB 180 operates in mmW or near mmW frequencies, the gNB 180 can be referred to as a mmW base station. Extremely high frequency (EHF) is part of the RF in the electromagnetic spectrum. EHF has a range from 30 GHz to 300 GHz and a wavelength between 1 millimeter and 10 millimeters. Radio waves in this band can be referred to as a millimeter wave. Near mmW can extend down to a 3 GHz frequency with a wavelength of 100 millimeters. The super high frequency (SHF) band extends between 3 GHz and 30 GHz, also referred to as centimeter wave. Communications using the mmW / near mmW radio frequency band have extremely high path loss and short range. The mmW base station 180 can utilize beamforming 182 with the UEs 104 to compensate for the extremely high path loss and short range. The base stations 102 referred to herein can include a gNB 180.

[0038] The EPC 160 can include a mobility management entity (MME) 162, other MMEs 164, a serving gateway 166, a multimedia broadcast multicast service (MBMS) gateway 168, a broadcast multicast service center (BM-SC) 170, and a packet data network (PDN) gateway 172. The MME 162 can be in communication with a home subscriber server (HSS) 174. The MME 162 is the control node that processes the signaling between the UEs 104 and the EPC 160. Generally, the MME 162 provides bearer and connection management. All user Internet protocol (IP) packets are transferred through the serving gateway 166, which itself is connected to the PDN gateway 172. The PDN gateway 172 provides UE IP address allocation as well as other functions. The PDN gateway 172 and the BM-SC 170 are connected to the IP services 176. The IP services 176 can include the Internet, an intranet, an IP multimedia subsystem (IMS), a PS streaming service, and / or other IP services. The BM-SC 170 can provide functions for MBMS user service provisioning and delivery. The BM-SC 170 can serve as an entry point for content provider MBMS transmission, can be used to authorize and initiate MBMS Bearer Services, and can be used to schedule MBMS transmissions. The MBMS gateway 168 can be used to

[0039] The 5GC 190 can include an access and mobility management function (AMF) 192, other AMFs 193, a session management function (SMF) 194, and a user plane function (UPF) 195. The AMF 192 can be in communication with a unified data management (UDM) 196. The AMF 192 can be the control node that processes the signaling between the UEs 104 and the 5GC 190. Generally, the AMF 192 can provide QoS flow and session management. User Internet protocol (IP) packets (e.g., packets from one or more UEs 104) can be transferred through the UPF 195. The UPF 195 can provide UE IP address allocation as well as other functions; for example, the UPF 195 can act as an anchor for intra- / inter-RAT mobility, an anchor for UV mobility, or as a broadcast multicast service center (BM-SC). The UPF 195 can be connected to one or more of the UEs 104 by way of an NG2 interface. The UPF 195 can be connected to the IP services 197. The IP services 197 can include the Internet, an intranet, an IP multimedia subsystem (IMS), a PS streaming service, and / or other IP services.

[0040] A base station can also be referred to as a gNB, NodeB, evolved NodeB (eNB), an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS), an extended service set (ESS), a transmit reception point (TRP), or some other suitable terminology. A base station 102 provides an access point to the EPC 160 or 5GC 190 for a UE 104. Examples of UEs 104 include a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small kitchen appliance, a healthcare device, an implant, a sensor / actuator, a display, or any other similar functional device. Some of the UEs 104 can be referred to as IoT devices (e.g., a parking meter, gas pump, toaster, vehicle, heart monitor, etc.). IoT UEs can include MTC / eMTC (also called Category (CAT)-M, Cat Ml) UEs, NB-IoT (also called CAT NB1) UEs, as well as other types of UEs. In the present disclosure, eMTC and NB-IoT can refer to future technologies that can evolve from these technologies or can be based on these technologies. For example, eMTC can include FeMTC (further eMTC), eFeMTC (enhanced further eMTC), mMTC (massive MTC), etc., while NB-IoT can include eNB-IoT (enhanced NB-IoT), FeNB-IoT (further enhanced NB-IoT), etc. A UE 104 can also be referred to as a station, a mobile, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communication device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology.

[0041] In one example, the communication component 242 can determine the RRC message of the new RRC message type using the various mechanisms described herein. For example, the communication component 242 can determine that the RRC message belongs to the new RRC message type based on the resource through which the new RRC message is received or based on an explicit or implicit message type indication in the RRC message, etc. For example, the new RRC message can indicate the new RRC message type using a parameter defined for a legacy RRC message, such as an indicator bit of the message type, padding bits, a spare or reserved field, etc. In another example, the new RRC message can indicate a CRC, a CORESET, a SS set, an RNTI, etc., which can imply the new RRC message type. In any case, the communication component 242 can determine the new RRC message type accordingly and can decode the RRC message accordingly. In one example, the RRC message can be generated by the configuration component 342 and transmitted to the UE 104 by the corresponding base station 102. Thus, for example, the configuration component 342 can generate the RRC message to indicate the new RRC message type, as described above and further herein.

[0042] Turning now to Figures 2 to 7 , aspects are described with reference to one or more components and one or more methods that can perform the actions or operations described herein, where aspects in dashed line can be optional. Although the operations described below in Figures 4-6 are presented in a particular order and / or by example components, it should be understood that the ordering of the actions and the components performing the actions can be changed, depending on the implementation. Moreover, it should be understood that the following actions, functions, and / or described components can be performed by a processor specifically programmed to perform the actions, a processor executing an

[0043] Referring to Figure 2 , one example of an implementation of the UE 104 can include various components, some of which have already been described above and are described further herein, including components such as the one or more processors 212 and memory 216 and transceiver 202 in communication via one or more buses 244, which can operate in conjunction with the modem 240 and / or the communication component 242 for configuring, determining an indication of a new RRC message type, and / or decoding a new RRC message type, as described further herein.

[0044] In one aspect, the one or more processors 212 can include modem 240 and / or can be part of modem 240 that uses one or more modem processors. Thus, the various functions related to communication component 242 can be included in modem 240 and / or processors 212 and, in one aspect, can be executed by a single processor, while in other aspects, different ones of the functions can be executed by a combination of two or more different processors. For example, in one aspect, the one or more processors 212 can include any one or any combination of a modem processor, or a baseband processor, or a digital signal processor, or a transmit processor, or a receiver processor, or a transceiver processor associated with transceiver 202. In other aspects, some of the features of the one or more processors 212 and / or modem 240 associated with communication component 242 can be performed by transceiver 202.

[0045] Further, memory 216 can be configured to store data used by at least one of the processors 212 or software 275 or communication component 242 and / or one or more of its subcomponents executed by at least one of the processors 212. Memory 216 can include any type of computer-readable medium usable by a computer or at least one of the processors 212, such as random access memory (RAM), read only memory (ROM), tapes, magnetic

[0046] The transceiver 202 can include at least one receiver 206 and at least one transmitter 208. The receiver 206 can include hardware, firmware, and / or software code executable by a processor for receiving data, the code including instructions for receiving data and being stored in a memory (e.g., computer-readable medium). The receiver 206 can be, for example, a radio frequency (RF) receiver. In an aspect, the receiver 206 can receive signals transmitted by at least one base station 102. Additionally, the receiver 206 can process such received signals, and also can obtain measurements of the signals, such as, but not limited to, Ec / Io, signal-to-noise ratio (SNR), reference signal received power (RSRP), received signal strength indicator (RSSI), etc. The transmitter 208 can include hardware, firmware, and / or software code executable by the processor for transmitting data, the code including instructions for transmitting data and being stored in the memory (e.g., computer-readable medium). A suitable example of the transmitter 208 can including, but not limited to, an RF transmitter.

[0047] Further, in an aspect, the UE 104 can include a RF front end 288, which can operate in communication with the one or more antennas 265 and the transceiver 202 for receiving and transmitting radio transmissions, for example, wireless communications transmitted by the at least one base station 102 or wireless transmissions transmitted by the UE 104. The RF front end 288 can be connected to the one or more antennas 265 and can include one or more low-noise amplifiers (LNAs) 290, one or more switches 292, one or more power amplifiers (PAs) 298, and one or more filters 296 for transmitting and receiving RF signals.

[0048] In an aspect, the LNA 290 can amplify a received signal at a desired output level. In an aspect, each LNA 290 can have specified minimum and maximum gain values. In an aspect, the RF front end 288 can use the one or more switches 292 to select a particular LNA 290 and its specified gain value based on a desired gain value for a particular application.

[0049] Further, for example, the RF front end 288 can use one or more PA(s) 298 to amplify a signal for an RF output at a desired output power level. In an aspect, each PA 298 can have specified minimum and maximum gain values. In an aspect, the RF front end 288 can use the one or more switches 292 to select a particular PA 298 and its specified gain value based on a desired gain value for a particular application.

[0050] Similarly, for example, RF front-end 288 may use one or more filters 296 to filter the received signal to obtain the input RF signal. Likewise, in one aspect, for example, a corresponding filter 296 may be used to filter the output from a corresponding PA 298 to produce an output signal for transmission. In one aspect, each filter 296 may be connected to a specific LNA 290 and / or PA 298. In one aspect, RF front-end 288 may use one or more switches 292 to select the transmit or receive path using a specified filter 296, LNA 290, and / or PA 298 based on a configuration as specified by transceiver 202 and / or processor 212.

[0051] Thus, transceiver 202 can be configured to transmit and receive wireless signals via RF front-end 288 through one or more antennas 265. In one aspect, the transceiver can be tuned to operate at a specified frequency, enabling UE 104 to communicate with, for example, one or more base stations 102 or one or more cells associated with one or more base stations 102. In another aspect, for example, modem 240 can configure transceiver 202 to operate at a specified frequency and power level based on the UE configuration of UE 104 and the communication protocol used by modem 240.

[0052] In one aspect, modem 240 may be a multi-band, multi-mode modem capable of processing digital data and communicating with transceiver 202, enabling the use of transceiver 202 to transmit and receive digital data. In another aspect, modem 240 may be multi-band and configured to support multiple frequency bands for a specific communication protocol. In another aspect, modem 240 may be multi-mode and configured to support multiple operating networks and communication protocols. In one aspect, modem 240 may control one or more components of UE 104 (e.g., RF front-end 288, transceiver 202) to transmit and / or receive signals from the network based on a specified modem configuration. In one aspect, the modem configuration may be based on the modem's mode and the frequency band in use. In another aspect, the modem configuration may be based on UE configuration information associated with UE 104, such as information provided by the network during cell selection and / or cell reselection.

[0053] In one aspect, the communication component 242 may optionally include a message type determination component 252 for determining the RRC message type of a received RRC message, and / or a message processing component 254 for processing the RRC message based on the RRC message type, as further described herein.

[0054] In one respect, processor 212 can correspond to a combination Figure 7one or more of the processors described in connection with the UE in Figure 7 The memory 216 can correspond to the memory described in connection with the UE in

[0055] Referring to Figure 3 One example of an implementation of the base station 102 (e.g., base station 102 and / or gNB 180 as described above) can include various components

[0056] The transceiver 302, receiver 306, transmitter 308, one or more processors 312, memory 316, applications 375, buses 344, RF front end 388, LNAs 390, switches 392, filters 396, PAs 398, and one or more antennas 365 can be the same as or similar to the corresponding components of UE 104, but configured or otherwise programmed for base station operations rather than UE operations, as described above.

[0057] In one aspect, the configuration component 342 can optionally include a scheduling component 352 for scheduling resources for transmitting RRC messages, and / or a message generation component 354 for generating RRC messages that can belong to a new (or legacy) RRC message type, as described further herein.

[0058] In one aspect, the processor 312 can correspond to one or more of the processors described in connection with the base station in Figure 7 The memory 316 can correspond to the memory described in connection with the base station in Figure 7

[0059] Figure 4 A flow diagram illustrating an example of a method 400 for configuring and / or indicating RRC messages of a new RRC message type is shown. Figure 5 A flow diagram illustrating an example of a method 500 for receiving and decoding RRC messages of a new RRC message type is shown. In one example, a base station can perform the functionality described in the method 400 using one or more of the components described in Figure 1 and Figure 3 The UE can perform the functionality described in the method 400 using one or more of the components described in Figure 1 and Figure 2 ​One or more of the components described in the preceding description can perform the functions described in the method 500. The methods 400 and 500 are described below in connection with one another to facilitate explanation of the associated functionality and concepts. The methods 400 and 500 need not be performed in conjunction with one another, and in at least one example, a device can be configured to perform the method 400 without having a corresponding device performing the method 500, and vice versa.

[0060] In the method 400, at block 402, an RRC message belonging to a new RRC message type can be generated. In one aspect, the message generation component 354 (e.g., in conjunction with the processor(s) 312, the memory 316, the transceiver 302, the configuration component 342, etc.) can generate an RRC message belonging to a new RRC message type. For example, the message generation component 354 can generate an RRC message based on one or more aspects, use cases, modes of operation, etc., of the UE 104 for which the message is being generated. In one example, the message generation component 354 can generate an RRC message for a new UE class, which can include a NR-light device or other implementable class. In this example, the NR-light device can have one or more different RRC messages than other (e.g., legacy) devices, which have different RRC parameters.

[0061] In another example, the message generation component 354 can generate an RRC message for a new use case, such as non-orthogonal multiple access (NOMA), coverage enhancement (e.g., multiple instances of an RRC message being transmitted), communication enhancement based on sidelink (e.g., a new RRC message corresponding to sidelink communication between devices), small data transmission from RRC idle / inactive state, etc. In yet another example, the message generation component 354 can generate an RRC message for a new mode of operation of a device or other network component, such as half duplex frequency division duplexing (HD-FDD) for NR light, dynamic spectrum sharing (DSS) for NR light, enhanced UE paging (e.g., multiple RRC paging messages being transmitted), enhanced multiple transmission / reception points (TRPs), enhanced connected mode discontinuous reception (C-DRX), etc. The new RRC message can be, for example, a newly defined RRC message in a wireless communication technology (e.g., 5G NR) on top of other RRC messages to allow for extending or enhancing functionality or related parameters communicated using the RRC message. The other RRC messages defined in the wireless communication technology can be messages defined in a version or technical specification (TS) of the wireless communication technology, which can also be referred to or can include legacy RRC messages, legacy RRC parameters, etc.

[0062] In method 400, at block 404, the RRC message can be transmitted to one or more UEs. In an aspect, configuration component 342, e.g., in combination with processor 312, memory 316, transceiver 302, etc., can transmit the RRC message to one or more UEs. For example, configuration component 342 can transmit the RRC message on resources (e.g., time, frequency, spatial, code, etc. resources) defined for transmitting the RRC message. In one example, configuration component 342 can transmit the RRC message in a search space defined for the RRC message based on a CORESET defined for the RRC message, etc. Further, as described herein, the resources can be defined for any RRC message in a wireless communication technology, or the resources can be defined specifically for the new RRC message (and / or defined based on a particular type of new RRC message being transmitted, or based on a UE class or class, use case, mode of operation, etc. for which the new RRC message is being transmitted, etc.).

[0063] In method 500, at block 502, the RRC message can be received. In an aspect, communication component 242, e.g., in combination with processor 212, memory 216, transceiver 202, etc., can receive the RRC message. For example, communication component 242 can receive the RRC message on resources (e.g., time, frequency, spatial, code, etc. resources) defined for receiving the RRC message. In one example, communication component 242 can receive the RRC message in a search space defined for the RRC message based on a CORESET defined for the RRC message, etc. Further, as described herein, the resources can be defined for any RRC message in a wireless communication technology, or the resources can be defined specifically for the new RRC message (and / or defined based on a particular type of new RRC message being transmitted, or based on a UE class or class, use case, mode of operation, etc. for which the new RRC message is being transmitted, etc.).

[0064] In method 500, optionally at block 504, it can be determined that the RRC message belongs to a new RRC message type. In an aspect, message type determination component 252, e.g., in combination with processor 212, memory 216, transceiver 202, communication component 242, etc., can determine that the RRC message belongs to a new RRC message type. For example, the new RRC message type can be different from a legacy RRC message type currently defined in 5G NR. Further, the new RRC message type can be indicated using various mechanisms described above and further herein.

[0065] In method 500, at block 506, the RRC message can be decoded based on the new RRC message type. In one aspect, the message handling component 254, e.g., in combination with the processor(s) 212, memory 216, transceiver 202, communication component 242, etc., can decode the RRC message based on the new RRC message type, e.g., based on determining that the RRC message belongs to the new RRC message type. For example, the message handling component 254 can decode the RRC message as belonging to the new RRC message type, where the resources used to receive the RRC message are resources for the new RRC message type (e.g., as opposed to resources for a legacy RRC message type), or where a message type indication of the RRC message indicates that the RRC message belongs to the new RRC message type, etc. For example, the message handling component 254 can determine a structure of the RRC message (e.g., a structure of fields and / or related values in the RRC message) based on determining the RRC message type. As described, for example, the RRC message can belong to a new RRC message type for indicating RRC message data for a new UE category, use case, mode of operation, etc. Accordingly, the message handling component 254 can decode the new RRC message to obtain information regarding the new UE category, use case, mode of operation, etc., to determine reception of the new RRC message and / or subsequent RRC messages in accordance with the new UE category, use case, mode of operation, etc., and / or similar information. In one example, decoding the new RRB message can be based on determining that the RRC message belongs to the new RRC message type or format (e.g., as determined at block 504).

[0066] When generating the RRC message at block 402, optionally at block 406, resources for transmitting the RRC message can be selected to indicate the new RRC message type. In one aspect, the message generation component 354, e.g., in combination with the processor 312, the memory 316, the transceiver 302, the configuration component 342, etc., can select resources for transmitting the RRC message to indicate the new RRC message type. For example, the message generation component 354 can select resources on which to transmit the RRC message, where the resources can be selected from known resources to indicate the new RRC message type. For example, the resources can be defined, configured, or otherwise known between the UE 104 and the base station 102 for communicating RRC messages of the new RRC message type, or the resources can be configured or known not to be used for legacy RRC information. The resources can include one or more of time, frequency, spatial, code, etc. domain resources that are specific to the new RRC message type, which can include specific resources for a particular new RRC message type, resources for all new RRC message types (where a more specific type can be indicated in the RRC message), etc. Thus, in one example, the resources can differ in one aspect of time, frequency, space, and / or code from legacy resources defined for legacy RRC messages. In one example, the base station 102 can configure the resources to the UE 104, or the UE 104 can otherwise be aware of the resources (e.g., based on implementation of UE functionality defined by the wireless communication technology).

[0067] Further, for example, the message generation component 354 can select the resources as dedicated resources related to a new monitoring occasion for the new RRC message type. For example, the new monitoring occasion can be defined by a periodicity for the monitoring occasion, a slot / symbol level offset for the monitoring occasion, etc. In other examples, the message generation component 354 can select the resources to include a new bandwidth part (BWP), sub-band, etc. for the new RRC message type. Further, in one example, the message generation component 354 can select the resources to include a new beam, antenna panel or antenna port index, transmission configuration indication (TCI) state, etc. for the new RRC message type. In yet another example, the message generation component 354 can select the resources to include a new scrambling scheme for the new RRC message type. In the foregoing examples, the message generation component 354 can select the resources to include new features that are not defined for legacy RRC messages in order to distinguish the RRC messages of the new RRC message type and / or prevent legacy UEs from attempting to decode the RRC messages of the new RRC message type, etc.

[0068] Upon determining, at block 504, that the RRC message belongs to the new RRC message type, optionally at block 508, the RRC message can be determined to belong to the new RRC message type based on resources used to receive the RRC message. In one aspect, the message type determination component 252, e.g., in combination with the processor 212, the memory 216, the transceiver 202, the communication component 242, etc., can determine that the RRC message belongs to the new RRC message type based on resources used to receive the RRC message. For example, as described, the RRC message can be received over resources specifically defined for the new RRC message type and / or multiple types, and these resources can not be used for legacy RRC message types. In this example, the message type determination component 252 can accordingly distinguish the RRC message as belonging to the new RRC message type based on determining that the resources over which the RRC message is received are specific to the new RRC message type (e.g., in terms of time, frequency, space, code, etc.). In one example, the message type determination component 252 can determine the resources over which the RRC message is received based on monitoring various resources. In one example, the base station 102 can configure resources, monitoring occasions, or other indications of resources, etc., for the UE 104, and the message type determination component 252 can determine the new RRC message type based on the configured resources.

[0069] In this example, the method 400 can optionally include, at block 408, transmitting scheduling information or an indication of resources for transmitting the RRC message. In one aspect, the configuration component 342, e.g., in conjunction with the processor 312, the memory 316, the transceiver 302, etc., can transmit scheduling information or an indication of resources for transmitting the RRC message, which can involve or otherwise implicitly indicate the new RRC message type. For example, the configuration component 342 can transmit scheduling information for the RRC message (e.g., in lower layer signaling, such as physical (PHY) or medium access control (MAC) layer signaling), where the scheduling information can indicate a mapping to a physical downlink control channel (PDCCH), which can include PDCCH resources defining the PDCCH on which the RRC message can be transmitted. In another example, the configuration component 342 can transmit an indication of resources for the new RRC message type (e.g., in the PDCCH or in a lookup table or other structure transmitted in system information (SI) or other RRC signaling), which can define monitoring occasions in the PDCCH for the RRC message of the new RRC message type. For example, the indication of resources can identify a periodicity of monitoring occasions, a slot / symbol level offset, etc., within the PDCCH. In one example, the indication of resources can additionally or alternatively identify one or more of a BWP / subband, a beam, an antenna panel or port index, a TCI state, a scrambling scheme, etc., for transmitting the RRC message of the new RRC message type. In either case, for example, the resources can include or can be different from resources used to transmit a legacy RRC message.

[0070] Further, in this example, the method 500 can optionally include, at block 510, receiving scheduling information or an indication of resources for receiving the RRC message. In an aspect, the message type determination component 252, e.g., in conjunction with the processor 212, memory 216, transceiver 202, communication component 242, etc., can receive scheduling information or an indication of resources for receiving the RRC message. For example, the message type determination component 252 can receive scheduling information defining a PDCCH over which a new RRC message type is transmitted (e.g., in lower layer signaling), and / or can receive an indication of resources of the PDCCH over which a new RRC message type is transmitted (e.g., monitoring occasion information, BWP, sub-band, beam, antenna panel or port, TCI state, scrambling scheme, etc.) of the RRC message. However, in other examples, at least a portion of this information can be specified in standards of a wireless communication technology (e.g., 5G NR) and implemented accordingly in the memory 216 of the UE and / or the memory 316 of the base station. In any case, the message type determination component 252 can determine that the RRC message received over the time and / or frequency resources defined in the scheduling information and / or as indicated in the PDCCH belongs to the new RRC message type.

[0071] In another example, when generating the RRC message at block 402, optionally at block 410, a message type indication can be included to indicate that the RRC message belongs to a new RRC message type. In one aspect, the message generation component 354 (e.g., in combination with the processor 312, the memory 316, the transceiver 302, the configuration component 342, etc.) can include a message type indicator to indicate that the RRC message belongs to a new RRC message type. For example, the message generation component 354 can include the message type indication as an explicit or implicit indication that the message type belongs to a new RRC message type. For example, the message generation component 354 can include the message type indication using bits corresponding to an extension mechanism defined in 5G NR for extending RRC message types. For example, 5G NR currently defines one indication bit to allow for the definition of extensions of certain RRC messages, such as RRC messages transmitted over BCCH, PCCH, or CCCH, as described above. BCCH can be used to transmit system information and can be mapped to physical channels including a physical broadcast channel (PBCH), a physical downlink shared channel (PDSCH), a physical downlink control channel (PDCCH) (e.g., for scheduling PDSCH), etc. PCCH can be used to transmit paging information, to inform UEs of updates to system information, to transmit wake-up signals to UEs, etc., and can be mapped to physical channels including PDSCH, PDCCH (e.g., for scheduling PDSCH), etc. CCCH can be used to transmit control information related to random access procedures and can be mapped to physical channels including PDCCH, PDSCH, etc.

[0072] For example, 5G NR can define various RRC message categories, such as BCCH-BCH-MessageType, PCCH-MessageType, DL-CCCH-MessageType, or BCCH-DL-SCH-MessageType, which include a messageClassExtension field that can be a parameter (e.g., a bit or other parameter) that, when set to a non-zero value, can indicate that there are message extensions for the RRC message type. Further, in one example, at least PCCH-MessageType and DL-CCCH-MessageType can have spare or reserved bits defined in the message type. Thus, in one particular example, message generation component 354 can use at least one of the messageClassExtension field or one or more spare or reserved bits for certain RRC messages to indicate a new RRC message type. For example, message generation component 354 can use one of the above message categories (e.g., BCCH-BCH-MessageType, PCCH-MessageType, DL-CCCH-MessageType, or BCCH-DL-SCH-MessageType) for a new RRC message type (e.g., as a legacy RRC message category or as a new message category derived from a legacy RRC message category or otherwise include parameters similar to a legacy RRC message category) and can reset the message type indicator (e.g., the messageClassExtension field) to a value used in the relevant RRC message category to indicate the new RRC message type. For example, a legacy device or a device that only supports legacy operations or use cases can not understand this value (e.g., a non-zero value or other value not defined for legacy devices, operations, or use cases) and, as such, can be ignored to prevent the legacy device from attempting to decode the new RRC message type.

[0073] In another example, the message generation component 354 can use one or more spare or reserved bits of a message class to indicate a new RRC message type. In one particular example, the message generation component 354 can use one or more spare bits of a PCCH-MessageType or DL-CCCH-MessageType message class to indicate a new RRC message type. In one example, one bit can be used to indicate a new RRC message type (e.g., as opposed to a legacy RRC message type) and / or additional bits can be used to indicate different types of each new RRC message type, etc. For example, using a spare or reserved bit for an RRC message can include the message generation component 354 setting the spare or reserved bit to an extension value (e.g., a value other than zero or otherwise not used in a legacy RRC message), which can not be understood by legacy UEs and / or can only be understood by desired devices or groups of devices associated with a new UE class, new use case, or new mode of operation.

[0074] In another example, the message generation component 354 can use padding bits of an RRC message to indicate a new RRC message type. For example, if an encoded RRC message (e.g., following ASN.1 encoding) does not pad a transport block, the RRC layer of the base station 102 can typically add padding bits to pad the transport block, where each padding bit is set to zero and the number of padding bits is a multiple of eight. In one example, this can apply to BCCH and PCCH RRC messages. In this example, the message generation component 354 can instead set one or more padding bits to a value used to indicate a new RRC message type. For example, setting a padding bit of an RRC message to an extension value can not be understood by legacy UEs and, as such, the legacy UEs can not process the RRC message, but a UE that supports the message can determine the new RRC message type based on the value of the one or more padding bits. For example, the value of the one or more padding bits can be set to a non-zero value.

[0075] In the above example, upon determining at block 504 that the RRC message belongs to the new RRC message type, optionally at block 512, the RRC message can be determined to belong to the new RRC message type based on a message type indication. In one aspect, the message type determination component 252, e.g., in combination with the processor 212, the memory 216, the transceiver 202, the communication component 242, etc., can determine that the RRC message belongs to the new RRC message type based on a message type indication. In one example, the message type indication can be used for both legacy RRC message types and new RRC message types. For example, as described, the RRC message can include a configurable parameter, such as a message type indication in a parameter of the RRC message class, where the RRC message class can be or can be derived from a legacy RRC message class, as described. In this example, the message type determination component 252 can determine the message type based on a value of the message type indicator in the RRC message class. In another example, the RRC message can include a message type indication in one or more spare or reserved bits defined in the RRC message class, where the RRC message class can be or can be derived from a legacy RRC message class, as described. In this example, the message type determination component 252 can determine the message type based on a value of the one or more spare or reserved bits. In another example, the RRC message can include a message type indication in one or more padding bits included in the RRC message, as described. In this example, the message type determination component 252 can determine the message type based on a value of the one or more padding bits.

[0076] In another example, upon generating the RRC message at block 402, optionally at block 412, the RRC message can be generated based on a CRC scheme that implies the new RRC message type. In one aspect, the message generation component 354, e.g., in combination with the processor 312, the memory 316, the transceiver 302, the configuration component 342, etc., can generate the RRC message based on a CRC scheme that implies the new RRC message type. For example, the message generation component 354 can apply a CRC to payload bits of the RRC message based on the CRC scheme. In one example, the message generation component 354 can determine to modify one or more parameters of the CRC scheme with a value known or configured to indicate the new RRC message type. For example, the message generation component 354 can modify a length of parity bits of the CRC scheme, an interleaving scheme of the CRC bits, etc., to a value that is only for the new RRC message type in order to indicate the new RRC message type.

[0077] In this example, upon determining at block 504 that the RRC message belongs to the new RRC message type, optionally at block 514, the RRC message can be determined to belong to the new RRC message type based on a CRC of the RRC message. In one aspect, the message type determination component 252, e.g., in combination with the processor 212, the memory 216, the transceiver 202, the communication component 242, etc., can determine that the RRC message belongs to the new RRC message type based on a CRC of the RRC message. For example, the message type determination component 252 can determine the CRC of the RRC message based on performing CRC scheme detection to determine one or more parameters related to the CRC of the RRC message. In this example, the message type determination component 252 can perform the CRC scheme detection based on various parameter values to attempt to determine whether certain parameter values are indicative of the new RRC message type (e.g., length of parity bits, interleaving scheme of CRC bits, etc.), and if so, can determine that the RRC message belongs to the new RRC message type.

[0078] In another example, upon generating the RRC message at block 402, optionally at block 414, a CORESET or SS set for the RRC message can be generated that implies the new RRC message type. In one aspect, the message generation component 354, e.g., in combination with the processor 312, the memory 316, the transceiver 302, the configuration component 342, etc., can generate a CORESET or SS set for the RRC message that implies the new RRC message type. For example, the message generation component 354 can configure a PDCCH that schedules the new RRC message based on one or more CORESET parameters or SS set parameters defined for the new RRC message type. For example, the CORESET or SS set parameters can include or otherwise indicate a set of time, frequency, space, code, etc. resources for the PDCCH that schedules the new RRC message. In one example, the CORESET or SS set parameters can include parameters that are different from or otherwise not defined for traditional RRC message types. For example, the CORESET and / or SS set parameters (or configuration) can be configured to the UE 104 (e.g., by the base station 102) or otherwise known by the base station 102 and the UE 104 (e.g., based on its implementation of the wireless communication techniques, as described).

[0079] In this example, upon determining at block 504 that the RRC message belongs to the new RRC message type, optionally at block 516, the RRC message can be determined to belong to the new RRC message type based on a CORESET or SS set used for the RRC message. In one aspect, the message type determination component 252, e.g., in combination with the processor 212, the memory 216, the transceiver 202, the communication component 242, etc., can determine that the RRC message belongs to the new RRC message type based on a CORESET or SS set used for the RRC message. For example, the message type determination component 252 can monitor for the RRC message based on a CORESET or SS set configuration for the new RRC message type and / or can monitor for a legacy RRC message based on a CORESET or SS set defined for the legacy RRC message. In this example, based on detecting the CORESET or SS set of the RRC message, the message type determination component 252 can determine whether the RRC message belongs to the new RRC message type, whether the RRC message belongs to the legacy RRC message type, and / or the like.

[0080] In another example, upon generating the RRC message at block 402, optionally at block 416, an RNTI that implies the new RRC message type can be applied to the RRC message or a control channel that schedules the RRC message. In one aspect, the message generation component 354, e.g., in combination with the processor 312, the memory 316, the transceiver 302, the configuration component 342, and / or the like, can apply an RNTI that implies the new RRC message type to the RRC message or a control channel that schedules the RRC message. For example, the message generation component 354 can configure an RNTI value that is unique to the new RRC message type, which the message generation component 354 can apply to the new RRC message (e.g., scramble the new RRC message) and / or can use to mask a CRC of the PDCCH. For example, the RNTI can be configured to the UE 104 (e.g., by the base station 102) or otherwise known to the base station 102 and the UE 104 (e.g., based on its implementation of the wireless communication techniques, as described).

[0081] In this example, upon determining at block 504 that the RRC message belongs to the new RRC message type, optionally at block 518, the RRC message can be determined to belong to the new RRC message type based on an RNTI applied to the RRC message or a control channel thereof. In one aspect, the message type determination component 252, e.g., in combination with the processor 212, the memory 216, the transceiver 202, the communication component 242, and / or the like, can determine that the RRC message belongs to the new RRC message type based on an RNTI applied to (e.g., used to scramble) the RRC message or a control channel thereof. For example, the message type determination component 252 can attempt to decode or descramble a signal received in a search space based on an RNTI to determine whether the signal indicates the new RRC message type.

[0082] In cases where the new RRC message can be differentiated based on an explicit or implicit message type indication, as described in the example above, the new RRC message type can reuse resources allocated for legacy RRC messages. In this or other examples, the new RRC message type can have the same or different payload size as legacy RRC messages, the same or different number of fields as legacy RRC messages, the same or different field size for “common” fields as legacy RRC messages, the same or different mapping order for MAC sub-protocol data units (PDUs) as legacy RRC messages, the same or different content of MAC sub-headers as legacy RRC messages, and / or the like. The message generation component 354 can generate the RRC message of the new RRC message type accordingly based on these parameters. In any case, the message processing component 254 can decode the received RRC message based on the determined new RRC message type (e.g., based on the same or different number of fields as legacy RRC messages, the same or different field size for “common” fields as legacy RRC messages, the same or different mapping order for MAC sub-protocol data units (PDUs) as legacy RRC messages, the same or different content of MAC sub-headers as legacy RRC messages, and / or the like) as indicated or configured for the new RRC message.

[0083] Additionally, in one example, in the method 500, optionally at block 520, a determination can be made that decoding of the RRC message is supported based on the new RRC message type. In one aspect, the message type determination component 252 (e.g., in combination with the processor(s) 212, memory 216, transceiver 202, communication component 242, and / or the like) can determine that decoding of the RRC message is supported based on the new RRC message type. For example, the message type determination component 252 can determine this based on a determination of the new RRC message type and / or an ability to otherwise correctly determine related parameters (e.g., message type indication, and / or the like). In any case, for example, the message processing component 254 can determine to decode the RRC message based on the message type determination component 252 determining that the new RRC message type is supported.

[0084] While the examples described above describe using mechanisms for distinguishing new RRC message types from legacy RRC message types, these mechanisms can additionally or alternatively be used to distinguish certain new RRC message types from other RRC message types. For example, a set of resources, indicators, spare or reserved bits or bit values, padding bits or bit values, CRC, CORESET or SS set configurations, RNTIs, etc. can be used for a first new RRC message type (e.g., for a first UE category, use case, mode of operation, etc.) while a second set of resources, indicators, spare or reserved bits or bit values, padding bits or bit values, CRC, CORESET or SS set configurations, RNTIs, etc. can be used for a second new RRC message type (e.g., for a second UE category, use case, mode of operation, etc.).

[0085] Figure 6 A flow diagram illustrating an example of a method 600 for attempting to process a new RRC message type is shown. In one example, the UE 104 can perform the functions described in the method 600 using one or more of the components described in the Figures 1 to 2 The components described in the

[0086] In the method 600, at block 602, the UE can process scheduling information for a desired RRC message type or can search configured resources for a desired RRC message type. In one aspect, the message type determination component 252 (e.g., in combination with the processor 212, the memory 216, the transceiver 202, the communication component 242, etc.) can cause the UE to process scheduling information for a desired RRC message type or to search configured resources for a desired RRC message type. For example, the message type determination component 252 can be configured with or otherwise can know (e.g., based on implementation of the wireless communication technology) or can determine the RRC messages for a new RRC message type and / or scheduling information for a corresponding control channel to search for, as described above. In this example, the message type determination component 252 can accordingly monitor resources and / or otherwise receive RRC messages of the desired RRC message type (e.g., new RRC message type) on the resources. In one example, the message processing component 254 can attempt to decode the received RRC messages.

[0087] In method 600, at block 604, the UE can determine whether the decoding or detection was successful. In an aspect, message processing component 254, e.g., in conjunction with processor 212, memory 216, transceiver 202, communication component 242, etc., can cause the UE to determine whether the decoding or detection of the new RRC message or message type was successful. For example, message processing component 254 can determine that the decoding or detection was successful based on one or more of the following: whether the CRC was successful, whether valid data was obtained in the RRC message upon decoding, whether the RRC message has an expected parameter value (e.g., for a message type indicator in bits, padding bits, spare / reserved bits, etc.), whether the RRC message has an expected implicit indicator of the new RRC message type (e.g., expected CRC parameters, RNTI, etc.), and / or the like.

[0088] If the UE determines that the decoding or detection was successful at block 604, at block 606, the UE can process the new RRC message type. In an aspect, message processing component 254, e.g., in conjunction with processor 212, memory 216, transceiver 202, communication component 242, etc., can cause the UE to process the new RRC message type. For example, message processing component 254 can process the RRC message according to the new RRC message type (e.g., based on a location of a value in the new RRC message according to the new RRC message type). Thus, in this example, message processing component 254 can attempt to obtain certain data from the RRC message based on the new RRC message type.

[0089] For example, at block 608, the UE can determine whether it understands the indicator for the new RRC message type. In an aspect, message type determination component 252, e.g., in conjunction with processor 212, memory 216, transceiver 202, communication component 242, etc., can cause the UE to determine whether it understands the indicator for the new RRC message type. For example, the indicator can be an implicit or explicit indicator, as described in the various examples above. Thus, in one example, message type determination component 252 can determine whether the RRC message includes an indicator of the new RRC message type.

[0090] If the UE understands the indicator for the new RRC message type at block 608, at block 610, the UE can follow the signaling information in the new RRC message type. In an aspect, message processing component 254, e.g., in conjunction with processor 212, memory 216, transceiver 202, communication component 242, etc., can cause the UE to follow the signaling information in the new RRC message type in order to determine information from the received RRC message based on the new RRC message type (e.g., based on a format of parameters determined for the new RRC message type).

[0091] If the UE does not understand the indicator for the new RRC message type at block 608, the UE can follow a general error handling procedure for RRC messages at block 612. In one aspect, the message handling component 254732

[0092] The message handling component 254 (e.g., in combination with the processor 212, the memory 216, the transceiver 202, the communication component 242, etc.) can cause the UE to follow a general error handling procedure for RRC messages. For example, this can include the message handling component 254 considering the value to be not understood, in which case the message handling component 254 can determine to discard the message, indicate an error to an upper layer and / or the base station 102, etc. Similarly, if the decoding or detection is unsuccessful at block 604, the UE can follow a general error handling procedure for RRC messages at block 612.

[0093] Figure 7 is a block diagram of a MIMO communication system 700 including a base station 102 and a UE 104. The MIMO communication system 700 can illustrate aspects of the wireless communication access network 100 described with reference to Figure 1 The base station 102 can be an example of aspects of the base station 102 described with reference to Figure 1 The base station 102 can be equipped with antennas 734 and 735, and the UE 104 can be equipped with antennas 752 and 753. In the MIMO communication system 700, the base station 102 can be able to send data over multiple communication links at the same time. Each communication link can be called a “layer” and the “rank” of the communication link can indicate the number of layers used for communication. For example, in a 2x2 MIMO communication system where base station 102 transmits two “layers,” the rank of the communication link between the base station 102 and the UE 104 is two.

[0094] At the base station 102, a transmit (Tx) processor 720 can receive data from a data source. The transmit processor 720 can process the data. The transmit processor 720 can also generate control symbols or reference symbols. A transmit MIMO processor 730 can perform spatial processing (e.g., precoding) on data symbols, control symbols, or reference symbols, if applicable, and can provide output symbol streams to the transmit modulator / demodulators 732 and 733. Each modulator / demodulator 732 to 733 can process a respective output symbol stream (e.g., for OFDM, etc.) to obtain an output sample stream. Each modulator / demodulator 732 to 733 can further process (e.g., convert to analog, amplify, filter, and upconvert) the output sample stream to obtain a DL signal. In one example, DL signals from modulator / demodulators 732 and 733 can be transmitted via the antennas 734 and 735, respectively.

[0095] The UE 104 can be an example of aspects of the UE 104 described with reference to Figures 1 to 2Examples of aspects of the described UE 104. At the UE 104, the UE antennas 752 and 753 can receive DL signals from the base station 102 and can provide the received signals to the modulator / demodulators 754 and 755, respectively. Each modulator / demodulator 754 through 755 can condition (e.g., filter, amplify, downconvert, and digitize) a respective received signal to obtain input samples. Each modulator / demodulator 754 through 755 can further process the input samples (e.g., for OFDM, etc.) to obtain received symbols. A MIMO detector 756 can obtain received symbols from the modulator / demodulators 754 and 755, perform MIMO detection on the received symbols if applicable, and provide detected symbols. A receive (Rx) processor 758 can process (e.g., demodulate, deinterleave, and decode) the detected symbols, providing decoded data for the UE 104 to a data output, and provide decoded control information to a processor 780, or memory 782.

[0096] In some cases, the processor 780 can execute stored instructions to instantiate a communication component 242 (see, e.g., Figure 1 and Figure 2 ).

[0097] On the uplink (UL), at the UE 104, a transmit processor 764 can receive and process data from a data source. The transmit processor 764 can also generate reference symbols for a reference signal. The symbols from the transmit processor 764 can be precoded by a transmit MIMO processor 766 if applicable, further processed by the modulator / demodulators 754 and 755 (e.g., for SC-FDMA, etc.), and be transmitted to the base station 102 in accordance with the communication parameters received from the base station 102. At the base station 102, the UL signals from the UE 104 can be received by the antennas 734 and 735, processed by the modulator / demodulators 732 and 733, detected by a MIMO detector 736 if applicable, and further processed by a receive processor 738. The receive processor 738 can provide decoded data to a data output and to the processor 740 or memory 742.

[0098] In some cases, the processor 740 can execute stored instructions to instantiate a configuration component 342 (see, e.g., Figure 1 and Figure 3 ).

[0099] The components of UE 104 may, individually or collectively, be implemented with one or more ASICs adapted to perform some or all of the applicable functions in hardware. Each of the noted modules can be a means for implementing one or more functions of the MIMO communication system 700 in accordance with the operations described herein. Similarly, the components of base station 102 may, individually or collectively, be implemented with one or more ASICs adapted to perform some or all of the applicable functions in hardware. Each of the noted components can be a means for implementing one or more functions of the MIMO communication system 700 in accordance with the operations described herein.

[0100] The following aspects are merely illustrative and, in various aspects, can take on forms other than those described herein.

[0101] Aspect 1 is a method for wireless communication, comprising: receiving a RRC message from a base station; determining, based on at least one of a resource used to receive the RRC message or a message type indication of the RRC message, that the RRC message belongs to a new RRC message type that is different from a legacy RRC message type; and decoding the RRC message based on the determination that the RRC message belongs to the new RRC message type.

[0102] In Aspect 2, the method of Aspect 1 includes: wherein decoding the RRC message is further based on determining, based on the new RRC message type, that decoding of the new RRC message type is supported.

[0103] In Aspect 3, the method of any of Aspect 1 or 2 includes: wherein the resource for the RRC message of the new RRC message type is different from a resource used to receive a legacy RRC message at least in time, frequency, space, code domain, or a combination thereof.

[0104] In Aspect 4, the method of any of Aspect 1 to 3 includes: receiving scheduling information or an indication of a resource used to receive the RRC message, wherein determining that the RRC message belongs to the new RRC message type is based on the scheduling information or the indication of the resource.

[0105] In Aspect 5, the method of Aspect 4 includes: wherein the scheduling information or the indication of the resource indicates at least one of: one or more monitoring occasions to use to receive the RRC message, a BWP to use to receive the RRC message, a beam to use to receive the RRC message, an antenna panel or port index to use to receive the RRC message, a TCI state to use to receive the RRC message, or a scrambling scheme to use to transmit the RRC message.

[0106] In Aspect 6, the method of any of Aspects 1 to 5 includes: wherein resources for the RRC message of the new RRC message type are shared with resources for receiving legacy RRC messages, and wherein the new RRC message type is associated with at least one of: a different payload size, a different number of fields, different field sizes of common fields, a different mapping order of MAC sub-PDUs, or different contents of one or more MAC sub-headers than for a legacy RRC message type.

[0107] In Aspect 7, the method of any of Aspects 1 to 6 includes: wherein the RRC message includes at least a configurable parameter that specifies a message type indication, and wherein the message type indication is usable for both a legacy RRC message type and a new RRC message type.

[0108] In Aspect 8, the method of Aspect 7 includes: wherein the message type indication is specified as an extension value and wherein determining that the RRC message belongs to the new RRC message type includes decoding the RRC message and determining the extension value.

[0109] In Aspect 9, the method of any of Aspects 1 to 8 includes: wherein the new RRC message type includes a plurality of padding bits, wherein the message type indication is specified by configuring different values for at least a portion of the plurality of padding bits, and wherein determining that the RRC message belongs to the new RRC message type includes decoding the RRC message and detecting the different values for at least the portion of the plurality of padding bits.

[0110] In Aspect 10, the method of any of Aspects 1 to 9 includes: wherein the new RRC message type includes one or more spare or reserved bits, wherein the message type indication is specified by configuring different values for at least one of the one or more spare or reserved bits, and wherein determining that the RRC message belongs to the new RRC message type includes decoding the RRC message and detecting the different values for at least the one of the one or more spare or reserved bits.

[0111] In Aspect 11, the method of any of Aspects 1 to 10 includes: wherein the message type indication is implied by a CRC scheme of the RRC message, and wherein determining that the RRC message belongs to the new RRC message type includes performing a CRC scheme detection of the RRC message.

[0112] In Aspect 12, the method of any of Aspects 1 to 11 includes: wherein the message type indication is implied by a control resource set or search space set configuration for a control channel that schedules the RRC message, and wherein determining that the RRC message belongs to the new RRC message type includes determining the control resource set or search space set configuration of the control channel.

[0113] In Aspect 13, the method of any of Aspects 1-12 includes wherein the message type indication is implied by a RNTI used to scramble a control channel of the RRC message or to mask the scheduled RRC message, and wherein determining that the RRC message belongs to the new RRC message type comprises determining the RNTI.

[0114] Aspect 14 is a method for wireless communication comprising generating a RRC message belonging to a new RRC message type that is different from a legacy RRC message type, wherein generating the RRC message comprises at least one of scheduling resources for transmitting the RRC message to indicate that the RRC message belongs to the new RRC message type or including a message type indication of the RRC message to indicate that the RRC message belongs to the new RRC message type, and transmitting the RRC message to one or more UEs.

[0115] In Aspect 15, the method of Aspect 14 includes wherein the resources are different from resources used to receive the legacy RRC message.

[0116] In Aspect 16, the method of Aspect 15 includes transmitting scheduling information or an indication of the resources used to transmit the RRC message.

[0117] In Aspect 17, the method of any of Aspects 14-16 includes wherein the resources correspond to at least one of one or more monitoring occasions to transmit the RRC message, a BWP used to transmit the RRC message, a beam used to transmit the RRC message, an antenna panel or port index used to transmit the RRC message, a TCI state used to transmit the RRC message, or a scrambling scheme used to transmit the RRC message.

[0118] In Aspect 18, the method of any of Aspects 14-17 includes wherein the resources are shared with resources used to transmit the legacy RRC message, and wherein the new RRC message type is associated with at least one of a different payload size from the legacy RRC message type, a different number of fields, a different field size of a common field, a different mapping order of MAC sub-PDUs, or a different content of one or more MAC sub-headers.

[0119] In Aspect 19, the method of any of Aspects 14-18 includes wherein the RRC message is generated to include a parameter that specifies a message type indication, and wherein the message type indication is usable for both the legacy RRC message type and the new RRC message type.

[0120] In Aspect 20, the method of Aspect 19 includes wherein the RRC message is generated to include the message type indication that is specified as an extension value.

[0121] In Aspect 21, the method of any of Aspects 14 to 20 includes wherein the RRC message includes a plurality of padding bits, and wherein generating the RRC message comprises generating the RRC message to include the message type indication specified by configuring different values for at least a portion of the plurality of padding bits.

[0122] In Aspect 22, the method of any of Aspects 14 to 21 includes wherein the RRC message includes one or more spare or reserved bits, and wherein generating the RRC message comprises generating the RRC message to include the message type indication specified by configuring different values for at least one of the one or more spare or reserved bits.

[0123] In Aspect 23, the method of any of Aspects 14 to 22 includes wherein generating the RRC message comprises generating the RRC message based on a CRC scheme that implies the message type indication based on a value.

[0124] In Aspect 24, the method of any of Aspects 14 to 23 includes wherein generating the RRC message comprises generating the RRC message based on a control resource set or search space set configuration for a control channel that schedules the RRC message, and wherein the control resource set or synchronization signal set configuration implies the message type indication.

[0125] In Aspect 25, the method of any of Aspects 14 to 24 includes wherein generating the RRC message comprises based on an RNTI that scrambles the RRC message or masks a control channel that schedules the RRC message, wherein the RNTI implies the message type indication.

[0126] Aspect 26 is a method for wireless communication comprising receiving a RRC message from a base station, and decoding the RRC message based on a new RRC message type in a case that resources used to receive the RRC message are resources for the new RRC message type that are different from a legacy RRC message type, or in a case that a message type indication of the RRC message indicates that the RRC message belongs to the new RRC message type.

[0127] In Aspect 27, the method of Aspect 26 includes wherein decoding the RRC message is further based on determining, based on the new RRC message type, that decoding of the new RRC message type is supported.

[0128] In Aspect 28, the method of any of Aspects 26 or 27 includes wherein the resources for the RRC message of the new RRC message type are different from resources used to receive a legacy RRC message at least in time, frequency, space, code domain, or a combination thereof.

[0129] In Aspect 29, the method of any of Aspects 26-28 includes receiving scheduling information or an indication of resources for receiving the RRC message, wherein the scheduling information or the indication of resources corresponds to the new RRC message type.

[0130] In Aspect 30, the method of Aspect 29 includes wherein the scheduling information or the indication of resources indicates at least one of: one or more monitoring occasions to receive the RRC message, a BWP to receive the RRC message, a beam to receive the RRC message, an antenna panel or port index to receive the RRC message, a TCI state to receive the RRC message, or a scrambling scheme to transmit the RRC message.

[0131] In Aspect 31, the method of any of Aspects 26-30 includes wherein the resources for the RRC message of the new RRC message type are shared with resources for receiving legacy RRC messages, and wherein the new RRC message type is associated with at least one of: a different payload size, a different number of fields, different field sizes for common fields, a different mapping order of MAC sub-PDUs, or different contents of one or more MAC sub-headers than for a legacy RRC message type.

[0132] In Aspect 32, the method of any of Aspects 26-31 includes wherein the RRC message includes at least a configurable parameter that specifies a message type indication, and wherein the message type indication is usable for both a legacy RRC message type and a new RRC message type.

[0133] In Aspect 33, the method of Aspect 32 includes wherein the message type indication is specified as an extension value and wherein decoding the RRC message based on the new RRC message type includes decoding at least a portion of the RRC message based on the legacy RRC message type and determining the extension value.

[0134] In Aspect 34, the method of any of Aspects 26-33 includes wherein the new RRC message type includes a plurality of padding bits, wherein the message type indication is specified by configuring non-zero values for at least a portion of the plurality of padding bits, and wherein decoding the RRC message based on the new RRC message type includes decoding the RRC message based on the legacy RRC message type and detecting the non-zero values for at least the portion of the plurality of padding bits.

[0135] In Aspect 35, the method of any of Aspects 26-34 includes wherein the new RRC message type includes one or more spare or reserved bits, wherein the message type indication is specified by configuring a non-zero value for at least one of the one or more spare or reserved bits, and wherein decoding the RRC message based on the new RRC message type includes decoding the RRC message based on the legacy RRC message type and detecting the non-zero value for the at least one of the one or more spare or reserved bits.

[0136] In Aspect 36, the method of any of Aspects 26-35 includes wherein the message type indication is implied by a cyclic redundancy check (CRC) scheme of the RRC message, and wherein decoding the RRC message based on the new RRC message type includes performing CRC scheme detection of the RRC message.

[0137] In Aspect 37, the method of any of Aspects 26-36 includes wherein the message type indication is implied by a control resource set or search space set configuration for a control channel that schedules the RRC message, and wherein decoding the RRC message based on the new RRC message type includes determining the control resource set or search space set configuration of the control channel.

[0138] In Aspect 38, the method of any of Aspects 26-37 includes wherein the message type indication is implied by an RNTI used to scramble the RRC message or mask a control channel that schedules the RRC message, and wherein decoding the RRC message based on the new RRC message type includes determining the RNTI.

[0139] Aspect 39 is an apparatus for wireless communication including a transceiver, a memory configured to store instructions, and one or more processors communicatively coupled with the memory and the transceiver, wherein the one or more processors are configured to perform one or more of the methods of any of Aspects 1-38.

[0140] Aspect 40 is an apparatus for wireless communication including means for performing one or more of the methods of any of Aspects 1-38.

[0141] Aspect 41 is a computer-readable medium including code executable by one or more processors for wireless communication, the code including code for performing one or more of the methods of any of Aspects 1-38.

[0142] Examples are described above with reference to the detailed description and are illustrated in the accompanying drawings, which are by way of example only. The description is not intended to be exhaustive or to limit the examples to the precise forms disclosed. The description is intended, rather, to provide examples and teaching for understanding the examples. The terminology used in the description is for the purpose of describing examples only and is not intended to be limiting. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the examples.

[0143] Information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that can be referenced throughout the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, computer-executable code or instructions stored on computer-readable media, or any combination thereof.

[0144] The various illustrative blocks and components described in connection with the examples disclosed herein can be implemented or performed with specially-programmed apparatuses such as, but not limited to, a processor, a digital signal processor (DSP), an ASIC, a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof. The specially-programmed processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. The specially-programmed processor can also be implemented as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0145] The functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions can be stored on or transmitted over as one or more instructions or code on a non-transitory computer-readable medium. Other examples and implementations are within the scope and spirit of the disclosure and appended claims. For example, due to the nature of software, functions described above can be implemented using software executed by a specially programmed processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions can also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations. Also, as used herein, including in the claims, “or” as used in a list of items prefaced by “at least one of’ indicates a disjunctive list such that, for example, a list of “at least one of A, B, or C” means A or B or C or AB or AC or BC or ABC (i.e., A and B and C).

[0146] Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks and blu-ray discs where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above also are included within the scope of computer-readable media.

[0147] The above description of the disclosure has been presented to enable any person skilled in the art to implement or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other variations without departing from the spirit or scope of the disclosure. Furthermore, although elements of the described aspects and / or embodiments can be described or claimed in singular form, plural forms can be intended where constraints permit. Also, unless otherwise stated, all or a portion of any aspect and / or embodiment can be used with all or a portion of any other aspect and / or embodiment. Thus, the disclosure is not to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An apparatus for wireless communication by a user equipment (UE), comprising: a transceiver; a memory configured to store instructions; and one or more processors communicatively coupled with the memory and the transceiver, wherein the one or more processors are configured to: receive a radio resource control (RRC) message; decode the RRC message based on a new RRC message type in a case that a resource used to receive the RRC message is a resource for the new RRC message type that is different from a legacy RRC message type; and receive scheduling information or an indication of a resource used to receive the RRC message, wherein the scheduling information or the indication of the resource corresponds to the new RRC message type, wherein the resource of the RRC message for the new RRC message type is different from a resource used to receive a legacy RRC message at least in a time domain, a frequency domain, a spatial domain, or a combination thereof, and wherein the resource of the RRC message for the new RRC message type includes one or more of a time domain, a frequency domain, or a spatial domain resource that is specific to the new RRC message type.

2. The apparatus of claim 1, wherein the one or more processors are configured to decode the RRC message further based on determining, based on the new RRC message type, that decoding of the new RRC message type is supported.

3. The apparatus of claim 1, wherein the scheduling information or the indication of the resource indicates at least one of: one or more monitoring occasions to receive the RRC message, a bandwidth part (BWP) to receive the RRC message, a beam to receive the RRC message, an antenna panel or port index to receive the RRC message, a transmission configuration indicator (TCI) state to receive the RRC message, or a scrambling scheme to transmit the RRC message.

4. The apparatus of claim 1, wherein the resource of the RRC message for the new RRC message type is shared with a resource used to receive a legacy RRC message, and wherein the new RRC message type is associated with at least one of: a different payload size from a legacy RRC message type, a different number of fields, a different field size of a common field, a different mapping order of medium access control (MAC) sub-protocol data unit (PDU), or different content of one or more MAC sub-headers.

5. The apparatus of claim 1, wherein the RRC message includes at least a configurable parameter that specifies a message type indication indicating that the RRC message belongs to the new RRC message type, and wherein the message type indication is usable for both a legacy RRC message type and a new RRC message type.

6. The apparatus of claim 5, wherein the message type indication is specified as an extension value, and wherein the one or more processors are configured to decode the RRC message based on the new RRC message type and determining the extension value. ​ 7. The apparatus of claim 1, wherein the new RRC message type includes a plurality of padding bits, wherein a message type indication that the RRC message belongs to the new RRC message type is specified by configuring a non-zero value for at least a portion of the plurality of padding bits, and wherein the one or more processors are configured to decode the RRC message based on the new RRC message type and detecting the non-zero value for the at least a portion of the plurality of padding bits.

8. The apparatus of claim 1, wherein the new RRC message type includes one or more spare or reserved bits, wherein a message type indication that the RRC message belongs to the new RRC message type is specified by configuring a non-zero value for at least one of the one or more spare or reserved bits, and wherein the one or more processors are configured to decode the RRC message based on the new RRC message type and detecting the non-zero value for at least one of the one or more spare or reserved bits.

9. The apparatus of claim 1, wherein a message type indication that the RRC message belongs to the new RRC message type is implied by a cyclic redundancy check (CRC) scheme of the RRC message, and wherein the one or more processors are configured to decode the RRC message based on the new RRC message type and performing CRC scheme detection of the RRC message.

10. The apparatus of claim 1, wherein a message type indication that the RRC message belongs to the new RRC message type is implied by a control resource set or search space set configuration of a control channel used to schedule the RRC message, and wherein the one or more processors are configured to decode the RRC message based on the new RRC message type and determining the control resource set or search space set configuration of the control channel.

11. The apparatus of claim 1, wherein a message type indication that the RRC message belongs to the new RRC message type is implied by a radio network temporary identifier (RNTI) used to scramble the RRC message or mask a control channel used to schedule the RRC message, and the one or more processors are configured to decode the RRC message based on the new RRC message type and determining the RNTI.

12. An apparatus for wireless communication by a base station, comprising: a transceiver; a memory configured to store instructions; and one or more processors communicatively coupled with the memory and the transceiver, wherein the one or more processors are configured to: generate a radio resource control (RRC) message that belongs to a new RRC message type that is different from a legacy RRC message type, wherein generating the RRC message includes scheduling resources for transmitting the RRC message to indicate that the RRC message belongs to the new RRC message type; transmit the RRC message to one or more user equipment (UE); and transmit scheduling information or an indication of the resources for transmitting the RRC message, wherein the scheduling information or the indication of the resources corresponds to the new RRC message type, wherein the resources are different from resources used to transmit legacy RRC messages at least in time domain, frequency domain, spatial domain, or a combination thereof, and wherein the resources for the RRC message of the new RRC message type include one or more of time domain, frequency domain, or spatial domain resources that are specific to the new RRC message type.

13. The apparatus of claim 12, wherein the resources correspond to at least one of one or more monitoring occasions for transmitting the RRC message, a bandwidth part, BWP, for transmitting the RRC message, a beam for transmitting the RRC message, an antenna panel or port index for transmitting the RRC message, a transmission configuration indicator, TCI, state for transmitting the RRC message, or a scrambling scheme for transmitting the RRC message.

14. The apparatus of claim 12, wherein the resources are shared with resources used to transmit legacy RRC messages, and wherein the new RRC message type is associated with at least one of a different payload size, a different number of fields, different field sizes for common fields, a different mapping order of medium access control, MAC, sub-protocol data unit, PDU, or different contents of one or more MAC sub-headers than for legacy RRC message types.

15. The apparatus of claim 12, wherein the one or more processors are configured to generate the RRC message to include a parameter that specifies a message type indication that indicates that the RRC message belongs to the new RRC message type, and wherein the message type indication is usable for both legacy RRC message types and new RRC message types.

16. The apparatus of claim 15, wherein the one or more processors are configured to generate the RRC message to include the message type indication that is specified as an extended value.

17. The apparatus of claim 12, wherein the RRC message includes a plurality of padding bits, and wherein the one or more processors are configured to generate the RRC message to include a message type indication that indicates that the RRC message belongs to the new RRC message type specified by configuring a non-zero value for at least a portion of the plurality of padding bits.

18. The apparatus of claim 12, wherein the RRC message includes one or more spare or reserved bits, and wherein the one or more processors are configured to generate the RRC message to include a message type indication that indicates that the RRC message belongs to the new RRC message type specified by configuring a non-zero value for at least one of the one or more spare or reserved bits.

19. The apparatus of claim 12, wherein the one or more processors are configured to generate the RRC message based on a cyclic redundancy check (CRC) scheme that implies a value of a message type indication that the RRC message belongs to the new RRC message type.

20. The apparatus of claim 12, wherein the one or more processors are configured to generate the RRC message based on a control resource set or search space set configuration for a control channel that schedules the RRC message, and wherein the control resource set or synchronization signal set configuration implies a message type indication that the RRC message belongs to the new RRC message type.

21. The apparatus of claim 12, wherein the one or more processors are configured to generate the RRC message at least in part by scrambling the RRC message based on a radio network temporary identifier (RNTI) or by masking a control channel that schedules the RRC message, wherein the RNTI implies a message type indication that the RRC message belongs to the new RRC message type.

22. A method for wireless communications by a user equipment (UE), comprising: receiving a radio resource control (RRC) message; decoding the RRC message based on a new RRC message type in a case that resources used to receive the RRC message are resources for the new RRC message type that are different from a legacy RRC message type; and receiving scheduling information or an indication of resources used to receive the RRC message, wherein the scheduling information or the indication of the resources corresponds to the new RRC message type, wherein the resources for the RRC message of the new RRC message type are different from resources used to receive a legacy RRC message at least in a time domain, a frequency domain, a spatial domain, or a combination thereof, and wherein the resources for the RRC message of the new RRC message type include one or more of time domain, frequency domain, or spatial domain resources that are specific to the new RRC message type.

23. The method of claim 22, wherein decoding the RRC message is further based on determining, based on the new RRC message type, that decoding of the new RRC message type is supported.

24. A method for wireless communications by a base station, comprising: generating a radio resource control (RRC) message that belongs to a new RRC message type that is different from a legacy RRC message type, wherein generating the RRC message includes scheduling resources for transmitting the RRC message to indicate that the RRC message belongs to the new RRC message type; transmitting the RRC message to one or more user equipments (UEs); and transmitting scheduling information or an indication of the resources used to transmit the RRC message, wherein the scheduling information or the indication of the resources corresponds to the new RRC message type, wherein the resources for the RRC message of the new RRC message type are different from resources used to receive a legacy RRC message at least in a time domain, a frequency domain, a spatial domain, or a combination thereof, and wherein the resources for the RRC message of the new RRC message type include one or more of time domain, frequency domain, or spatial domain resources that are specific to the new RRC message type. wherein the resources are different from resources used to transmit legacy RRC messages at least in time domain, frequency domain, spatial domain, or a combination thereof, and wherein the resources for the RRC message for the new RRC message type include one or more of time domain, frequency domain, or spatial domain resources that are specific to the new RRC message type.

25. An apparatus for wireless communications by a user equipment (UE), comprising means for performing the method of claim 22.

26. An apparatus for wireless communications by a base station, comprising means for performing the method of claim 24.

27. A computer-readable medium having program code stored thereon, wherein the program code is executable by one or more processors of a user equipment (UE) to cause the one or more processors to perform the method of claim 22.

28. A computer-readable medium having program code stored thereon, wherein the program code is executable by one or more processors of a base station to cause the one or more processors to perform the method of claim 24.

Images