Patent Description:
Fifth generation (<NUM>) wireless communications networks are a next generation of mobile communications networks. Standards for <NUM> communications networks are currently being developed by the Third Generation Partnership Project (3GPP). These standards are known as 3GPP New Radio (NR) standards.

Further technological background is known from <CIT>, which discloses that a base station controls access to a shared RACH separately for both MTC and non-MTC devices by sending an access control mask for each device type; Documentation of the <NPL>; <CIT>; and <CIT>.

In the context of the related art, the subject matter of the independent claims is provided.

Example embodiments will become more fully understood from the detailed description given herein below and the accompanying drawings, wherein like elements are represented by like reference numerals, which are given by way of illustration only and thus are not limiting of this disclosure.

Detailed illustrative embodiments are disclosed herein. However, specific structural and functional details disclosed herein are merely representative for purposes of describing example embodiments. The example embodiments may, however, be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein.

It should be understood that there is no intent to limit example embodiments to the particular forms disclosed. On the contrary, example embodiments are to cover all modifications, equivalents, and alternatives. Like numbers refer to like elements throughout the description of the figures.

While one or more example embodiments may be described from the perspective of radio network elements (e.g., gNB), user equipment, or the like, it should be understood that one or more example embodiments discussed herein may be performed by the one or more processors (or processing circuitry) at the applicable device. For example, according to one or more example embodiments, at least one memory may include or store computer program code, and the at least one memory and the computer program code may be configured to, with at least one processor, cause a radio network element (or user equipment) to perform the operations discussed herein.

It will be appreciated that a number of example embodiments may be used in combination.

<FIG> illustrates a simplified diagram of a portion of a <NUM>rd Generation Partnership Project (3GPP) New Radio (NR) access network <NUM> for explaining example embodiments. The 3GPP NR radio access deployment includes at least a first base station (e.g., gNB 101a) having transmission and reception points (TRPs) 102a, 102b, 102c. Each TRP 102a, 102b, 102c may be, for example, a remote radio head (RRH) or remote radio unit (RRU) including at least, for example, a radio frequency (RF) antenna (or antennas) or antenna panels, and a radio transceiver, for transmitting and receiving data within a geographical area. In an example embodiment, the TRP 102a, 102b, 102c can be considered secondary base stations that serve secondary cells (SCells), from the standpoint the TRP 102a, 102b, 102c are smaller base stations that communicate in conjunction with a larger base station (e.g., gNB 101a) that serves a larger cell. The TRPs 102a, 102b, 102c provide cellular resources for user equipment (UEs) 106a, 106b, 106c within a geographical coverage area. In some cases, baseband processing may be divided between the TRPs 102a, 102b, 102c and gNB 101a in a 5th Generation (<NUM>) cell. Alternatively, the baseband processing may be performed at the gNB 101a. In the example shown in <FIG>, the TRPs 102a, 102b, 102c are configured to communicate with the UEs (e.g., UE 106a) via one or more transmit (TX)/receive (RX) beam pairs. The gNB 101a communicates with the network core <NUM>, which is referred to as the New Core in 3GPP NR. In an example embodiment, at least a second base station (e.g., gNB 101b), in a different cell (serving area), can also be included in the network <NUM>.

The TRPs 102a, 102b, 102c may have independent schedulers, or the gNB 101a may perform joint scheduling among the TRPs 102a, 102b, 102c.

It should be understood that the gNB 101a and TRPs 102a, 102b, 102c can provide communication services to a relatively large number of UEs 106a, 106b, 106c within the coverage area of the TRPs 102a, 102b, 102c. For the sake of clarity of example embodiments, communication services (including transmitting and receiving wireless signals) will be discussed primarily between the gNB 101a, TRP 102a and/or the UE 106a, though it should be understood that signals may be transmitted between the gNB <NUM>, any of the TRPs 102a, 102b, 102c, and any of the UEs 106a, 106b, 106c.

<FIG> illustrates a block diagram of a gNB 101a (shown in <FIG>), in accordance with an example embodiment. As shown, the gNB 101a includes: a memory <NUM>; a processor <NUM> connected to the memory <NUM>; various interfaces <NUM> connected to the processor <NUM>; and one or more antennas or antenna panels <NUM> connected to the various interfaces <NUM>. The various interfaces <NUM> and the antenna <NUM> may constitute a transceiver for transmitting/receiving data from/to the gNB 101a via a plurality of wireless beams or from/to the plurality of TRPs 102a, 102b, 102c, etc. As will be appreciated, depending on the implementation of the gNB 101a, the gNB 101a may include many more components than those shown in <FIG>. However, it is not necessary that all of these components be shown in order to disclose the illustrative example embodiment.

The memory <NUM> may be a computer readable storage medium that generally includes a random access memory (RAM), read only memory (ROM), and/or a permanent mass storage device, such as a disk drive. The memory <NUM> also stores an operating system and any other routines/modules/applications for providing the functionalities of the gNB 101a (e.g., functionalities of a gNB, methods according to the example embodiments, etc.) to be executed by the processor <NUM>. These software components may also be loaded from a separate computer readable storage medium into the memory <NUM> using a drive mechanism (not shown). Such separate computer readable storage medium may include a disc, tape, DVD/CD-ROM drive, memory card, or other like computer readable storage medium (not shown). In some example embodiments, software components may be loaded into the memory <NUM> via one of the various interfaces <NUM>, rather than via a computer readable storage medium.

The processor <NUM> may be configured to carry out instructions of a computer program by performing the arithmetical, logical, and input/output operations of the system. Instructions may be provided to the processor <NUM> by the memory <NUM>.

The various interfaces <NUM> may include components that interface the processor <NUM> with the antenna <NUM>, or other input/output components. As will be understood, the various interfaces <NUM> and programs stored in the memory <NUM> to set forth the special purpose functionalities of the gNB 101a will vary depending on the implementation of the gNB 101a.

The interfaces <NUM> may also include one or more user input devices (e.g., a keyboard, a keypad, a mouse, or the like) and user output devices (e.g., a display, a speaker, or the like).

Although not specifically discussed herein, the configuration shown in <FIG> may be utilized to implement, inter alia, the TRPs 102a, 102b, 102c, other radio access and backhaul network elements and/or devices. In this regard, for example, the memory <NUM> may store an operating system and any other routines/modules/applications for providing the functionalities of the TRPs, etc. (e.g., functionalities of these elements, methods according to the example embodiments, etc.) to be executed by the processor <NUM>.

In an example embodiment, the second base station 101b, and additional base stations in the network <NUM>, have the same structure that is depicted in <FIG> for the first base station 101a.

<FIG> illustrates a block diagram of the user equipment (UE) 106a, in accordance with an example embodiment. It should be understood that the other UEs 106b, 106c have the same structure. The UE 106a is a device used by an end-user to communicate via the 3GPP NR radio access deployment shown in <FIG>. Examples of UEs include cellular phones, smartphones, tablet, computers, laptop computers, or the like.

As shown, the UE 106a includes: a memory <NUM>; a processor <NUM> connected to the memory <NUM>; various interfaces <NUM> connected to the processor <NUM>; and one or more antennas or antenna panels <NUM> connected to the various interfaces <NUM>. The various interfaces <NUM> and the antenna <NUM> may constitute a transceiver for transmitting/receiving data to/from the gNB 101a via a plurality of wireless beams or to/from the plurality of TRPs 102a, 102b, 102c, etc. As will be appreciated, depending on the implementation of the UE 106a, the UE 106a may include many more components than those shown in <FIG>. However, it is not necessary that all of these generally conventional components be shown in order to disclose the illustrative example embodiment.

The memory <NUM> may be a computer readable storage medium that generally includes a random access memory (RAM), read only memory (ROM), and/or a permanent mass storage device, such as a disk drive. The memory <NUM> also stores an operating system and any other routines/modules/applications for providing the functionalities of the UE 106a (e.g., functionalities of a UE, methods according to the example embodiments, etc.) to be executed by the processor <NUM>. These software components may also be loaded from a separate computer readable storage medium into the memory <NUM> using a drive mechanism (not shown). Such separate computer readable storage medium may include a disc, tape, DVD/CD-ROM drive, memory card, or other like computer readable storage medium (not shown). In some example embodiments, software components may be loaded into the memory <NUM> via one of the various interfaces <NUM>, rather than via a computer readable storage medium.

The various interfaces <NUM> may include components that interface the processor <NUM> with the antenna <NUM>, or other input/output components. As will be understood, the various interfaces <NUM> and programs stored in the memory <NUM> to set forth the special purpose functionalities of the UE 106a will vary depending on the implementation of the UE 106a.

In an example embodiment, usage scenarios identified for <NUM> are "enhanced mobile broadband" (eMBB), "massive machine-type communication" (mMTC), and "Ultra-Reliable and Low Latency communication" (URLLC). In an example embodiment, another identified area, to locate the boundary between mMTC and URLLC, is "time sensitive communication" (TSC). In an example embodiment, mMTC, URLLC and TSC are associated with novel internet-of things (IoT) use cases that are targeted, for instance, in vertical industries. In an example embodiment, eMBB, mMTC, URLLC and TSC use cases need to be supported in a same network, such as the network <NUM> described below (see <FIG>). In an example embodiment, narrowband internet-of things (NB-IoT) and long-term evolution machine communication (LTE-M) fulfill a requirement for mMTC and can be certified for use in <NUM> technologies. In an example embodiment, for ultra-reliable low-latency communication (URLLC) support, URLLC features have been introduced for both LTE and new radio (NR), and NR URLLC is further enhanced within enhanced URLLC (eURLLC) and industrial IoT work items. Support for time-sensitive networking (TSN) and <NUM> integration for TSC use cases have also been introduced.

In an example embodiment, <NUM> is enabled to connect industries. In an example embodiment, <NUM> connectivity serves as a catalyst for a next wave of industrial transformation and digitalization, which improves flexibility, enhancing productivity and efficiency, reducing maintenance costs, and improving operational safety. In an example embodiment, devices in such environment include, for example, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, actuators, etc. In an example embodiment, connecting these sensors and actuators to <NUM> networks and a core network can be beneficial. A massive industrial wireless sensor network (IWSN) uses requirements described in at least 3GPP specification TR <NUM>, TS <NUM>, TR <NUM> and TS <NUM>, which include URLLC services with very high requirements, and also relatively low-end services with the requirements for small devices or completely wireless devices with a battery life lasting several years. The 3GPP requirements for these services are higher than low-power wide-area LPWA devices, such as LTE-M/NB-IOT, but the requirements are lower than ultra-reliable and low latency (URLCC) devices and eMBB devices.

In an example embodiment, and similar to connected industries, <NUM> connectivity can serve as a catalyst for a next wave of smart city innovations. For example, the 3GPP specification TS <NUM> describes "smart city" requirements. In an example embodiment, the smart city vertically covers data collection and processing, in order to more efficiently monitor and control city resources, and provide services to city residents. In an example embodiment, a deployment of surveillance cameras is an essential part of the smart city, which may also be implemented for factories and industries.

In an example embodiment, wearable devices, such as smart watches, rings, eHealth related devices, and medical monitoring devices can benefit from low-end service requirements for small devices. In an example embodiment, a characteristic for these service requirements is that the device is relatively "small in size.

In an example embodiment, the requirements for these "small in size" devices is listed, below.

Device complexity: In an example embodiment, a motivation for the small device is a lower cost device, with a lower complexity, as compared to high-end eMBB and URLLC devices (which are defined, for instance, in Rel-<NUM>/Rel-<NUM> of 3GPP). In an example embodiment, this is especially the case for small devices that are industrial sensors.

Device size: In an example embodiment, a requirement for most the small devices is that the devices are enabled as a physically small device, from a form factor standpoint. In an example embodiment, and as described above, the small devices are for instance wearables, small sensors, small monitors, etc..

Deployment scenarios: In an example embodiment, a system should support all frequency-<NUM> (FR1) / frequency-<NUM> (FR2) bands, for frequency division duplex (FDD) and time division duplex (TDD) networks.

In an example embodiment, use case specific requirements are listed below:.

Industrial wireless sensors: In an example embodiment, requirements for sensors is described in 3GPP TR <NUM> and TS <NUM>. In an example embodiment, sensors have a communication service availability of <NUM>% and an end-to-end latency of less than <NUM>. In an example embodiment, a reference bit rate of the sensors is less than <NUM> Mbps for all devices that are stationary, where the bit rate is potentially asymmetric (e.g. UL heavy traffic). In an example embodiment, a battery for the sensor should last at least a few years. In an example embodiment, for safety related sensors, a latency requirement is relatively low, such as <NUM>-<NUM>.

Video Surveillance: In an example embodiment, and as described in 3GPP TS <NUM>, a reference economic video bitrate for video surveillance devices is <NUM>-<NUM> Mbps, a latency is less than <NUM>, a reliability (availability) is <NUM>%-<NUM>%. In an example embodiment, high-end video is used with the video surveillance, for example the video transmission rate is <NUM>-<NUM> Mbps. In an example embodiment, a traffic pattern for the video surveillance is dominated by uplink (UL) transmissions.

Wearables: In an example embodiment, a reference bitrate for smart wearable application can be <NUM>-<NUM> Mbps, in a downlink (DL) direction, with a minimum <NUM> Mbps in UL, and with a peak bit rate of <NUM> Mbps for downlink and <NUM> Mbps for uplink. In an example embodiment, a battery for the device lasts multiple days (up to <NUM>-<NUM> weeks).

Example embodiments are applicable to user equipment (UE) features and parameters with lower end capabilities, relative to 3GPP Release <NUM> for eMBB and URLLC NR, to serve the three use cases described above.

In an example embodiment, the devices that have reduced capabilities may include a limited set of one or more device types to ensure that the device types may be used for their intended use.

In an example embodiment, a functionality for the reduced capability devices is to be explicitly identifiable to networks and network operators, to allow network operators to restrict the access of the devices, if desired.

"Reduced capability" (REDCAP) devices, such as for example REDCAP UEs, may consume more network resources compared to traditional devices, and therefore the network needs the capability to allow the network, or the network operators, to control access of the REDCAP devices.

In an example embodiment, to manage use of potentially extensive resources from the network for REDCAP devices, a network operator may prevent specific subscribers from using enhanced coverage, for example. In an example embodiment, when in narrowband (NB) S <NUM> mode, the UE shall indicate support for restriction on use of enhanced coverage. In an example embodiment, when in wide-band (WB) S <NUM> mode, the UE supporting either Coverage Extention (CE) mode A or CE mode B shall indicate support for restriction on use of enhanced coverage. In an example embodiment, the UE supporting restriction on use of enhanced coverage indicates its support for restriction on use of enhanced coverage in an "attach request" and a "tracking area update request" message. In an example embodiment, if the UE supports restriction on use of enhanced coverage, the mobility management entity (MME) indicates whether the use of enhanced coverage is restricted or not in an "attach accept" message and a "tracking area update accept" message. In an example embodiment, if the use of enhanced coverage is restricted, the UE shall not use enhanced coverage in a registered public land mobile network (PLMN), and in any PLMN which is in a list of equivalent PLMNs.

In an example embodiment, if the REDCAP UE supports CE mode B, the network determines the following:.

In an example embodiment, if the REDCAP UE supports CE mode B, and upper layers of the network indicate that CE mode B is restricted, then the cell selection criterion (S) in a normal coverage is based on values Qrxlevmin and Qqualmin, or in enhanced coverage the cell selection criterion is based on values Qrxlevmin_CE and Qqualmin_CE that are to be fulfilled.

In an example embodiment, if cell selection criterion S in normal coverage is not fulfilled for a cell, and the REDCAP UE does not consider itself in enhanced coverage based on coverage specific values Qrxlevmin_CE and Qqualmin_CE, the UE shall consider itself to be in enhanced coverage, if the UE supports CE Mode B and CE mode B is not restricted by upper layers, and the cell selection criterion S for enhanced coverage is fulfilled, where:.

The example embodiments include restricting access of REDCAP UEs. More specifically, in an example embodiment the restriction/allowance of access can be limited to certain REDCAP UEs, for instance, pertaining to a used feature and/or a subscription type.

<FIG> illustrates a communication diagram for providing access for reduced capability devices, in accordance with an example embodiment. In an example embodiment, the UE 106a of <FIG> is a REDCAP device that has reduced capabilities, as defined above. In an example embodiment, while the discussion of <FIG> includes UE 106a, it should be understood that any other REDCAP device, in addition to another UE device, or any other REDCAP device as discussed herein, can instead be included in this <FIG> example embodiment.

In an example embodiment, and as shown in step S402 of <FIG>, the UE 106a is turned on.

In an example embodiment, and as shown in step S404, the processor <NUM> of the first base station (e.g., gNB 101a of <FIG>) sends system information for the network <NUM>. In an example embodiment, the system information is sent within a first registered public land mobile network (PLMN1), which is associated with a coverage area of the gNB 101a.

In an example embodiment, and as shown in step S406, the processor <NUM> of the UE 106a sends a registration request message (REDCAP indication) to a mobility management function (AMF) that is located within the network core <NUM>.

In an example embodiment, and as shown in step S408, the processor <NUM> of the UE 106a receives a registration accept message from the AMF, in response to the registration request message. In an example embodiment, the registration accept message includes information that includes a REDCAP authorization configuration for the UE 106a.

With regard steps S404, S406 and S408 of <FIG>, a further discussion of a content of the information exchange for these steps, is included below.

In an example embodiment, the REDCAP UE 106a is informed, for example via radio resource control (RRC) or NAS signaling, whether REDCAP functionality is allowed in the network, or not.

In an example embodiment, allowance information is signaled, based on the PLMN, the radio access network (RAT), the frequency, and/or the frequency range. In one example embodiment, allowance information may comprise multiple of the PLMNs, the RATs, the frequencies, and/or the frequency ranges, and/or a combination of these.

In an example embodiment, allowance information for REDCAP functionality is signaled explicitly for different features (i.e. usage of some feature can be allowed, and usage of some feature can be disallowed, etc.). In an example embodiment, the processor <NUM> of the UE 106a may deduce, for example from broadcasted system information, whether the UE 106a is allowed to access the serving cell of the gNB 101a, based on the allowed functionality.

In an example embodiment, allowance information is signaled, for example for one or more of the following functionalities: reduced number of UE 106a receive (RX) / transmit (TX) antennas, radio resource management (RRM) relaxation, coverage enhancement, half-duplex-FDD, device type (e.g., REDCAP type-<NUM>, REDCAP type-<NUM>), etc..

In an example embodiment, the UE 106a is assigned a REDCAP device category. In an example embodiment, notification of this assignment occurs, for example, via RRC or NAS signaling, or encoded in a universal subscriber identity module (USIM), where the processor <NUM> of the UE 106a checks the access restriction/allowance for a specific cell (such as the cell served by the gNB 101a that the UE 106a is currently in). In an example embodiment, the core <NUM> of the network <NUM>, or the AMF of the core <NUM>, can indicate to the UE 106a (for example via the system information), the identity of the device categories that are allowed and restricted in the cell.

Continuing with the discussion of <FIG>, in an example embodiment and as shown in step S410, the processor <NUM> of the UE 106a determines that uplink data in the memory <NUM> of the UE 106a is available for transmission.

In an example embodiment, and as shown in step S412, the processor <NUM> of the UE 106a and the processor <NUM> of the gNB 101a establish a RRC connection.

In an example embodiment, and as shown in step S414, the processor <NUM> of the UE 106a and the processor <NUM> of the gNB 101a conduct an uplink data transmission exchange.

In an example embodiment, and as shown in step S416, the processor <NUM> of the UE 106a receives a RRC release message from the processor <NUM> of the gNB 101a.

Continuing with the discussion of <FIG>, in an example embodiment and as shown in step S418, UE 106a moves to another geographic location (e.g., PLMN2), and the processor <NUM> of the UE 106a determines that the UE 106a is now in another cell area, such as for instance a cell of the second base station (e.g., gNB 101b of network <NUM> of <FIG>).

In an example embodiment, and as shown in step S420, the processor <NUM> of the UE 106a performs cell selection, to select the new cell area associated with gNB 101b.

In an example embodiment, and as shown in step S422, the processor <NUM> of the UE 106a receives system information from the gNB 101b. In an example embodiment, this step is the same as step S404, described above.

In an example embodiment, and as shown in step S424, the processor <NUM> of the UE 106a determines that "camping" of the UE 106a is not allowed in the new cell area (PLMN2), due to the indication information that was originally obtained in step S408 from the AMF of the core <NUM>.

In an example embodiment, and as shown in step S426, the processor <NUM> of the UE 106a determines that a new cell selection process should be conducted. Therefore, in an example embodiment, the processor <NUM> of the UE 106a starts the selection process for a new cell that allows access for the UE 106a (e.g., a new cell that allows access of a REDCAP device).

In an example embodiment, and alternatively to the step S408 of <FIG>, the Registration Accept (step S408 in <FIG>) could provide the processor <NUM> of the UE 106a with indication information that includes of an identity of carriers (under a PLMN(s)) that can be used by REDCAP UEs (e.g. for camping). In an example embodiment, the network <NUM>, or the core <NUM> of the network <NUM>, can indicate to the REDCAP UE 106a that only a first frequency carrier (e.g., FR1 carrier) is allowed, while a second frequency carrier (e.g., FR2 carrier) does not allow access for the UE 106a. In an example embodiment, the indication from the network <NUM> informs the UE 106a, for instance, whether TDD carriers allow access of the UE 106a, or whether only FDD carriers allow access of the UE 106a for high-density (HD) operations (as an example).

In an example embodiment, the network <NUM>, or the core <NUM> of the network <NUM>, determines the PLMN, RAT, carrier frequencies or frequency ranges, based on the UE 106a capability, for example so that if the REDCAP UE 106a bandwidth capability requires, for instance, maximum bandwidth (max BW) or radio frequency (RF) front-end requirements, these requirements are met. In an example embodiment, if the network <NUM> cannot meet the requirements for the UE 106a, the network <NUM> or the core <NUM>, access for the UE 106a will be restricted for certain carrier frequencies, for example, where the total carrier bandwidth is not large enough. In an example embodiment, if the REDCAP UE 106a is for example only half-duplex capable, only TDD carriers are indicated to be allowed. Consequently, if the UE 106a has limitations for the HD capability (as an example), in terms of continuous UL or DL allocations, the network <NUM> and/or core <NUM> can indicate only selected TDD carriers which UL-DL-TDD configuration would be best match for the capability, or whether FDD carriers are to be used, and minimize the network implications. In one example embodiment, the REDCAP UE 106a is authorized to use only certain maximum channel bandwidth or bandwidth part width. In case such is not available on a cell, the REDCAP UE 106a may not be allowed to access the cell.

<FIG> illustrates a method for providing access for reduced capability devices, in accordance with a claimed embodiment. In an example embodiment, the method is performed by a REDCAP device. In an example embodiment, the method is performed by the processor <NUM> of the REDCAP UE 106a, as shown in <FIG> and <FIG>.

In an embodiment, and as shown in step S500, the processor <NUM> of the UE 106a receives authorization information. In an example embodiment, the authorization information is received from the core <NUM> of the network <NUM>. In an example embodiment, the authorization information is received directly via the core <NUM>, or the AMF of the core <NUM>, or from a base station (e.g., gNB 101a) that provides cell coverage within the area of the UE 106a. In an example embodiment, the authorization information includes configuration information (configuration data). In an example embodiment, the authorization information includes REDCAP authorization configuration information, that includes REDCAP access information. In an example embodiment, the configuration information includes access information for the UE 106a for at least one of: a PLMN, a RAT, a frequency, or a frequency range. In an example embodiment, the authorization information includes permissions to allow REDCAP access for the UE 106a, for the UE 106a to operate with at least one capability that is reduced, in terms of: a reduced number of RX/TX antennas, a RRM relaxation, coverage enhancement, and/or half-duplex FDD. In an example embodiment, the authorization information and//or the configuration information includes an identity of the device type for the UE 106a (e.g., REDCAP device type). In an example embodiment, this step S500 is the same as step S408 of <FIG>.

In an embodiment, and as shown in step S502, the processor <NUM> of the UE 106a receives system information. In an example embodiment, the system information is received from a base station (e.g., gNB 101a) that provides cell coverage within the area of the UE 106a (e.g., the area where the UE 106a is "camping"). In an example embodiment, the system information is specific to the first base station (e.g., gNB 101a). In an example embodiment, this step S502 is the same as step S404 described in <FIG>.

In an example embodiment, and as shown in step S504, the processor <NUM> of the UE 106a determines access information, at least in part due to the system information from step S502. In an example embodiment, the processor <NUM> of the UE 106a determines access information, at least in part due to the system information and the authorization information (of step S500). In an example embodiment, the determination of the access information includes a determination of whether the UE 106a is allowed to access the cell of the gNB <NUM>. In an example embodiment, this step is the same as step S424 of <FIG>.

In an example embodiment, and as shown in step S506, the processor <NUM> of the UE 106a accesses the cell (first cell), or performs a selection of another cell (a second cell) that does allow REDCAP access, based on the determination of step S504. In an example embodiment, the step of accessing of the first cell is the same as steps S410-S416 of <FIG>. In an example embodiment, the selection of the second cell is the same as step S426 of <FIG>.

In an example embodiment, the first cell is served by at least one first base station that includes the first base station (101a), as shown in <FIG>. In an example embodiment, the second cell is served by at least one second base station that includes the second base station (101b), as shown in <FIG>. In an example embodiment, the first cell and the second cell each include multiple base stations that serve each of the cells. In an example embodiment, the first cell and the second cell include at least one common base station that is common to both cells. In an example embodiment, the first cell and the second cell do not share any common base stations.

As discussed herein, illustrative embodiments will be described with reference to acts and symbolic representations of operations (e.g., in the form of flow charts, flow diagrams, data flow diagrams, structure diagrams, block diagrams, etc.) that may be implemented as program modules or functional processes include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types and may be implemented using existing hardware at, for example, existing user equipment, base stations, an as Evolved Node B (eNBs), a remote radio head (RRH), a <NUM> base station (gNBs), femto base stations, network controllers, computers, or the like. Such existing hardware may be processing or control circuitry such as, but not limited to, one or more processors, one or more Central Processing Units (CPUs), one or more controllers, one or more arithmetic logic units (ALUs), one or more digital signal processors (DSPs), one or more microcomputers, one or more field programmable gate arrays (FPGAs), one or more System-on-Chips (SoCs), one or more programmable logic units (PLUs), one or more microprocessors, one or more Application Specific Integrated Circuits (ASICs), or any other device or devices capable of responding to and executing instructions in a defined manner.

As disclosed herein, the term "storage medium," "computer readable storage medium" or "non-transitory computer readable storage medium" may represent one or more devices for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other tangible machine-readable mediums for storing information. The term "computer-readable medium" may include, but is not limited to, portable or fixed storage devices, optical storage devices, and various other mediums capable of storing, containing or carrying instruction(s) and/or data.

Furthermore, example embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine or computer readable medium such as a computer readable storage medium. When implemented in software, a processor or processors will perform the necessary tasks. For example, as mentioned above, according to one or more example embodiments, at least one memory may include or store computer program code, and the at least one memory and the computer program code may be configured to, with at least one processor, cause a network element or network device to perform the necessary tasks. Additionally, the processor, memory and example algorithms, encoded as computer program code, serve as means for providing or causing performance of operations discussed herein.

A code segment of computer program code may represent a procedure, function, subprogram, program, routine, subroutine, module, software package, class, or any combination of instructions, data structures or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable technique including memory sharing, message passing, token passing, network transmission, etc..

The terms "including" and/or "having," as used herein, are defined as comprising (i.e., open language). The term "coupled," as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. Terminology derived from the word "indicating" (e.g., "indicates" and "indication") is intended to encompass all the various techniques available for communicating or referencing the object/information being indicated. Some, but not all, examples of techniques available for communicating or referencing the object/information being indicated include the conveyance of the object/information being indicated, the conveyance of an identifier of the object/information being indicated, the conveyance of information used to generate the object/information being indicated, the conveyance of some part or portion of the object/information being indicated, the conveyance of some derivation of the object/information being indicated, and the conveyance of some symbol representing the object/information being indicated.

According to example embodiments, user equipment, base stations, eNBs, RRHs, gNBs, femto base stations, network controllers, computers, or the like, may be (or include) hardware, firmware, hardware executing software or any combination thereof. Such hardware may include processing or control circuitry such as, but not limited to, one or more processors, one or more CPUs, one or more controllers, one or more ALUs, one or more DSPs, one or more microcomputers, one or more FPGAs, one or more SoCs, one or more PLUs, one or more microprocessors, one or more ASICs, or any other device or devices capable of responding to and executing instructions in a defined manner.

Claim 1:
A method for a reduced capability, REDCAP, device (106a), the method comprising:
receiving (S502) system information from a base station (101a) serving a cell, the system information including allowance information specific to a device category associated with the REDCAP device (106a);
receiving (S500) authorization information including configuration data for REDCAP devices and indicating whether a half-duplex frequency division duplex functionality is allowed for the REDCAP device (106a); and
determining (S504), based on the allowance information and the authorization information, whether access to the cell by the REDCAP device (106a) is permitted.