Patent Description:
It is known, for a user equipment, to perform a radio resource control connection setup, resume, or reestablishment procedure. <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, 3GPP DRAFT R2-<NUM>, 3GPP DRAFT R2-<NUM>, 3GPP DRAFT R2-<NUM>, <CIT>, <CIT>, <CIT> and <CIT> describe techniques comprising assigning a LCID to NR low-complexity UE, NR-lite UE, MTC UE. Category <NUM> UE, MTC terminal, or RedCap UE.

<NUM> sets out a Medium Access Control (MAC) protocol specification for Evolved Universal Terrestrial Radio Access (E-UTRA); and 3GPP Technical Report <NUM> V2. <NUM> provides a study on support of reduced capability NR devices,.

The invention is defined in independent claims. Some further aspects are defined in the dependent claims.

Turning to <FIG>, this figure shows a block diagram of one possible and non-limiting example in which the examples may be practiced. A user equipment (UE) <NUM>, radio access network (RAN) node <NUM>, and network element (s) <NUM> are illustrated. In the example of <FIG>, the user equipment (UE) <NUM> is in wireless communication with a wireless network <NUM>. A UE is a wireless device that can access the wireless network <NUM>. The UE <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The UE <NUM> includes a module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The module <NUM> may be implemented in hardware as module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module <NUM> may be implemented as module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> may be configured to, with the one or more processors <NUM>, cause the user equipment <NUM> to perform one or more of the operations as described herein. The UE <NUM> communicates with RAN node <NUM> via a wireless link <NUM>.

The RAN node <NUM> in this example is a base station that provides access by wireless devices such as the UE <NUM> to the wireless network <NUM>. The RAN node <NUM> may be a base station (e.g. <NUM>, <NUM>, etc.), for example, a base station for <NUM>, also called New Radio (NR). In <NUM>, the RAN node <NUM> may be a NG-RAN node, which is defined as either a gNB or a ng-eNB. A gNB is a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to a 5GC (such as, for example, the network element(s) <NUM>). The ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC. The NG-RAN node may include multiple gNBs, which may also include a central unit (CU) (gNB-CU) <NUM> and distributed unit(s) (DUs) (gNB-DUs), of which DU <NUM> is shown. Note that the DU may include or be coupled to and control a radio unit (RU). The gNB-CU is a logical node hosting RRC, SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected with the gNB-DU. The F1 interface is illustrated as reference <NUM>, although reference <NUM> also illustrates a link between remote elements of the RAN node <NUM> and centralized elements of the RAN node <NUM>, such as between the gNB-CU <NUM> and the gNB-DU <NUM>. The gNB-DU is a logical node hosting RLC, MAC and PHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU. One gNB-CU supports one or multiple cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface <NUM> connected with the gNB-CU. Note that the DU <NUM> is considered to include the transceiver <NUM>, e.g., as part of a RU, but some examples of this may have the transceiver <NUM> as part of a separate RU, e.g., under control of and connected to the DU <NUM>. The RAN node <NUM> may also be an eNB (evolved NodeB) base station, for LTE (long term evolution), or any other suitable base station or node.

The RAN node <NUM> includes a module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The module <NUM> may be implemented in hardware as module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module <NUM> may be implemented as module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the RAN node <NUM> to perform one or more of the operations as described herein. Note that the functionality of the module <NUM> may be distributed, such as being distributed between the DU <NUM> and the CU <NUM>, or be implemented solely in the DU <NUM>.

The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers <NUM> may be implemented as a remote radio head (RRH) <NUM> for LTE or a distributed unit (DU) <NUM> for gNB implementation for <NUM>, with the other elements of the RAN node <NUM> possibly being physically in a different location from the RRH/DU, and the one or more buses <NUM> could be implemented in part as, for example, fiber optic cable or other suitable network connection to connect the other elements (e.g., a central unit (CU), gNB-CU) of the RAN node <NUM> to the RRH/DU <NUM>. Reference <NUM> also indicates those suitable network link(s).

It is noted that description herein indicates that "cells" perform functions, but it should be clear that equipment which forms the cell will perform the functions. The cell makes up part of a base station. That is, there can be multiple cells per base station. For example, there could be three cells for a single carrier frequency and associated bandwidth, each cell covering one-third of a <NUM> degree area so that the single base station's coverage area covers an approximate oval or circle. Furthermore, each cell can correspond to a single carrier and a base station may use multiple carriers. So if there are three <NUM> degree cells per carrier and two carriers, then the base station has a total of <NUM> cells.

The wireless network <NUM> may include a network element or elements <NUM> that may include core network functionality, and which provides connectivity via a link or links <NUM> with a further network, such as a telephone network and/or a data communications network (e.g., the Internet). Such core network functionality for <NUM> may include access and mobility management function(s) (AMF(s)) and/or user plane functions (UPF(s)) and/or session management function(s) (SMF(s)). Such core network functionality for LTE may include MME (Mobility Management Entity)/SGW (Serving Gateway) functionality. These are merely exemplary functions that may be supported by the network element(s) <NUM>, and note that both <NUM> and LTE functions might be supported. The RAN node <NUM> is coupled via a link <NUM> to a network element <NUM>. The link <NUM> may be implemented as, e.g., an NG interface for <NUM>, or an S1 interface for LTE, or other suitable interface for other standards. The network element <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more network interfaces (N/W I/F(s)) <NUM>, interconnected through one or more buses <NUM>. The one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the network element <NUM> to perform one or more operations.

The computer readable memories <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer readable memories <NUM>, <NUM>, and <NUM> may be means for performing storage functions. The processors <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multicore processor architecture, as non-limiting examples. The processors <NUM>, <NUM>, and <NUM> may be means for performing functions, such as controlling the UE <NUM>, RAN node <NUM>, and other functions as described herein.

In addition, various embodiments of the user equipment <NUM> can include, but are not limited to, devices integrated into vehicles, infrastructure associated with vehicular travel, wearable devices used by pedestrians or other non-vehicular users of roads, user equipment unrelated to traffic users, public safety user equipment and/or other commercial user equipment, sensors having wired or wireless communication capabilities, Internet of Things (IoT) devices, devices capable of receiving information from sensors and having wireless communication capabilities, etc..

Features as described herein generally relate to enabling of identification of reduced capability (RedCap) devices and network access control. As noted in 3GPP TR <NUM>, a RedCap UE may refer to an NR UE with reduced capabilities. It was introduced in 3GPP specifications Release <NUM> for enabling the expansion of <NUM> use cases (including wearables, video surveillance, and Industrial wireless sensors networks) which are not yet best served by current NR specifications. RedCap devices may include devices with relatively low complexity, cost, and/or size. Use cases for RedCap UE and example embodiments of the present disclosure may include, but are not limited to, industrial Internet of Things (IoT) sensors, wireless sensors, video surveillance devices, Internet of Things (IoT) devices, wearables, and/or devices used for transportation, tracking, infrastructure, agriculture, smart cities, etc. Wearables may include sensors in contact with or near skin, smart fabric, heart rate monitors, temperature monitors, etc. RedCap devices may or may not conform to the following description from RP-<NUM>:.

Device complexity: Main motivation for the new device type is to lower the device cost and complexity as compared to high-end eMBB and URLLC devices of Rel-<NUM>/Rel-<NUM>. This is especially the case for industrial sensors.

Device size: Requirement for most use cases is that the standard enables a device design with compact form factor.

Deployment scenarios: System should support all FR1/FR2 bands for FDD and TDD.

Industrial wireless sensors: Reference use cases and requirements are described in TR <NUM> and TS <NUM>: Communication service availability is <NUM>% and end-to-end latency less than <NUM>. The reference bit rate is less than <NUM> Mbps (potentially asymmetric e.g. UL heavy traffic) for all use cases and the device is stationary. The battery should last at least few years. For safety related sensors, latency requirement is lower, <NUM>-<NUM> (TR <NUM>).

Video Surveillance: As described in TS <NUM>, reference economic video bitrate would be <NUM>-<NUM> Mbps, latency < <NUM>, reliability <NUM>%-<NUM>%. High-end video e.g. for farming would require <NUM>-<NUM> Mbps. It is noted that traffic pattern is dominated by UL transmissions.

Wearables: Reference bitrate for smart wearable application can be <NUM>-<NUM> Mbps in DL and minimum <NUM> Mbps in UL and peak bit rate of the device higher, <NUM> Mbps for downlink and <NUM> Mbps for uplink. Battery of the device should last multiple days (up to <NUM>-<NUM> weeks).

In example embodiments of the present disclosure, RedCap UE identification and network access control may be enabled when UE attempt access to the network while in an RRC_IDLE or RRC_INACTIVE state. More specifically, in some example embodiments RedCap UE identification may be enabled in MsgA of a <NUM>-step Random Access (RA) procedure or in Msg3 of a <NUM>-step Random Access procedure. In an example embodiment of the present disclosure, an indication of the RedCap UE may be conveyed in a logical channel ID (LCID) field of a subheader of a medium access control (MAC) service data unit (SDU) or MAC control element (CE).

<NUM>-step RA procedure may involve UE sending MsgA, which includes Random Access preamble and a physical uplink shared channel (PUSCH) transmission, which may include data. The network then may respond to the UE MSGA transmission by sending MsgB. <NUM>-step RA procedure may involve UE sending Msg1 which includes Random Access preamble; the network may respond to the Msg1 transmission by Msg2 or Random Access Response which includes transmission resources for Msg3 and, for example, timing advance command; the UE may then transmit Msg3 on the assigned resources; if the network is able to decode the Msg3, it can respond with Msg4, which is also called as contention resolution. Examples of <NUM>-Step RA procedure are described below with references to <FIG> and <FIG>. With regards to the discussions in this description, the example embodiments as hereinafter described in terms of Msg3 are equally applicable to MsgA, and vice versa.

In 3GPP Release <NUM>, (RP-<NUM>), a work item on the support for RedCap devices (also known as NR-Light) has been approved. The following objectives have been identified for supporting RedCap devices:
". Identify and study potential UE complexity reduction features, including:.

Study UE power saving and battery lifetime enhancement for reduced capability UEs in applicable use cases (e.g. delay tolerant):.

Study functionality that will enable the performance degradation of such complexity reduction to be mitigated or limited, including:
Coverage recovery to compensate for potential coverage reduction due to the device complexity reduction.

Study standardization framework and principles for how to define and constrain such reduced capabilities - considering definition of a limited set of one or more device types and considering how to ensure those device types are only used for the intended use cases.

Study functionality that will allow devices with reduced capabilities to be explicitly identifiable to networks and network operators, and allow operators to restrict their access, if desired.

Note2: Potential overlap with coverage enhancements study is discussed and resolved in RAN#<NUM>.

Note3: Coexistence with Rel-<NUM> and Rel-<NUM> UE should be ensured Note4: This SI should focus on SA mode and single connectivity.

The objective to "Study functionality that will allow devices with reduced capabilities to be explicitly identifiable to networks and network operators, and allow operators to restrict their access, if desired" may be enabled by example embodiments of the present disclosure.

In RAN2#<NUM>-e, the following agreements have been made:
". An indication in system information is needed to indicate whether a REDCAP UE can camp on the cell. FFS whether the indication is explicit or implicit.

System information indicates whether REDCAP operation is allowed/barred on a frequency. FFS reuse the legacy intraFreqReselection or introduce separate flag.

Further discuss enhancement of UAC for REDCAP UEs, including e.g.:.

(for any final decision we need to check with SA1 and/or CT1).

In RAN1#<NUM>-e, the following agreements were made with regard to UE identification for RedCap UEs:
". Further study the options for identification of RedCap UEs, including the following indication methods:.

Note: This study intends to establish feasibility of, and pros and cons for the identified options from RAN1 perspective, without any intention of down-selection without guidance from RAN2.

RAN1 to wait for further progress in RAN2 on the issues of temporary access barring and congestion control.

Example embodiments of the present disclosure may relate to identification of RedCap UEs during MsgA and/or Msg3 transmission.

In 3GPP RAN2#<NUM> e-meeting, the following agreements were made on RedCap Identification and access restriction:
". Whether it is needed to identify RedCap UEs during Msg3 from RAN2 perspective or not depends on the following two aspects:.

Postpone the discussion on the camping indicator for RedCap UEs to the WI phase.

Postpone the discussion on intraFreqReselection indicator for RedCap UEs to the WI phase.

RAN1 studied feasibility, necessity, pros, and cons from RAN1 perspective for these different options for identification of RedCap UEs. For option <NUM> (i.e. the UE identification happens during MSG3 transmission), the following methods may be possible for enablement:.

Table <NUM> is included from <NPL>). As noted in Table <NUM>, using the spare bit of the existing RRCSetupRequest or RRCResumeRequest (carried in MsgA/Msg3) might not be preferred, as it would use the only spare bit in those messages. As a result, any essential additions later on could not be introduced. As noted in Table <NUM>, extending Msg3's size to carry additional bit(s) configured to indicate RedCap UE type(s) may result in needing further mechanisms to identify which MSG3 type/size is used. Accordingly, worse coverage might result where more information is required to be encoded into Msg3. It may be noted that coverage may be worse for RedCap UE than for non-RedCap UE even without implementation of Method <NUM> of Table <NUM>.

Example embodiments of the present disclosure may provide an alternative to Method <NUM> and Method <NUM> of Table <NUM>. The alternative method may enable the NW to identify RedCap UEs based on the RRC message content without using the spare bit of the RRC messages and without extending MsgA/Msg3 size with additional bit(s).

Example embodiments of the present disclosure may involve UE identification being performed in Msg3 at the latest (or PUSCH part of MsgA). In example embodiments, Msg3-based identification may be mandatory for the UE; the Msg1 based solution may be optional for the NW to configure, depending on the scenario. In example embodiments, UE identification may happen/occur during MsgA/Msg3 transmission, i.e. during a RRC resume procedure (when the UE is in RRC_INACTIVE state) or during RRC establishment procedure (when the UE is in RRC_IDLE state).

Referring now to <FIG>, illustrated is an example RRC state machine in <NUM> NR with state transitions, in which the exemplary embodiments may be practiced.

A UE may be in an RRC_CONNECTED state (<NUM>), an RRC _INACTIVE state (<NUM>), or an RRC_IDLE state (<NUM>). When a UE is in RRC _INACTIVE state (<NUM>), the radio connection may only be suspended while the core network connectivity is maintained active, i.e. UE is kept in Connection Management (CM)-CONNECTED state. A UE Access Stratum (AS) context (referred to as UE Inactive AS context) may be stored at both UE and anchor gNB sides for the fast resume of a suspended connection (with Resume message <NUM>). Based on this retained information, the UE may resume the radio connection with a much lower delay and associated signaling overhead as compared to a UE in RRC_IDLE state (<NUM>) that requires establishment of a new connection to both the radio and core network (with Setup message <NUM>).

After a certain data activity (which may be timer-based), the UE may be moved from RRC_CONNECTED state (<NUM>) to RRC_INACTIVE (<NUM>) or RRC_IDLE (<NUM>) state. For example, this state transition may occur with a suspend message (<NUM>) (or suspend carried over a release message) or a release message (<NUM>), respectively. A UE in RRC_INACTIVE state (<NUM>) may also transition to RRC_IDLE state (<NUM>) due to timer expiration and/or data inactivity with a release message <NUM>.

State transition may also occur due to overload or "failure" cases. A UE in RRC_CONNECTED state <NUM> may transition to RRC_INACTIVE state (<NUM>) with a Reject message (<NUM>) or to RRC_IDLE state (<NUM>) with a Reject message (<NUM>). A UE in RRC_INACTIVE state (<NUM>) may transition to RRC_IDLE state (<NUM>) with a Release message (<NUM>). Referring now to <FIG>, illustrated is an example of a (successful) RRC Connection establishment/setup procedure/process. This procedure may be used by a UE in RRC_IDLE state (<NUM>) to connect to a gNB (i.e. request establishment of an RRC connection) and transition to RRC_CONNECTED state (<NUM>). In the example of <FIG>, the Msg3 transmission may carry an RRCSetupRequest as well as a UE-Identity and a reason/cause for establishing the connection.

At <NUM>, the UE, which may be in an RRC_IDLE mode, may transmit a Msg1 to the gNB. Msg1 may include a random access channel (RACH) preamble. At <NUM>, the gNB may transmit to the UE a Msg2. Msg2 may include a random access (RA) response. At <NUM>, the UE transmits a Msg3 to the gNB. Msg3 may include a RRC Connection Setup Request or a RRC Setup Request. In an example embodiment, the Msg3 may also include identification of the UE, which may be a RedCap UE. In an example embodiment, the UE determines a logical channel identifier that indicates a common control channel and a type of the apparatus. According to the invention as claimed, the logical channel identifier comprises one of a plurality of logical channel identifiers that distinguish between an apparatus having one receiver chain and an apparatus having two receiver chains.

The Msg3 may include a common control channel (CCCH) service data unit (SDU) which may include the RRC Setup Request. The determined LCID may be associated with the MAC subheader of the CCCH SDU. The determined logical channel identifier is transmitted along with Msg3. At <NUM>, the gNB may transmit a Msg4 to the UE. Msg4 may include an RRC Connection Setup message or a RRC Setup message. At <NUM>, the UE may transmit a Msg5 to the gNB. Msg5 may include an RRC Connection Setup Complete or an RRC Setup Complete message and a non access stratum (NAS) Service request. At <NUM>, the gNB may transmit an initial UE message to the access and mobility management function (AMF) of the network. At <NUM>, the AMF may transmit an initial context setup request to the gNB. At <NUM>, the gNB may transmit a Msg6 to the UE. Msg6 may include a security mode command, and a RRC Connection Reconfiguration (or RRC Reconfiguration) message. At <NUM>, the UE may transmit a Msg7 to the gNB. Msg7 may include a Security Mode Complete indication, and an RRC Connection Reconfiguration Complete message or RRC Reconfiguration complete message. At <NUM>, the gNB may transmit an initial context setup complete message to the AMF. The process of <FIG> may result in the UE transitioning to the RRC_CONNECTED state.

The RRCSetupRequest message included in Msg3 may include an indication of an establishment cause and/or an indication of the identity of the UE. In an example, the RRCSetupRequest message may be transmitted from the UE to the network using signaling radio bearer SRB0; with a radio link control service access point (RLC-SAP) in transparent mode (TM); and with common control channel (CCCH) as the logical channel. The RRCSetupRequest message may be as follows:
<IMG>.

establishmentCause may provide the establishment cause for the RRCSetupRequest in accordance with the information received from upper layers. The gNB might not be expected to reject an RRCSetupRequest due to an unknown cause value being used by the UE. ue-Identity may comprise a UE identity included to facilitate contention resolution by lower layers.

Referring now to <FIG>, illustrated is an example of an RRC Connection Resume procedure in which Msg3 corresponds to RRCResumeRequest(<NUM>) and includes, among other information elements (IE), the ResumeIdentity and the resumeCause IEs. This procedure may be used by a UE in RRC_INACTIVE state (<NUM>) to connect to a gNB (i.e. request resume of an RRC connection) and transition to RRC_CONNECTED state (<NUM>). The RRCResumeRequest(<NUM>) message may be used to request the resumption of a suspended RRC connection or to perform an RAN notification area (RNA) update (RNAU).

At <NUM>, the UE, which may be in an RRC_INACTIVE state (<NUM>), may transmit a Msg1 to a gNB. Msg1 may include a RACH preamble. At <NUM>, the gNB may transmit a Msg2 to the UE. Msg2 may include a RA response. At <NUM>, the UE transmits a Msg3 to the gNB. Msg3 may include an RRC Resume Request. Msg3 may also include identification of the UE, which may be a RedCap UE. In an example embodiment, the UE determines a logical channel identifier that indicates a common control channel and a type of the apparatus. According to the invention as claimed, the logical channel identifier comprises one of a plurality of logical channel identifiers that distinguish between an apparatus having one receiver chain and an apparatus having two receiver chains.

The Msg3 may include a common control channel (CCCH) service data unit (SDU) which may include the RRC Setup Request. The determined LCID may be associated with the MAC subheader of the CCCH SDU. The determined logical channel identifier is transmitted along with Msg3. At <NUM>, the gNB may transmit a Retrieve UE Context Request to an anchor gNB. At <NUM>, the anchor gNB may transmit a Retrieve UE Context Response to the gNB. At <NUM>, the gNB may transmit Msg4 to the UE. Msg4 may include an RRC Resume message. The UE may transition to an RRC_CONNECTED state (<NUM>). At <NUM>, the UE may transmit a Msg5 to the gNB. Msg5 may include an RRC Resume Complete message. At <NUM>, the gNB may transmit an Xn-UP address indication to the anchor gNB. At <NUM>, the gNB may transmit a path switch request to the AMF. At <NUM>, the AMF may transmit a path switch response to the gNB. At <NUM>, the gNB may transmit a context release message to the AMF.

The RRCResumeRequest message included in Msg3 may include an indication of a resume clause, an indication of the identity of the UE, and/or an indication of an authentication token. In an example, the RRCResumeRequest message may be transmitted from the UE to the network using signaling radio bearer SRB0; with RLC-SAP in TM; and with CCCH as the logical channel. The RRCResumeRequest message may be as follows:
<IMG>
resumeCause may provide the resume cause for the RRC connection resume request as provided by the upper layers or RRC. The network might not be expected to reject an RRCResumeRequest due to an unknown cause value being used by the UE. resumeIdentity may provide the UE identity to facilitate UE context retrieval at the gNB. resumeMAC-I may comprise an authentication token to facilitate UE authentication at gNB. The <NUM> least significant bits of the MAC-I may be calculated using a specified AS security configuration.

Alternatively, a RRCResumeRequest1 message may be included in Msg3, which may include an indication of a resume cause, an indication of the identity of the UE, and/or an indication of an authentication token. In an example, the RRCResumeRequest1 message may be transmitted from the UE to the network using signaling radio bearer SRB0; with RLC-SAP in TM; and with CCCH1 as the logical channel. The RRCResumeRequest1 message may be as follows:
<IMG>
resumeCause may provide the resume cause for the RRCResumeRequest1 as provided by the upper layers or RRC. A gNB might not be expected to reject an RRCResumeRequest1 due to unknown cause value being used by the UE. resumeIdentity may provide the UE identity to facilitate UE context retrieval at the gNB. resumeMAC-I may comprise an authentication token to facilitate UE authentication at gNB. The <NUM> least significant bits of the MAC-I may be calculated using a specified AS security configuration.

Referring now to <FIG>, illustrated is an example of a <NUM> NR medium access control (MAC) protocol data unit (PDU) for the uplink (UL) shared channel (SCH), which may carry the Msg3 of the exemplary embodiments. The RRCResumeRequest(<NUM>) or RRCSetupRequest which may be carried in MSg3 may be transferred/transmitted/sent using SRB0 on the Common Control Channel (CCCH, CCCH1). The Msg3 may be transmitted on UL-SCH transport channel.

A MAC PDU may consist of one or more MAC sub-PDUs. Each MAC sub-PDU may consist of one of the following fields: a MAC subheader only (including padding); a MAC subheader and a MAC SDU; a MAC subheader and a MAC CE (Control Element); and/or a MAC subheader and padding. Other configurations of a MAC sub-PDU may be possible.

Referring now to <FIG>, the example MAC PDU comprises at least MAC subPDUs <NUM>, <NUM>, <NUM>, etc. MAC subPDU <NUM> includes MAC SDU. MAC subPDU <NUM> comprises R/F/LCID/L fields in a subheader <NUM> and MAC SDU <NUM>. MAC subPDU <NUM> includes MAC CE <NUM>. MAC subPDU <NUM> comprises R/LCID fields in a subheader <NUM> and fixed-sized MAC CE <NUM>. MAC subPDU <NUM> includes MAC CE <NUM>. MAC subPDU <NUM> comprises R/F/LCID/L fields in a subheader <NUM> and variable-sized MAC CE <NUM>. Other configurations of a MAC PDU may be possible.

MAC SDUs may be of variable sizes. Each MAC subheader may correspond to either a MAC SDU, a MAC CE, or padding. A MAC subheader for fixed sized MAC CE, padding, and a MAC SDU containing UL CCCH (e.g. <NUM>) may consist of the two header fields R/LCID/(eLCID). Referring now to <FIG>, illustrated are examples of R/LCID/(eLCID) MAC subheader fields for MAC SDU containing CCCH. The MAC subheader may comprise a reserved bit R, which may be set to <NUM> (e.g. <NUM>, <NUM>, <NUM>, <NUM>). The MAC subheader may also comprise an LCID field (e.g. <NUM>, <NUM>). The Logical Channel ID (LCID) field may identify the logical channel instance of the corresponding MAC SDU, or the type of the corresponding MAC CE, or padding, as described in Table <NUM> below, for the UL-SCH.

There may be one LCID field per MAC subheader. The LCID field size may be/comprise <NUM> bits. In an example, if the LCID field is set to Codepoint/Index <NUM> (i.e. has a value of <NUM>) (see Table <NUM> below), one additional octet comprising <NUM> bits may be present in the MAC subheader, containing the eLCID field (<NUM>), and may follow the octet containing LCID field (<NUM>). If the LCID field is set to Codepoint/Index <NUM> (i.e. has a value of <NUM>) (see Table <NUM> below), two additional octets may be present in the MAC subheader, for/containing the eLCID field(s), and these two additional octets may follow the octet containing the LCID field (not shown in <FIG>).

The MAC subheader may comprise an eLCID field. The extended Logical Channel ID (eLCID) field may identify the logical channel instance of the corresponding MAC SDU or the type of the corresponding MAC CE. The size of the eLCID field may be either <NUM> bits or <NUM> bits. It may be noted that the eLCID space using two-octet eLCID and the relevant MAC subheader format may be used, only when configured, on the NR backhaul links between integrated access and backhaul (IAB) nodes or between an IAB node and an IAB Donor.

The LCID field may be unique per MAC subheader and may indicate the content of the transmission, e.g. when transmitting the RRCSetupRequest or RRCResumeRequest(<NUM>), the CCCH(<NUM>) is used, for <NUM> bits or <NUM> bits corresponding to Codepoint/Index <NUM> or <NUM>, respectively.

Table <NUM> demonstrates the values of the LCID field for UL-SCH (i.e. MAC LCID field structure):.

In Table <NUM>, index <NUM> indicates a CCCH of size <NUM> bits, which may be referred to as CCCH1. If a MAC PDU comprises a MAC subPDU comprising an LCID subheader field with this value, it may be understood that CCCH1 may be used to transmit RRCSetupRequest or RRCResumeRequest(<NUM>). If a MAC PDU comprises a MAC subPDU comprising an LCID subheader field with a value of <NUM>, it may be understood that CCCH, which a size of <NUM> bits may be used to transmit RRCSetupRequest or RRCResumeRequest. In other words, a CCCH SDU may comprise a RRC connection request such as RRCSetupRequest or RRCResumeRequest.

In an example embodiment, a UE may be identified via Msg3 transmission using the existing content of the RRC messages. In an example embodiment, additional logical channel identifier (LCID) value (s) are defined that correspond to one or more CCCH(s) for RedCap UEs. For example, one LCID value may be defined per CCCH SDU size (e.g. CCCH SDU sizes of <NUM> or <NUM> bits). In other words, in an example embodiment, a logical channel identifier may indicate a CCCH SDU size. The size may be a predefined size, such as <NUM> bits or <NUM> bits. In an example embodiment, this defined LCID value may use the reserved values of the LCID field in a MAC subheader for the corresponding CCCH SDU.

In an example embodiment, a gNB receiving a MAC PDU carrying Msg3 (or MsgA) from a UE understands/determines the UE to be a UE of a certain type, such as a RedCap UE or a type of RedCap UE, if a MAC subPDU of the MAC PDU comprises an LCID subheader field carrying an LCID value configured to indicate a type of UE, such as a RedCap UE or a type of RedCap UE. Additionally, the LCID value may indicate a CCCH SDU size. The LCID value may be identified by a codepoint or an index, for example a defined codepoint or index as in Table <NUM> below. Not according to the invention as claimed, if the MAC PDU does not comprise a MAC subPDU of the MAC PDU comprising an LCID subheader field carrying an LCID value configured to indicate a CCCH SDU size associated with a (type of) RedCap UE, the gNB might not consider the UE to be a RedCap UE.

In an example embodiment, a UE determines a logical channel identifier that indicates a CCCH and a type of the UE.

According to the invention as claimed, the logical channel identifier comprises one of a plurality of logical channel identifiers that distinguish between an apparatus having one receiver chain and an apparatus having two receiver chains. The logical channel identifier is transmitted via an LCID field.

In an example embodiment, a UE may determine to transmit a CCCH SDU, and determine the logical channel identifier to transmit via the MAC subPDU based on CCCH SDU to be transmitted. The logical channel identifier is transmitted via an LCID field.

In the example of Table <NUM>, Codepoint/Index <NUM>-<NUM> are reserved. In an example embodiment, two Codepoint/Index within the range of [<NUM>-<NUM>] may be used for RedCap UE identification, which may result in LCID Values for UL-SCH, as illustrated in the example of Table <NUM> below.

In an example embodiment, a RedCap UE may be identified based on the LCID value used in a MAC PDU of Msg3.

In an example embodiment, the LCID for the CCCH and RedCap UE identification may be defined only for a single CCCH SDU size, e.g., only for a size of <NUM> or <NUM> bits.

More LCID values are defined to distinguish further different RedCap UE types e.g. RedCap UE type <NUM>, RedCap UE type <NUM>, RedCap UE type <NUM>, etc. For example, based on the example of Table <NUM>, a Codepoint/Index of <NUM> or any other codepoint/index may be additionally defined to indicate a specific RedCap UE type.

Table <NUM> demonstrates example values of/for the LCID field for UL-SCH (i.e. MAC LCID field structure), including new values for RedCap UE identification:.

In contrast to the example of Table <NUM>, in which Codepoint/Index <NUM>-<NUM> may be reserved, in the example of Table <NUM> Codepoint/Index <NUM>-<NUM> may be reserved. In the example of Table <NUM>, Codepoint/Index <NUM> may be configured to indicate a CCCH of size <NUM> bits for RedCap UEs, which may also be referred to as CCCH1. In other words, LCID <NUM> may indicate a CCCH (CCCH(<NUM>) of size <NUM> bits) and a type of a UE (RedCap UE). In the example of Table <NUM>, Codepoint/Index <NUM> may be configured to indicate a CCCH of size <NUM> bits for RedCap UEs, which may also be referred to as CCCH. In other words, LCID <NUM> may indicate a CCCH (CCCH of size <NUM> bits) and a type of a UE (RedCap UE). Additional reserved Codepoint/Index are repurposed/defined to distinguish additional different RedCap UE types, for example in the range of <NUM>-<NUM>. According to the invention as claimed, the different RedCap UE types comprise <NUM> Rx capable RedCap UE and <NUM> Rx capable RedCap UE where the RedCap UE has either <NUM> or <NUM> receiver chains, respectively.

In an example based on Table <NUM>, a Msg3 transmitted by a RedCap UE may comprise, for example, an LCID subheader field of <NUM> bits. The LCID field of the subheader may comprise the value <NUM> (i.e. <NUM>) and/or <NUM> (i.e. <NUM>). Different or additional LCID values may be defined to indicate, for example one or more RedCap UE types. Values defined to indicate RedCap UEs might not be considered reserved LCID field values. Because the MAC PDU configured of Msg3 may comprise an LCID value configured to indicate a CCCH SDU size and a UE type (e.g. RedCap), a receiving gNB, base station, or another network node is able to identify the transmitting UE as a UE of a certain type (e.g. RedCap) transmitting via a certain CCCH.

There may be only one LCID field possible per MAC subheader. In an example embodiment, it may be determined/ensured that no conflicts are possible, for example by determining whether the LCID field intended to use for RedCap UE identification is already utilized/intended for some other use. In an example embodiment, a conflict in the intended use for an LCID field may be resolved/prevented by indicating RedCap UE together with common control channel (CCCH) length. In the example of Table <NUM>, an LCID value may be associated with a RedCap UE and a CCCH size (e.g. at Codepoint/Index <NUM>), while another LCID value may be associated with a RedCap UE and a (different or same) CCCH size (e.g. at Codepoint/Index <NUM>). In an example, these LCID may be associated with the same or different types of RedCap UE.

Not according to the invention as claimed, other LCID values may be indicated via Msg3 that might not be specific to RedCap UEs. For example, a UE which may be in an RRC_CONNECTED may indicate a cell radio network temporary identifier (C-RNTI) e.g. at Codepoint/Index <NUM>. If MAC group C-RNTI MAC CE (LCID=<NUM>) is transmitted in the Msg3, inclusion of an LCID value associated with RedCap UE identification may be unnecessary, as the UE has already been identified as a RedCap UE.

In an example not according to the invention as claimed, a message transmitted by a UE to a gNB that includes an indication of whether the UE is a RedCap UE may comprise, at least, a CCCH SDU comprising a RRC connection request. In other words, the message may include a CCCH SDU as well as other content, such as a subheader, MAC CE, data, etc. (see e.g. <FIG>). The message may be, for example a MAC PDU. The UE may be in one of an RRC_IDLE or RRC_INACTIVE state when transmitting such a message. The indication of whether the UE is a RedCap UE may be an indication that the UE is one of a plurality of different RedCap UE types.

In an example not according to the invention as claimed, a message transmitted by a UE to a gNB that includes an indication of a type of the UE may also include an indication of a CCCH. The indication of the CCCH may be an indication of one of a plurality of different CCCH (e.g. CCCH, CCCH1, etc.).

In an example not according to the invention as claimed, a gNB (or other base station) receiving a message from a UE including an indication of a type of the UE and/or an indication of a CCCH may determine whether to restrict access of the UE based on a determination that the UE is a RedCap UE or a type of RedCap UE. Additionally or alternatively, the gNB may determine whether to schedule the UE in connection establishment/resume phase (e.g. with respect to bandwidth capability). For example, if the gNB determines that the UE is a RedCap UE or a type of RedCap UE, the gNB may decide to schedule the UE for transition to a CM-CONNECTED state (see <FIG>) using a bandwidth the RedCap UE or type of RedCap UE is capable of using according to a specification. Additionally or alternatively, the gNB may determine a feature set (e.g. modulation and coding scheme (MCS) based on a determination that the UE is a RedCap UE or a type of RedCap UE.

A technical effect of example embodiments of the present disclosure, such as enablement and/or use of new LCID values that may be specific for RedCap UEs/other types of UE, may be to enable the NW to identify a RedCap UE from a legacy NR UE without including any additional bits in MSG3 and/or without using the only spare bit in MSG3 to identify a RedCap UE.

A technical effect of example embodiments of the present disclosure may be that identification of RedCap UE may be transparent to legacy UEs.

A technical effect of example embodiments of the present disclosure may be enabling identification of RedCap UE in any RRC state, including RRC_IDLE or RRC_INACTIVE.

A technical effect of example embodiments of the present disclosure may be enabling identification of RedCap UE for the case of initial attach when no temporary identification of the UE has been assigned by the NW.

<FIG> illustrates the potential steps of an example method <NUM>. The example method <NUM> includes : determining a logical channel identifier, wherein the logical channel identifier indicates a common control channel and indicates a type of the user equipment, <NUM>; and transmitting a message comprising the determined logical channel identifier <NUM>. According to the invention as claimed, the logical channel identifier comprises one of a plurality of logical channel identifiers that distinguish between an apparatus having one receiver chain and an apparatus having two receiver chains.

<FIG> illustrates the potential steps of an example method <NUM> performed by means of an apparatus.

The example method <NUM> includes : receiving, from a user equipment, a message comprising a logical channel identifier, wherein the logical channel identifier indicates a common control channel and indicates a type of the user equipment, <NUM>; and determining whether the user equipment comprises a reduced capability user equipment based on the logical channel identifier, <NUM>. According to the invention as claimed, the logical channel identifier comprises one of a plurality of logical channel identifiers that distinguish between an apparatus having one receiver chain and an apparatus having two receiver chains.

In accordance with one example embodiment, an apparatus may comprise: processing circuitry; memory circuitry including computer program code, the memory circuitry and the computer program code configured to, with the processing circuitry, enable the apparatus to perform the recited operations.

As used in this application, the term "circuitry" may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit(s) and or processor (s), such as a microprocessor (s) or a portion of a microprocessor (s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. " This definition of circuitry applies to all uses of this term in this application, including in any claims.

In accordance with one example embodiment, a non-transitory computer-readable medium comprising program instructions stored thereon which, when executed with at least one processor, cause the at least one processor to perform the recited operations of the claimed method.

In accordance with another example embodiment, a non-transitory program storage device readable by a machine may be provided, tangibly embodying a program of instructions executable by the machine for performing the operations of the claimed method.

Claim 1:
An apparatus comprising means for performing:
determining a logical channel identifier (<NUM>, <NUM>), wherein the logical channel identifier indicates a common control channel and indicates a type of the apparatus (<NUM>); and
transmitting a message comprising the determined logical channel identifier(<NUM>, <NUM>);
characterized in that the logical channel identifier (<NUM>, <NUM>) comprises one of a plurality of logical channel identifiers that distinguish between an apparatus having one receiver chain and an apparatus having two receiver chains.