Nothing Special   »   [go: up one dir, main page]

WO2022140170A1 - Améliorations apportées à des états inactifs et au repos de commande de ressources radio (rrc) et à une transition à un état connecté dans des réseaux cellulaires - Google Patents

Améliorations apportées à des états inactifs et au repos de commande de ressources radio (rrc) et à une transition à un état connecté dans des réseaux cellulaires Download PDF

Info

Publication number
WO2022140170A1
WO2022140170A1 PCT/US2021/063963 US2021063963W WO2022140170A1 WO 2022140170 A1 WO2022140170 A1 WO 2022140170A1 US 2021063963 W US2021063963 W US 2021063963W WO 2022140170 A1 WO2022140170 A1 WO 2022140170A1
Authority
WO
WIPO (PCT)
Prior art keywords
rrc
network
coverage
message
state
Prior art date
Application number
PCT/US2021/063963
Other languages
English (en)
Inventor
Fatemeh HAMIDI-SEPEHR
Sangeetha L. Bangolae
Youn Hyoung Heo
Qian Li
Sudeep Palat
Original Assignee
Intel Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corporation filed Critical Intel Corporation
Publication of WO2022140170A1 publication Critical patent/WO2022140170A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/02—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration by periodical registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W64/00—Locating users or terminals or network equipment for network management purposes, e.g. mobility management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/19—Connection re-establishment

Definitions

  • Various embodiments generally may relate to the field of wireless communications.
  • some embodiments may relate to enhancements of radio resource control (RRC) inactive and idle states and transition to connected state in wireless cellular networks.
  • RRC radio resource control
  • 6G wireless systems are expected to provide better user experience and performance compared to the prior wireless technologies such as LTE and 5G.
  • Some of the target key performance indicators (KPI) to aim for are supporting wider bandwidths compared to 5G (e.g. at least 2 GHz or larger), supporting higher peak data rates such as beyond 100 Gbps, and providing lower physical layer latency such as under 100 usee turnaround time.
  • KPI target key performance indicators
  • 6G is also expected to enable better support of vertical industries, including support for private networks.
  • Figure 1 illustrates NR Control Plane states and associated transitions.
  • Figure 2 illustrates RRC states and associated transitions. For ease of understanding, the mobility, handover, and corresponding measurement aspects are not depicted in Figure 2.
  • Figure 3 illustrates a process for NR Idle to Connected mode transition from 3GPP TS 38.401, V16.3.0, Section 8.1.
  • Figures 4A-4B illustrate an NR service request procedure according to 3GPP TS 23.502, V16.6.0, Section 4.2.3.2.
  • Figure 4B is a continuation of the portion of the procedure illustrated in Figure 4 A.
  • Figure 5 illustrates a first option (Option A) of an enhanced service request procedure, in which a number of RRC messages over the air is equivalent to the Resume procedure, in accordance with various embodiments.
  • Figure 6 illustrates a second option (Option B) of an enhanced service request procedure, in which a number of RRC messages over the air is similar to that of the legacy RRC Idle to Connected transition procedure, in accordance with various embodiments.
  • Figure 7 illustrates enhancements at the UE to support the RRC IDLE to RRC CONNECTED transition, in accordance with various embodiments.
  • Figure 8 illustrates a procedure for a UE transition from RRC INACTIVE to RRC CONNECTED, in accordance with various embodiments.
  • FIG. 9 illustrates RRC states and associated transitions with RRC inactive state split into an RRC inactive in-coverage state and an RRC inactive out-of-coverage state, in accordance with various embodiments.
  • Figure 10 illustrates an example procedure for providing UE assistance information to obtain specific RNA update timer, in accordance with various embodiments.
  • Figure 11 schematically illustrates a network in accordance with various embodiments.
  • Figure 12 schematically illustrates components of a wireless network in accordance with various embodiments.
  • Figure 13 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.
  • a machine-readable or computer-readable medium e.g., a non-transitory machine-readable storage medium
  • the RRC inactive state may be set as the fallback state for the UE when the UE goes out of coverage.
  • the RRC inactive state may be split into an RRC inactive in-coverage state and an RRC inactive out-of-coverage state. Alternatively, the same RRC inactive state may be used for both in-coverage and out-of-coverage.
  • Embodiments further provide techniques to reduce the latency of idle to connected mode transition for the UE.
  • a system design which minimizes connection establishment and network access time may be preferable to allow the most possible data transfer during the short in-coverage durations, e.g., to enable the user (UE) to quickly transfer and/or receive data, whenever the coverage becomes available.
  • one of the goals of the future technology is to develop a system design which enables accessing the network and transferring data (large or small payload) in uplink (UL) or downlink (DL) direction, with the least possible incurred latency and overhead, before the network coverage is lost (likely in a very short time).
  • Such design involves both radio access network (RAN) and core network aspects. As such, it is necessary to identify the limitations, potential bottlenecks, and any room for enhancement or optimization of the current system design (from both control plane (CP) and user plane (UP) perspectives) under limited coverage. At the same time, there may be deployments and/or use-cases that cannot be reasonably addressed by evolving the current state-based system design. Such cases require looking into the new designs or solutions which may be better tailored for the problems at hand.
  • RAN radio access network
  • core network aspects As such, it is necessary to identify the limitations, potential bottlenecks, and any room for enhancement or optimization of the current system design (from both control plane (CP) and user plane (UP) perspectives) under limited coverage.
  • CP control plane
  • UP user plane
  • RRC IDLE state plays the role of a fallback state. For example, when the UE faces an radio link failure (RLF) event which cannot recover from or goes out of network coverage, it enters the RRC IDLE state.
  • RLF radio link failure
  • UE is required to transition to the RRC CONNECTED state (though there are some exceptions for transmission of very small payload sizes in RRC INACTIVE state).
  • the overhead and latency of idle-to-active transitions in the core network is not tolerable in scenarios with transient duration of UE being in-coverage.
  • embodiments herein provide new features for the RRC INACTIVE state, such as for operation under limited coverage (e.g., in deployments with coverage islands, etc.).
  • limited coverage e.g., in deployments with coverage islands, etc.
  • embodiments provide solutions in order to optimize/enhance the RRC IDLE state connection establishment procedure (e.g., to reduce CP latency). For operation under sparse deployments with limited coverage, such solutions enable making better use of the transient time that the UE spends in network coverage.
  • One advantage of embodiments herein is to support UEs in coverage islands that get transitioned into IDLE mode and require a shorter access latency to be able to send uplink data compared to current scheme.
  • the device may reside in different states depending on the traffic activity.
  • Figure 1 and Figure 2 demonstrate NR CP and RRC states and the associated transitions, respectively.
  • the core network states CM IDLE and CM CONNECTED are defined based on whether the device has established a connection with the core network or not (see Figure 1).
  • An NR device can be in one of three RRC states, RRC IDLE, RRC ACTIVE, and RRC INACTIVE (see Figure 2).
  • the first two RRC states, RRC IDLE and RRC CONNECTED are similar to the counterparts in LTE, while RRC INACTIVE is a new state introduced in NR and not present in the original LTE design.
  • RRC IDLE there is no RRC context (e.g., the necessary parameters for communication between the device and the network) in the RAN, and the device does not belong to a specific cell. From a core network perspective, the device is in the CM IDLE state. No data transfer may take place as the device sleeps most of the time to reduce battery consumption. In the downlink, devices in idle state periodically wake up to receive paging messages, if any, from the network. Mobility is handled by the device through cell reselection. Uplink synchronization is not maintained and hence the only uplink transmission activity that may take place is random access, to move to a connected state. As part of moving to a connected state, the RRC context is established in both the device and the network.
  • RRC context e.g., the necessary parameters for communication between the device and the network
  • the RRC context is established and all necessary parameters for communication between the device and the radio-access network are known to both entities.
  • the device is in the CM CONNECTED state.
  • the cell to which the device belongs is known and an identity of the device, the Cell Radio-Network Temporary Identifier (C-RNTI), used for signaling purposes between the device and the network, has been configured.
  • C-RNTI Cell Radio-Network Temporary Identifier
  • the connected state is intended for data transfer to/from the device, but discontinuous reception (DRX) can be configured to reduce device power consumption. Since there is an RRC context established in the gNB in the connected state, leaving DRX and starting to receive/transmit data is relatively fast as no connection setup with its associated signaling is needed.
  • Mobility is managed by the radio-access network, that is, the device provides neighboring-cell measurements to the network which commands the device to perform a handover when relevant. Uplink time alignment may or may not exist but need to be established using random access and maintained for data transmission to take place.
  • RRC IDLE In LTE and older releases, only RRC IDLE and RRC CONNECTED states are supported. Practically, the RRC IDLE state is considered as the primary sleep state to reduce the device power consumption. However, as frequent transmission of small packets is common for many smartphone applications, the result is a significant amount of idle-to-active transitions in the core network. These transitions come at a cost in terms of signaling load and associated delays. Therefore, to reduce the signaling load and in general reduce the latency, suspending the connection while storing the context and keeping the UE in inactive was introduced in LTE Release 13. On the other hand, an explicit third state is defined in NR, e.g. the RRC INACTIVE state. In RRC INACTIVE, the UE context is kept in both the device and the gNB.
  • the core network connection is also kept, that is, the device is in CM CONNECTED from a core network perspective. Hence, transition to connected state for data transfer is fast. No core network signaling is needed (In terms of messaging, only Resume request and Resume messages are exchanged, upon which the UE enters the CONNECTED state).
  • the RRC context is already in place in the network and idle-to-active transitions can be handled in the radio-access network.
  • the device is allowed to sleep in a similar way as in the idle state and mobility is handled through cell reselection, without involvement of the network.
  • RRC INACTIVE can be seen as a mix of RRC IDLE and RRC CONNECTED states (In LTE release 13, the RRC suspend/resume mechanism was introduced to provide similar functionality as RRC INACTIVE in NR. However, the connection to the core network is not maintained in RRC suspend/resume). Different from RRC IDLE state, in RRC IN ACTIVE state, the UE is expected to monitor broadcast downlink signals (system information, paging, etc.) as part of PDCCH monitoring just like in RRC CONNECTED. On the other hand, the mobility handling is similar to RRC IDLE state.
  • the UE’s initial/reset state is the RRC IDLE (MM IDLE) state (UE is not maintained in RRC INACTIVE state). Accordingly, if the UE needs to send data, it has to enter the RRC CONNECTED state (following the existing design). As such, the price to pay is establishing the RRC connection both at the RAN and at the core network level. There is a price in terms of the delay and signaling overhead, as the context has to be first established between the RAN and the core network. In this regard, it is important to optimize the transition from the RRC IDLE state to RRC CONNECTED state.
  • Enhancements to the service request procedure are provided herein to help the UE operate in opportunistic access scenarios (as described above), with initial state of RRC IDLE.
  • Figure 3 illustrates a procedure for NR Idle mode to Connected mode transition (e.g., from 3GPP TS 38.401, Section 8.1).
  • Figures 4A-4B illustrate an NR service request procedure (e.g., from 3GPP TS 23.502, Section 4.2.3.2). Comparing NR UE-triggered service request procedure and the Resume procedure on the RAN side, it is noted that in the Resume procedure, there is no need to perform security handling, since the UE context is available in the gNB (e.g., not necessary to perform any reconfiguration). For the UE-triggered service request procedure (Figures 4A-4B), what happens in the core network between the nodes is elaborated in TS 23.502, where many steps of the entire procedure are optional (the NAS security establishment, etc., are also performed in this procedure).
  • the service request message is relatively large as discussed below. As such, it might cause a delay due to the potential segmentation.
  • the service request is usually sent in the RRC setup complete message as shown in figures 3 and 4.
  • the service request message in step 1 of Figures 4A-4B corresponds to step 5 in Figure 3.
  • the maximum size of the message in LTE was 4 octets.
  • the message size is a minimum of 13 octets (due to introduction of 5G-S-TMSI) and with the list of PDU sessions to be activated or indicating those that are active in the UE could add up to another 34 octets making a message total of 47 octets or more!
  • This design adds a lot of flexibility for the UE that moves from RRC IDLE to RRC CONNECTED and the transition was expected to be infrequent given the introduction of RRC INACTIVE state.
  • a UE may find itself in RRC IDLE more often in deployments with potentially limited/sparse coverage, and/or in high frequency scenarios where there may be prolonged blockages. This motivates the need to optimize/shorten the idle to connected mode transition as an important part of connection establishment, which will be discussed in the next sections. Enhancements to UE-triggered service request procedure
  • Embodiments herein provide techniques to enhance/optimize the service request procedure. This topic was discussed during Rel-15 in 3GPP but opponents argued that it was not a major problem; also ITU agreed to use INACTIVE to CONNECTED transition delay for control plane latency analysis. However, with the advent of mmWave and future high frequency technologies and scenarios, as well as potentially sparse deployments with limited-coverage, optimizing the idle to connected transition (e.g., to be as good as inactive to connected transition) is further motivated.
  • Embodiments are further described below to enable fast UL data transfer, upon transitioning from RRC IDLE.
  • Embodiment 1 Idle to connected transition signaling enhancements
  • message 3 size limitation may be overcome in that a larger grant can be provided for the UE, a UE in RRC IDLE state, can send parts of the service request (referring to Figure 5.) message with some basic information (if not the entire large service request as currently defined) in the first message (Msg3).
  • Msg3 the basic information (if not the entire large service request as currently defined) in the first message (Msg3).
  • Msg3 the basic information
  • the contents of the message 3 to support service request initiation may include but not limited to: UE ID such as for example, 5G-S-TMSI (parts or whole), establishment cause (e.g., including some form of opportunistic access indication), along with selected PLMN identity, registered AMF information (that refers to PLMN ID and AMF ID), GUAMI type (whether it is native or mapped), S-NSSAI list if supported, and a dedicated NAS message that will include basic information to initiate contact with the AMF for fetching UE’s context info.
  • UE ID such as for example, 5G-S-TMSI (parts or whole)
  • establishment cause e.g., including some form of opportunistic access indication
  • the dedicated NAS message could primarily include the necessary PDU session information that needs to be activated immediately e.g. only pertaining to the data that needs to be sent.
  • the detailed status on other PDU sessions may be sent as part of message 5 similar to what is done in 5G already.
  • the dedicated NAS message may also include any necessary security parameters or some default security parameters may be considered.
  • the gNB may also provide a larger grant to accommodate uplink data as part of message 5.
  • the UE upon receiving the RRC setup message (which includes the SMC and may include the reconfiguration message), prepares the “RRC Setup Complete” message shown in step 9 as follows:
  • PDU sessions information including PDU session status and list of PDU sessions to be activated/allowed. This is so that some of the sessions may remain inactive while those that need to be activated now are indicated accordingly. This adds flexibility to not activate all the sessions unlike in LTE where all the sessions are activated implicitly. However, this further adds delay not only for idle to connected transition but also the ability to send data after transitioning from inactive to connected (as the UE has to do service request procedure after switching to connected in case some of the sessions are still inactive).
  • As the gNB may also provide a larger grant uplink data may be sent in message 5 as well.
  • the proposed optimization is based on the current security procedure, with the security mode command for AS security exchange (which primarily handles the security algorithm exchange), and the UE being expected to respond to it.
  • these messages can be piggybacked with the setup and/or reconfiguration messages and may not necessarily impose much overhead problem.
  • optimizations can be considered by assuming that the algorithms are the default configurations exchanged in the past or pre-configured or part of the UE’s stored information.
  • Integrity verification is the primary procedure that needs to be performed at the gNB, in order to be able to receive UL data and the gNB can send message 4 integrity protected with the MAC-I. With the proposed approach, it is thus possible to reduce the number of messages and shrink the procedure, in order to improve the incurred latency (due to the setup messages/ signaling between the RAN and the core NW, etc.).
  • the service request message in NR currently includes the list of current active PDU sessions (in addition to all other parameters).
  • the AMF also checks the active sessions on its side and deletes the sessions that are no longer active.
  • the AMF will only send the context of the active sessions, and the gNB establishes the sessions accordingly (the reconfiguration is to modify any necessary bearer configuration).
  • the bearer to session mapping has to be synchronized between the UE and the network (even if the synchronization does not happen frequently/periodically).
  • the service request can be performed even in the connected mode (in the LTE it cannot be).
  • the UE once the UE has entered the connected state, it can perform a service request procedure again (it is only a matter of when the UE does it; it may not necessarily be performed as soon as the UE comes out of the RRC IDLE state and transitions into the RRC CONNECTED state).
  • Figure 5 illustrates a procedure in accordance with various embodiments.
  • the procedure operations corresponding to the signaling enhancements discussed thus far and corresponding to Figure 5 may include one or more of:
  • a UE in RRC IDLE may obtain a larger grant based on pre-configuration information or RACH-based differentiation and sends RRC Setup Request message along with an initial or complete Service request message (a NAS message) which is encrypted using stored security context (NAS security keys) or default configuration as provided by the network a priori. If a large enough grant is provided, UE may also send data with this message using the stored security or default configuration or pre-configured security settings.
  • the gNB DU receives the set up request message from UE and stores the UL data if any, until it receives UE context information; upon receiving the NAS message, the DU forwards the message to the CU.
  • the gNB CU initiates the initial UE message as per legacy upon receiving the NAS message.
  • the AMF fetches UE’s context and initiates UE context setup request towards the gNB
  • the gNB CU forwards the UE context towards the gNB DU.
  • the gNB DU responds to the gNB CU
  • the gNB CU forwards the UE context setup success response to the AMF.
  • the gNB DU upon receiving the UE context will send the Setup response and piggyback updated security command message and reconfiguration message if any.
  • the DU may process the UL data and if successful, it will forward towards the core network.
  • the UE enters RRC CONNECTED and responds with RRC Setup Complete message and send update service request message and more data if necessary.
  • the gNB DU forwards the received RRC message and uplink data.
  • the gNB CU may send a new updated UE message (corresponding to the initial UE message sent earlier) to provide updated service request message towards the AMF.
  • Figure 6 shows another variation for performing the enhanced service request procedure which is similar to the procedure of Figure 5, except that the number of RRC messages is similar to that of the idle to connected transition rather than resume procedure.
  • the primary enhancement is the ability to piggyback data within the initial RRC messages as well as ability to send service request message in message 3 (RRC Setup Request) along with data.
  • RRC Setup Request service request message
  • the SMC and reconfiguration messages may go separately indicating that there may be more round trip TTIs involved in transmitting the uplink data.
  • Option 1 is highly efficient and reduces the overall time taken to complete the idle to connected transition due to merging of multiple control messages into few.
  • Embodiment 2 Store and forward the data between UE and gNB
  • the gNB DU may need to store received data from the UE and forward towards the network appropriately upon processing. This enables the UE to be able to transmit data using any available uplink grant and as quickly as possible (upon waking from idle mode).
  • the storing of the data at the DU may be bound by a specific timer that is configured by the network.
  • the UE may be configured to use any of the following configuration settings for packaging the data as disclosed below.
  • the UE may be configured with default configuration for PHY settings and default configuration for RLC bearer to utilize for piggybacking data within initial RRC messages e.g. RRC Setup Request, RRC Setup Complete. This may be either specified in the specification or provided through dedicated signaling by the network.
  • RLC bearer configuration may also be based on pre-configuration. It is understood that during RRC IDLE, the UE purges its UE context and therefore it may not have any RLC bearer stored configuration. However, it may be possible that the UE stores this configuration.
  • the UE For security purposes, including for the NAS message (e.g. Service request) and for the data itself, the UE also may have to utilize stored configuration from previous connection.
  • the NAS message e.g. Service request
  • the UE also may have to utilize stored configuration from previous connection.
  • the gNB DU will store the data until it can obtain the UE’s context information. It is possible that the UE may go out of coverage during this process before it receives the RLC ACK or higher layer ACK. If the DU is able to process the data successfully, it may forward the data thereafter towards the core network. It is up to UE implementation or prior configuration or traffic settings at upper layer on whether the UE resends the data once it reconnects or not.
  • Figure 7 illustrates enhancements at the UE to support RRC IDLE to RRC CONNECTED transition.
  • Figure 7 depicts the requirements for a UE in RRC IDLE to be able to send data within message 3 (RRC Set up Request) or message 5 (RRC set up complete) while transitioning to connected mode.
  • the exemplary step 1 corresponds to the beginning of the steps as described in embodiment 1.
  • RLF Radio Link Failure
  • ⁇ NR did not optimize the reestablishment procedure at all (compared to LTE). Further, in current technologies, in most cases the UE is assumed to be in coverage. Facing an RLF is a very rare situation, and the expectation is that even if the UE faces an RLF on one cell, it will find another cell during cell selection to do a reestablishment in.
  • the price for the network is the configuration resources.
  • gNBs are distributed units with limited memory. In a real wide-area deployment potentially with millions of gNB, populating all gNBs with large memory is a significant cost. But for small area deployment, the cost of memory may not be an issue. With a CU/DU split, the memory in the CU may not be a big issue. If resources are critical, price to be paid is in terms of the radio delay due to the RRC IDLE to RRC CONNECTED transition and look for possible optimizations in this regard.
  • the new gNB needs to fetch/retrieve the UE’s context from the previous gNB. This can be done using resume ID, which is unique within the RAN. o
  • the price to pay is the context fetch and potential inter-gNB handover latency. If it is desired to avoid even the context fetch delay from the CU to the DU, the context needs to be stored at the DU. But that will still not solve the problem when the UE appears in another DU (e.g., still need to do a context fetch).
  • the UE is in CM CONNECTED state and can have PDU sessions maintained.
  • RRC INACTIVE is similar to RRC IDLE, which is very beneficial from the UE power saving perspective. Since the price of transitioning from the RRC INACTIVE to RRC CONNECTED state is also negligible, it is not worth keeping the UE in the RRC_ INACTIVE especially from mobility and handover related signalling perspective.
  • the UE which is kept in RRC CONNECTED has to undergo unnecessary signalling (and thereby wasted power) overhead in performing handovers during mobility.
  • the gNB stores the UE context information including the radio configuration, but radio resource configuration is not reserved for that UE by the serving cell (the only dedicated/reserved radio resources is potentially the SR resource, and even that can be released).
  • RRC INACTIVE in RRC INACTIVE state, the previous RRC CONNECTED configuration is stored. Accordingly, when the UE comes back into the RRC CONNECTED state, only a single message is exchanged to retrieve the old configuration as shown in Figure 8. The amount of signaling exchange from RRC INACTIVE to RRC CONNECTED is almost negligible.
  • RRC INACTIVE state can be split to two sub-states, one for in-coverage and one for out-of-coverage operation.
  • the in-coverage sub-state follows the current NR RRC INACTIVE behavior.
  • out-of-coverage sub-state the main difference is that the UE is not expected to monitor broadcast signals, paging, etc.
  • the main characteristic of the RRC INACTIVE out-of-coverage state is support of different behavior with respect to identifying cells, performing cell search, etc.
  • the network does not release the UE context/configurations (UE maintains context, last connected cell, time stamp/location for when it goes out of coverage).
  • the overall procedure is then transitioning from RRC CONNECTED to RRC INACTIVE in-coverage (as in current NR design), and when UE goes out of coverage, it transitions into RRC INACTIVE out-of-coverage.
  • RRC INACTIVE out-of-coverage can take place via an RRC message when the UE is back in coverage (e.g., without involving the core network) ( Figure 9).
  • the RRC IDLE state is the fallback state for the UE.
  • the UE faces an RLF event which it cannot recover from, it enters the IDLE state.
  • the overhead and latency of idle-to-active transitions in the core network is not tolerable in scenarios with transient duration of UE being in-coverage and having to transfer large amount of data within the short in-coverage duration.
  • RRC INACTIVE state is the efficient state to keep minimal access for opportunistic communication. It is desired to make the RRC INACTIVE state as the reset/initial state, e.g., when UE goes to out-of-coverage and comes back to the network coverage, it is still maintained in the RRC INACTIVE state.
  • the current specification allows (by network configuration) the UE to remain in RRC INACTIVE state even if the UE goes out of coverage for an extended period of time (also, from the UE perspective, staying in INACTIVE state does not impose any problem on the protocol).
  • UE’s initial/reset/fallback state is RRC INACTIVE (instead of the RRC IDLE state, upon facing RLF and not finding another cell)
  • the UE context is stored in the RAN node (the gNB).
  • the transition to the RRC CONNECTED state is very efficient in terms of both the signaling and the incurred latency.
  • the connection set-up time from the RRC_ INACTIVE state may even be further reduced by means of the two-step RACH, or other mechanisms.
  • the gNB may (dynamically) save/store the configuration, and if (unrecoverable) RLF happens, the UE enters the RRC INACTIVE state (with the stored configuration/context) and the network may also store UE’s context for a certain albeit long period of time.
  • RNA RAN Network Area
  • a failure of the RNA update from the UE or failure of the RAN paging results in a release of the UE context/configuration (from the RAN node) and exiting the RRC INACTIVE state
  • a network implementation aspect and may not be specified, and also depends on the configuration. For example, if the network has configured a UE to perform periodic RNA updates, and if it fails, the normal network implementation releases the configuration from the RAN node. However, it is also possible to configure a different configuration on the network.
  • the UE may not necessarily transition to RRC IDLE state, depending on the RAN paging and RNA update timer.
  • the UE can reside in RRC inactive state, if the paging is properly configured (e.g., to give the UE some time no to do anything until the timer triggers the next RNA update, etc.).
  • the periodic RNA update timer can be set to infinity, and the RAN tracking areas can be configured to be the same size as (equal to or less than) TA update area, with no additional signaling involved with the RNA update from the UE.
  • the current configuration may allow the UE to operate with infinite RAN update periodicity, while it is not explicitly specified that infinity is a possible value for the T380 (RNA update).
  • infinity is considered for RNA periodic updates, otherwise it is a value set in NR between 5 minutes and 720 minutes. Consequently, the UE may not be guaranteed to be configured to infinity RNA update periodicity, since it may be left up to the network implementation.
  • UE assistance information may be introduced in which, the UE indicates that it wants to be configured by infinity RNA periodic update, e.g., depending on the deployment, type of device, mobility, etc. (when the UE knows it is likely to go out of the network coverage). For example, such indication may be carried in the capability signaling, in the establishment request, or it could be an independent UE assistance information as shown in Figure 10.
  • This mechanism may define a UE initiated configuration/behavior, if the network may not be aware of when UE goes out of coverage (if UE’s location information is not available, and/or a map of network’s coverage area is not available). On the other hand, availability of some information at the network and/or UE, facilitates the proper configuration. For example, if the network informs the UEs under its service that the (private) deployment does not provide full coverage, e.g., several coverage holes exists by deployment (likely resulting in more transient out of coverage event), or only coverage islands/spots are available (likely resulting in more extended out of coverage events), proper configurations can be enabled from the beginning of the service.
  • both the network and the UE can expect experiencing potential outages/blockages (especially with UE mobility and/or sparse network deployments), proper configurations can be enabled from the beginning of the service.
  • higher frequency bands e.g., mmWave or THz
  • both the network and the UE can expect experiencing potential outages/blockages (especially with UE mobility and/or sparse network deployments)
  • proper configurations can be enabled from the beginning of the service.
  • the network may page the UE (since the network does not know whether the UE is in coverage or not) but the UE may not be reachable.
  • the loss is in additional network signaling due to paging, but the UE will not get moved autonomously into the idle state (since responding to RAN paging is a choice and not responding does not necessarily cause transitioning to IDLE) (DL unreachability is still a problem. Later in this document, we discuss ideas to solve the unreachability problem).
  • the UE needs to operate with infinite RAN update regardless of UE being in-coverage or out-of-coverage. Ideally, it may be desired to have a different handling when the UE is in-coverage or out-of-coverage.
  • RAN configuration resources are critical, it is not desired to store many UE configurations in RAN, if the UEs are going to be unreachable. Therefore, if UE does not respond to RAN paging from the INACTIVE state over a period of time (e.g., after a certain number of retries), the UE context might be released from the RAN (and the UE transitions to RRC IDLE state) based on network implementation.
  • the UE context can be maintained in the RAN in INACTIVE even when UE goes out of coverage, and paging could also continue (even without UE response).
  • a UE in vicinity can be introduced/configured to perform the keepalive approach by informing the gNB about the existence of the UE.
  • the UE without connectivity to the network can let a designated UE know that it is still under the serving gNB, in the same cell coverage.
  • the designated UE can then update the gNB about the out-of-coverage UE status (and send an ACK information to the UE, for example using Sidelink), when the target UE is no able to do so.
  • the designated UE maintains the target UE context in the RAN levels, since the target UE may be out of coverage for a long period of time, and it is desired to avoid the target UE being sent to RRC IDLE state.
  • the target UE context (the configuration being stored in the RAN), does not entirely help with the target UE reachability.
  • the target UE is still unreachable for receiving DL data, unless the designated UE can also support data buffering and forwarding or it allows the gNB to buffer the data for a given period of time.
  • the designated UE can also support data buffering and forwarding or it allows the gNB to buffer the data for a given period of time.
  • the network can configure the UE to act in Mobile Initiated RRC INACTIVE state wherein, the core network is made aware that the UE is in CM CONNECTED/RRC INACTIVE state but can only perform Mobile originated traffic. Any downlink traffic can then be buffered at the UPF. This ensures that the downlink data is not lost and made available when the UE is finally able to connect at any gNB in the network.
  • FIGS 11-13 illustrate various systems, devices, and components that may implement aspects of disclosed embodiments.
  • FIG 11 illustrates a network 1100 in accordance with various embodiments.
  • the network 1100 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems.
  • 3GPP technical specifications for LTE or 5G/NR systems 3GPP technical specifications for LTE or 5G/NR systems.
  • the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3GPP systems, or the like.
  • the network 1100 may include a UE 1102, which may include any mobile or non-mobile computing device designed to communicate with a RAN 1104 via an over-the-air connection.
  • the UE 1102 may be communicatively coupled with the RAN 1104 by a Uu interface.
  • the UE 1102 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.
  • the network 1100 may include a plurality of UEs coupled directly with one another via a sidelink interface.
  • the UEs may be M2M/D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.
  • the UE 1102 may additionally communicate with an AP 1106 via an over-the-air connection.
  • the AP 1106 may manage a WLAN connection, which may serve to offload some/all network traffic from the RAN 1104.
  • the connection between the UE 1102 and the AP 1106 may be consistent with any IEEE 802.11 protocol, wherein the AP 1106 could be a wireless fidelity (Wi-Fi®) router.
  • the UE 1102, RAN 1104, and AP 1106 may utilize cellular- WLAN aggregation (for example, LWA/LWIP).
  • Cellular- WLAN aggregation may involve the UE 1102 being configured by the RAN 1104 to utilize both cellular radio resources and WLAN resources.
  • the RAN 1104 may include one or more access nodes, for example, AN 1108.
  • AN 1108 may terminate air-interface protocols for the UE 1102 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and LI protocols. In this manner, the AN 1108 may enable data/voice connectivity between CN 1120 and the UE 1102.
  • the AN 1108 may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network, which may be referred to as a CRAN or virtual baseband unit pool.
  • the AN 1108 be referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc.
  • the AN 1108 may be a macrocell base station or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.
  • the RAN 1104 may be coupled with one another via an X2 interface (if the RAN 1104 is an LTE RAN) or an Xn interface (if the RAN 1104 is a 5G RAN).
  • the X2/Xn interfaces which may be separated into control/user plane interfaces in some embodiments, may allow the ANs to communicate information related to handovers, data/context transfers, mobility, load management, interference coordination, etc.
  • the ANs of the RAN 1104 may each manage one or more cells, cell groups, component carriers, etc. to provide the UE 1102 with an air interface for network access.
  • the UE 1102 may be simultaneously connected with a plurality of cells provided by the same or different ANs of the RAN 1104.
  • the UE 1102 and RAN 1104 may use carrier aggregation to allow the UE 1102 to connect with a plurality of component carriers, each corresponding to a Pcell or Scell.
  • a first AN may be a master node that provides an MCG and a second AN may be secondary node that provides an SCG.
  • the first/second ANs may be any combination of eNB, gNB, ng-eNB, etc.
  • the RAN 1104 may provide the air interface over a licensed spectrum or an unlicensed spectrum.
  • the nodes may use LAA, eLAA, and/or feLAA mechanisms based on CA technology with PCells/Scells.
  • the nodes Prior to accessing the unlicensed spectrum, the nodes may perform medium/carrier-sensing operations based on, for example, a listen-before-talk (LBT) protocol.
  • LBT listen-before-talk
  • the UE 1102 or AN 1108 may be or act as a RSU, which may refer to any transportation infrastructure entity used for V2X communications.
  • An RSU may be implemented in or by a suitable AN or a stationary (or relatively stationary) UE.
  • An RSU implemented in or by: a UE may be referred to as a “UE-type RSU”; an eNB may be referred to as an “eNB-type RSU”; a gNB may be referred to as a “gNB-type RSU”; and the like.
  • an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs.
  • the RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic.
  • the RSU may provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may provide other cellular/WLAN communications services.
  • the components of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network.
  • the RAN 1104 may be an LTE RAN 1110 with eNBs, for example, eNB 1112.
  • the LTE RAN 1110 may provide an LTE air interface with the following characteristics: SCS of 15 kHz; CP-OFDM waveform for DL and SC-FDMA waveform for UL; turbo codes for data and TBCC for control; etc.
  • the LTE air interface may rely on CSI-RS for CSI acquisition and beam management; PDSCH/PDCCH DMRS for PDSCH/PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE.
  • the LTE air interface may operating on sub-6 GHz bands.
  • the RAN 1104 may be an NG-RAN 1114 with gNBs, for example, gNB 1116, or ng-eNBs, for example, ng-eNB 1118.
  • the gNB 1116 may connect with 5G-enabled UEs using a 5GNR interface.
  • the gNB 1116 may connect with a 5G core through an NG interface, which may include an N2 interface or an N3 interface.
  • the ng-eNB 1118 may also connect with the 5G core through an NG interface, but may connect with a UE via an LTE air interface.
  • the gNB 1116 and the ng-eNB 1118 may connect with each other over an Xn interface.
  • the NG interface may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the nodes of the NG-RAN 1114 and a UPF 1148 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN1114 and an AMF 1144 (e.g., N2 interface).
  • NG-U NG user plane
  • N-C NG control plane
  • the NG-RAN 1114 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar, repetition, simplex, and Reed-Muller codes for control and LDPC for data.
  • the 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS similar to the LTE air interface.
  • the 5G-NR air interface may not use a CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signal for time tracking.
  • the 5G-NR air interface may operating on FR1 bands that include sub-6 GHz bands or FR2 bands that include bands from 24.25 GHz to 52.6 GHz.
  • the 5G-NR air interface may include an SSB that is an area of a downlink resource grid that includes PSS/SSS/PBCH.
  • the 5G-NR air interface may utilize BWPs for various purposes.
  • BWP can be used for dynamic adaptation of the SCS.
  • the UE 1102 can be configured with multiple BWPs where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 1102, the SCS of the transmission is changed as well.
  • Another use case example of BWP is related to power saving.
  • multiple BWPs can be configured for the UE 1102 with different amount of frequency resources (for example, PRBs) to support data transmission under different traffic loading scenarios.
  • a BWP containing a smaller number of PRBs can be used for data transmission with small traffic load while allowing power saving at the UE 1102 and in some cases at the gNB 1116.
  • a BWP containing a larger number of PRBs can be used for scenarios with higher traffic load.
  • the RAN 1104 is communicatively coupled to CN 1120 that includes network elements to provide various functions to support data and telecommunications services to customers/subscribers (for example, users of UE 1102).
  • the components of the CN 1120 may be implemented in one physical node or separate physical nodes.
  • NFV may be utilized to virtualize any or all of the functions provided by the network elements of the CN 1120 onto physical compute/storage resources in servers, switches, etc.
  • a logical instantiation of the CN 1120 may be referred to as a network slice, and a logical instantiation of a portion of the CN 1120 may be referred to as a network sub-slice.
  • the CN 1120 may be an LTE CN 1122, which may also be referred to as an EPC.
  • the LTE CN 1122 may include MME 1124, SGW 1126, SGSN 1128, HSS 1130, PGW 1132, and PCRF 1134 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the LTE CN 1122 may be briefly introduced as follows.
  • the MME 1124 may implement mobility management functions to track a current location of the UE 1102 to facilitate paging, bearer activation/deactivation, handovers, gateway selection, authentication, etc.
  • the SGW 1126 may terminate an SI interface toward the RAN and route data packets between the RAN and the LTE CN 1122.
  • the SGW 1126 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.
  • the SGSN 1128 may track a location of the UE 1102 and perform security functions and access control. In addition, the SGSN 1128 may perform inter-EPC node signaling for mobility between different RAT networks; PDN and S-GW selection as specified by MME 1124; MME selection for handovers; etc.
  • the S3 reference point between the MME 1124 and the SGSN 1128 may enable user and bearer information exchange for inter-3 GPP access network mobility in idle/active states.
  • the HSS 1130 may include a database for network users, including subscription-related information to support the network entities’ handling of communication sessions.
  • the HSS 1130 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.
  • An S6a reference point between the HSS 1130 and the MME 1124 may enable transfer of subscription and authentication data for authenticating/authorizing user access to the LTE CN 1120.
  • the PGW 1132 may terminate an SGi interface toward a data network (DN) 1136 that may include an application/content server 1138.
  • the PGW 1132 may route data packets between the LTE CN 1122 and the data network 1136.
  • the PGW 1132 may be coupled with the SGW 1126 by an S5 reference point to facilitate user plane tunneling and tunnel management.
  • the PGW 1132 may further include a node for policy enforcement and charging data collection (for example, PCEF).
  • the SGi reference point between the PGW 1132 and the data network 11 36 may be an operator external public, a private PDN, or an intra-operator packet data network, for example, for provision of IMS services.
  • the PGW 1132 may be coupled with a PCRF 1134 via a Gx reference point.
  • the PCRF 1134 is the policy and charging control element of the LTE CN 1122.
  • the PCRF 1134 may be communicatively coupled to the app/content server 1138 to determine appropriate QoS and charging parameters for service flows.
  • the PCRF 1132 may provision associated rules into a PCEF (via Gx reference point) with appropriate TFT and QCI.
  • the CN 1120 may be a 5GC 1140.
  • the 5GC 1140 may include an AUSF 1142, AMF 1144, SMF 1146, UPF 1148, NSSF 1150, NEF 1152, NRF 1154, PCF 1156, UDM 1158, and AF 1160 coupled with one another over interfaces (or “reference points”) as shown.
  • Functions of the elements of the 5GC 1140 may be briefly introduced as follows.
  • the AUSF 1142 may store data for authentication of UE 1102 and handle authentication- related functionality.
  • the AUSF 1142 may facilitate a common authentication framework for various access types.
  • the AUSF 1142 may exhibit an Nausf service-based interface.
  • the AMF 1144 may allow other functions of the 5GC 1140 to communicate with the UE 1102 and the RAN 1104 and to subscribe to notifications about mobility events with respect to the UE 1102.
  • the AMF 1144 may be responsible for registration management (for example, for registering UE 1102), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization.
  • the AMF 1144 may provide transport for SM messages between the UE 1102 and the SMF 1146, and act as a transparent proxy for routing SM messages.
  • AMF 1144 may also provide transport for SMS messages between UE 1102 and an SMSF.
  • AMF 1144 may interact with the AUSF 1142 and the UE 1102 to perform various security anchor and context management functions.
  • AMF 1144 may be a termination point of a RAN CP interface, which may include or be an N2 reference point between the RAN 1104 and the AMF 1144; and the AMF 1144 may be a termination point of NAS (Nl) signaling, and perform NAS ciphering and integrity protection.
  • AMF 1144 may also support NAS signaling with the UE 1102 over an N3 IWF interface.
  • the SMF 1146 may be responsible for SM (for example, session establishment, tunnel management between UPF 1148 and AN 1108); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at UPF 1148 to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent via AMF 1144 over N2 to AN 1108; and determining SSC mode of a session.
  • SM may refer to management of a PDU session, and a PDU session or “session” may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 1102 and the data network 1136.
  • the UPF 1148 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to data network 1136, and a branching point to support multi-homed PDU session.
  • the UPF 1148 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF- to-QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering.
  • UPF 1148 may include an uplink classifier to support routing traffic flows to a data network.
  • the NSSF 1150 may select a set of network slice instances serving the UE 1102.
  • the NSSF 1150 may also determine allowed NSSAI and the mapping to the subscribed S-NSSAIs, if needed.
  • the NSSF 1150 may also determine the AMF set to be used to serve the UE 1102, or a list of candidate AMFs based on a suitable configuration and possibly by querying the NRF 1154.
  • the selection of a set of network slice instances for the UE 1102 may be triggered by the AMF 1144 with which the UE 1102 is registered by interacting with the NSSF 1150, which may lead to a change of AMF.
  • the NSSF 1150 may interact with the AMF 1144 via an N22 reference point; and may communicate with another NSSF in a visited network via an N31 reference point (not shown). Additionally, the NSSF 1150 may exhibit an Nnssf service-based interface.
  • the NEF 1152 may securely expose services and capabilities provided by 3GPP network functions for third party, internal exposure/re-exposure, AFs (e.g., AF 1160), edge computing or fog computing systems, etc.
  • the NEF 1152 may authenticate, authorize, or throttle the AFs.
  • NEF 1152 may also translate information exchanged with the AF 1160 and information exchanged with internal network functions. For example, the NEF 1152 may translate between an AF-Service-Identifier and an internal 5GC information.
  • NEF 1152 may also receive information from other NFs based on exposed capabilities of other NFs. This information may be stored at the NEF 1152 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 1152 to other NFs and AFs, or used for other purposes such as analytics. Additionally, the NEF 1152 may exhibit an Nnef servicebased interface.
  • the NRF 1154 may support service discovery functions, receive NF discovery requests from NF instances, and provide the information of the discovered NF instances to the NF instances. NRF 1154 also maintains information of available NF instances and their supported services. As used herein, the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. Additionally, the NRF 1154 may exhibit the Nnrf service-based interface.
  • the PCF 1156 may provide policy rules to control plane functions to enforce them, and may also support unified policy framework to govern network behavior.
  • the PCF 1156 may also implement a front end to access subscription information relevant for policy decisions in a UDR of the UDM 1158.
  • the PCF 1156 exhibit an Npcf service-based interface.
  • the UDM 1158 may handle subscription-related information to support the network entities’ handling of communication sessions, and may store subscription data of UE 1102. For example, subscription data may be communicated via an N8 reference point between the UDM 1158 and the AMF 1144.
  • the UDM 1158 may include two parts, an application front end and a UDR.
  • the UDR may store subscription data and policy data for the UDM 1158 and the PCF 1156, and/or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 1102) for the NEF 1152.
  • TheNudr service-based interface may be exhibited by the UDR 221 to allow the UDM 1158, PCF 1156, and NEF 1152 to access a particular set of the stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notification of relevant data changes in the UDR.
  • the UDM may include a UDM- FE, which is in charge of processing credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions.
  • the UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, registration/mobility management, and subscription management.
  • the UDM 1158 may exhibit the Nudm service-based interface.
  • the AF 1160 may provide application influence on traffic routing, provide access to NEF, and interact with the policy framework for policy control.
  • the 5GC 1140 may enable edge computing by selecting operator/3 rd party services to be geographically close to a point that the UE 1102 is attached to the network. This may reduce latency and load on the network.
  • the 5GC 1140 may select a UPF 1148 close to the UE 1102 and execute traffic steering from the UPF 1148 to data network 1136 via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by the AF 1160. In this way, the AF 1160 may influence UPF (re)selection and traffic routing.
  • the network operator may permit AF 1160 to interact directly with relevant NFs. Additionally, the AF 1160 may exhibit an Naf service-based interface.
  • the data network 1136 may represent various network operator services, Internet access, or third party services that may be provided by one or more servers including, for example, application/content server 1138.
  • FIG 12 schematically illustrates a wireless network 1200 in accordance with various embodiments.
  • the wireless network 1200 may include a UE 1202 in wireless communication with an AN 1204.
  • the UE 1202 and AN 1204 may be similar to, and substantially interchangeable with, like-named components described elsewhere herein.
  • the UE 1202 may be communicatively coupled with the AN 1204 via connection 1206.
  • connection 1206 is illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols such as an LTE protocol or a 5G NR. protocol operating at mmWave or sub-6GHz frequencies.
  • cellular communications protocols such as an LTE protocol or a 5G NR. protocol operating at mmWave or sub-6GHz frequencies.
  • the UE 1202 may include a host platform 1208 coupled with a modem platform 1210.
  • the host platform 1208 may include application processing circuitry 1212, which may be coupled with protocol processing circuitry 1214 of the modem platform 1210.
  • the application processing circuitry 1212 may run various applications for the UE 1202 that source/sink application data.
  • the application processing circuitry 1212 may further implement one or more layer operations to transmit/receive application data to/from a data network. These layer operations may include transport (for example UDP) and Internet (for example, IP) operations
  • the protocol processing circuitry 1214 may implement one or more of layer operations to facilitate transmission or reception of data over the connection 1206.
  • the layer operations implemented by the protocol processing circuitry 1214 may include, for example, MAC, RLC, PDCP, RRC and NAS operations.
  • the modem platform 1210 may further include digital baseband circuitry 1216 that may implement one or more layer operations that are “below” layer operations performed by the protocol processing circuitry 1214 in a network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/de-mapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, which may include one or more of space-time, space-frequency or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.
  • PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/de-mapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, which may
  • the modem platform 1210 may further include transmit circuitry 1218, receive circuitry 1220, RF circuitry 1222, and RF front end (RFFE) 1224, which may include or connect to one or more antenna panels 1226.
  • the transmit circuitry 1218 may include a digital-to-analog converter, mixer, intermediate frequency (IF) components, etc.
  • the receive circuitry 1220 may include an analog-to-digital converter, mixer, IF components, etc.
  • the RF circuitry 1222 may include a low-noise amplifier, a power amplifier, power tracking components, etc.
  • RFFE 1224 may include filters (for example, surface/bulk acoustic wave filters), switches, antenna tuners, beamforming components (for example, phase-array antenna components), etc.
  • transmit/receive components may be specific to details of a specific implementation such as, for example, whether communication is TDM or FDM, in mmWave or sub-6 gHz frequencies, etc.
  • the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be disposed in the same or different chips/modules, etc.
  • the protocol processing circuitry 1214 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit/receive components.
  • a UE reception may be established by and via the antenna panels 1226, RFFE 1224, RF circuitry 1222, receive circuitry 1220, digital baseband circuitry 1216, and protocol processing circuitry 1214.
  • the antenna panels 1226 may receive a transmission from the AN 1204 by receive-beamforming signals received by a plurality of antennas/antenna elements of the one or more antenna panels 1226.
  • a UE transmission may be established by and via the protocol processing circuitry 1214, digital baseband circuitry 1216, transmit circuitry 1218, RF circuitry 1222, RFFE 1224, and antenna panels 1226.
  • the transmit components of the UE 1204 may apply a spatial filter to the data to be transmitted to form a transmit beam emitted by the antenna elements of the antenna panels 1226.
  • the AN 1204 may include a host platform 1228 coupled with a modem platform 1230.
  • the host platform 1228 may include application processing circuitry 1232 coupled with protocol processing circuitry 1234 of the modem platform 1230.
  • the modem platform may further include digital baseband circuitry 1236, transmit circuitry 1238, receive circuitry 1240, RF circuitry 1242, RFFE circuitry 1244, and antenna panels 1246.
  • the components of the AN 1204 may be similar to and substantially interchangeable with like- named components of the UE 1202.
  • the components of the AN 1208 may perform various logical functions that include, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.
  • Figure 13 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.
  • Figure 13 shows a diagrammatic representation of hardware resources 1300 including one or more processors (or processor cores) 1310, one or more memory/storage devices 1320, and one or more communication resources 1330, each of which may be communicatively coupled via a bus 1340 or other interface circuitry.
  • a hypervisor 1302 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1300.
  • the processors 1310 may include, for example, a processor 1312 and a processor 1314.
  • the processors 1310 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radiofrequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.
  • CPU central processing unit
  • RISC reduced instruction set computing
  • CISC complex instruction set computing
  • GPU graphics processing unit
  • DSP such as a baseband processor, an ASIC, an FPGA, a radiofrequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.
  • the memory/storage devices 1320 may include main memory, disk storage, or any suitable combination thereof.
  • the memory/storage devices 1320 may include, but are not limited to, any type of volatile, non-volatile, or semi-volatile memory such as 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 storage, etc.
  • DRAM dynamic random access memory
  • SRAM static random access memory
  • EPROM erasable programmable read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • Flash memory solid-state storage, etc.
  • the communication resources 1330 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 1304 or one or more databases 1306 or other network elements via a network 1308.
  • the communication resources 1330 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communication components.
  • Instructions 1350 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1310 to perform any one or more of the methodologies discussed herein.
  • the instructions 1350 may reside, completely or partially, within at least one of the processors 1310 (e.g., within the processor’s cache memory), the memory/storage devices 1320, or any suitable combination thereof.
  • any portion of the instructions 1350 may be transferred to the hardware resources 1300 from any combination of the peripheral devices 1304 or the databases 1306. Accordingly, the memory of processors 1310, the memory/storage devices 1320, the peripheral devices 1304, and the databases 1306 are examples of computer-readable and machine-readable media.
  • the electronic device(s), network(s), system(s), chip(s) or component(s), or portions or implementations thereof, of Figures 11-13, or some other figure herein may be configured to perform one or more processes, techniques, or methods as described herein, or portions thereof.
  • One such process is depicted in Figure 14.
  • the process of Figure 14 may be performed by a UE or a portion thereof.
  • the process may include, at 1402, determining that the UE is out of coverage of a wireless cellular network.
  • the process may further include entering a radio resource control (RRC) inactive state based on the determination.
  • RRC radio resource control
  • the RRC inactive state entered by the UE based on the determination may be an RRC inactive out-of-coverage state may be different than an RRC inactive in-coverage state.
  • the UE may monitor for broadcast signals and/or paging messages while in the RRC inactive in-coverage state but not while in the RRC inactive out-of- coverage state.
  • the UE and/or network e.g., gNB
  • the UE may enter the RRC Inactive state (e.g., without a bifurcation of two separate inactive states for out-of-coverage and in-coverage) when the UE goes out of coverage.
  • the UE may request extension of an RNA update timer (e.g., to infinity) prior to entering the RRC Inactive state.
  • the UE may determine that it has re-entered coverage of the wireless cellular network and may send an RRC message to a gNB to re-establish an RRC connected state based on the determination.
  • Figure 15 illustrates another process in accordance with various embodiments. In some embodiments, the process of Figure 15 may be performed by a gNB or a portion thereof.
  • the process may include determining that a UE is out of coverage of a wireless cellular network and will enter a radio resource control (RRC) inactive state.
  • RRC radio resource control
  • the process may further include maintaining UE context information while the UE is in the RRC inactive state.
  • the RRC inactive state entered by the UE when out of coverage may be an RRC inactive out-of-coverage state that is different than an RRC inactive in-coverage state.
  • the UE may monitor for broadcast signals and/or paging messages while in the RRC inactive in-coverage state but not while in the RRC inactive out-of-coverage state.
  • the UE may enter the RRC Inactive state (e.g., without a bifurcation of two separate inactive states for out-of-coverage and in-coverage) when the UE goes out of coverage.
  • the gNB may receive a request from the UE to extend an RNA update timer (e.g., to infinity) prior to entering the RRC Inactive state.
  • the gNB may receive an RRC message from the UE to re-establish an RRC connected state (e.g., when the UE has re-entered coverage of the wireless cellular network).
  • Figure 16 illustrates another process in accordance with various embodiments.
  • the process of Figure 16 may be performed by a user equipment (UE) or a portion thereof.
  • the process may include, at 1602, receiving, from a next generation Node B (gNB) while in an RRC IDLE state, a resource allocation for a radio resource control (RRC) setup request message.
  • the resource allocation may be received as part of a random access channel (RACH) procedure, e.g., in a random access response message in response to a random access request transmitted by the UE.
  • RACH random access channel
  • the process may further include sending, to the gNB, the RRC setup request message and uplink data using the resource allocation.
  • Figure 17 illustrates another process in accordance with various embodiments.
  • the process of Figure 17 may be performed by a gNB or a portion thereof.
  • the process of Figure 17 may be performed by a gNB distributed unit (gNB-DU).
  • gNB-DU gNB distributed unit
  • the process may include receiving, from a user equipment (UE) in an RRC IDLE state, a message that includes a radio resource control (RRC) service request message and uplink data.
  • the process may further include buffering the uplink data.
  • the process may further include receiving context information associated with the UE.
  • the process may further include forwarding the buffered uplink data based on the context information.
  • at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth in the example section below.
  • the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below.
  • circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.
  • Example Al may include a method in which the RRC INACTIVE state is evolved and extended to avoid the connection-related latency, in consideration of limited coverage availability in futuristic sparse-coverage deployments.
  • Example A2 may include the method of example Al or some other example herein, wherein RRC INACTIVE state is split to two sub-states, one for in-coverage and one for out-of- coverage operation.
  • the in-coverage sub-state follows the current NR RRC -INACTIVE behavior.
  • the main difference is that the UE is not expected to monitor broadcast signals, paging, etc.
  • the main characteristic of the RRC INACTIVE out-of-coverage state is support of different behavior with respect to identifying cells, performing cell search, etc.
  • the network does not release the UE context/configurations (UE maintains context, last connected cell, time stamp/location for when it goes out of coverage).
  • Example A3 may include the method of examples Al, A2, or some other example herein, wherein, the transition from RRC INACTIVE out-of-coverage to RRC INACTIVE incoverage can take place via an RRC message when the UE is back in coverage (e.g., without involving the core network)
  • Example A4 may include the method and procedure in which RRC INACTIVE state is set as the reset/initial state, e.g., when UE goes to out-of-coverage and comes back to the network coverage, it is still maintained in the RRC INACTIVE state.
  • Example A5 may include the method of example A4 or some other example herein, wherein when the UE is in RRC_CONNECTED state, the gNB may (dynamically) save/store the configuration, and if (unrecoverable) RLF happens, the UE enters the RRC INACTIVE state (with the stored configuration/context) and the network may also store UE’s context for a certain albeit long period of time.
  • Example A6 may include the method of example A4 or some other example herein, wherein UE assistance information may be introduced in which, the UE indicates that it wants to be configured by infinity RNA periodic update, e.g., depending on the deployment, type of device, mobility, etc. (when the UE knows it is likely to go out of the network coverage). Such indication may be carried in the capability signaling, in the establishment request, or it could be an independent UE assistance information.
  • Example A7 may include the method of example A6 or some other example herein, wherein a UE initiated configuration/behavior is defined to enable the mechanism.
  • the network may also inform the UEs under its service if its deployment does not provide full coverage, e.g., several coverage holes exists by deployment, and may enable proper configurations from the beginning of the service.
  • higher frequency bands e.g., mmWave or THz
  • both the network and the UE can expect experiencing potential outages/blockages (especially with UE mobility and/or sparse network deployments), proper configurations can be enabled from the beginning of the service.
  • Example A8 may include the method of example A4 or some other example herein, wherein a UE in vicinity (of the UE going out of coverage) can be introduced/configured to perform the keepalive approach by informing the gNB about the existence of the UE.
  • Example A9 may include the method of example A8 or some other example herein, wherein the UE without connectivity to the network can let a designated UE know that it is still under the serving gNB, in the same cell coverage. The designated UE can then update the gNB about the out-of-coverage UE status (and send an ACK information to the UE, for example using Sidelink), when the target UE is no able to do so. The designated UE maintains the target UE context in the RAN levels, since the target UE may be out of coverage for a long period of time, and it is desired to avoid the target UE being sent to RRC IDLE state.
  • Example A10 may include the method of example A8 or some other example herein, wherein when the UE provides UE assistance information or has capability indication that requests the RNAU update timer to be infinity, then the network can configure the UE to act in Mobile Initiated RRC INACTIVE state wherein, the core network is made aware that the UE is in CM CONNECTED/RRC INACTIVE state but can only perform Mobile originated traffic. Any downlink traffic can then be buffered at the UPF.
  • Example Al 1 may include a method of a UE, the method comprising: determining that the UE is out of coverage of a wireless cellular network; and entering a radio resource control (RRC) inactive out-of-coverage state based on the determination.
  • Example A12 may include the method of example Al 1 or some other example herein, wherein the UE does not monitor for broadcast signals and/or paging messages while in the RRC inactive out-of-coverage state.
  • Example A13 may include the method of example Al 1-A12 or some other example herein, further comprising maintaining UE context information while in the RRC inactive out- of-coverage state.
  • Example A14 may include the method of example A13 or some other example herein, wherein the UE context information includes one or more of a last connected cell, a time stamp, and/or a location corresponding to the determination that the UE is out of coverage.
  • Example A15 may include the method of example Al 1-A14 or some other example herein, wherein the UE enters the RRC inactive out-of-coverage state from a RRC inactive incoverage state.
  • Example A16 may include the method of example Al 1-A14 or some other example herein, wherein the UE enters the RRC inactive out-of-coverage state from an RRC connected state.
  • Example Al 7 may include the method of example Al 1 -Al 6 or some other example herein, further comprising determining that the UE has re-entered coverage of the wireless cellular network; and sending an RRC signaling message to a gNB to enter an RRC connected state based on the determination that the UE has re-entered coverage.
  • Example Al 8 may include a method of a UE, the method comprising: determining that the UE is out of coverage of a wireless cellular network; and entering an RRC inactive state based on the determination.
  • Example Al 9 may include the method of example Al 8 or some other example herein, further comprising maintaining UE context information while in the RRC inactive state.
  • Example A20 may include the method of example Al 9 or some other example herein, wherein the UE context information includes one or more of a last connected cell, a time stamp, and/or a location corresponding to the determination that the UE is out of coverage.
  • Example A21 may include the method of example A18-A20 or some other example herein, wherein the determination that the UE is out of coverage is based on one or more radio link failures (RLFs).
  • RLFs radio link failures
  • Example A22 may include the method of example A18-A21 or some other example herein, wherein the UE enters the RRC inactive state from an RRC connected state.
  • Example A23 may include the method of example Al 1 -Al 6 or some other example herein, further comprising determining that the UE has re-entered coverage of the wireless cellular network; and sending an RRC signaling message to a gNB to enter an RRC connected state based on the determination that the UE has re-entered coverage.
  • Example A24 may include a method of a UE, the method comprising: sending, to a gNB, UE assistance information including a request to extend a timer for a periodic radio access network (RAN) network area (RNA) update; and receiving, from the gNB based on the request, an indicator to configure a value the timer.
  • RAN radio access network
  • RNA network area
  • Example A25 may include the method of example A24 or some other example herein, wherein the value is infinity.
  • Example A26 may include the method of example A24-A25 or some other example herein, further comprising determining that the UE is to or is likely to go out of coverage of a wireless cellular network associated with the gNB, wherein the request is sent based on the determination.
  • Example A27 may include a method of a gNB, the method comprising: determining that a UE is out of coverage of a wireless cellular network and will enter a radio resource control (RRC) inactive out-of-coverage state; and maintaining UE context information while the UE is in the RRC inactive out-of-coverage state.
  • RRC radio resource control
  • Example A28 may include the method of example A27 or some other example herein, wherein the UE context information is maintained until expiration of a timer.
  • Example A29 may include the method of example A27-A28 or some other example herein, wherein the UE does not monitor for broadcast signals and/or paging messages while in the RRC inactive out-of-coverage state.
  • Example A30 may include the method of example A27-A29 or some other example herein, wherein the UE enters the RRC inactive out-of-coverage state from a RRC inactive incoverage state.
  • Example A31 may include the method of example A27-A29 or some other example herein, wherein the UE enters the RRC inactive out-of-coverage state from an RRC connected state.
  • Example A32 may include the method of example A27-A31 or some other example herein, further comprising: receiving an RRC signaling message from the UE to re-establish a RRC connected state; and entering an RRC connected state with the UE based on the RRC signal.
  • Example A33 may include a method of a gNB, the method comprising: determining that a UE is out of coverage of a wireless cellular network and will enter a radio resource control (RRC) inactive state; and maintaining UE context information while the UE is in the RRC inactive state.
  • RRC radio resource control
  • Example A34 may include the method of example A33 or some other example herein, wherein the UE context information is maintained until expiration of a timer.
  • Example A35 may include the method of example A33-A34 or some other example herein, wherein the determination is based on one or more radio link failures (RLFs).
  • RLFs radio link failures
  • Example A36 may include the method of example A33 -A35 or some other example herein, wherein the UE enters the RRC inactive out-of-coverage state from a RRC inactive incoverage state.
  • Example A37 may include the method of example A33 -A35 or some other example herein, wherein the UE enters the RRC inactive out-of-coverage state from an RRC connected state.
  • Example A38 may include the method of example A33 -A37 or some other example herein, further comprising: receiving an RRC signaling message from the UE to re-establish a RRC connected state; and entering an RRC connected state with the UE based on the RRC signal.
  • Example A39 may include a method of a gNB, the method comprising: receiving, from a UE, UE assistance information including a request to extend a timer for a periodic radio access network (RAN) network area (RNA) update; and sending, to the UE based on the request, an indicator to configure a value the timer.
  • RAN radio access network
  • RNA network area
  • Example A40 may include the method of example A39 or some other example herein, wherein the value is infinity.
  • Example Bl may include a method in which a UE in RRC IDLE is in high frequency next generation cellular network has limited coverage and needs to send uplink data.
  • Example B2 may include the method of example Bl or some other example herein, wherein the network differentiates UEs requiring quick access through RACH or other indication and provides larger grant for first RRC message.
  • Example B3 may include the method of examples Bl, B2, or some other example herein, wherein the UE utilizes the larger grant to send necessary NAS service request message and uplink data.
  • Example B4 may include the method of example B3 or some other example herein, wherein the UE uses stored or preconfigured security settings for both NAS and data.
  • Example B5 may include the method of example B3 or some other example herein, wherein the UE uses stored or preconfigured settings for RLC bearer of the uplink data.
  • Example B6 may include the method of example B3 or some other example herein, wherein the UE uses default configuration for PHY settings to send data.
  • Example B7 may include the method of example B2 or some other example herein, wherein the network/RAN, specifically the DU, stores the received uplink data until it fetches the context from the CU and/or core network.
  • Example B8 may include the method of example B2 or some other example herein, wherein the DU processes the buffered data once context is available and forwards it towards the core network (e.g., to the CU and then the core network).
  • Example B9 may include the method of example B2 or some other example herein, wherein the RAN/network performs combined RRC message transmission e.g. including RRC Setup, SMC and Reconfiguration along with another grant for data if necessary towards the UE of example 1.
  • RRC message transmission e.g. including RRC Setup, SMC and Reconfiguration along with another grant for data if necessary towards the UE of example 1.
  • Example B10 may include the method of example Bl or some other example herein, wherein the UE sends response message with updated service request message and more data if available.
  • Example Bl 1 may include a method of a UE, the method comprising: receiving, from a next generation Node B (gNB) while in an RRC IDLE state, a resource allocation for a radio resource control (RRC) setup request message; and sending, to the gNB, the RRC setup request message and uplink data using the resource allocation.
  • gNB next generation Node B
  • RRC radio resource control
  • Example B12 may include the method of example Bl 1 or some other example herein, wherein the RRC setup request message is in a Msg3 of a random access channel (RACH) procedure.
  • RACH random access channel
  • Example B13 may include the method of example Bl 1-B 12 or some other example herein, wherein the RRC setup request message is included in a non-access stratum (NAS) message.
  • NAS non-access stratum
  • Example B14 may include the method of example Bl 1-B 13 or some other example herein, further comprising using stored or preconfigured security settings for the RRC setup request message and the uplink data.
  • Example B15 may include the method of example Bl 1-B 14 or some other example herein, further comprising using stored or preconfigured settings for an RLC bearer of the uplink data.
  • Example B16 may include the method of example Bl 1-B 15 or some other example herein, further comprising using a default configuration for PHY settings to send the uplink data.
  • Example B17 may include the method of example Bl 1-B 16 or some other example herein, further comprising: receiving, from the gNB, an RRC Setup Response message; and sending an RRC Setup Complete Message to the gNB based on the RRC Setup Response message, wherein the RRC Setup Complete Message includes additional uplink data.
  • Example B18 may include the method of example B 17 or some other example herein, wherein the RRC Setup Response Message is received with an updated security command message and/or an RRC reconfiguration message.
  • Example B19 may include a method of a next generation Node B (gNB), the method comprising: receiving, from a user equipment (UE) in an RRC IDLE state, a message that includes a radio resource control (RRC) service request message and uplink data; buffering the uplink data; receiving context information associated with the UE; and forwarding the buffered uplink data based on the context information.
  • gNB next generation Node B
  • Example B20 may include the method of example B 19 or some other example herein, further comprising sending a response message to the UE, wherein the response message includes a RRC Setup Response Message and includes one or more of an updated security command message, an RRC reconfiguration message, and/or a resource allocation for additional data.
  • the response message includes a RRC Setup Response Message and includes one or more of an updated security command message, an RRC reconfiguration message, and/or a resource allocation for additional data.
  • Example B21 may include the method of example Bl 9-B20 or some other example herein, further comprising determining a resource allocation for the message that includes the RRC service request message and the uplink data; and sending an indication of the resource allocation to the UE.
  • Example B22 may include the method of example B21 or some other example herein, wherein the resource allocation is determined based on a determination that the UE is of a first type that requires low latency delivery of uplink data.
  • Example B23 may include the method of example Bl 9-B22 or some other example herein, wherein the message is a non-access stratum (NAS) message.
  • NAS non-access stratum
  • Example B24 may include the method of example Bl 9-B23 or some other example herein, wherein the uplink data is forwarded to a core network.
  • Example B25 may include the method of example Bl 9-B24 or some other example herein, wherein the method is performed by a gNB distributed unit (gNB -DU).
  • Example B26 may include the method of example B25 or some other example herein, wherein the gNB-DU is to forward the uplink data to a gNB centralized unit (gNB-CU).
  • gNB-CU gNB centralized unit
  • Example Cl may include one or more non-transitory computer-readable media (NTCRM) having instructions, stored thereon, that when executed by one or more processors of a user equipment (UE) cause the UE to: determine that the UE is out of coverage of a wireless cellular network; and enter a first inactive state, from a radio resource control (RRC) inactive state or an RRC connected state, based on the determination.
  • NCRM non-transitory computer-readable media
  • Example C2 may include the one or more NTCRM of example Cl, wherein the instructions, when executed, are further to cause the UE to maintain UE context information while in the first inactive state.
  • Example C3 may include the one or more NTCRM of example C2, wherein the UE context information includes one or more of a last connected cell, a time stamp, or a location corresponding to the determination that the UE is out of coverage.
  • Example C4 may include the one or more NTCRM of examples C1-C3, wherein the determination that the UE is out of coverage is based on one or more radio link failures (RLFs).
  • RLFs radio link failures
  • Example C5 may include the one or more NTCRM of examples C1-C4, wherein the instructions, when executed, are further to cause the UE to: determine that the UE has re-entered coverage of the wireless cellular network; and send an RRC message to a next generation Node B (gNB) to enter the RRC connected state based on the determination that the UE has re-entered coverage.
  • gNB next generation Node B
  • Example C6 may include the one or more NTCRM of examples C1-C5, wherein the instructions, when executed, are further to cause the UE to encode, for transmission to a next generation Node B (gNB), an indication to configure the UE with a timer for periodic radio access network (RAN) network area (RNA) updates with a value of infinity.
  • gNB next generation Node B
  • RAN radio access network
  • RNA network area
  • Example C7 may include the one or more NTCRM of examples C1-C6, wherein the UE is a first UE, and wherein a second UE is to perform a keepalive procedure or maintain the UE context information on behalf of the first UE based on the indication.
  • Example C8 may include an apparatus of a next generation Node B (gNB), the apparatus comprising: a memory to store user equipment (UE) context information associated with a UE; and one or more processors coupled to the memory.
  • the one or more processors are to: determine that a UE is out of coverage of a wireless cellular network and will enter a first inactive state from a radio resource control (RRC) inactive state or an RRC connected state; and maintain the UE context information in the memory while the UE is in the first inactive state.
  • RRC radio resource control
  • Example C9 may include the apparatus of example C8, wherein the UE context information is maintained until expiration of a timer.
  • Example CIO may include the apparatus of examples C8-C9, wherein the UE context information includes one or more of a last connected cell, a time stamp, or a location corresponding to the determination that the UE is out of coverage.
  • Example Cl 1 may include the apparatus of examples C8-C10, wherein the determination is based on one or more radio link failures (RLFs).
  • RLFs radio link failures
  • Example C12 may include the apparatus of examples C8-C11, wherein the one or more processors are further to: receive an RRC message from the UE to re-establish a RRC connected state; and enter an RRC connected state with the UE based on the RRC message and the UE context information.
  • Example C13 may include the apparatus of examples C8-C12, wherein the one or more processors are further to: receive from the UE, a request to configure the UE with a timer for periodic radio access network (RAN) network area (RNA) updates with a value of infinity.
  • RAN radio access network
  • RNA network area
  • Example C14 may include the apparatus of example Cl 3, wherein the one or more processors are further to, based on the request: configure the UE in the first inactive state, wherein the first inactive state is a UE-initiated inactive state; and inform a core network that the UE is in a CM CONNECTED state and can only communicate UE-originated traffic, to indicate that downlink traffic for the UE is to be buffered at a user plane function (UPF).
  • UPF user plane function
  • Example C15 may include the apparatus of examples C13-C14, wherein the UE is a first UE, and wherein the one or more processors are further to, based on the request, configure a second UE to perform a keepalive procedure or maintain the UE context information on behalf of the first UE.
  • Example C16 may include one or more non-transitory computer-readable media (NTCRM) having instructions, stored thereon, that when executed by one or more processors of a user equipment (UE) cause the UE to: receive, from a next generation Node B (gNB) while in an RRC IDLE state, a resource allocation for a radio resource control (RRC) setup request message; and send, to the gNB, the RRC setup request message and uplink data using the resource allocation.
  • NCRM non-transitory computer-readable media
  • Example C17 may include the one or more NTCRM of example Cl 6, wherein the RRC setup request message is in a Msg3 of a random access channel (RACH) procedure.
  • RACH random access channel
  • Example Cl 8 may include the one or more NTCRM of examples C16-C17, wherein the instructions are further to cause the UE to send a non-access stratum (NAS) setup message using the resource allocation.
  • NAS non-access stratum
  • Example C19 may include the one or more NTCRM of examples C16-C18, wherein the UE is to use stored or preconfigured security settings for the RRC setup request message and the uplink data.
  • Example C20 may include the one or more NTCRM of examples C16-C19, wherein the instructions, when executed, are further to cause the UE to use stored or preconfigured settings for an RLC bearer of the uplink data.
  • Example C21 may include the one or more NTCRM of examples C16-C20, wherein the instructions, when executed, are further to cause the UE to use a default configuration for PHY settings to send the uplink data.
  • Example C22 may include the one or more NTCRM of examples C16-C21, wherein the instructions, when executed, are further to cause the UE to: receive, from the gNB, an RRC Setup Response message; and send an RRC Setup Complete Message to the gNB based on the RRC Setup Response message, wherein the RRC Setup Complete Message includes additional uplink data.
  • Example C23 may include the one or more NTCRM of example C22, wherein the RRC Setup Response Message is received with an updated security command message or an RRC reconfiguration message.
  • Example Z01 may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples A1-A40, B1-B26, C1-C23, or any other method or process described herein.
  • Example Z02 may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples A1-A40, B1-B26, C1-C23, or any other method or process described herein.
  • Example Z03 may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples A1-A40, B1-B26, C1-C23, or any other method or process described herein.
  • Example Z04 may include a method, technique, or process as described in or related to any of examples A1-A40, B1-B26, C1-C23, or portions or parts thereof.
  • Example Z05 may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples A1-A40, B1-B26, C1-C23, or portions thereof.
  • Example Z06 may include a signal as described in or related to any of examples A1-A40, B1-B26, C1-C23, or portions or parts thereof.
  • Example Z07 may include a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of examples A1-A40, B1-B26, C1-C23, or portions or parts thereof, or otherwise described in the present disclosure.
  • PDU protocol data unit
  • Example Z08 may include a signal encoded with data as described in or related to any of examples A1-A40, B1-B26, C1-C23, or portions or parts thereof, or otherwise described in the present disclosure.
  • Example Z09 may include a signal encoded with a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of examples A1-A40, Bl- B26, C1-C23, or portions or parts thereof, or otherwise described in the present disclosure.
  • PDU protocol data unit
  • Example Z10 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples A1-A40, B1-B26, C1-C23, or portions thereof.
  • Example Z11 may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples A1-A40, Bl- B26, C1-C23, or portions thereof.
  • Example Z12 may include a signal in a wireless network as shown and described herein.
  • Example Z13 may include a method of communicating in a wireless network as shown and described herein.
  • Example Z14 may include a system for providing wireless communication as shown and described herein.
  • Example Z15 may include a device for providing wireless communication as shown and described herein.
  • EPDCCH interface Enhanced CCE 70 enhanced FACCH Fast 35 FEC Forward Error Satellite
  • FCCH Frequency RAN GSM EDGE Mobile
  • Protocol Version 4 40 authentication 75 LLC Logical Link IPv6 Internet key Control, Low Layer Protocol Version 6 KPI Key Compatibility IR Infrared Performance Indicator LPLMN Local IS In Sync KQI Key Quality PLMN
  • IRP Integration 45 Indicator 80 LPP LTE Reference Point KSI Key Set Positioning Protocol ISDN Integrated Identifier LSB Least Services Digital ksps kilo-symbols Significant Bit Network per second LTE Long Term
  • Interworking 60 (network layer) 95 Machine WLAN LAA Licensed MAC Medium Access
  • Non- Standalone 40 EXpense Convergence operation mode OSI Other System Protocol, Packet NSD Network Information 75 Data Convergence Service Descriptor OSS Operations Protocol layer NSR Network Support System PDCCH Physical Service Record 45 OTA over-the-air Downlink Control NSSAINetwork Slice PAPR Peak-to- Channel Selection Average Power 80 PDCP Packet Data
  • NSSF Network Slice Broadcast Channel 85 PDSCH Physical Selection Function PC Power Control, Downlink Shared NW Network Personal Channel NWU S N arrowb and 55 Computer PDU Protocol Data wake-up signal, PCC Primary Unit N arrowb and WU S Component Carrier, 90 PEI Permanent NZP Non-Zero Primary CC Equipment Power PCell Primary Cell Identifiers
  • ODU2 Optical channel Identity 95 P-GW PDN Gateway Data Unit - type 2 PCEF Policy and PHICH Physical OFDM Orthogonal Charging hybrid-ARQ indicator Frequency Division 65 Enforcement channel Multiplexing Function PHY Physical layer OFDMA PCF Policy Control 100 PLMN Public Land
  • Network Function 40 Channel 75 QoS Quality of
  • PRB Physical 55 Telephone Network 90 Authentication Dial resource block PT-RS Phase-tracking In User Service PRG Physical reference signal RAN Radio Access resource block PTT Push-to-Talk Network group PUCCH Physical RAND RANDom ProSe Proximity 60 Uplink Control 95 number (used for Services, Channel authentication)
  • Radio Modulation Update PS Packet Services QCI QoS class of RB Resource block, identifier Radio Bearer RBG Resource block System RTS Ready-To-Send group Information RTT Round Trip REG Resource RN Relay Node Time Element Group RNC Radio Network Rx Reception, Rel Release 40 Controller 75 Receiving, Receiver REQ REQuest RNL Radio Network S1AP SI Application RF Radio Layer Protocol Frequency RNTI Radio Network Sl-MME SI for RI Rank Indicator Temporary the control plane RIV Resource 45 Identifier 80 Sl-U SI for the user indicator value ROHC RObust Header plane RL Radio Link Compression S-GW Serving RLC Radio Link RRC Radio Resource Gateway Control, Radio Control, Radio S-RNTI SRNC
  • Link Control 50 Resource Control 85 Radi o N etwork layer layer Temporary RLC AM RLC RRM Radio Resource Identity Acknowledged Mode Management S-TMSI SAE RLC UM RLC RS Reference Temporary Mobile Unacknowledged 55 Signal 90 Station Mode RSRP Reference Identifier RLF Radio Link Signal Received SA Standalone Failure Power operation mode
  • Protocol 50 SGSN Serving GPRS 85 SpCell Special Cell
  • Storage Network 60 SIM Subscriber 95 Radio Bearer
  • Storage Function 65 Package 100 SSB SS Block
  • Synchronization Protocol Technical Signal based Signal 50 TDD Time Division Standard to Noise and Duplex 85 TTI Transmission Interference Ratio TDM Time Division Time Interval SSS Secondary Multiplexing Tx Transmission, Synchronization TDMATime Division Transmitting,
  • circuitry refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e.g., 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 SoC), digital signal processors (DSPs), etc., that are configured to provide the described functionality.
  • FPD field-programmable device
  • FPGA field-programmable gate array
  • PLD programmable logic device
  • CPLD complex PLD
  • HPLD high-capacity PLD
  • DSPs digital signal processors
  • the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality.
  • the term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.
  • processor circuitry refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and/or transferring digital data.
  • Processing circuitry may include one or more processing cores to execute instructions and one or more memory structures to store program and data information.
  • processor circuitry may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computerexecutable instructions, such as program code, software modules, and/or functional processes.
  • Processing circuitry may include more hardware accelerators, which may be microprocessors, programmable processing devices, or the like.
  • the one or more hardware accelerators may include, for example, computer vision (CV) and/or deep learning (DL) accelerators.
  • CV computer vision
  • DL deep learning
  • application circuitry and/or “baseband circuitry” may be considered synonymous to, and may be referred to as, “processor circuitry.”
  • interface circuitry refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices.
  • interface circuitry may refer to one or more hardware interfaces, for example, buses, I/O interfaces, peripheral component interfaces, network interface cards, and/or the like.
  • user equipment or “UE” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network.
  • user equipment or “UE” may be considered synonymous to, and may be referred to as, 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, etc.
  • user equipment or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface.
  • network element refers to physical or virtualized equipment and/or infrastructure used to provide wired or wireless communication network services.
  • network element may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, and/or the like.
  • computer system refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” and/or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” and/or “system” may refer to multiple computer devices and/or multiple computing systems that are communicatively coupled with one another and configured to share computing and/or networking resources.
  • appliance refers to a computer device or computer system with program code (e.g., software or firmware) that is specifically designed to provide a specific computing resource.
  • program code e.g., software or firmware
  • a “virtual appliance” is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or otherwise is dedicated to provide a specific computing resource.
  • resource refers to a physical or virtual device, a physical or virtual component within a computing environment, and/or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor/CPU time, processor/CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input/output operations, ports or network sockets, channel/link allocation, throughput, memory usage, storage, network, database and applications, workload units, and/or the like.
  • a “hardware resource” may refer to compute, storage, and/or network resources provided by physical hardware element(s).
  • a “virtualized resource” may refer to compute, storage, and/or network resources provided by virtualization infrastructure to an application, device, system, etc.
  • network resource or “communication resource” may refer to resources that are accessible by computer devices/ systems via a communications network.
  • system resources may refer to any kind of shared entities to provide services, and may include computing and/or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.
  • channel refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream.
  • channel may be synonymous with and/or equivalent to “communications channel,” “data communications channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier,” “radiofrequency carrier,” and/or any other like term denoting a pathway or medium through which data is communicated.
  • link refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information.
  • instantiate refers to the creation of an instance.
  • An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.
  • Coupled may mean two or more elements are in direct physical or electrical contact with one another, may mean that two or more elements indirectly contact each other but still cooperate or interact with each other, and/or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other.
  • directly coupled may mean that two or more elements are in direct contact with one another.
  • communicatively coupled may mean that two or more elements may be in contact with one another by a means of communication including through a wire or other interconnect connection, through a wireless communication channel or link, and/or the like.
  • information element refers to a structural element containing one or more fields.
  • field refers to individual contents of an information element, or a data element that contains content.
  • SMTC refers to an SSB-based measurement timing configuration configured by SSB-MeasurementTimingConfiguration .
  • SSB refers to an SS/PBCH block.
  • Primary Cell refers to the MCG cell, operating on the primary frequency, in which the UE either performs the initial connection establishment procedure or initiates the connection re-establishment procedure.
  • Primary SCG Cell refers to the SCG cell in which the UE performs random access when performing the Reconfiguration with Sync procedure for DC operation.
  • Secondary Cell refers to a cell providing additional radio resources on top of a Special Cell for a UE configured with CA.
  • Secondary Cell Group refers to the subset of serving cells comprising the PSCell and zero or more secondary cells for a UE configured with DC.
  • Secondary Cell refers to the primary cell for a UE in RRC CONNECTED not configured with CA/DC there is only one serving cell comprising of the primary cell.
  • serving cell refers to the set of cells comprising the Special Cell(s) and all secondary cells for a UE in RRC CONNECTED configured with CA/.
  • Special Cell refers to the PCell of the MCG or the PSCell of the SCG for DC operation; otherwise, the term “Special Cell” refers to the Pcell.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Divers modes de réalisation de la présente invention concernent des améliorations apportées aux états inactif et au repos de commande de ressources radio (RRC) pour permettre une transition rapide à un état connecté RRC. Par exemple, dans certains modes de réalisation, l'état inactif RRC peut être défini en tant qu'état de repli pour l'équipement utilisateur (UE) lorsque l'UE sort de couverture. Selon certains modes de réalisation, l'état inactif RRC peut être divisé en un état en couverture inactif RRC et un état hors couverture inactif RRC. En variante, le même état inactif RRC peut être utilisé à la fois en couverture et hors couverture. Des modes de réalisation concernent en outre des techniques pour réduire la latence de transition de mode au repos à connecté pour l'UE. D'autres modes de réalisation peuvent être décrits et revendiqués.
PCT/US2021/063963 2020-12-22 2021-12-17 Améliorations apportées à des états inactifs et au repos de commande de ressources radio (rrc) et à une transition à un état connecté dans des réseaux cellulaires WO2022140170A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202063129455P 2020-12-22 2020-12-22
US63/129,455 2020-12-22
US202063131176P 2020-12-28 2020-12-28
US63/131,176 2020-12-28

Publications (1)

Publication Number Publication Date
WO2022140170A1 true WO2022140170A1 (fr) 2022-06-30

Family

ID=82158766

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2021/063963 WO2022140170A1 (fr) 2020-12-22 2021-12-17 Améliorations apportées à des états inactifs et au repos de commande de ressources radio (rrc) et à une transition à un état connecté dans des réseaux cellulaires

Country Status (1)

Country Link
WO (1) WO2022140170A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220287132A1 (en) * 2019-08-19 2022-09-08 Qualcomm Incorporated Suspend and resume techniques with radio access network (ran) and user plane function (upf) buffered downlink data for multi-usim user equipment
CN118714673A (zh) * 2024-08-28 2024-09-27 荣耀终端有限公司 数据无线承载释放方法、通信装置、通信系统及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180270894A1 (en) * 2017-03-17 2018-09-20 Ofinno Technologies, Llc Inactive State Data Forwarding
US20180270895A1 (en) * 2017-03-17 2018-09-20 Ofinno Technologies, Llc Radio Access Network Notification Area Update Failure
US20180368196A1 (en) * 2017-06-16 2018-12-20 Huawei Technologies Co., Ltd. Downlink transmission in a ran inactive mode
US20190191483A1 (en) * 2016-08-11 2019-06-20 Samsung Electronics Co., Ltd. Low power rrc operating method and device
KR20200003183A (ko) * 2017-05-05 2020-01-08 후아웨이 테크놀러지 컴퍼니 리미티드 통신 방법 및 통신 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190191483A1 (en) * 2016-08-11 2019-06-20 Samsung Electronics Co., Ltd. Low power rrc operating method and device
US20180270894A1 (en) * 2017-03-17 2018-09-20 Ofinno Technologies, Llc Inactive State Data Forwarding
US20180270895A1 (en) * 2017-03-17 2018-09-20 Ofinno Technologies, Llc Radio Access Network Notification Area Update Failure
KR20200003183A (ko) * 2017-05-05 2020-01-08 후아웨이 테크놀러지 컴퍼니 리미티드 통신 방법 및 통신 장치
US20180368196A1 (en) * 2017-06-16 2018-12-20 Huawei Technologies Co., Ltd. Downlink transmission in a ran inactive mode

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220287132A1 (en) * 2019-08-19 2022-09-08 Qualcomm Incorporated Suspend and resume techniques with radio access network (ran) and user plane function (upf) buffered downlink data for multi-usim user equipment
CN118714673A (zh) * 2024-08-28 2024-09-27 荣耀终端有限公司 数据无线承载释放方法、通信装置、通信系统及存储介质

Similar Documents

Publication Publication Date Title
US11902985B2 (en) Default PDSCH beam setting and PDCCH prioritization for multi panel reception
US20210227442A1 (en) Location-based event trigger and conditional handover
US20210243782A1 (en) Methods of enhanced sps transmission and harq feedback
US11838886B2 (en) Mechanisms for integrated access and backhaul (IAB) mobile terminal distributed unit simultaneous operation
US11910433B2 (en) Physical uplink shared channel (PUSCH) transmission scheduling for new radio (NR)
US12010540B2 (en) Coverage for physical random access channel and repetition of CSI report on PUSCH for coverage enhancement
US20230189380A1 (en) Small data exchange handling by a user equipment in inactive state
US20230037852A1 (en) Techniques for paging early indication for ue power saving in idle/inactive state
US20220272706A1 (en) Downlink control information (dci) based beam indication for wireless cellular network
US20230037090A1 (en) Per-panel power control operation for uplink in 5g systems
US20230164598A1 (en) Self-organizing network coordination and energy saving assisted by management data analytics
US11985670B2 (en) Mode-1 downlink control information transmission-reception for configured sidelink scheduling in NR V2X
US20230216639A1 (en) Srs configuration and transmission in multi-dci multi-trp and carrier aggregation
US20230163984A1 (en) User equipment (ue) route selection policy (usrp) ue in an evolved packet system (eps)
US20240237082A1 (en) Using physical random access channel (prach) to identify multiple features and combinations of features
US20240292348A1 (en) Methods and apparatus for bandwidth efficient configuration of time synchronization services in 5g systems
WO2022197678A1 (fr) Configuration de signaux de référence de sondage pour commutation d'antenne et commutation de porteuse
US20240188097A1 (en) Default beam operations for uplink transmissions
US20240155503A1 (en) Spatial relationship and power control configuration for uplink transmissions
US20240007314A1 (en) Converged charging for edge enabling resource usage and application context transfer
WO2022140170A1 (fr) Améliorations apportées à des états inactifs et au repos de commande de ressources radio (rrc) et à une transition à un état connecté dans des réseaux cellulaires
US20240236990A1 (en) Valid pdschs or puschs with multiple pdsch or pusch scheduling
US20230155781A1 (en) User equipment behavior and requirements for positioning measurement without gap
US20240236787A1 (en) User equipment (ue) switching between networks using measurement gaps
US20240155589A1 (en) Techniques for channel state information reference signal (csi-rs) transmission

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21911927

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21911927

Country of ref document: EP

Kind code of ref document: A1