Extended discontinuous reception (eDRX) for reduced capability (REDCAP) user equipment

Abstract

This application relates to extended discontinuous reception (eDRX) for reduced capability (RedCap) user equipment. This application relates to support of eDRX by a RedCap UE. In one example, a UE indicates to a network that the UE is operating as a RedCap UE and requests an eDRX configuration. In response, the network selects one or more values for the eDRX and sends such values to the UE.

Description

[0001] The Third Generation Partnership Project (3GPP) Technical Specifications (TSs) define standards for wireless networks. These TSs define the operation of a 5G system (5GS) that provides data connectivity and services. BRIEF DESCRIPTION OF DRAWINGS

[0002] Figure 1 A network environment is shown in accordance with some embodiments.

[0003] Figure 2 An example of a timing diagram for non-access stratum (NAS) transmission and extended discontinuous reception (eDRX) is shown in accordance with some embodiments.

[0004] Figure 3 Another example of a timing diagram for NAS transmission and eDRX is shown in accordance with some embodiments.

[0005] Figure 4 A further example of a timing diagram for NAS transmission and eDRX is shown in accordance with some embodiments.

[0006] Figure 5 An example of a timing diagram for NAS registration and eDRX is shown in accordance with some embodiments.

[0007] Figure 6 Another example of a timing diagram for NAS registration and eDRX is shown in accordance with some embodiments.

[0008] Figure 7 An example of a signaling diagram for indicating reduced capability and associated eDRX cycle value is shown in accordance with some embodiments.

[0009] Figure 8 An example of a reduced capability based data transmission diagram is shown in accordance with some embodiments.

[0010] Figure 9 Another example of a reduced capability based data transmission diagram is shown in accordance with some embodiments.

[0011] Figure 10 A further example of a reduced capability based data transmission diagram is shown in accordance with some embodiments.

[0012] Figure 11 An example of an operational flow / algorithmic structure for indicating reduced capability and associated eDRX cycle value is shown in accordance with some embodiments.

[0013] Figure 12 Another example of an operational flow / algorithmic structure for indicating reduced capability and associated eDRX cycle value is shown in accordance with some embodiments.

[0014] Figure 13 An example of a receiving component is shown in accordance with some embodiments.

[0015] Figure 14 An example of a UE is shown in accordance with some embodiments.

[0016] Figure 15 An example of a base station is shown in accordance with some embodiments. DETAILED DESCRIPTION

[0017] The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments can be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrase “A or B” means (A), (B), or (A and B).

[0018] Generally, a user equipment (UE) can communicate information with a network. The amount of uplink (UL) and downlink (DL) traffic from and to the UE can vary based on a number of factors including, for example, the UE type. Optimization can be performed based on the UE type and the amount of expected traffic. In one example, the UE type is a reduced capability (RedCap) UE type, where the UE has reduced capabilities relative to a non-RedCap UE. The reduced capabilities relate to the RedCap UE’s communication bandwidth, receive branches, multiple-input multiple-output (MIMO) layers, modulation order, and / or duplex operation. The amount of expected traffic for a RedCap UE is relatively lower than the amount of expected traffic for a non-RedCap UE, and the RedCap UE has lower battery consumption than the non-RedCap UE.

[0019] To improve battery consumption for RedCap UEs, extended discontinuous reception (eDRX) can be used. In one example, values for eDRX cycle can be defined for RedCap UE types and associated with a Fifth Generation Mobility Management (5GMM)-IDLE mode or a 5GMM-CONNECTED mode with Radio Resource Control (RRC) inactive indication. These values can be defined together with non-access stratum (NAS) message retransmission timers and NAS periodic registration timers such that the eDRX cycle does not cause NAS transmission (NAS retransmission) failures or NAS periodic registration failures. In addition, a RedCap UE can indicate its reduced capability to the network. In response, the network selects one or more of the eDRX cycle values and indicates the selected values to the RedCap UE. Thereafter, the RedCap UE can set the eDRX cycle to the relevant values and enter the eDRX state. These and other eDRX related functions for RedCap UEs are further described herein below.

[0020] The following is a glossary of terms that can be found in the disclosure.

[0021] As used herein, the term “circuitry” refers to, is part of, or includes: hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (for example, a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable system-on-a-chip (SoC)), or a digital signal processor (DSP) that is configured to provide the described functionality. In some embodiments, circuitry can execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” can also refer to the combination of one or more hardware elements with the program code used to carry out the functionality of the program code, which may

[0022] As used herein, the term “processor circuitry” refers to, is part of, or includes: circuitry capable of sequentially and automatically processing a series of arithmetic or logical operations or recording, storing, or transmitting digital data. The term “processor circuitry” can refer to an application processor, a baseband processor, a central processing unit (CPU), a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions such as program code, software modules, and / or functional processes.

[0023] As used herein, the term “interface circuitry” refers to circuitry that enables the exchange of information between two or more components or devices, is part of, or includes, such circuitry. The term “interface circuitry” can refer to one or more hardware interfaces, such as a bus, an I / O interface, a peripheral component interface, a network interface card, and the like.

[0024] As used herein, the term “user equipment” or “UE” refers to a device with radio communication capabilities and can describe a remote user of network resources in a communication network. Further, the term “user equipment” or “UE” can be considered synonymous, and can be referred to as a client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, and the like. Further, the term “user equipment” or “UE” can include any type of wireless / wired device or any computing device including a wireless communication interface.

[0025] As used herein, the term “base station” refers to a device with radio communication functionality that is a network node of a communication network (or more succinctly, a network) and can be configured as an access node in the communication network. Access by a UE to the communication network can be managed at least in part by the base station, whereby the UE connects with the base station to access the communication network. Depending on the radio access technology (RAT), the base station can be referred to as a gNodeB (gNB), an eNodeB (eNB), an access point, and the like.

[0026] As used herein, the term “computer system” refers to any type of interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” or “system” can refer to various components of a computer that are communicatively coupled to one another. Further, the term “computer system” or “system” can refer to multiple computer devices or multiple computing systems that are communicatively coupled to one another and configured to share computing resources or networking resources.

[0027] As used herein, the term "resource" refers to a physical or virtual device, a physical or virtual component within a computing environment, or a physical or virtual component within a particular device, such as a computer device, a mechanical device, memory space, processor / CPU time, processor / CPU usage, processor and accelerator load, hardware time or usage, power supply, input / output operations, port or network socket, channel / link allocation, throughput, memory usage, storage, network, database and application, units of work, and the like. A "hardware resource" can refer to computing, storage, or network resources provided by a physical hardware element. A "virtualized resource" can refer to computing, storage, or network resources provided by a virtualization infrastructure to an application, device, system, and the like. The term "network resource" or "communication resource" can refer to a resource that is accessible to a computer device / system via a communication network. The term "system resource" can refer to any kind of shared entity that provides a service, and can include a computing resource or a network resource. A system resource can be considered as a set of coherent functionalities, network data objects, or services that are accessible through a server, where such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0028] As used herein, the term "channel" refers to any tangible or intangible transmission medium that is used to communicate data or data streams. The term "channel" can be synonymous with or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," or any other similar term denoting a pathway or medium through which data is communicated. Additionally, as used herein, the term "link" refers to a connection made between two devices for transmitting and receiving information.

[0029] As used herein, the terms "instantiate," "instantiation," and the like refer to the creation of an instance. An "instance" refers to a concrete occurrence of an object, which can occur, for example, during execution of program code.

[0030] The term "connect" can mean that two or more elements have an established signaling relationship with each other over a communication channel, link, interface, or reference point at a common communication protocol layer.

[0031] As used herein, the term "network element" refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term "network element" can be considered synonymous with or referred to as a networked computer, networked hardware, network equipment, network node, virtualized network function, and the like.

[0032] The term "information element" refers to a structural element containing one or more fields. The term "field" refers to individual content of an information element, or a data element containing content. An information element can include one or more additional information elements.

[0033] Figure 1 A network environment 100 is shown in accordance with some embodiments. The network environment 100 can include a UE 104 as part of a Fifth Generation (5G) system (5GS) 108. The 5GS 108 can also include a 5G access network, e.g., a Next Generation (NG) Radio Access Network (RAN) 112, and a 5G core network, e.g., a 5GC 116. The NG RAN 112 can include base stations, e.g., gNBs such as gNB 114, that provide New Radio (NR) user plane and control plane protocol terminations toward the UE 104. The NG RAN 112 can be coupled with an Access and Mobility Management Function (AMF) 120 of the 5GC 116.

[0034] The components of the network environment 100 can be coupled with one another through various interfaces (or reference points) that define signaling protocols between the respective components. These interfaces can include an N1 interface between the UE 104 and the AMF 120 (e.g., between a NAS layer or NAS of the UE and the AMF 120 for brevity), an N2 interface between the NG RAN 112 and the AMF 120, an NR-Uu interface between the UE 104 and the NG RAN 112, an LTE-Uu interface between the UE 104 and an Evolved Universal Terrestrial Access Network (E-UTRAN) 124, and an Xn interface between the E-UTRAN 124 and the NG RAN 112. It should be understood that these interfaces define end-to-end signaling protocols between the respective components. Actual signals can pass through other components. For example, while signals between the AMF 120 and the UE 104 can be exchanged using the N1 protocol, the signals can be transmitted through one or more nodes of the NG RAN 112.

[0035] The AMF 120 can be a control plane function that provides registration management, connection management, reachability management, and mobility management services. Registration management can allow the UE 104 to register and deregister with the 5GS 108. Upon registration, a UE context can be created within the 5GC 116. The UE context can be a set of parameters that identify and characterize the UE 104. The UE context can include UE identity information, UE capability information, access and mobility information, or protocol data unit (PDU) session information.

[0036] Generally, the AMF 120 and the 5GS 108 can perform a number of registration area management functions to allocate / reallocate a registration area to the UE 104. The registration area can include a set of tracking areas, where each tracking area includes one or more cells that cover a geographic area. A tracking area is identified by a tracking area identity, which can be broadcasted in the cells of the tracking area.

[0037] Connection management can be used to establish and release a control plane signaling connection between the UE 104 (e.g., NAS) and the AMF 120. Establishing a control plane signaling connection moves the UE 104 from a connection management (CM)-IDLE to a CM-CONNECTED.

[0038] Mobility management can be used to maintain knowledge of the location of the UE 104 within the network. Mobility management can be performed by a 5GS mobility management (5GMM) sublayer of the NAS within the UE 104 and the AMF 120 to support identification, security, and mobility of the UE 104 and to provide connection management services to other sublayers.

[0039] The 5GMM sublayer can be associated with different states managed independently according to access type (e.g., 3GPP access or non-3GPP access). The 5GMM sublayer can be in a 5GMM-DEREGISTERED state if a 5GMM context has not been established and the network is not aware of the UE location. To establish a 5GMM context, the sublayer can participate in an initial registration to enter a 5GMM-REGISTERED-INITIATED state and, once the initial registration is accepted, the sublayer can enter a 5GMM-REGISTERED state with a 5GMM context established. From the 5GMM-REGISTERED state, once a deregistration is requested, the sublayer can enter a 5GMM DEREGISTERED-INITIATED state. Once the deregistration is accepted, the sublayer can enter the 5GMM-DEREGISTERED state. From the 5GMM-REGISTERED state, the sublayer can also enter a 5GMM-SERVICE-REQUEST-INITIATED state by initiating a service request and, once the service request is accepted, rejected, or failed, the sublayer can re-enter the 5GMM-REGISTERED state. As used herein, a service request can refer to both control plane and user plane service requests.

[0040] The 5GMM sublayer can have a 5GMM-CONNECTED mode and a 5GMM-IDLE mode that affect the manner in which various procedures are performed.

[0041] The 5GMM-CONNECTED mode with an RRC inactivity indication (or RRC suspended state) is a NAS state introduced by 3GPP to improve the resume and suspend operation of the RRC connection by reducing the time taken to reactivate suspended bearers to release the RRC connection and use the service request procedure to activate the RRC connection compared to the long term evolution (LTE) approach. Fast recovery or suspension of active data radio bearers (DRBs) can improve user experience and reduce the usage of radio resources.

[0042] The transition to and operation within the 5GMM-CONNECTED mode with RRC Inactive indication is defined as follows:

[0043] A UE is in the 5GMM-CONNECTED mode with RRC Inactive indication when it is in:

[0044] a) 5GMM-CONNECTED mode over 3GPP access at NAS layer; and

[0045] b) RRC_INACTIVE state at AS layer (see 3GPP TS 38.300

[27] ).

[0046] …

[0047] The UE shall transition from the 5GMM-CONNECTED mode to the 5GMM-CONNECTED mode with Inactive indication over 3GPP access when it receives an indication from lower layers that the RRC connection has been suspended.

[0048] NOTE 0: When receiving an indication from lower layers that the RRC connection has been suspended, any pending procedure or uplink data packet triggers a request to lower layers to transition to RRC_CONNECTED state. This is also the case when a pending procedure or uplink data packet triggers a previous request to lower layers to transition to RRC_CONNECTED state.

[0049] …

[0050] If a UE in the 5GMM-CONNECTED mode with RRC Inactive indication receives an indication from lower layers that the RRC connection has been suspended, the UE shall remain in the 5GMM-CONNECTED mode with RRC Inactive indication. If still needed, the UE shall re-initiate any pending procedure that triggered a request to lower layers to transition to RRC_CONNECTED state.

[0051] 3GPP TS 24.501 v16.8.0 (2021-04), clause 5.3.1.4.

[0052] Accordingly, the UE 104 can operate in a 5GMM-CONNECTED mode with an inactive indication (which can be considered a connected mode of the NAS layer over the signaling plane with the AMF 120) and in an RRC_INACTIVE state (which can be considered a connected state of the access stratum (AS) layer over the data plane with the network, whereby the UE 104 is not receiving and / or transmitting data). The UE 104 can also operate in the 5GMM-CONNECTED mode of the NAS layer and the RRC_CONNECTED state of the AS layer (whereby the UE 104 is receiving and / or transmitting data).

[0053] With Rel-17 of the 3GPP Technical Specifications, a proposal is considered for RedCap UEs. Although there is no final 3GPP definition for whether a UE qualifies as a RedCap UE, RedCap UEs generally have reduced capabilities relative to non-RedCap UEs, where the capabilities relate to communication with the network and can help reduce battery (or power) consumption. In 3GPP document RP-210918 (March 2021), a set of possible requirements that the reduced capabilities can relate to are found:

[0054] • Reduced maximum UE bandwidth:

[0055] o A maximum bandwidth of 20 MHz for FR1 RedCap UEs during initial access and after.

[0056] o A maximum bandwidth of 100 MHz for FR2 RedCap UEs during initial access and after.

[0057] • Reduced minimum number of Rx branches:

[0058] o For frequency bands where legacy NR UEs are required to be equipped with a minimum of 2 Rx antenna ports, the minimum number of Rx branches supported for RedCap UEs is 1. The specification also supports 2 Rx branches for RedCap UEs in these frequency bands.

[0059] o For frequency bands where legacy NR UEs (except 2-Rx vehicular UEs) are required to be equipped with a minimum of 4 Rx antenna ports, the minimum number of Rx branches supported for RedCap UEs is 1. The specification also supports 2 Rx branches for RedCap UEs in these frequency bands.

[0060] o Means by which a gNB can learn the number of Rx branches of a UE should be specified.

[0061] • Maximum number of DL MIMO layers:

[0062] o For RedCap UEs with 1 Rx branch, 1 DL MIMO layer is supported.

[0063] o For RedCap UEs with 2 Rx branches, 2 DL MIMO layers are supported.

[0064] • Relaxation of maximum modulation order:

[0065] o For FR1 RedCap UEs, support of 256QAM in DL is optional (instead of mandatory).

[0066] o No maximum modulation order is specified for RedCap UEs.

[0067] • Duplex operation:

[0068] o HD-FDD Type A with minimal normative impact (note that FD-FDD and TDD are also supported).

[0069] As used herein, the term “RedCap UE” (or, in other words, New Radio (NR)-RedCap) refers to a UE with reduced capabilities according to any adopted 3GPP TS definition. The reduced capabilities can relate to the RedCap UE’s communication bandwidth, receive branches, MIMO layers, modulation order, and / or duplex operation.

[0070] RedCap UEs can be used in multiple scenarios, including for enhanced mobile broadband (eMBB), massive machine type communication (mMTC), ultra-reliable and low latency communication (URLLC), time sensitive communication (TSC), industrial internet of things (IIoT), smart city innovation, wearable devices (eHealth related devices, personal protective equipment (PPE), and medical monitoring devices used in public safety applications, among others), and other use cases. UE complexity reduction, coverage recovery, and / or UE power saving are some of the key requirements for devices in these categories.

[0071] DRX is a mechanism for reducing the power consumption of a UE. Generally, the mechanism involves the UE entering a sleep mode (e.g., by deactivating or powering down its receive chain or some components of the UE) for a certain period of time, and then waking up (e.g., by activating or powering up the receive chain or components) at fixed intervals to receive signals. eDRX is an extension of DRX to further reduce power and involves a longer duration of the sleep mode.

[0072] For LTE, eDRX has already been supported, whereby the duration of the eDRX cycle is 2,621.44 seconds for wideband (WB)-N1 UEs in 5GMM-IDLE mode, 10,488.76 seconds for narrowband (NB)-N1 UEs in 5GMM-IDLE mode, and 10.24 seconds for WB-N1 UEs in 5GMM_CONNECTED mode with RRC Inactive indication.

[0073] The eDRX feature can be used to enhance and improve the power consumption of RedCap UEs. However, extending the DRX cycle by up to 10,488.76 seconds (e.g., as for NB-N1 UEs in 5GMM-IDLE mode for LTE) can impact the operations of RedCap UEs. These operations can include NAS transmission and NAS periodic registration. To mitigate, reduce, or avoid the impact, specific eDRX cycle values can be defined together with NAS transmission timers and NAS periodic registration timers, as further described in the following figures.

[0074] Figure 2 An example of a timing diagram 200 for NAS transmission and eDRX is shown, in accordance with some embodiments. These timing diagrams 200 can result in a NAS transmission failure 210. As shown, the top timing diagram corresponds to NAS transmission, and the bottom timing diagram corresponds to the eDRX cycle.

[0075] In general, a NAS layer of a UE (e.g., UE 104) can send signaling information to the network (e.g., to an AMF 120). Likewise, the network can send signaling information to the UE. These types of signaling information communications are referred to herein as NAS transmission. A network node (e.g., a UE or an AMF) can initiate a NAS related procedure and perform a NAS transmission of a message (shown in the top timing diagram with a blank rectangle) to another node (e.g., an AMF or a UE) as part of the procedure. Based on the message, the node expects a response back from the other node (e.g., from the AMF or the UE). If the response is not received, a NAS retransmission of the message (shown in the top timing diagram with a diagonally hatched rectangle) is performed. The NAS retransmission can be performed multiple times (the number is shown in the top timing diagram as five) if the response is still not received. And if the response has still not been received, the node can determine that the NAS transmission failed 210, and the failure can be considered a failure of the NAS related procedure. The timing between the NAS transmission and the first NAS retransmission, and between the NAS retransmissions, is shown in the top timing diagram as a retransmission timer and is an example of a NAS timer. Example values of the retransmission timer are defined in Tables 10.2.1 and 10.3.1 of 3GPP TS 24.501 V16.8.0 (2021-04). Figure 2 Figure 2 In general, a NAS layer of a UE (e.g., UE 104) can send signaling information to the network (e.g., to an AMF 120). Likewise, the network can send signaling information to the UE. These types of signaling information communications are referred to herein as NAS transmission. A network node (e.g., a UE or an AMF) can initiate a NAS related procedure and perform a NAS transmission of a message (shown in the top timing diagram with a blank rectangle) to another node (e.g., an AMF or a UE) as part of the procedure. Based on the message, the node expects a response back from the other node (e.g., from the AMF or the UE). If the response is not received, a NAS retransmission of the message (shown in the top timing diagram with a diagonally hatched rectangle) is performed. The NAS retransmission can be performed multiple times (the number is shown in the top timing diagram as five) if the response is still not received. And if the response has still not been received, the node can determine that the NAS transmission failed 210, and the failure can be considered a failure of the NAS related procedure. The timing between the NAS transmission and the first NAS retransmission, and between the NAS retransmissions, is shown in the top timing diagram as a retransmission timer and is an example of a NAS timer. Example values of the retransmission timer are defined in Tables 10.2.1 and 10.3.1 of 3GPP TS 24.501 V16.8.0 (2021-04).​

[0076] As shown in the bottom timing diagram, an eDRX cycle can include an on duration corresponding to a number of subframes at the beginning of each eDRX cycle, and during the on duration the UE can perform physical downlink control channel (PDCCH) monitoring. Unless the on duration is extended, during the remainder of the eDRX cycle the UE is in a power saving mode and unable to receive information (including signaling information and downlink data) from the network. The duration value (e.g., length of time) of the eDRX cycle and the on duration value can be configured by the network (e.g., AMF).

[0077] Accordingly, if the eDRX cycle has a duration value (e.g., length of time) that is too large (e.g., up to 10,485,76 seconds), the NAS transmission and retransmission can occur while the UE is in a power saving mode (e.g., sleeping). In one example, the transmitting node is the UE. In this case, the UE is unable to receive a response back from the network and thus determines that a NAS transmission failure 210 occurs. In another example, the transmitting node is the network. In this case, the UE is unable to receive the NAS transmission and retransmission and does not send a response back to the network. Accordingly, the network determines that a NAS transmission failure 210 occurs.

[0078] Figure 3 Another example of a timing diagram 300 for NAS transmission and eDRX is shown, in accordance with some embodiments. Unlike the timing diagram 200, these timing diagrams 300 can result in a NAS transmission success 310. Specifically, the duration value of the eDRX cycle and / or the value of the retransmission timer can be adjusted to increase the likelihood of a NAS transmission success 310 and decrease the likelihood of a NAS transmission failure. As shown, the top timing diagram corresponds to the NAS transmission and the bottom timing diagram corresponds to the eDRX cycle.

[0079] In general, for non-RedCap UEs, the maximum value of the retransmission timer is:

[0080] • 5GMM in NB-N1 mode: UE side: T3519 - 300 seconds, network side: T3575 - 255 seconds;

[0081] • 5GMM in WB-N1 mode: UE side: T3525 - 120 seconds, network side: T3575 - 60 seconds;

[0082] • 5GSM in NB-N1 mode: UE side: T3580 - 196 seconds, network side: T3593 - 240 seconds; and

[0083] • 5GSM in WB-N1 mode: UE side: T3580 - 24 seconds, network side: T3593 - 60 seconds.

[0084] In one example, for a RedCap UE, the value of the retransmission timer can be similarly extended as for WB-N1 and NB-N1. For example, the value can be in the range of 200 seconds to 300 seconds, such as about 255 seconds.

[0085] The duration value of the eDRX cycle can also be defined for a RedCap UE based on the extended value of the retransmission timer. In Figure 4 In the illustration of FIG. 13, the duration value is set to be equal to or less than the extended value of the retransmission timer. For example, when the extended value is in the range of 200 seconds to 300 seconds, the eDRX cycle can also have a length in the range of 200 seconds to 300 seconds. In a particular illustration, when the extended value is about 255 seconds, the eDRX cycle length is equal to or less than about 255 seconds.

[0086] In Figure 3 In the illustrative example of FIG. 14, the NAS transmission occurs while the RedCap UE is in the power saving mode and thus is not received. However, since the duration value of the eDRX cycle is equal to or less than the extended value of the retransmission timer, the first NAS retransmission can be received, resulting in a successful NAS transmission 310.

[0087] Figure 4 Another example of timing diagrams 400 for NAS transmission and eDRX, in accordance with some embodiments, is shown. Similar to timing diagrams 300, these timing diagrams 400 can result in a successful NAS transmission 410. In particular, the duration value of the eDRX cycle is greater than the value of the retransmission timer since it is set to correspond to the retransmission timer multiplied by the number of NAS retransmissions. As shown, the top timing diagram corresponds to the NAS transmission, and the bottom timing diagram corresponds to the eDRX cycle.

[0088] In one example, for a RedCap UE, the value of the retransmission timer can be similarly extended as for WB-N1 and NB-N1. For example, the value can be in the range of 200 seconds to 300 seconds, such as about 255 seconds. In another example, the extended value can be less than those values for WB-N1 and NB-N1. For example, if the number of NAS retransmissions is “k”, the extended value can be equal to the maximum value WB-N1 / NB-N1 / (k+1). In a particular illustration of 255 seconds and four retransmissions, the extended value can be set to be equal to or less than 255 / (4+1) = 51 seconds.

[0089] The duration value of the eDRX cycle can also be limited based on the extended value of the retransmission timer and the number of NAS retransmissions “k” for a RedCap UE. For example, the duration value can be equal to the maximum extended value x (k + 1) + a predefined time margin. Referring back to the specific illustration of 51 seconds for the retransmission timer and a 55 second predefined time margin, the duration value can be set to 51 x (5) + 55 = 300 seconds.

[0090] In Figure 3 the exemplary example, the NAS transmission and the first three NAS retransmissions occur while the RedCap UE is in the power saving mode and thus are not received. However, the fourth NAS retransmission can be received, resulting in a successful NAS transmission 410.

[0091] Figure 5 Examples of timing diagrams 500 for NAS registration and eDRX are shown, in accordance with some embodiments. These timing diagrams 500 can result in a failed NAS registration 510. As shown, the top timing diagram corresponds to NAS periodic registration, and the bottom timing diagram corresponds to eDRX cycle.

[0092] Generally, a UE performs NAS periodic registration to a network (e.g., to an AMF of the network) to indicate a location of the UE to the network. The location can be relative to the network (e.g., a tracking area - TA) so that the network can page the UE. Rel-16 allows for a 54 minute NAS periodic registration timer T3512 to be used. In Figure 5 the illustration of, the UE performs a first NAS registration (e.g., by sending a NAS registration request to the network), and performs a second NAS registration after the NAS periodic timer (shown as registration timer in the figure) time elapses.

[0093] As shown in the bottom timing diagram, the duration value of the eDRX cycle is set to a value greater than the registration timer (e.g., 10,485.76 seconds compared to 54 minutes). Due to the longer eDRX duration, the second registration can only be performed while the UE is in the power saving mode. Thus, if the UE remains in the power saving mode, the second NAS registration can not be performed, resulting in a failed NAS registration 510.

[0094] In contrast, a RedCap UE can be configured to use a shorter eDRX cycle than the registration timer to improve the likelihood of a successful NAS registration. In this case, and referring back to the illustration of, the RedCap UE can wake up to successfully perform the second NAS registration. Figure 5

[0095] Figure 6 ​Another example of a timing diagram 600 for NAS registration and eDRX is shown in accordance with some embodiments. Unlike the timing diagram 500, these timing diagrams 600 can result in a successful NAS registration 610. Specifically, the duration value of the eDRX cycle and / or the value of the registration timer can be adjusted to increase the likelihood of a successful NAS transmission 610 and decrease the likelihood of a failed NAS transmission. As shown, the top timing diagram corresponds to NAS period registration, and the bottom timing diagram corresponds to the eDRX cycle.

[0096] In one example, the duration value of the eDRX cycle can be defined specifically for RedCap UE types. Referring back to Figure 3 to Figure 4 , the duration value can be based on the value of the NAS retransmission timer. The value of the registration timer can become equal to or greater than the duration value of the eDRX cycle, and in turn can be less than 54 minutes. For example, if the duration value of the eDRX cycle is set to about 255 seconds (or in the range of 200 seconds to 300 seconds), the registration timer can be set to be equal to at least 255 seconds (or a value in the range of 200 seconds to 300 seconds).

[0097] In Figure 6 the illustration, the RedCap UE performs a first NAS registration and then enters the eDRX mode. Since the registration timer is longer than the eDRX cycle, the RedCap UE exits the eDRX mode before performing a second NAS registration. As a result, the second NAS registration results in a successful NAS registration 610.

[0098] Figure 7 An example of a signaling diagram 700 for indicating reduced capability and associated eDRX cycle values is shown in accordance with some embodiments. Generally, RedCap UEs can have specific requirements, such as supporting a specific eDRX cycle duration or needing to support a reduced number of packet filters (in the allowed range of seventeen to one thousand twenty-four). Further, there is a need to constrain RedCap UEs from using features not intended for RedCap UEs, such as carrier aggregation, dual connectivity, and wider bandwidths. Redcap UEs can also be configured with operator-specific access classes and policy controls, and the network (e.g., its AMF) needs to know the UE capability to support subscription verification, differentiated charging, access control. Thus, the network needs to determine that the UE is a Redcap UE and is using eDRX. The signaling diagram 700 can be implemented to provide RedCap UE indication, eDRX usage indication, and eDRX configuration.

[0099] As shown, the signaling diagram 700 involves a RedCap UE, a gNB of the network, and an AMF of the network. Two mechanisms can be used in combination or alternated with each other to indicate to the network that the UE is a RedCap UE. The first mechanism is shown with dashed arrows, while the second mechanism is shown with dotted arrows.

[0100] In the first mechanism, the RedCap UE can send a message to the gNB, where the message includes reduced capability information. This information indicates that the RedCap UE has reduced capabilities of the RedCap UE type, its type is a RedCap UE type, and / or it is operating in a RedCap operating mode instead of a non-RedCap operating mode (which can be a normal operating mode without constraining operation to reduced capabilities). Further, the reduced capability information can indicate supported eDRX cycle values (e.g., corresponding to a RedCap UE’s preferred specific duration values; however, typically, these values are not available to the gNB or RAN, and can be available to the AMF. Thus, when the first mechanism is used, the eDRX cycle values are only optionally indicated). In one example, the message is at least one of Msg1, Msg3, or MsgA. Also in the first mechanism, the gNB can send a message to the AMF, where the message includes part or all of the reduced capability information. In one example, this message can be sent between the gNB and the AMF over the N2 interface.

[0101] In the second mechanism, the RedCap UE can send an N1 message to the AMF, where the message includes reduced capability information. For example, the N1 message can be included in a REGISTRATION REQUEST message.

[0102] In both mechanisms, the AMF becomes aware of the RedCap UE’s reduced capabilities. Further, the RedCap UE sends a REGISTRATION REQUEST message (which can not include reduced capability information if only the first mechanism is used) as part of a NAS registration procedure. In this request, the RedCap UE can indicate that eDRX is to be used. Thus, the AMF determines one or more values of an eDRX cycle, and can indicate such values in a REGISTRATION ACCEPT message sent to the RedCap UE. The AMF can also indicate this timing configuration of the eDRX cycle to the gNB in a message over the N2 interface.

[0103] In one example, the AMF determines the value of the eDRX cycle based on the reduced capability of the RedCap UE. For example, possible values can be pre-defined in a technical specification (e.g., 3GPP TS) and can be stored by the AMF in a data structure (e.g., table). One set of values can be associated with the 5GMM-IDLE mode and another set of values can be associated with the 5GMM-CONNECTED mode with inactivity indication. The pre-definition of different values can be based on pre-defined NAS timers, including the retransmission timer and / or the registration timer. Thus, the AMF can look up the table and determine the value that is applicable to the reduced capability and the 5GMM-IDLE mode and the 5GMM-CONNECTED mode with inactivity indication.

[0104] Other factors can be used to determine the value of the eDRX cycle. For example, and as shown in the following figures, the network (AMF or gNB) can buffer data to be transmitted to the RedCap UE. The longer the eDRX cycle, the greater the amount of data that can be buffered and the greater the required memory space can become. Thus, one factor for determining the value of the eDRX cycle is the available memory space. For example, the greater the available memory space, the longer the eDRX cycle can become. In another example, the buffered data can have a priority. Depending on the priority, the value can be set. For example, the higher the priority, the shorter the eDRX cycle can become. In a further example, the buffered data can be associated with a particular type of application (e.g., voice, messaging, emergency alert, etc.) of the RedCap UE. The application type can be associated with a data time sensitivity (e.g., voice data can be more time sensitive than messaging data, but not as time sensitive as emergency alert data). Thus, the value can be defined based on the application type or equivalently the data time sensitivity. The higher the time sensitivity, the shorter the eDRX cycle can become.

[0105] Although the signaling diagram 700 is shown in connection with a gNB, embodiments of the disclosure are not limited thereto. For example, a RedCap UE can include the reduced capability information during an LTE attach or tracking area update (TAU) procedure, such that an E-UTRAN eNB can redirect the RedCap UE to an appropriate RedCap-enabled NG-RAN gNB.

[0106] Figure 8An example of a reduced capability-based data transmission diagram 800 is shown in accordance with some embodiments. Specifically, data (e.g., DL packets) can be buffered by the network (e.g., 5GC or its AMF) based on UE state (e.g., 5GMM-IDLE mode and 5GMM-CONNECTED mode with inactivity indication) and sleep cycle length. Specifically, for RedCap UEs, the sleep cycle length can be longer than that of non-RedCap UEs due to longer eDRX cycles. Accordingly, the network can buffer a relatively larger amount of data. In Figure 8 In the illustration, the buffering is performed by the 5GC.

[0107] In one example, the data transmission diagram 800 involves a RedCap UE and the 5GC of the network. While the RedCap UE is operating in 5GMM-IDLE mode or 5GMM-CONNECTED mode with inactivity indication, the UE can enter a power saving mode (e.g., sleep cycle) during a DRX cycle. The 5GC can buffer data to be transmitted to the RedCap UE when the UE transitions from 5GMM-IDLE mode or 5GMM-CONNECTED mode with inactivity indication to 5GMM-CONNECTED mode with RRC CONNECTED state. In this case, the transition can be indicated by the UE to the 5GC based on a SERVICE REQUEST or CONTROLPLANE SERVICE REQUEST (or resume request). Upon receiving the service request from the RedCap UE, the 5GC can send the buffered data to the RedCap UE (along with other signaling information, such as a SERVICE ACCEPT message).

[0108] The buffered data can be temporarily stored in a memory space in association with information about a user plane function (UPF) session or session management function (SMF) session with the RedCap UE. This information can include, for example, an Internet Protocol (IP) address of the UE. The amount of data buffered by the 5GC for the RedCap UE can vary based on a number of factors. These factors can include the amount of available memory space at the 5GC. This amount can be dedicated to the UE or can be shared among multiple UEs (in which case the amount of data buffered for the RedCap UE can depend on the number of other UEs for which the 5GC also buffers data). These factors can also include the duration length of the eDRX cycle. Yet another factor can be the actual amount of data received and to be sent to the RedCap UE. Additional factors can include the priority of the data, the type of application associated with the data, and / or the time sensitivity of the data.

[0109] Figure 9Another example of reduced-capability based data transfer diagram 900 is shown, in accordance with some embodiments. Here, instead of the 5GC buffering data, a gNB of the network buffers data. This type of buffering can be possible when the UE is operating in 5GMM-CONNECTED mode with an inactivity indication.

[0110] As shown, the gNB can send an RRC release message to the RedCap UE to transition into 5GMM-CONNECTED mode with an inactivity indication. While the RedCap UE is in 5GMM-CONNECTED mode with an inactivity indication and during an eDRX cycle, the gNB can receive data (e.g., DL packets from the 5GC) that is to be transmitted to the UE. The gNB can buffer this data. The buffered data can be stored in a memory space of the gNB in association with an identifier of the UE (e.g., a Fifth Generation (5G) Globally Unique Temporary Identifier (GUTI)). Upon receiving an RRC resume message from the RedCap UE, the gNB can send the data (along with any other signaling so that the UE can transition to 5GMM-CONNECTED mode and RRC CONNECTED state to receive the data). The amount of data that is buffered can depend on one or more of the factors described herein above.

[0111] Figure 10 Another example of reduced-capability based data transfer diagram 1000 is shown, in accordance with some embodiments. Here, a first gNB of the network buffers data for a RedCap UE. However, when the RedCap transitions to RRC CONNECTED state, the RedCap UE connects to a second gNB. In this case, a cell change has occurred, and the first gNB sends the buffered data to the second gNB, which then sends the received data to the RedCap UE based on the cell change.

[0112] In one example, a first gNB sends an RRC release message to a RedCap UE so that the UE can transition to operating in 5GMM-CONNECTED mode with an inactivity indication. While the RedCap UE is in 5GMM-CONNECTED mode with an inactivity indication and during an eDRX cycle, the first gNB receives data (e.g., DL packets from the 5GC) that is to be transmitted to the RedCap UE. Accordingly, the first gNB buffers this data for the RedCap UE.

[0113] Subsequently, the UE wakes up and performs a mobility and periodic registration update procedure (e.g., to update the network about the TA list, connect to the second gNB, and / or transition to a 5GMM-CONNECTED mode with RRC CONNECTED state). The mobility and periodic registration update procedure can include the second gNB receiving an RRC resume message from the RedCap UE. The first gNB sends the buffered data to the second gNB, which then sends the data to the RedCap UE. Different mechanisms can be used to send the buffered data from the first gNB to the second gNB. In one example, a pull mechanism is used, whereby the second gNB requests the buffered data from the first gNB upon receiving the RRC resume message from the RedCap UE. In another example, a push mechanism is used, whereby the network (e.g., 5GC) informs the first gNB of the connection of the RedCap UE with the second gNB, and the first gNB sends the buffered data based on the notification.

[0114] The techniques described herein above can mitigate the impact of eDRX on the reduced capabilities of RedCap UEs. For example, bad user experience due to delayed DL NAS procedures (Mobile-Termination (MT) Voice over New Radio (VoNR)) can be mitigated by knowing more about the specific UE capabilities and enabling longer eDRX cycles only for certain categories of UEs, such as in loT, sensors, wearables, and avoiding UEs that cannot tolerate high latency communications. If not enabled, Multimedia Telephony (MMTEL) services can be implicitly released during longer eDRX cycles based on UE actions.

[0115] Furthermore, the network (RAN and / or 5GC) can easily be overloaded due to suspending all DL 5GSM messages. This can be mitigated by buffering in the 5GC, limiting the eDRX cycle (e.g., to 255 seconds), having more storage space at the 5GC entity (cloud). Additionally, NAS procedure collisions can occur more often. This can be mitigated by knowing more about the UE capabilities and the type of communication that is ongoing before enabling longer eDRX cycles. The AMF can limit the number of UEs with longer eDRX cycles that are allowed at any given time.

[0116] Other mechanisms can further improve RedCap UE support for eDRX. In one example mechanism, a RedCap UE can delay the start of an eDRX cycle to improve the likelihood of receiving data and / or can extend the on-duration to improve the likelihood of detecting a paging message. For example, when a RedCap UE has completed a registration procedure for mobility and periodic registration update (MRU), the RedCap UE can maintain a NAS connection for a first amount of time (e.g., “x” seconds, which can be referred to as an extended connection time) before entering an eDRX mode. Additionally or alternatively, the RedCap UE can monitor for paging for a second amount of time (e.g., “y” seconds, which can be referred to as a “wait time”) before entering an eDRX mode (e.g., entering a power saving mode). The first amount of time and / or the second amount of time can be used when a timing difference between determining the MRU and the start of the eDRX cycle exceeds a certain timing threshold (e.g., a predefined threshold in minutes). Doing so can enable the network to push pending data to the RedCap UE earlier than waiting for the next paging occasion.

[0117] In another example mechanism, an identifier of the RedCap UE is used in NAS procedures. Instead of assigning a different identifier each time a NAS procedure is performed, the same identifier can be reassigned. For example, the NAS procedures include paging procedures, and the identifier includes a 5G-GUTI. Based on a signaling message from the RedCap UE or an MRU from the RedCap UE, the 5G GUTI can be reused for multiple paging procedures (e.g., up to a maximum number “N”) or changed (e.g., before reaching the maximum number “N”). In this way, no delegation is used to reassign the 5G-GUTI at each paging procedure. This mechanism can reduce the signaling overhead associated with reassigning the 5G-GUTI.

[0118] In yet another example mechanism, a RedCap UE performs a high priority public land mobile network (HPPLMN) search. The search involves a time that can be based on a duration value of an eDRX cycle. Additionally or alternatively, the HPPLMN search is synchronized with the eDRX cycle (the start of the search can be synchronized with the end of the eDRX cycle or with the on-duration of the eDRX cycle). In other words, the HPPLMN search duration can closely match the eDRX timer duration. The HPPLMN search timer duration can be stored in the SIM and closely match the EC-GSM-IoT, Category M1, or Category NB1 values. Doing so enables the RedCap UE to remain in a sleep mode for a longer time and synchronize the search with a paging wake-up.

[0119] In yet another example mechanism, a RedCap UE performs a PLMN search prior to performing a registration procedure. This search can take into account whether a cell supports reduced capabilities for UEs of the RedCap UE type. When a RedCap UE finds multiple cells and determines that one of these cells supports reduced capabilities, the cell selection (or reselection) procedure selects that cell even when another cell that does not support reduced capabilities is associated with a stronger signal strength. If multiple cells are found and support reduced capabilities, the RedCap UE can select one of these cells based on other factors such as signal strength. This mechanism can be used because RedCap UEs have specific capabilities and not all neighboring cells in a PLMN can support RedCap UEs. Therefore, initial PLMN and cell selection can be modified to take network capabilities into account prior to triggering registration. Prior to attempting to select a cell to register, a RedCap UE can take into account cell support for RedCap in system information block (SIB) indications. If a cell with RedCap capabilities cannot be found, the RedCap UE behavior can be modified relative to when a cell with RedCap capabilities is found. For example, a RedCap UE can camp on a non-RedCap cell for limited service and emergency call setup. In another illustration, a RedCap UE can camp on other radio access technologies (RATs) or PLMNs for emergency service.

[0120] In yet another example mechanism, the UE supports multiple modes of operation, where a first mode of operation uses reduced capabilities (e.g., is a RedCap mode of operation), and where a second mode of operation does not use reduced capabilities (e.g., is a non-RedCap mode of operation). In this case, the UE can switch between these modes of operation to operate as a RedCap UE and a non-RedCap UE (but not simultaneously). When the UE switches from operating in the RedCap mode of operation to the non-RedCap mode of operation, the UE can send an indication to the network about the switch. A PDU session that was ongoing prior to the switch can remain ongoing after the switch. Context and / or parameters of the PDU session that were used prior to the switch can accordingly remain available after the switch. Conversely, the network (e.g., its 5GC) can receive the indication and reuse the same PDU session and / or context / parameters of the PDU switch after the switch. In this way, the UE can be enabled to switch between RedCap and normal UE based on internal constraints (e.g., heat, battery, need for higher bandwidth, etc.). When the switch occurs, minimal disruption to ongoing services can occur. Thus, when the UE is capable of operating with normal and reduced capabilities (not simultaneously), the UE can decide to switch between these modes of operation. When the switch occurs, the UE can perform an MRU and update the UE current mode of operation without losing the PDU session and some of its associated context / parameters (e.g., IP Multimedia Subsystem (IMS) or other critical PDU sessions).

[0121] Figure 11 An example of an operational flow / algorithmic structure 1100 for indicating reduced capabilities and associated eDRX cycle values is shown, in accordance with some embodiments. The operational flow / algorithmic structure 1100 can be implemented by a UE that supports reduced capabilities (e.g., such that the UE can operate as a RedCap UE). The UE can be, for example, the UE 104 or the UE 1400, or the operational flow / algorithmic structure 1100 can be implemented by a component of the UE, such as by the processor 1404.

[0122] In one example, the operational flow / algorithmic structure 1100 can include, at 1102, sending, to a network, capability information indicating that the UE is a reduced capability (RedCap) UE. The RedCap UE has reduced capabilities relative to a non-RedCap UE, and where the reduced capabilities are associated with at least one of: a communication bandwidth, a receive branch, a multiple-input multiple-output (MIMO) layer, a modulation order, or a duplex operation. For example, the capability information can be sent in a registration request to an AMF, or in Msgl, Msg3, or MsgA to a base station. If sent to the base station, the UE can also send a registration request to the AMF, where the registration optionally indicates the reduced capabilities, indicates that the UE is requesting to use eDRX, and indicates eDRX values that the UE optionally supports.

[0123] In one example, the operational flow / algorithmic structure 1100 can include receiving, from a network, one or more values of extended discontinuous reception (eDRX) at 1104. The one or more values are defined for reduced capability and are associated with at least one of: a 5thGeneration Mobility Management (5GMM)-IDLE mode or a 5GMM-CONNECTED mode with a radio resource control (RRC) inactive indication. For example, the values are defined based on an extended NAS retransmission timer and / or a NAS registration timer and can be stored by the network. The network (e.g., AMF) can select from possible values based on a number of factors. The factors include UE supported eDRX values (if indicated in a registration request), a number of other RedCap UEs connected to the network and using eDRX, available storage space, data priority, data time sensitivity, application type associated with data to be sent to the UE, and other factors described herein above.

[0124] In one example, the operational flow / algorithmic structure 1100 can include setting, according to the one or more values, values for use in eDRX cycles occurring while the RedCap UE is in a 5GMM-IDLE mode or a 5GMM-CONNECTED mode with a RRC inactive indication at 1106. For example, the one or more values of eDRX are received from the network in configuration information in the 5GMM-IDLE mode and in the 5GMM-CONNECTED mode with the RRC inactive indication. The UE uses the applicable eDRX cycle duration when entering the eDRX mode in the 5GMM-IDLE mode and in the 5GMM-CONNECTED mode with the RRC inactive indication.

[0125] Figure 12 Another example of an operational flow / algorithmic structure 1200 for indicating reduced capability and associated eDRX cycle values is shown in accordance with some embodiments. The operational flow / algorithmic structure 1200 can be implemented by a network of a UE supporting reduced capability (e.g., a network with RedCap capability such that UEs connected to the network can operate as RedCap UEs). The network can be, for example, the 5GS 108, the 5GC, an AMF, a base station, or the operational flow / algorithmic structure 1100 can be implemented by one or more processors of a component of the network such as the 5GC, the AMF, and / or the base station.

[0126] In one example, the operational flow / algorithmic structure 1200 can include receiving, from a UE, capability information indicating that the UE is a reduced capability (RedCap) UE, at 1202. The RedCap UE has reduced capabilities relative to a non-RedCap UE, and wherein the reduced capabilities are associated with at least one of: a communication bandwidth, a receive branch, a multiple-input multiple-output (MIMO) layer, a modulation order, or a duplex operation. For example, the capability information can be received by the AMF in a registration request, or by the base station in Msgl, Msg3, or MsgA. If received by the base station, the AMF can also receive a REGISTRATION REQUEST message indicating the reduced capabilities, indicating that the UE is requesting to use eDRX, and indicating eDRX values that the UE optionally supports.

[0127] In one example, the operational flow / algorithmic structure 1200 can include determining one or more values to extend an extended discontinuous reception (eDRX) cycle, at 1206. The one or more values are defined for reduced capabilities and are associated with at least one of: a fifth generation mobility management (5GMM)-IDLE mode or a 5GMM-CONNECTED mode with radio resource control (RRC) inactive indication. For example, the values are defined based on an extended NAS retransmission timer and / or a NAS registration timer, and can be stored by the network. The network (e.g., AMF) can select from possible values based on a number of factors. The factors include eDRX values supported by the UE (if indicated in the registration request), a number of other RedCap UEs connected to the network and using eDRX, available storage space, data priority, data time sensitivity, application type associated with data to be transmitted to the UE, and other factors described herein above.

[0128] In one example, the operational flow / algorithmic structure 1200 can include sending the one or more values to the UE, at 1206. For example, the one or more values are sent to the UE to configure eDRX for the UE in a 5GMM-IDLE mode and in a 5GMM-CONNECTED mode with RRC inactive indication. The configuration information can be sent in a REGISTRATION ACCEPT message.

[0129] Figure 13 A receive component 1300 of a UE 104 is shown in accordance with some embodiments. The receive component 1300 can include an antenna panel 1304 that includes a plurality of antenna elements. The panel 1304 is shown with four antenna elements, but other embodiments can include other numbers of antenna elements.

[0130] Antenna panel 1304 can be coupled to an analog beamforming (BF) component that includes a plurality of phase shifters 1308(1)-1308(4). Phase shifters 1308(1)-1308(4) can be coupled with a radio frequency (RF) chain 1312. RF chain 1312 can amplify a received analog RF signal, downconvert the RF signal to baseband, and convert the analog baseband signal to a digital baseband signal that can be provided to a baseband processor for further processing.

[0131] In various embodiments, control circuitry, which can reside in the baseband processor, can provide BF weights (e.g., W1-W4) to phase shifters 1308(1)-1308(4), which can represent phase shift values to provide a receive beam at antenna panel 1304. These BF weights can be determined based on channel-based beamforming.

[0132] Figure 14 A UE 1400 according to some embodiments is shown. UE 1400 can be similar to UE 104 of Figure 1 and substantially interchangeable therewith.

[0133] Similar to the description above regarding UE 104, UE 1400 can be any mobile or non- mobile computing device, such as a mobile phone, computer, tablet, industrial wireless sensor (e.g., microphone, carbon dioxide sensor, pressure sensor, humidity sensor, thermometer, motion sensor, accelerometer, laser scanner, fluid level sensor, inventory sensor, voltage / current meter, and actuator), video surveillance / monitoring device (e.g., camera and video camera), wearable device, or Relaxed IoT device. In some embodiments, the UE can be a capacity-reduced UE or NR-Light UE.

[0134] UE 1400 can include a processor 1404, RF interface circuitry 1408, memory / storage 1412, user interface 1416, sensors 1420, drive circuitry 1422, power management integrated circuit (PMIC) 1424, and battery 1428. The components of UE 1400 can be implemented as integrated circuits (ICs), portions of ICs, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. Figure 14 The block diagram of FIG. 14 is intended to show a high-level view of certain ones of the components of UE 1400. However, some of the components shown can be omitted in some embodiments, additional components can be present, and different arrangements of the components shown can occur in other embodiments.

[0135] The components of the UE 1400 can be coupled through one or more interconnects 1432, which can represent any type of interface, input / output, bus (local, system, or expansion), transmission line, trace, optical connection, etc. that allows the various circuit components (on common or different chips or chip sets) to interact.

[0136] The processor 1404 can include processor circuitry, such as baseband processor circuitry (BB) 1404A, central processor unit circuitry (CPU) 1404B, and graphics processor unit circuitry (GPU) 1404C. The processor 1404 can contain any type of circuit or processor circuitry that executes or otherwise operates computer executable instructions, such as program code, software modules, or functional processes from memory / storage 1412, to cause the UE 1400 to perform operations as described herein.

[0137] In some embodiments, the baseband processor circuitry 1404A can access the communication protocol stack 1436 in the memory / storage 1412 to communicate over a 3GPP compliant network. Generally, the baseband processor circuitry 1404A can access the communication protocol stack to perform user plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer; and control plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and non-access stratum (NAS) layer. In some embodiments, PHY layer operations can additionally / alternatively be performed by components of the RF interface circuitry 1408.

[0138] The baseband processor circuitry 1404A can generate or process baseband signals or waveforms that carry information for transmission across the 3GPP compliant network. In some embodiments, waveforms for NR can be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.

[0139] The baseband processor circuitry 1404A can also access the group information 1424 from the memory / storage 1412 to determine a search space group for which a number of repetitions of a PDCCH can be transmitted.

[0140] Memory / storage 1412 can include any type of volatile or nonvolatile memory that can be distributed throughout UE 1400. In some embodiments, some of memory / storage 1412 can reside on the processor 1404 itself (e.g., L1 cache and L2 cache) while other memory / storage 1412 resides outside of the processor 1404 but can be accessed via a memory interface. Memory / storage 1412 can include any suitable memory or storage such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.

[0141] RF interface circuitry 1408 can include transceiver circuitry and radio frequency front module (RFEM) that allow UE 1400 to communicate with other devices over a radio access network. RF interface circuitry 1408 can include various elements arranged in transmit or receive paths. These elements can include switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0142] In the receive path, the RFEM can receive a radiated signal from the air interface via antenna 1424 and continue to filter and amplify the signal (with a low noise amplifier). The signal can be provided to a receiver of the transceiver that down-converts the RF signal to a baseband signal that is provided to the baseband processor of processor 1404.

[0143] In the transmit path, a transmitter of the transceiver up-converts baseband signals received from the baseband processor and provides RF signals to the RFEM. The RFEM can amplify the RF signals through a power amplifier before the signals are radiated across the air interface via antenna 1424.

[0144] In various embodiments, RF interface circuitry 1408 can be configured to transmit / receive signals in a manner compatible with NR access technology.

[0145] Antenna 1424 can include multiple antenna elements each of which converts electrical signals into radio waves for transmission through the air and converts received radio waves into electrical signals. The antenna elements can be arranged into one or more antenna panels. Antenna 1424 can have an omnidirectional, directional, or a combination thereof antenna panels to enable beamforming and multiple-input multiple-output communication. Antenna 1424 can include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. Antenna 1424 can have one or more panels designed for specific frequency bands including frequency bands in FR1 or FR2.

[0146] User interface circuitry 1416 includes various input / output (I / O) devices that allow a user to interact with UE 1400. User interface 1416 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for entering or providing input to the UE 1400. In particular, input device circuitry includes one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, keypad, mouse, touchpad, touchscreen, microphone, scanner, headset, and / or any other suitable device that

[0147] Sensors 1420 can include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information about the detected events (sensor data) to some other a device, module, subsystem, etc. Examples of such sensors include, inter alia, an inertial measurement unit including a gyroscope, an accelerometer, or a magnetometer; a microelectromechanical system or nanoelectromechanical system including a three-axis accelerometer, a three-axis gyroscope, or a magnetometer; a level sensor; a flow sensor; a temperature sensor (e.g., a thermistor); a pressure sensor; a barometric pressure sensor; a gravimeter; an altimeter; an image capture device (e.g., a camera or a lensless aperture); a light detection and ranging sensor; a proximity sensor (e.g., an infrared radiation detector, etc.); a depth sensor; an ambient light sensor; an ultrasonic transceiver; a microphone or other like audio capture device; etc.

[0148] The drive circuitry 1422 can include software and hardware elements that are embodied in general by processors, application-specific integrated circuits, programmable-logic arrays, and other hardware components that are customized for a particular device. The drive circuitry 1422 can include individual drivers that allow other components to interact with or control various input / output (I / O) devices that can be present within, or connected to, the UE 1400. For example, the drive circuitry 1422 can include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, a sensor driver to fetch sensor readings of sensor circuitry 1420 and to control and allow access to the sensor circuitry 1420, a driver to fetch actuator positions of electromechanical components or to control and allow access to electromechanical components, a camera driver to control and allow access to an embedded image capture device, or an audio driver to control and allow access to one or more audio devices.

[0149] The PMIC 1424 can manage power provided to the various components of the UE 1400. In particular, with respect to the processor 1404, the PMIC 1424 can control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0150] In some embodiments, the PMIC 1424 can control, or otherwise be part of, various power-saving mechanisms of the UE 1400. For example, if the platform UE is in an RRC_CONNECTED state, in which it is still connected to the RAN node as it expects to receive traffic shortly, the platform can enter a state known as Discontinuous Reception (DRX) after a period of inactivity. During this state, the UE 1400 can power down for brief intervals of time, thus saving power. If there is no data traffic activity for an extended period of time, the UE 1400 can transition off to an RRC_IDLE state, in which it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The UE 1400 goes into a very low power state, and enters a deep sleep, from which it wakes up at a scheduled time to listen to the network. The UE 1400 can not receive data in this state; in order to receive data, it must transition back to RRC_CONNECTED state. An additional power saving mode can be flight mode, where the device cannot use the network at all. It can not connect to a network, and can power down completely. Any data sent during this time will incur a large delay.

[0151] The battery 1428 can power the UE 1400, although in some examples the UE 1400 can be installed in a fixed location, and can have a power supply coupled to an electrical grid. The battery 1428 can be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some examples, such as in vehicle-based applications, the battery 1428 can be a typical lead-acid automotive battery.

[0152] Figure 15 A gNB 1500 is shown in accordance with some embodiments. The gNB node 1500 can be similar to and substantially interchangeable with the gNB 108.

[0153] The gNB 1500 can include a processor 1504, RF interface circuitry 1508, core network (CN) interface circuitry 1512, and memory / storage circuitry 1516.

[0154] The components of the gNB 1500 can be coupled with various other components over one or more interconnects 1528.

[0155] The processor 1504, RF interface circuitry 1508, memory / storage circuitry 1516, including the communication protocol stack 1510, antenna 1524, and interconnects 1528 can be similar to the processor 1404, RF interface circuitry 1408, memory / storage circuitry 1416, including the communication protocol stack 1410, antenna 1424, and interconnects 1428, respectively, described with reference to Figure 13 Like-named components have been described with reference to the

[0156] The CN interface circuitry 1512 can provide connectivity to a core network (e.g., a 5thGeneration Core Network (5GC) using 5GC-compatible network interface protocols such as carrier Ethernet protocols or some other suitable protocol). Network connectivity can be provided to / from the gNB 1500 via a fiber or wireless backhaul. The CN interface circuitry 1512 can include one or more specialized processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 1512 can include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0157] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled in a way to minimize risk of unintentional or unauthorized access or use, and the nature of authorization should be clearly expressed to the users.

[0158] For one or more embodiments, at least one of the components illustrated in one or more of the preceding figures can be configured to perform one or more operations, techniques, processes or methods as described in the following Examples section. For example, the baseband circuitry described above in connection with one or more of the preceding figures can be configured to operate in accordance with one or more of the following embodiments. For another example, circuitry associated with a UE, base station, network element, etc. described above in connection with one or more of the preceding figures can be configured to operate in accordance with one or more of the examples illustrated in the following Examples section.

[0159] Example

[0160] In the following sections, further example embodiments are provided.

[0161] Example 1 includes a method implemented by a user equipment (UE), the method comprising: sending, to a network, capability information indicating that the UE is a reduced capability (RedCap) UE, wherein the RedCap UE has reduced capabilities relative to a non-RedCap UE, and wherein the reduced capabilities are associated with at least one of: a communication bandwidth, a receive branch, a multiple-input multiple-output (MIMO) layer, a modulation order, or a duplex operation; receiving, from the network, one or more values of extended discontinuous reception (eDRX), wherein the one or more values are defined for the reduced capabilities and are associated with at least one of: a fifth generation mobility management (5GMM)-IDLE mode or a 5GMM-CONNECTED mode with a radio resource control (RRC) inactive indication; and setting a value for use in an eDRX cycle occurring while the RedCap UE is in the 5GMM-IDLE mode or the 5GMM-CONNECTED mode with the RRC inactive indication in accordance with the one or more values.

[0162] Example 2 includes the method of Example 1, wherein the one or more values are defined based on a non-access stratum (NAS) timer of the network or the UE.

[0163] Example 3 includes the method of any preceding example, wherein the value is less than or equal to a duration corresponding to a non-access stratum (NAS) retransmission timer multiplied by a number of NAS retransmissions.

[0164] Example 4 includes the method of any preceding example, wherein the value is a first value, and the method further comprises: receiving or transmitting a message based on a non-access stratum (NAS) retransmission performed using a NAS retransmission timer, wherein the NAS retransmission timer has a second value defined based on the reduced capabilities.

[0165] Example 5 includes the method of any preceding example, wherein the value is a first value, and the method further comprises: performing a periodic registration procedure based on a non-access stratum (NAS) periodic registration timer, wherein the NAS periodic registration timer has a second value that is based on the reduced capability limit and is equal to or greater than the first value.

[0166] Example 6 includes the method of any preceding example, wherein the capability information is transmitted in a registration request to an access and mobility management function (AMF) of the network or in a message prior to the registration request to a base station of the network.

[0167] Example 7 includes the method of Example 6, wherein the one or more values represent eDRX cycle values supported by the network, and the method further comprises: receiving the one or more values from the AMF in a registration accept message.

[0168] Example 8 includes the method of Example 7, the method further comprising: transmitting information about eDRX cycle values supported by the UE to the AMF in the registration request, and wherein the one or more values are received based on the eDRX cycle values supported by the UE and the network.

[0169] Example 9 includes the method of any preceding example, the method further comprising: transitioning a non-access stratum (NAS) layer of the UE from the 5GMM-CONNECTED mode with the RRC inactive indication to the 5GMM-CONNECTED mode and transitioning an access stratum (AS) layer of the UE from an RRC_INACTIVE state to an RRC_CONNECTED state; and receiving downlink data from a fifth generation core (5GC) of the network that is buffered by the 5GC for a duration corresponding to at least the value of the eDRX cycle.

[0170] Example 10 includes the method of any preceding example, the method further comprising: transitioning a non-access stratum (NAS) layer of the UE from the 5GMM-CONNECTED mode with the RRC inactive indication to the 5GMM-CONNECTED mode and transitioning an access stratum (AS) layer of the UE from an RRC_INACTIVE state to an RRC_CONNECTED state; and receiving downlink data from a fifth generation core (5GC) of the network or from a base station of the network that is buffered by the 5GC or the base station for a duration corresponding to at least the value of the eDRX cycle.

[0171] Example 11 includes the method of any preceding example, further comprising: establishing a non-access stratum (NAS) connection with the network based on a registration procedure for mobility and periodic registration update (MRU); comparing a timing difference between the MRU and a start of the eDRX cycle to a timing threshold; and based on the comparison and prior to the start of the eDRX cycle, maintaining the NAS connection for a first duration or monitoring for paging for a second duration.

[0172] Example 12 includes the method of any preceding example, further comprising: performing a high priority public land mobile network (HPPLMN) search, wherein at least one of: a timer of the HPPLMN search is based on the value of the eDRX cycle, or the HPPLMN search is synchronized with the eDRX cycle.

[0173] Example 13 includes the method of any preceding example, further comprising: performing a public land mobile network (PLMN) search; determining a first cell and a second cell based on the PLMN search; and performing a cell selection procedure, wherein the first cell is selected based on a determination that the reduced capability is supported by the first cell and is not supported by the second cell.

[0174] Example 14 includes the method of any preceding example, wherein the UE supports a first mode of operation using the reduced capability and a second mode of operation not using the reduced capability, and the method further comprises: performing a switch from operating in the first mode of operation to the second mode of operation; and sending an indication to the network regarding the switch.

[0175] Example 15 includes the method of Example 14, wherein the indication regarding the switch is sent in a mobility and periodic registration update (MRU), wherein a context or parameters of a protocol data unit (PDU) session applicable prior to the switch remain unchanged after the switch.

[0176] Example 16 includes a method implemented by a network, the method comprising: receiving, from a user equipment (UE), capability information indicating that the UE is a reduced capability (RedCap) UE, wherein the RedCap UE has reduced capabilities relative to a non-RedCap UE, and wherein the reduced capabilities are associated with at least one of: a communication bandwidth, a receive branch, a multiple-input multiple-output (MIMO) layer, a modulation order, or a duplex operation; determining one or more values of an extended discontinuous reception (eDRX) cycle, wherein the one or more values are defined for the reduced capabilities and are associated with at least one of: a fifth generation mobility management (5GMM)-IDLE mode or a 5GMM-CONNECTED mode with a radio resource control (RRC) inactive indication; and sending the one or more values to the UE.

[0177] Example 17 includes the method of Example 16, wherein the capability information is received by an access and mobility management function (AMF) of the network from the UE in a REGISTRATION REQUEST message, or is received by a base station of the network from the UE in another message and is sent by the base station to the AMF.

[0178] Example 18 includes the method of Example 17, wherein the one or more values are sent by the AMF to the UE in a REGISTRATION ACCEPT message, and wherein the method further comprises: sending, by the AMF to the base station, the one or more values in a N2 interface message.

[0179] Example 19 includes the method of any preceding Example 16 to 18, the method further comprising: determining that a non-access stratum (NAS) layer of the UE is in the 5GMM-IDLE mode; and buffering, by a fifth generation core (5GC) of the network and for a duration corresponding to at least the eDRX cycle, data for a user plane function (UPF) session or a session management function (SMF) session with the UE.

[0180] Example 20 includes the method of any preceding Example 16 to 19, the method further comprising: determining that the NAS layer is in the 5GMM-CONNECTED mode with the inactive indication and an access stratum (AS) layer of the UE is in an RRC_INACTIVE state; and buffering, by a fifth generation core (5GC) of the network or by a first base station of the network and for a duration corresponding to at least the eDRX cycle, data for a user plane function (UPF) session or a session management function (SMF) session with the UE.

[0181] Example 21 includes the method of any of Example 20, wherein the data is buffered by the first base station, and the method further comprises transmitting, by the first base station, the data to a second base station based on a cell change of the UE.

[0182] Example 22 includes the method of any of the preceding Example 16 to 21, the method further comprising performing a paging procedure by using a Fifth Generation (5G) Globally Unique Temporary Identifier (GUTI), wherein the 5G GUTI is repeatable for multiple paging procedures or changed based on a signaling message from the UE or a Mobility and Periodic Registration Update (MRU) from the UE.

[0183] Example 23 includes the method of any of the preceding Example 16 to 22, wherein the UE supports a first mode of operation using the reduced capability and a second mode of operation not using the reduced capability, and wherein the method further comprises receiving an indication from the UE regarding a switch from operating in the first mode of operation to the second mode of operation; and using a context or parameters of a Protocol Data Unit (PDU) session with the UE after the switch, wherein the context or the parameters are used prior to the switch.

[0184] Example 24 includes a UE comprising means for performing one or more elements of a method described in or related to any of Examples 1-15.

[0185] Example 25 includes one or more non-transitory computer-readable media comprising instructions to cause a UE, upon execution of the instructions by one or more processors of the UE, to perform one or more elements of a method described in or related to any of Examples 1-15.

[0186] Example 26 includes a UE comprising logic, module, or circuitry for performing one or more elements of a method described in or related to any of Examples 1-15.

[0187] Example 27 includes a UE comprising one or more processors and one or more computer-readable media comprising instructions to cause the one or more processors, upon execution of the instructions, to perform one or more elements of a method described in or related to any of Examples 1-15.

[0188] Example 28 includes a system comprising means for performing one or more elements of a method described in or related to any of Examples 1-15.

[0189] Example 29 includes a network that includes means for performing one or more elements of the method described in or related to any of Examples 16-23.

[0190] Example 30 includes one or more non-transitory computer-readable media comprising instructions to cause a network, upon execution of the instructions by one or more processors of the network, to perform one or more elements of the method described in or related to any of Examples 16-23.

[0191] Example 31 includes a network that includes logic, modules, or circuitry to perform one or more elements of a method described in or related to any of Examples 16-23.

[0192] Example 32 includes a network that includes one or more processors and one or more computer-readable media comprising instructions to cause the one or more processors, upon execution of the instructions, to perform one or more elements of a method described in or related to any of Examples 16-23.

[0193] Example 33 includes a system that includes means for performing one or more elements of a method described in or related to any of Examples 16-23.

[0194] Any of the above examples can be combined with any other example (or combination of examples), unless otherwise stated explicitly. The foregoing description of one or more implementations provides functionality and / or technical advantages, but that does not mean that every implementation necessitates every advantage. Modifications and variations are possible in light of the above teachings or can be acquired from other

[0195] While the foregoing implementations have been described in some detail for purposes of clarity and the specific embodiments herein disclosed have been shown by way of example, it is not the intention that these arrangements should be limited to the details of the foregoing disclosure, but rather that they should be broad enough to cover all modifications and alternative methods of available to one skilled in the art having the benefit of the teachings herein.

Claims

1. A user equipment (UE), the UE comprising: one or more processors; and one or more memories storing instructions that, when executed by the one or more processors, configure the UE to: send, to a network, capability information indicating that the UE is a reduced capability (RedCap) UE, wherein the RedCap UE has reduced capabilities relative to a non-RedCap UE, and wherein the reduced capabilities are associated with at least one of: a communication bandwidth, a receive branch, a multiple-input multiple-output (MIMO) layer, a modulation order, or a duplex operation; receive, from the network, one or more values of extended discontinuous reception (eDRX), wherein the one or more values are defined for the reduced capabilities and are associated with at least one of: a fifth generation mobility management (5GMM)-IDLE mode or a 5GMM-CONNECTED mode with a radio resource control (RRC) inactive indication, and wherein the one or more values are based on a non-access stratum (NAS) procedure of the UE or the network; and set a value for use in an eDRX cycle occurring while the RedCap UE is in the 5GMM-IDLE mode or the 5GMM-CONNECTED mode with the RRC inactive indication according to the one or more values.

2. The UE of claim 1, wherein the one or more values are defined based on a non-access stratum (NAS) timer of the network or the UE.

3. The UE of claim 1 or 2, wherein the value is less than or equal to a duration corresponding to a non-access stratum (NAS) retransmission timer multiplied by a NAS retransmission number.

4. The UE of claim 1 or 2, wherein the value is a first value, wherein the execution of the instructions further configure the UE to: receive or send a message based on a non-access stratum (NAS) retransmission using a NAS retransmission timer, wherein the NAS retransmission timer has a second value defined based on the reduced capabilities.

5. The UE of claim 1 or 2, wherein the value is a first value, wherein the execution of the instructions further configure the UE to: perform a periodic registration procedure based on a non-access stratum (NAS) periodic registration timer, wherein the NAS periodic registration timer has a second value defined based on the reduced capabilities and equal to or greater than the first value.

6. The UE of claim 1 or 2, wherein the capability information is sent to an access and mobility management function (AMF) of the network in a registration request or to a base station of the network in a message prior to the registration request.

7. The UE of claim 1 or 2, wherein the execution of the instructions further configure the UE to: ​ transitioning a non-access stratum (NAS) layer of the UE from the 5GMM-CONNECTED mode with the RRC inactive indication to the 5GMM-CONNECTED mode and transitioning an access stratum (AS) layer of the UE from an RRC INACTIVE state to an RRC CONNECTED state; and receiving, from a fifth generation core (5GC) of the network, downlink data buffered by the 5GC for a duration corresponding to at least the value of the eDRX cycle.

8. The UE of claim 1 or 2, wherein the execution of the instructions is to further configure the UE to: transition a non-access stratum (NAS) layer of the UE from the 5GMM-CONNECTED mode with the RRC inactive indication to the 5GMM-CONNECTED mode and transition an access stratum (AS) layer of the UE from an RRC INACTIVE state to an RRC CONNECTED state; and receive, from a fifth generation core (5GC) of the network or from a base station of the network, downlink data buffered by the 5GC or the base station for a duration corresponding to at least the value of the eDRX cycle.

9. One or more computer-readable media storing instructions that, when executed on a user equipment (UE), cause the UE to perform operations comprising: sending, to a network, capability information indicating that the UE is a reduced capability (RedCap) UE, wherein the RedCap UE has reduced capabilities relative to a non-RedCap UE, and wherein the reduced capabilities are associated with at least one of: a communication bandwidth, a receive branch, a multiple-input multiple-output (MIMO) layer, a modulation order, or a duplex operation; receiving, from the network, one or more values of an extended discontinuous reception (eDRX), wherein the one or more values are defined for the reduced capabilities and are associated with at least one of: a fifth generation mobility management (5GMM)-IDLE mode or a 5GMM-CONNECTED mode with a radio resource control (RRC) inactive indication, and wherein the one or more values are based on a non-access stratum (NAS) procedure of the UE or the network; and setting, according to the one or more values, a value for use in an eDRX cycle occurring while the RedCap UE is in the 5GMM-IDLE mode or the 5GMM-CONNECTED mode with the RRC inactive indication.

10. The one or more computer-readable media of claim 9, wherein the operations further comprise: establishing a non-access stratum (NAS) connection with the network based on a registration procedure for mobility and periodic registration update (MRU); comparing a timing difference between the MRU and a start of the eDRX cycle to a timing threshold; and maintaining the NAS connection for a first duration or monitoring for paging for a second duration based on the comparison and prior to the start of the eDRX cycle.

11. The one or more computer-readable media of claim 9 or 10, wherein the operations further comprise: performing a high priority public land mobile network (HPPLMN) search, wherein at least one of the following is true: a timer of the HPPLMN search is based on the value of the eDRX cycle, or the HPPLMN search is synchronized with the eDRX cycle.

12. The one or more computer-readable media of claim 9 or 10, wherein the operations further comprise: performing a public land mobile network (PLMN) search; determining a first cell and a second cell based on the PLMN search; and performing a cell selection procedure, wherein the first cell is selected based on a determination that the first cell is supported by the first cell using the reduced capability and is not supported by the second cell.

13. The one or more computer-readable media of claim 9 or 10, wherein the UE supports a first mode of operation using the reduced capability and a second mode of operation not using the reduced capability, and wherein the operations further comprise: performing a switch from operating in the first mode of operation to the second mode of operation; and sending an indication of the switch to the network.

14. A method implemented by a network, the method comprising: receiving, from a user equipment (UE), capability information indicating that the UE is a reduced capability (RedCap) UE, wherein the RedCap UE has a reduced capability relative to a non-RedCap UE, and wherein the reduced capability is associated with at least one of: a communication bandwidth, a receive branch, a multiple input multiple output (MIMO) layer, a modulation order, or a duplex operation; determining one or more values of an extended discontinuous reception (eDRX) cycle, wherein the one or more values are defined for the reduced capability and are associated with at least one of: a fifth generation mobility management (5GMM)-IDLE mode or a 5GMM-CONNECTED mode with a radio resource control (RRC) inactive indication, and wherein the one or more values are based on a non-access stratum (NAS) procedure of the UE or the network; and sending the one or more values to the UE.

15. The method of claim 14, wherein the capability information is received by an access and mobility management function (AMF) of the network from the UE in a REGISTRATION REQUEST message, or is received by a base station of the network from the UE in another message and sent by the base station to the AMF.

16. The method of claim 15, wherein the one or more values are sent by the AMF to the UE in a REGISTRATION ACCEPT message, and wherein the method further comprises: the one or more values are sent by the AMF to the base station in a N2 interface message.

17. The method of claim 14 or 15, further comprising: determining that a non-access stratum (NAS) layer of the UE is in the 5GMM-IDLE mode; and by a Fifth Generation Core (5GC) of the network and buffering data for a User Plane Function (UPF) session or a Session Management Function (SMF) session with the UE for at least a duration corresponding to the eDRX cycle.

18. The method of claim 14 or 15, further comprising: determining that the NAS layer is in the 5GMM-CONNECTED mode with the inactivity indication and an Access Stratum (AS) layer of the UE is in an RRC INACTIVE state; and by a Fifth Generation Core (5GC) of the network or by a first base station of the network and buffering data for a User Plane Function (UPF) session or a Session Management Function (SMF) session with the UE for at least a duration corresponding to the eDRX cycle.

19. The method of claim 14 or 15, further comprising: performing a paging procedure by using a Fifth Generation (5G) Globally Unique Temporary Identifier (GUTI), wherein the 5G GUTI is repeatable for multiple paging procedures or changed based on a signaling message from the UE or a Mobility and Periodic Registration Update (MRU) from the UE.

20. The method of claim 14 or 15, wherein the UE supports a first mode of operation using the reduced capability and a second mode of operation not using the reduced capability, and wherein the method further comprises: receiving an indication from the UE regarding a switch from operating in the first mode of operation to the second mode of operation; and using a context or parameters of a Protocol Data Unit (PDU) session with the UE after the switch, wherein the context or the parameters are used prior to the switch.

Images