Method and apparatus for enhanced recovery protection

Abstract

A communication method and system for converging a 5th-Generation (5G) communication system for supporting higher data rates beyond a 4th-Generation (4G) system with a technology for Internet of Things (IoT), are provided. The above-mentioned communication method and system include intelligent services based on 5G communication technologies and IoT-related technologies, such as smart home, smart building, smart city, smart car, connected car, health care, digital education, smart retail, security and safety services. A method, a terminal and a base station for small data transmission in a wireless communication system are provided.

Description

Technical Field

[0001] This disclosure relates to enhanced recovery protection. More specifically, this disclosure relates to backward compatibility in handling connection recovery protection and enhanced small data transfer procedures. Background Technology

[0002] To meet the increased demand for wireless data services since the deployment of 4G communication systems, efforts are underway to develop an improved 5G or near-5G communication system. Therefore, 5G or near-5G communication systems are also referred to as 'super 4G networks' or 'late LTE systems'. 5G wireless communication systems support not only lower frequency bands but also higher frequency (millimeter wave) bands, such as 10 GHz to 100 GHz, to achieve higher data rates. To reduce radio wave propagation loss and increase transmission distance, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and large antenna technology are considered in the design of 5G wireless communication systems. Furthermore, system network improvements are being developed in 5G communication systems based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, coordinated multipoint (CoMP), and receiver interference cancellation. In 5G systems, a combination of hybrid frequency shift keying (FSK) and quadrature amplitude modulation (QAM) – frequency and quadrature amplitude modulation (FQAM) – and sliding window superposition coding (SWSC) – has also been developed as advanced access technologies such as filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA).

[0003] Similarly, the internet, a human-centric connectivity network where humans generate and consume information, is now evolving into the Internet of Things (IoT), where distributed entities such as things exchange and process information without human intervention. The Internet of Everything (IoE) has also emerged, a combination of IoT technology and big data processing technology connected to cloud servers. Because IoT implementation requires technological elements such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology, sensor networks, machine-to-machine (M2M) communication, machine-type communication (MTC), and more have recently been developed. Such IoT environments can provide intelligent internet technology services that create new value for human life by collecting and analyzing data generated between connected things. In this context, IoT can be applied to multiple fields through the convergence and combination of existing information technology (IT) with various industrial applications, including smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0004] Accordingly, various efforts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, MTC, and M2M communication can be implemented through beamforming, MIMO, and array antennas. The application of cloud RAN as a means of processing these big data technologies can also be seen as an example of the convergence between 5G and IoT technologies.

[0005] In recent years, several broadband wireless technologies have been developed to meet the growing number of broadband subscribers and provide more and better applications and services, such as the following: Second-generation (2G) wireless communication systems have been developed to provide voice services while ensuring user mobility. Third-generation (3G) wireless communication systems support both voice and data services. 4G wireless communication systems have been developed to provide high-speed data services. However, 4G wireless communication systems are currently hampered by insufficient resources to meet the growing demand for high-speed data services. Therefore, 5G wireless communication systems (also known as next-generation radio or new radio (NR)) are being developed to meet the growing demand for a variety of services with diverse requirements, such as high-speed data services, supporting ultra-reliable and low-latency applications.

[0006] Furthermore, 5G wireless communication systems are expected to address diverse use cases with varying requirements in terms of data rate, latency, reliability, and mobility. However, the air interface design of 5G wireless communication systems is expected to be flexible enough to serve UEs with different capabilities depending on their use cases and the market segmentation of user equipment (UE) catering to end customers. The use cases expected to be addressed by 5G wireless communication systems include enhanced mobile broadband (eMBB), massive machine-type communications (m-MTC), and ultra-reliable low-latency communications (URLL). eMBB requirements (e.g., data rates of tens of gigabits per second, low latency, high mobility, etc.) address the market segment representing wireless broadband subscribers who require internet connectivity anytime, anywhere, and on the move. m-MTC requirements (e.g., extremely high connection density, infrequent data transmission, extremely long battery life, low mobility addresses, etc.) address the market segment representing IoT / IoE connectivity for hundreds of millions of devices. URLL requirements (e.g., extremely low latency, extremely high reliability, variable mobility, etc.) address market segments representing industrial automation applications and vehicle-to-vehicle / vehicle-to-infrastructure communication (which is foreseeable as one of the driving forces of autonomous vehicles).

[0007] 5G wireless communication systems support standalone operation mode and dual connectivity (DC). In DC, a multi-receive (Rx) / transmit (Tx) UE can be configured to utilize resources provided by two different nodes (or Node Bs (NBs)) via a non-ideal backhaul connection. One node acts as the primary node (MN), and the other acts as the secondary node (SN). The MN and SN are connected via a network interface, and at least the MN is connected to the core network. NR also supports Multi-Radio Access Technology (RAT) DC (MR-DC) operation, which configures a UE in Radio Resource Control (RRC)_CONNECTED mode to utilize radio resources provided by two different schedulers located in two different nodes via a non-ideal backhaul connection, providing Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (E-UTRA) (i.e., if the node is a Next Generation Evolution Node B (ng-eNB)) or NR access (i.e., if the node is a Next Generation Node B (gNB)).

[0008] In NR, for a UE in RRC_CONNECTED without carrier aggregation (CA) / DC configured, there is only one serving cell, which includes the primary cell (PCell). For a UE in RRC_CONNECTED with CA / DC configured, the term 'serving cell' is used to refer to the set of cells including one or more special cells (SpCell) and all secondary cells (SCell).

[0009] In NR, the term 'Primary Cell Group (MCG)' refers to the serving cell group associated with the MN, which includes a PCell and optionally one or more SCells. In NR, the term 'Secondary Cell Group (SCG)' refers to the serving cell group associated with the SN, which includes the primary SCG cell (PSCell) and optionally one or more SCells. In NR, a PCell refers to the serving cell in the MCG operating at the primary frequency on which the UE performs an initial connection establishment procedure or initiates a connection re-establishment procedure. In NR, for a UE configured with CA, an Scell ​​is a cell that provides additional radio resources above an SpCell. A PSCell refers to the serving cell in the SCG where the UE performs random access (RA) during a reconfiguration with a synchronization procedure. For DC operation, the term 'SpCell' refers to either the PCell of the MCG or the PSCell of the SCG; otherwise, the term 'SpCell' refers to the PCell.

[0010] In 5G wireless communication systems, the Physical Downlink (DL) Control Channel (PDCCH) is used to schedule DL transmissions on the Physical DL Shared Channel (PDSCH) and uplink (UL) transmissions on the PUSCH. The DL Control Information (DCI) on the PDCCH includes: DL allocation containing at least modulation and coding formats, resource allocation, and Hybrid Automatic Repeat Request (HARQ) information related to the DL-SCH; or UL scheduling permission containing at least modulation and coding formats, resource allocation, and HARQ information related to the UL-SCH. In addition to scheduling, PDCCH can also be used for: activating and deactivating configured PUSCH transmissions with configured permissions; activating and deactivating PDSCH semi-persistent transmissions; notifying one or more UEs of slot formats; notifying one or more UEs of Physical Resource Blocks (PRBs) and Orthogonal Frequency Division Multiplexing (OFDM) symbols, where the UE may assume there are no transmissions for the UE; transmitting TX Power Control (TPC) commands for Physical UL Control Channel (PUCCH) and PUSCH; transmitting one or more TPC commands for semi-persistent scheduling (SRS) transmissions performed by one or more UEs; switching the Active Bandwidth Part (BWP) of a UE; or initiating a RA procedure. Depending on the corresponding search space configuration, the UE monitors the PDCCH candidate set during the configured monitoring time in one or more configured control resource sets (CORESETs). A CORESET consists of a set of PRBs with a duration of 1 to 3 OFDM symbols. Within a CORESET are defined Resource Elements Groups (REGs) and Control Channel Elements (CCEs), each CCE consisting of a set of REGs. Control channels are formed by the aggregation of CCEs. Different code rates for the control channel are achieved by aggregating different numbers of CCEs. CORESET supports interleaved and non-interleaved mapping of CCEs to REGs. Polarity coding is used for the PDCCH. Each REG carrying the PDCCH carries its own demodulation reference signal (DMRS). Quadrature phase shift keying (QPSK) is modulated for the PDCCH.

[0011] In 5G wireless communication systems, for each configured BWP, the gNB signals a list of search space configurations, where each search configuration is uniquely identified by an identifier (ID). The gNB explicitly signals the ID of the search space configuration to be used for a specific purpose, such as paging reception, System Information (SI) reception, and RA response reception. In NR, the search space configuration includes parameters—Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot, and duration. The UE uses the parameters—Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, and Monitoring-symbols-PDCCH-within-slot—to determine one or more PDCCH monitoring opportunities within a slot. PDCCH monitoring opportunities exist for a duration from slot 'x' to x+, where a slot with a digit 'X' in a radio frame with a digit 'Y' satisfies the following equation.

[0012] (y*(number of slots in a radio frame)+x-Monitoring-offset-PDCCH-slot)mod(Monitoring-periodicity-PDCCH-slot)=0

[0013] The start symbol of the PDCCH monitoring opportunity in each slot with a PDCCH monitoring opportunity is given by Monitoring-symbols-PDCCH-within-slot. The length of the PDCCH monitoring opportunity (by symbol) is given in the CORESET associated with the search space. The search space configuration includes the ID of the CORESET configuration associated with it. For each configured BWP, the gNB transmits a list of CORESET configurations by signal, where each CORESET configuration is uniquely identified by an ID. It should be noted that each radio frame has a duration of 10 ms. Radio frames are identified by either a radio frame number or a system frame number. Each radio frame includes multiple slots, where the number of slots in a radio frame and the duration of the slots depend on the subcarrier spacing (SCS). The number of slots in a radio frame and the duration of the slots depend on the radio frames of each supported SCS and are predefined in the NR. Each CORESET configuration is associated with a column of Transmit Configuration Indicator (TCI) states. A DL Reference Signal (RS) ID (Synchronization Signal and Physical Broadcast Block (SSB) or Channel State Information (CSI)-RS) is configured for each TCI state. The gNB transmits a list of TCI states corresponding to the CORESET configuration via RRC signaling. One of the TCI states in the TCI state list is activated by the gNB and indicated to the UE. The TCI state indication is used by the gNB to transmit the DL TX beam of the PDCCH during PDCCH monitoring in the search space (the DL TX beam is quasi-co-located (QCLed) with the SSB / CSI-RS of the TCI state).

[0014] In 5G wireless communication systems, Bandwidth Adaptation (BA) is supported. With BA, the UE's receive and transmit bandwidth does not need to be as large as the cell's bandwidth and can be adjusted: bandwidth can be commanded to change (e.g., shrinking during periods of low activity to save power); location can be moved in the frequency domain (e.g., to improve scheduling flexibility); and SCS can be commanded to change (e.g., to allow different services). A subset of the cell's total bandwidth is called a BWP. BA is implemented by configuring one or more BWPs for a UE with an RRC connection and informing the UE which configured BWP is currently active. When BA is configured, the UE only needs to monitor the PDCCH on one active BWP; that is, it does not need to monitor the PDCCH on the entire DL frequency of the serving cell. In RRC connected state, one or more DL and ULBWPs are configured for the UE for each configured serving cell (i.e., PCell or SCell). For an active serving cell, there will always be one active UL and DL BWP at any given time. BWP handover for the serving cell is used to simultaneously activate inactive BWPs and deactivate active BWPs. BWP handover is controlled by the PDCCH indicating DL allocation or UL authorization, by the bwp-inactivity timer, by RRC signaling, or by the Media Access Control (MAC) entity itself after the RA procedure is initiated. After adding a SpCell or activating a SCell, the DL BWP and UL BWP indicated by the first active downlink BWP-Id and the first active uplink BWP-Id, respectively, are active if no PDCCH indicating DL allocation or UL authorization is received. The active BWP of the serving cell is indicated by RRC or PDCCH. For unpaired spectrum, the DL BWP is paired with the UL BWP, and BWP handover is shared for both UL and DL. After the BWP inactivity timer expires, the UE will switch the active DL BWP to the default DL BWP or the initial DL BWP (if the default DL BWP is not configured).

[0015] In 5G wireless communication systems, Responsive Array (RA) is supported. RA is used to achieve UL time synchronization. RA is used during initial access, handover, RRC connection reconstruction, scheduling request transmission, SCG addition / modification, beam fault recovery (BFR), and during data or control information transmission in the UL by asynchronous UEs in RRC connection state. Several types of RA procedures are supported.

[0016] Competition-based RA (CBRA)

[0017] This is also known as 4-step CBRA. In this type of RA, the UE first transmits the RA preamble (also known as message 1 (Msg1)) and then waits for the Random Access Response (RAR) within the RAR window. The RAR is also known as message 2 (Msg2). The next-generation node B (gNB) transmits the RAR on the Physical Downlink Shared Channel (PDSCH). The PDCCH that schedules the PDSCH carrying the RAR is addressed to the RA-Radio Network Temporary Identifier (RA-RNTI). The RA-RNTI identifies the time-frequency resource (also known as the Physical RA Channel (PRACH) timing, PRACH Transmission (TX) timing, or RA Channel (RACH) timing) where the gNB detected the RA preamble. The RA-RNTI is calculated as follows:

[0018] RA-RNTI=1+s_id+14*t_id+14*80*f_id+14*80*8*ul_carrier_id

[0019] Wherein, s_id is the index of the first Orthogonal Frequency Division Multiplexing (OFDM) symbol of the PRACH timing in which the UE transmits Msg1 (i.e., the RA preamble); 0 ≤ s_id < 14; t_id is the index of the first time slot of the PRACH timing (0 ≤ t_id < 80); f_id is the index of the PRACH timing within the time slot in the frequency domain (0 ≤ f_id < 8); and ul_carrier_id is the UL carrier used for Msg1 transmission (0 for normal UL (NUL) carriers, 1 for supplementary UL (SUL) carriers). The gNB can multiplex several RARs for various RA preambles detected by the gNB in ​​the same RAR Media Access Control (MAC) Protocol Data Unit (PDU). If the RAR includes the RA preamble identifier (RAPID) of the RA preamble transmitted by the UE, then the RAR in the MAC PDU corresponds to the UE's RA preamble transmission. If no RAR corresponding to its RA preamble transmission is received during the RAR window, and the UE has not yet transmitted a configurable number of RA preambles (e.g., configured by gNB in ​​the RACH configuration), the UE returns to step one, i.e., selects RA resources (preamble / PRACH timing) and transmits the RA preamble. Backoff can be applied before returning to step one.

[0020] If a RAR corresponding to the RA preamble transmission is received, the UE transmits Message 3 (Msg3) with the UL clearance received in the RAR. Msg3 includes messages such as RRC Connection Request, RRC Connection Re-establishment Request, RRC Handover Confirmation, Scheduling Request, and SI Request. Msg3 may include the UE identifier (i.e., Cell Radio Network Temporary Identifier (C-RNTI), System Architecture Evolution (SAE) - Temporary Mobile Subscriber Identifier (S-TMSI), or a random number). After transmitting Msg3, the UE starts a contention resolution timer. While the contention resolution timer is running, if the UE receives a PDCCH addressed to the C-RNTI included in Msg3, contention resolution is considered successful, the contention resolution timer stops, and the RA procedure is completed. While the contention resolution timer is running, if the UE receives a Contention Resolution MAC Control Element (CE) including the UE's contention resolution identifier (the first X bits of the Common Control Channel (CCCH) Service Data Unit (SDU) transmitted in Msg3), contention resolution is considered successful, the contention resolution timer stops, and the RA procedure is completed. If the contention resolution timer expires and the UE has not yet transmitted the RA preamble a configurable number of times, the UE returns to step one, i.e., selects the RA resource (preamble / PRACH timing) and transmits the RA preamble. Backoff can be applied before returning to step one.

[0021] Competition-Free RA (CFRA)

[0022] This is also known as traditional CFRA or 4-step CFRA. The CFRA procedure is used for situations such as handover requiring low latency, early timing setup of Scells, etc. The eNB (or gNB) assigns a dedicated RA preamble to the UE. The UE transmits the dedicated RA preamble. The eNB (or gNB) transmits a RAR on the PDSCH addressed to the RA-RNTI. The RAR conveys the RA preamble identifier and timing alignment information. The RAR may also include UL clearance. Similar to the CBRA procedure, the RAR is transmitted within the RAR window. CFRA is considered successfully completed after receiving a RAR with a RAPID including the RA preamble transmitted by the UE. In the case of initiating an RA for BFR, CFRA is considered successfully completed if a PDCCH addressed to the C-RNTI is received in the search space used for BFR. If the RAR window expires and the RA is not successfully completed, and the UE has not transmitted the RA preamble a configurable number of times (e.g., configured by the gNB in ​​the RACH configuration), the UE retransmits the RA preamble.

[0023] For certain events, such as handover and BFR, if one or more dedicated preambles are assigned to the UE, during the first step of the RA procedure, i.e., during the RA resource selection for the Msg1 transmission, the UE determines whether to transmit a dedicated preamble or a non-dedicated preamble. Dedicated preambles are typically provided for a subset of the SSB / Channel State Information Reference Signal (CSI-RS). If none of the SSBs / CSI-RS for which the gNB provides CFRA resources (i.e., dedicated preamble / PRACH timing) has a DL Reference Signal Received Power (RSRP) above a threshold, the UE selects a non-dedicated preamble. Otherwise, the UE selects a dedicated preamble. During the RA procedure, one RA attempt can be CFRA, while other RA attempts can be CBRA.

[0024] 2-Step CBRA

[0025] In the first step of the 2-step CBRA, the UE transmits the RA preamble on the PRACH and the payload (i.e., the MAC PDU) on the PUSCH. The transmission of the RA preamble and payload is also referred to as Message A (MSGA). In the second step, after the MSGA transmission, the UE monitors for responses from the network (i.e., from the gNB) within a configured window. This response is also referred to as Message B (MSGB). If a CCCH SDU is transmitted in the MsgA payload, the UE performs contention resolution using the contention resolution information in the MSGB. If the contention resolution identifier received in the MSGB matches the first 48 bits of the CCCH SDU transmitted in the MSGA, contention resolution is successful. If a C-RNTI is transmitted in the MSGA payload, contention resolution is successful if the UE receives a PDCCH addressed to the C-RNTI. If contention resolution is successful, the RA procedure is considered successfully completed. Instead of the contention resolution information corresponding to the transmitted MSGA, the MSGB may include backoff information corresponding to the RA preamble transmitted in the MSGA. If a fallback message is received, the UE transmits Msg3 and performs contention resolution using Msg4 as in the CBRA procedure. If contention resolution is successful, the RA procedure is considered successfully completed. If contention resolution fails during fallback (i.e., when transmitting Msg3), the UE retransmits MSGA. If the configuration window for monitoring network responses expires after the UE transmits MSGA and the UE does not receive an MSGB containing either contention resolution or fallback information as described above, the UE retransmits MSGA. If the RA procedure is still not successfully completed after transmitting MSGA a configurable number of times, the UE falls back to a 4-step RA procedure, i.e., the UE only transmits the PR preamble.

[0026] The MsgA payload may include one or more of the following: CCCH SDU, Dedicated Control Channel (DCCH) SDU, Dedicated Traffic Channel (DTCH) SDU, Buffer Status Report (BSR) MAC CE, Power Headroom Report (PHR) MAC CE, SSB information, C-RNTI MAC CE, or padding. The MSGA may include the UE ID (e.g., random ID, S-TMSI, C-RNTI, recovery ID, etc.) and the preamble from the first step. The UE ID may be included in the MAC PDU of the MSGA. The UE ID (such as C-RNTI) may be carried in the MAC CE, where the MAC CE is included in the MAC PDU. Other UE IDs (such as random ID, S-TMSI, C-RNTI, recovery ID, etc.) may be carried in the CCCH SDU. The UE ID may be one of the following: random ID, S-TMSI, C-RNTI, recovery ID, International Mobile Subscriber Identity (IMSI), idle mode ID, inactive mode ID, etc. The UE ID may differ depending on the UE's execution of the RA procedure. When a UE performs a Reset Request (RA) after power-on (e.g., before it is attached to the network), the UE ID is a random ID. When a UE performs an RA in an idle state after it is attached to the network, the UE ID is the S-TMSI. If the UE has an assigned C-RNTI (e.g., in a connected state), the UE ID is the C-RNTI. When the UE is in an inactive state, the UE ID is the recovery ID. In addition to the UE ID, some additional control information can be sent in the MSGA. The control information can be included in the MAC PDU of the MSGA. The control information may include one or more of the following: connection request indication, connection restoration request indication, SI request indication, buffer status indication, beam information (e.g., one or more DL TX beam IDs or SSBIDs), BFR indication / information, data indicator, cell / base station (BS) / transmit-receive point (TRP) handover indication, connection re-establishment indication, reconfiguration complete or handover complete message, etc.

[0027] 2-step CFRA

[0028] In this scenario, the gNB allocates one or more dedicated RA preambles and one or more Physical Uplink Shared Channel (PUSCH) resources to the UE for MSGA transmission. It may also indicate one or more PRACH timings to be used for preamble transmission. In the first step of the 2-step CFRA, the UE uses the CFRA resources (i.e., dedicated preamble / PUSCH resources / PRACH timings) to transmit the RA preamble on the PRACH and the payload on the PUSCH. In the second step of the 2-step CFRA, after the MsgA transmission, the UE monitors for responses from the network (i.e., the gNB) within the configured window. If the UE receives a PDCCH addressed to the C-RNTI, the RA procedure is considered successfully completed. If the UE receives backoff information corresponding to the transmitted preamble, the RA procedure is considered successfully completed.

[0029] For certain events, such as handover and BFR, if the UE is allocated one or more dedicated preambles and one or more PUSCH resources, during the first step of the RA procedure, i.e., during the RA resource selection period for MSGA transmission, the UE determines whether to transmit a dedicated preamble or a non-dedicated preamble. Dedicated preambles are typically provided for a subset of SSB / CSI-RS. If none of the SSB / CSI-RS for which the gNB provides CFRA resources (i.e., dedicated preamble / PRACH timing / PUSCH resources) has a DL RSRP above a threshold, the UE selects a non-dedicated preamble. Otherwise, the UE selects a dedicated preamble. During the RA procedure, one RA attempt can be a 2-step CFRA, and another RA attempt can be a 2-step CBRA.

[0030] When initiating an RA procedure, the UE first selects a carrier (i.e., SUL or NUL). If the gNB explicitly signals a carrier for the RA procedure, the UE selects the signaled carrier to perform the RA procedure. If the gNB does not explicitly signal a carrier for the RA procedure; and if the serving cell for the RA procedure is configured with SUL; and if the RSRP of the DL path loss reference is less than rsrp-ThresholdSSB-SUL, then the UE selects the SUL carrier to perform the RA procedure. Otherwise, the UE selects the NUL carrier to perform the RA procedure. When selecting the UL carrier, the UE determines the UL and DL BWP for the RA procedure as specified in Section 5.15 of Technical Specification (TS) 38.321, and then determines whether to perform a 2-step or 4-step RA for this RA procedure.

[0031] If this RA procedure is initiated by a PDCCH command, and if the ra-PreambleIndex explicitly provided by the PDCCH is not 0b000000, then the UE selects a 4-step RA procedure.

[0032] Otherwise, if the gNB signals two CFRA resources for this RA procedure, the UE selects the two RA procedure.

[0033] Otherwise, if the gNB signals 4-step CFRA resources for this RA procedure, the UE selects the 4-step RA procedure.

[0034] Otherwise, if the UL BWP selected for this RA procedure has only 2-step RA resources, the UE selects the 2-step RA procedure.

[0035] Otherwise, if the UL BWP selected for this RA procedure has only 4-step RA resources, the UE selects the 4-step RA procedure.

[0036] Otherwise, if the UL BWP configuration selected for this RA procedure has both 2-step and 4-step RA resources, and the RSRP of the DL path loss reference is lower than the configured threshold, then the UE selects the 4-step RA procedure. Otherwise, the UE selects the 2-step RA procedure.

[0037] In a 5G wireless communication system, a UE can be in one of the following RRC states: RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED. When an RRC connection has been established, the UE is in the RRC_CONNECTED or RRC_INACTIVE state. If this is not the case, i.e., no RRC connection has been established, the UE is in the RRC_IDLE state. The RRC states can be further characterized as follows:

[0038] In RRC_IDLE state, UE-specific discontinuous reception (DRX) can be configured by the upper layer (i.e., the non-access layer (NAS)). The UE monitors short messages transmitted via downlink control information (DCI) along with the paging radio network temporary identifier (P-RNTI), monitors the paging channel used for core network (CN) paging using 5G System Architecture Evolution (SAE) - Temporary Mobile Subscriber Identifier (5G-S-TMSI), performs neighbor cell measurements and cell selection or reselection, obtains SI, can send SI requests (if configured), and performs available measurements along with location and time recording for UEs configured to record measurements.

[0039] In the RRC_INACTIVE state, UE-specific DRX can be configured by the upper layer or by the RRC layer. In this state, the UE stores the UE Inactive Access Plane (AS) context. The Radio Access Network (RAN)-based notification area is configured by the RRC layer. The UE monitors short messages transmitted via DCI along with P-RNTI, monitors paging channels for CN paging using 5G-S-TMSI and RAN paging using fully inactive RNTI (I-RNTI), performs neighbor cell measurements and cell selection or reselection, periodically performs RAN-based notification area updates, and acquires SI when moving outside the configured RAN-based notification area. It can send SI requests (if configured) and, for UEs configured to record measurements, performs recording of available measurements along with location and time.

[0040] In the RRC_CONNECTED state, the UE stores the AS context. Unicast data is transmitted to / received from the UE. The UE monitors short messages transmitted via DCI along with P-RNTI, and if configured, monitors the control channel associated with the shared data channel to determine whether to schedule data for it, provides channel quality and feedback information, performs neighbor cell measurements and measurement reports, and acquires SI.

[0041] In the RRC_CONNECTED state, the network can initiate an RRC connection suspension by sending an RRCLease with a suspension configuration. When the RRC connection is suspended, the UE stores its inactive AS context and any configuration received from the network, and transitions to the RRC_INACTIVE state. If the UE has an SCG configured, the UE releases the SCG configuration when initiating the RRC connection recovery process. The RRC messages used to suspend the RRC connection are integrity protected and encrypted.

[0042] When a UE needs to transition from the RRC_INACTIVE state to the RRC_CONNECTED state, the restoration of the suspended RRC connection is initiated by the upper layer, or by the RRC layer to perform a RAN Notification Area (RNA) update, or by a RAN paging from the NG-RAN. When the RRC connection is restored, the network configures the UE according to the RRC connection restoration procedure based on the stored UE inactive AS context and any RRC configuration received from the network. The RRC connection restoration procedure reactivates AS security and rebuilds one or more signaling radio bearers (SRBs) and one or more data radio bearers (DRBs). In response to a request to restore the RRC connection, the network may restore the suspended RRC connection and send the UE to RRC_CONNECTED, or reject the restoration request and send the UE to RRC_INACTIVE (using a wait timer), or directly re-suspend the RRC connection and send the UE to RRC_INACTIVE, or directly release the RRC connection and send the UE to RRC_IDLE, or instruct the UE to initiate NAS-level restoration (in which case the network sends an RRC setup message).

[0043] After initiating the recovery process, the UE can: apply the default Layer 1 (L1) parameter values ​​specified in the corresponding physical layer specification, in addition to the parameters provided in SIB1; apply the default MAC cell group configuration; apply the CCCH configuration; start timer T319; apply timeAlignmentTimerCommon contained in SIB1; apply the default SRB1 configuration; set the variable pendingRNA-Update to "pseudo"; initiate the transmission of the RRCResumeRequest message or RRCResueRequest1; and recover the RRC configuration, Robust Header Compression (RoHC) state, stored Quality of Service (QoS) flow to DRB mapping rules, and K from the stored UE inactive AS context, except for the masterCellGroup, mrdc-SecondaryCellGroup (if stored), and pdcp configurations. gNB and K RRCint Key; Set resumeMAC-I to the 16 least significant bits of MAC-I calculated using the following: K in the UE inactive AS context RRCint The key and the previously configured integrity protection algorithm, along with all input bits set to binary for COUNT, BEARER, and DIRECTION; using the stored nextHopChainingCount value, based on the current K... gNB Key or next hop (NH) derived K gNB Key; Export K RRCenc Key, KRRCint Key, K UPint Key and K UPenc Key; using the configured algorithm and K RRCint Key and K UPint The key is configured at the lower layer to apply integrity protection to all signaling radio bearers except SRB0; that is, integrity protection should be applied to all subsequent messages received and sent by the UE. The lower layer is also configured to apply encryption to all signaling radio bearers except SRB0, using the configured encryption algorithm and K. RRCenc Key and K UPenc The key, i.e., the encryption configuration, should be applied to all subsequent messages received and sent by the UE; rebuild the Packet Data Convergence Protocol (PDCP) entity for SRB1; restore SRB1; and transmit RRCresumeRequest or RRCresueRequest1.

[0044] Other aspects, advantages, and salient features of this disclosure will become apparent to those skilled in the art from the following detailed description of various embodiments of the disclosure taken in conjunction with the accompanying drawings. Summary of the Invention

[0045] Technical issues

[0046] Question 1:

[0047] During a Radio Resource Control (RRC) connection restoration procedure or a small data transfer procedure (or an RRC connection restoration procedure initiated for a small data transfer), ResumeMAC-I is generated using the following inputs according to the current design:

[0048] KEY(K RRCint ), BEARER (set to 1), DIRECTION (set to 1), and COUNT (set to 1); and

[0049] MESSAGE: Source Physical Cell Identifier (PCI) (set to the physical cell identifier of the primary cell (PCell) to which the user equipment (UE) is connected before the RRC connection is suspended); Target Cell ID (set to the cell identifier of the first public land mobile network (PLMN) identifier included in the PLMN-IdentityInfoList broadcast in System Information Block 1 (SIB1) of the cell to which the UE sends the recovery request); and Source Cell Radio Network Temporary Identifier (C-RNTI) (set to the C-RNTI that the UE has in the PCell to which it is connected before the RRC connection is suspended).

[0050] To further enhance the security of recovery requests, we are considering including `resumeCause` when generating `resumeMAC-I`. The question is how to handle backward compatibility:

[0051] Current recovery operation: The UE and next-generation node B1 (gNB1) are in an RRC connection state; the UE receives an RRCRelease with a suspend configuration from gNB1. The UE enters an RRC inactive state and stores the current access layer (AS) context. When the criteria for restoring the RRC connection are met, the UE initiates an RRC connection recovery. The UE generates a resumeMAC-I using the input (explained above) and sends an RRCRelease to gNB2. The RRCRelease includes ResumeCause, resumeMAC-I, inactive RNTI (I-RNTI), and a spare bit. gNB2 identifies gNB1 from the I-RNTI and sends a context request to gNB1. The context request includes the UE's I-RNTI to the old gNB, the target cell ID, and the ResumeMAC-I. gNB1 verifies the ResumeMAC-I and sends the UE's context to gNB2.

[0052] If gNB2 does not understand the enhanced ResumeMAC-I operation, it will not send resumeCause to gNB1. Therefore, resumeMAC-I verification fails.

[0053] If gNB2 understands the enhanced ResumeMAC-I operation but gNB1 does not, gNB1 may not understand the context request that includes the resumeCause value. Therefore, resumeMAC-I verification will fail.

[0054] Therefore, methods to handle backward compatibility are needed.

[0055] Question 2:

[0056] In fifth-generation (5G) wireless communication systems, small data transmission (SDT) in the RRC_INACTIVE state is supported. In the case of a 4-step random access (RA) procedure, uplink data can be transmitted in message 3 (Msg3), and in the case of a 2-step RA procedure, uplink data is transmitted in message A (MSGA). In the current small data transmission method, uplink data is transmitted in Msg3. This requires configuring different random access channel (RACH) preambles and / or RACH timings for small data transmission. Uplink transmission is also not contention-free, leading to wasted physical uplink shared channel (PUSCH) resources in the event of collisions. Therefore, an enhanced method is needed.

[0057] Solution to the problem

[0058] The present disclosure aims to at least address the aforementioned problems and / or disadvantages, and to provide at least the advantages described below. Therefore, one aspect of the present disclosure is to provide a communication method and system for integrating fifth-generation (5G) communication systems that support higher data rates than fourth-generation (4G) systems.

[0059] According to one aspect of this disclosure, a method for small data transmission performed by a terminal in a wireless communication system is provided. The method includes: transmitting a random access preamble to a base station; receiving from the base station a random access response corresponding to the random access preamble, the random access response including an uplink grant for transmission of message 3 (Msg3); transmitting Msg3 to the base station based on the uplink grant for transmission of Msg3, including a recovery identifier, a recovery integrity message authentication code (MAC-I), and information about the size of uplink data; if the recovery MAC-I is verified, receiving from the base station a message 4 (Msg4) including a contention resolution identifier, wherein the uplink grant for uplink data transmission is received in Msg4 or received on a physical downlink control channel addressing a cell radio network temporary identifier (C-RNTI) received in the random access response after Msg4; and transmitting uplink data to the base station based on the uplink grant for uplink data transmission.

[0060] According to another aspect of this disclosure, a method for small data transmission performed by a base station in a wireless communication system is provided. The method includes: receiving a random access preamble from a terminal; transmitting to the terminal a random access response corresponding to the random access preamble, the random access response including an uplink grant for transmission of message 3 (Msg3); receiving from the terminal, based on the uplink grant for transmission of Msg3, Msg3 including a recovery identifier, a recovery integrity message authentication code (MAC-I), and information about the size of uplink data; verifying the recovery MAC-I; if the recovery MAC-I is verified, transmitting to the terminal a message 4 (Msg4) including a contention resolution identifier, wherein the uplink grant for uplink data transmission is transmitted in Msg4 or transmitted on a physical downlink control channel addressing to a cell radio network temporary identifier (C-RNTI) transmitted in the random access response after Msg4; receiving uplink data from the terminal based on the uplink grant for uplink data transmission; and transmitting the uplink data to a user plane function (UPF).

[0061] According to another aspect of this disclosure, a terminal in a wireless communication system is provided. The terminal includes a transceiver and at least one processor coupled to the transceiver. The at least one processor is configured to: transmit a random access preamble to a base station via the transceiver; receive a random access response corresponding to the random access preamble from the base station via the transceiver, the random access response including an uplink grant for transmission of message 3 (Msg3); based on the uplink grant for transmission of Msg3, transmit Msg3 to the base station via the transceiver including a recovery identifier, a recovery integrity message authentication code (MAC-I), and information about the uplink data size; if the recovery MAC-I is verified, receive a message 4 (Msg4) including a contention resolution identifier from the base station via the transceiver, wherein the uplink grant for uplink data transmission is received in Msg4 or received on a physical downlink control channel addressing the cell radio network temporary identifier (C-RNTI) received in the random access response after Msg4; and transmit uplink data to the base station via the transceiver based on the uplink grant for uplink data transmission.

[0062] According to another aspect of this disclosure, a base station in a wireless communication system is provided. The base station includes a transceiver and at least one processor coupled to the transceiver. The at least one processor is configured to: receive a random access preamble from a terminal via the transceiver; transmit a random access response corresponding to the random access preamble to the terminal via the transceiver, the random access response including an uplink grant for message 3 (Msg3) transmission; based on the uplink grant for Msg3 transmission, receive, via the transceiver, Msg3 from the terminal including a recovery identifier, a recovery integrity message authentication code (MAC-I), and information about the uplink data size; verify the recovery MAC-I; and after the recovery MAC-I is verified... In the event of a contention resolution flag, a message 4 (Msg4) is transmitted to the terminal via the transceiver, wherein an uplink license for uplink data transmission is transmitted in the Msg4 or on the physical downlink control channel addressing the Cell Radio Network Temporary Identifier (C-RNTI) transmitted in the random access response after the Msg4. Based on the uplink license for uplink data transmission, uplink data is received from the terminal via the transceiver, and the uplink data is transmitted to the User Plane Function (UPF) via the transceiver.

[0063] Advantages of the invention

[0064] The embodiments in this disclosure address backward compatibility issues related to recovery protection. The embodiments also disclose enhanced methods for small data transfers requiring fewer resources. Attached Figure Description

[0065] The above and other aspects, features, and advantages of certain embodiments of this disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings, in which:

[0066] Figure 1 Operation for enhanced connection recovery protection according to an embodiment of method 1 based on this disclosure is illustrated;

[0067] Figure 2 This is an example signaling stream using a 4-step RA for small data transmission according to embodiments of this disclosure;

[0068] Figure 3 The signaling flow for small data transmission using a 2-step RA is illustrated according to an embodiment of the present disclosure;

[0069] Figure 4 The signaling flow for small data transmission using a 4-step RA is illustrated according to an embodiment of the present disclosure;

[0070] Figure 5 This illustrates a signaling flow for small data transmission using a 4-step RA according to another embodiment of the present disclosure;

[0071] Figure 6 A block diagram of a terminal according to an embodiment of the present disclosure; and

[0072] Figure 7 This is a block diagram of a base station according to an embodiment of the present disclosure.

[0073] Throughout the accompanying drawings, the same reference numerals will be understood to refer to the same parts, components, and structures. Detailed Implementation

[0074] The following description, with reference to the accompanying drawings, is provided to aid in a comprehensive understanding of the various embodiments of this disclosure as defined by the claims and their equivalents. The following description includes various specific details to aid understanding, but these details should be considered exemplary only. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the various embodiments described herein without departing from the scope and spirit of this disclosure. Furthermore, for clarity and brevity, descriptions of well-known functions and constructions may be omitted.

[0075] The terms and words used in the following description and claims are not limited to their bibliographical meaning, but are merely intended to provide a clear and consistent understanding of this disclosure. Therefore, it will be apparent to those skilled in the art that the following description of various embodiments of this disclosure is provided for illustrative purposes only and is not intended to limit the disclosure as defined by the appended claims and their equivalents.

[0076] It should be understood that, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” include plural indicators. Thus, for example, referring to “the surface of a component” includes referring to one or more such surfaces.

[0077] The term “substantially” means that the feature, parameter, or value does not need to be precisely achieved, but can deviate or vary in a quantity that does not exclude the effect that the feature is intended to provide, including, for example, tolerances, measurement errors, measurement accuracy limitations, and other factors known to those skilled in the art.

[0078] Those skilled in the art know that blocks and combinations of flowcharts (or sequence diagrams) can be represented and executed by non-transitory computer program instructions. These computer program instructions can be loaded onto a processor of a general-purpose computer, a special-purpose computer, or a programmable data processing apparatus. When the loaded program instructions are executed by the processor, they create means for performing the functions described in the flowcharts. Because the computer program instructions can be stored in a computer-readable storage device that can be used in a special-purpose computer or programmable data processing apparatus, it is also possible to create articles of art that perform the functions described in the flowcharts. Because the computer program instructions can be loaded onto a computer or programmable data processing apparatus, when executed as a process, it can perform the operations of the functions described in the flowcharts.

[0079] A flowchart's boxes may correspond to modules, segments, or code containing one or more executable instructions that implement one or more logical functions, or they may correspond to a portion thereof. In some cases, the functions described by the boxes may be executed in a different order than they are listed. For example, two boxes listed in sequence may be executed simultaneously or in reverse order.

[0080] In this specification, the terms "unit," "module," etc., can refer to software or hardware components capable of performing functions or operations, such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs). However, "unit," etc., is not limited to hardware or software. Units, etc., can be configured to reside in addressable memory media or drive one or more processors. Units, etc., can also refer to software components, object-oriented software components, category components, task components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, or variables. The functionality provided by components and units can be a combination of smaller components and units, and can be combined with others to form larger components and units. Components and units can be configured to drive devices in a secure multimedia card or one or more processors.

[0081] Before providing a detailed description, the terms or definitions necessary for understanding this disclosure are described. However, these terms should be interpreted in a non-limiting manner.

[0082] A base station (BS) is an entity that communicates with user equipment (UE) and can be referred to as a BS, base transceiver station (BTS), node B (NB), evolved NB (eNB), access point (AP), fifth-generation (5G) NB (5GNB), or next-generation NB (gNB).

[0083] A UE is an entity that communicates with a BS and can be referred to as a UE, device, mobile station (MS), mobile device (ME), or terminal.

[0084] Handling backward compatibility of connection recovery protection

[0085] Method 1:

[0086] Example 1:

[0087] Figure 1 Operations for enhanced connection recovery (i.e., RRCResumeRequest / RRCResumeRequest1 messages) protection are illustrated according to an embodiment of method 1 based on this disclosure.

[0088] refer to Figure 1 In RRC_CONNECTED, during operation 110, the UE receives the UECapabilityEnquiry message from the gNB / eNB.

[0089] In response to the UECapabilityEnquiry message, during operation 120, the UE transmits a UECapabilityInformation message to the gNB / eNB. If the UE supports Enhanced Resume Protection, it indicates to the gNB / eNB that it supports Enhanced Resume Protection; that is, the UE includes `enhancedResumeProtectionSupported` in the UECapabilityInformation message. Otherwise, `enhancedResumeProtectionSupported` is not included in the UECapabilityInformation message. The UE sends the UECapabilityInformation message to the gNB / eNB. In an alternative embodiment, if the UE supports Enhanced Resume Protection, it can indicate to the gNB / eNB that it supports Enhanced Resume Protection by including `enhancedResumeProtectionSupported` in another message such as the UEAssistanceInformation message or any other Radio Resource Control (RRC) message or in a Non-Access Plane (NAS) message.

[0090] At a certain point in time, during operation 130, the gNB / eNB sends an RRCRelease message with suspendConfig to release the ongoing RRC connection. If the UE supports Enhanced Resume Protection and the gNB / eNB also supports Enhanced Resume Protection, the gNB includes the parameter enhancedResumeProtectionEnabled (also known as enhancedResumeProtectionSupported, or it can be any other parameter indicating that the gNB / eNB enables / supports Enhanced Resume Protection) in the RRCRelease message to indicate that the gNB / eNB enables / supports Enhanced Resume Protection. enhancedResumeProtectionEnabled can be added to the suspendConfig information element (IE). In an alternative embodiment, the gNB can indicate that it supports Enhanced Resume Protection by including enhancedResumeProtectionEnabled (also known as enhancedResumeProtectionSupported, or it can be any other parameter indicating that the gNB / eNB enables / supports Enhanced Resume Protection) in the system information (e.g., in some System Information Block (SIB)). In an alternative embodiment, the gNB can indicate that it supports enhanced recovery protection by including enhancedResumeProtectionEnabled in any other RRC or NAS message.

[0091] Upon receiving the RRCRelease message with suspendConfig, the UE enters RRC_INACTIVE during operation 140.

[0092] When the UE is in RRC_INACTIVE, if the criteria for restoring the RRC connection are met (e.g., the UE receives a paging message, or the UE has mobile source (MO) data to transmit, or the UE receives a paging message or a radio access network (RAN) update / location update is triggered, etc.) (or the criteria for performing a small data transmission procedure are met), then in operation 150, the UE initiates RRC connection restoration (or RRC connection restoration for small data transmission).

[0093] If the UE supports enhanced recovery protection, and the last gNB the UE was connected to also supports enhanced recovery protection (e.g., receiving enhancedResumeProtectionEnabled in the RRCRelease message that suspended the last RRC connection, or receiving enhancedResumeProtectionEnabled from the last gNB the UE was connected to (in a System Information (SI) message, RRC message, or NAS message): then the UE uses the enhanced method for recovery protection (operation 2 below) to generate ResumeMAC-I in operation 160. Otherwise: the UE uses the current method (operation 1 below) to generate ResumeMAC-I in operation 160.

[0094] In Operation 170, the UE sends an RRRCResumeRequest with ResumeMAC-I to the gNB / eNB.

[0095] If the gNB / eNB to which the UE sends a recovery request is different from the gNB / eNB that has the UE context, then in operation 180, the new gNB / eNB to which the UE sent the recovery request sends a context request to the old gNB / eNB that has the UE context. Figure 1 In this context, gNB1 corresponds to the old gNB / eNB with the UE context, and gNB2 corresponds to the new gNB / eNB to which the UE sent a recovery request.

[0096] If the new gNB / eNB supports enhanced recovery protection, it will send the UE's recovery identifier (e.g., Inactive Radio Network Temporary Identifier (I-RNTI)), target cell ID, resumeCause, ResumeMAC-I, and spare bits to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends a context request along with the aforementioned information to the old gNB / eNB.

[0097] Alternatively, if the new gNB / eNB supports enhanced recovery protection and the UE has already generated resumeMAC-I using enhanced recovery protection (the new gNB can identify that the UE has generated resumeMAC-I using enhanced recovery protection based on the indication in the ResumeRequest message or the Logical Channel ID (LCID) used for the ResumeRequest; a different LCID can be used in the case of enhanced recovery protection, and the LCID is carried in the MAC subheader of the Media Access Control (MAC) Protocol Data Unit (PDU) carrying the ResumeRequest): then the new gNB / eNB sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the aforementioned information.

[0098] Otherwise: The new gNB / eNB only sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the above information.

[0099] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection, and the old gNB / eNB also supports enhanced recovery protection, then the old gNB / eNB identifies whether it has received the recovery reason and standby bit from the new gNB / eNB.

[0100] 2> If the recovery reason and standby bit are received from the new gNB / eNB: then in operation 190, the old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source cell RNTI (C-RNTI), resumeCause, standby bit) to generate ResumeMAC-I.

[0101] 2> Otherwise, in Operation 190, the old gNB / eNB generates a ResumeMAC-I using the KEY, BEARER, DIRECTION, COUNT, and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, and spare bit). This is done for each resumeCause and spare bit value until the ResumeMAC-I is verified. Various ResumeCauses are predefined.

[0102] Alternatively, ResumeMAC-I verification is considered to have failed, and the new gNB sends RRCReject to the UE.

[0103] 1> Otherwise:

[0104] 2> In Operation 190, the old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0105] If the gNB / eNB to which the UE sent the recovery request is the same as the gNB / eNB with the UE context:

[0106] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection and the gNB / eNB also supports enhanced recovery protection:

[0107] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, spare bit) to generate ResumeMAC-I.

[0108] 1> Otherwise:

[0109] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0110] Example 2: In another embodiment of this method disclosed herein, the operation for enhanced connection recovery (i.e., RCResumeRequest / RRCResumeRequest1 messages) protection is as follows:

[0111] The UE is in RRC_CONNECTED.

[0112] The UE receives the UECapabilityEnquiry message from the gNB / eNB.

[0113] If the UE supports Enhanced Resume Protection, it indicates to the gNB / eNB that it supports Enhanced Resume Protection; that is, the UE includes `enhancedResumeProtectionSupported` in the UECapabilityInformation message. Otherwise, the UE does not include `enhancedResumeProtectionSupported` in the UECapabilityInformation message. The UE sends a UECapabilityInformation message to the gNB / eNB. In an alternative embodiment, if the UE supports Enhanced Resume Protection, it can indicate to the gNB / eNB that it supports Enhanced Resume Protection by including `enhancedResumeProtectionSupported` in another message such as the UEAssistanceInformation message or any other RRC message or NAS message.

[0114] At a certain point in time, the gNB / eNB sends an RRCRelease message with suspendConfig to release the ongoing RRC connection. If the UE supports Enhanced Resume Protection and the gNB / eNB also supports Enhanced Resume Protection, the gNB includes enhancedResumeProtectionEnabled (also known as enhancedResumeProtectionSupported, or it can be any other parameter indicating that the gNB / eNB enables / supports Enhanced Resume Protection) in the RRCRelease message. enhancedResumeProtectionEnabled can be added to the suspendConfig IE. In alternative embodiments, the gNB can indicate that it supports Enhanced Resume Protection by including enhancedResumeProtectionEnabled (also known as enhancedResumeProtectionSupported, or it can be any other parameter indicating that the gNB / eNB enables / supports Enhanced Resume Protection) in its system information (e.g., in some SIBs). In an alternative embodiment, the gNB can indicate that it supports enhanced recovery protection by including enhancedResumeProtectionEnabled in any other RRC or NAS message.

[0115] Upon receiving an RRCRelease message with suspendConfig, the UE enters RRC_INACTIVE.

[0116] When the UE is in RRC_INACTIVE, if the criteria for restoring the RRC connection are met (e.g., the UE receives a paging message, or the UE has MO data to transmit, or the UE receives a paging message or a RAN update / location update is triggered, etc.) (or the criteria for performing a small data transmission procedure are met), the UE initiates RRC connection restoration (or RRC connection restoration for small data transmission).

[0117] If the UE supports enhanced recovery protection, and the last gNB the UE was connected to supports enhanced recovery protection (e.g., receiving enhancedResumeProtectionEnabled in the RRCRelease message when the last RRC connection was suspended, or receiving enhancedResumeProtectionEnabled from the last gNB the UE was connected to (in an SI, RRC, or NAS message), and the currently camped cell supports enhanced recovery protection (the current gNB can broadcast enhancedResumeProtectionEnabled in the SI): then the UE uses the enhanced method for recovery protection (operation 2 below) to generate ResumeMAC-I. Otherwise: the UE uses the current method (operation 1 below) to generate ResumeMAC-I.

[0118] The UE sends an RRRCResumeRequest with ResumeMAC-I to the gNB / eNB.

[0119] If the gNB / eNB to which the UE sends a recovery request is different from the gNB / eNB that has the UE context, then the new gNB / eNB to which the UE sends the recovery request sends a context request to the old gNB / eNB that has the UE context.

[0120] If the new gNB / eNB supports enhanced recovery protection, it will send the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends a context request along with the aforementioned information to the old gNB / eNB.

[0121] Alternatively, if the new gNB / eNB supports enhanced recovery protection and the UE has already generated resumeMAC-I using enhanced recovery protection (the new gNB can identify that the UE has generated resumeMAC-I using enhanced recovery protection based on the indication in the ResumeRequest message or the LCID used for the ResumeRequest; a different LCID can be used in the case of enhanced recovery protection, and the LCID is carried in the MAC subheader of the MAC PDU carrying the ResumeRequest): then the new gNB / eNB sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the aforementioned information.

[0122] Otherwise: The new gNB / eNB only sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the above information.

[0123] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection, and the old gNB / eNB also supports enhanced recovery protection, and the recovery reason and spare bit are received from the new gNB / eNB:

[0124] 2> Old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, spare bit) to generate ResumeMAC-I.

[0125] 1> Otherwise:

[0126] 2> Old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0127] If the gNB / eNB to which the UE sent the recovery request is the same as the gNB / eNB with the UE context:

[0128] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection and the gNB / eNB also supports enhanced recovery protection:

[0129] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, spare bit) to generate ResumeMAC-I.

[0130] 1> Otherwise:

[0131] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0132] ResumeMAC-I generation details:

[0133] Operation 1:

[0134] Security Key: KEY(K) RRCint ); BEARER: set to 1; DIRECTION: set to 1; and COUNT: set to 1.

[0135] MESSAGE:

[0136] Source PCI (set to the physical cell identifier of the primary cell (PCell) to which the UE connects before the RRC connection is suspended);

[0137] The target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in SIB1 of the cell to which the UE is sending a recovery request); and

[0138] Source C-RNTI (set to the C-RNTI that the UE has in its connected PCell before the RRC connection is suspended).

[0139] Use the security key (KEY) and the inputs set above (BEARER, DIRECTION, COUNT) to generate an integrity message authentication code (MAC-I) via MESSAGE (set above).

[0140] Operation 2:

[0141] Security Key: KEY(K) RRCint ); BEARER: set to 1; DIRECTION: set to 1; and COUNT: set to 1.

[0142] MESSAGE:

[0143] Source PCI (set to the physical cell identifier of the PCell to which the UE connects before the RRC connection is suspended);

[0144] Target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in the SIB1 of the cell to which the UE is sending a recovery request);

[0145] Source C-RNTI (set to the C-RNTI that the UE had in its connected PCell before the RRC connection was suspended);

[0146] ResumeCause; and

[0147] Backup position.

[0148] Use the security key (KEY) and the inputs set above (BEARER, DIRECTION, COUNT) to generate a MAC-I via a message (set above).

[0149] Method 2:

[0150] Example 1: In one embodiment of this method disclosed herein, the operation for enhanced connection recovery (i.e., RCResumeRequest / RRCResumeRequest1 messages) protection is as follows:

[0151] The UE is in RRC_CONNECTED.

[0152] The UE receives the UECapabilityEnquiry message from the gNB / eNB.

[0153] If the UE supports Enhanced Resume Protection, it indicates to the gNB / eNB that it supports Enhanced Resume Protection; that is, the UE includes `enhancedResumeProtectionSupported` in the UECapabilityInformation message. Otherwise, the UE does not include `enhancedResumeProtectionSupported` in the UECapabilityInformation message. The UE sends a UECapabilityInformation message to the gNB / eNB. In an alternative embodiment, if the UE supports Enhanced Resume Protection, it can indicate to the gNB / eNB that it supports Enhanced Resume Protection by including `enhancedResumeProtectionSupported` in another message, such as a UEAssistanceInformation message, or any other RRC or NAS message.

[0154] At some point, the gNB / eNB sends an RRCRelease message with suspendConfig to release the ongoing RRC connection. If the UE supports Enhanced Resume Protection and the gNB / eNB also supports Enhanced Resume Protection, the gNB includes enhancedResumeProtectionEnabled (also known as enhancedResumeProtectionSupported, or it can be any other parameter indicating that the gNB / eNB enables / supports Enhanced Resume Protection) in the RRCRelease message. enhancedResumeProtectionEnabled can be added to the suspendConfig IE. In alternative embodiments, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in system information (e.g., in some SIBs). In alternative embodiments, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in any other RRC or NAS message.

[0155] Upon receiving an RRCRelease message with suspendConfig, the UE enters RRC_INACTIVE.

[0156] When the UE is in RRC_INACTIVE, if the criteria for restoring the RRC connection are met (e.g., the UE receives a paging message, or the UE has MO data to transmit, or the UE receives a paging message or a RAN update / location update is triggered, etc.) (or the criteria for performing a small data transmission procedure are met), the UE initiates RRC connection restoration (or RRC connection restoration for small data transmission).

[0157] If the UE supports enhanced recovery protection, and the last gNB the UE was connected to also supports enhanced recovery protection (e.g., receiving enhancedResumeProtectionEnabled in the RRCRelease message when the last RRC connection is suspended, or receiving enhancedResumeProtectionEnabled from the last gNB the UE was connected to (in an SI, RRC, or NAS message): then the UE uses the enhanced method for recovery protection (operation 2 below) to generate ResumeMAC-I. Otherwise: the UE uses the current method (operation 1 below) to generate ResumeMAC-I.

[0158] The UE sends an RRRCResumeRequest with ResumeMAC-I to the gNB / eNB.

[0159] If the gNB / eNB to which the UE sends a recovery request is different from the gNB / eNB with the UE context, then the new gNB / eNB to which the UE sends the recovery request sends a context request to the old gNB / eNB with the UE context.

[0160] If the new gNB / eNB supports enhanced recovery protection, it will send the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends a context request along with the aforementioned information to the old gNB / eNB.

[0161] Alternatively, if the new gNB / eNB supports enhanced recovery protection and the UE has already generated resumeMAC-I using enhanced recovery protection (the new gNB can identify that the UE has generated resumeMAC-I using enhanced recovery protection based on the indication in the ResumeRequest message or the LCID used for the ResumeRequest; a different LCID can be used in the case of enhanced recovery protection, and the LCID is carried in the MAC subheader of the MAC PDU carrying the ResumeRequest): then the new gNB / eNB sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the aforementioned information.

[0162] Otherwise: The new gNB / eNB only sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the above information.

[0163] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection, and the old gNB / eNB also supports enhanced recovery protection, then the old gNB / eNB identifies whether it has received a recovery reason from the new gNB / eNB.

[0164] 2> If a recovery reason is received from the new gNB / eNB: the old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause) to generate ResumeMAC-I.

[0165] 2> Otherwise, the old gNB / eNB generates a ResumeMAC-I using the KEY, BEARER, DIRECTION, COUNT, and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause). This is done for each resumeCause value until the ResumeMAC-I is verified. Various ResumeCauses are predefined. Alternatively, ResumeMAC-I verification is considered to have failed, and the new gNB sends an RRCReject to the UE.

[0166] 1> Otherwise:

[0167] 2> Old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0168] If the gNB / eNB to which the UE sent the recovery request is the same as the gNB / eNB with the UE context:

[0169] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection and the gNB / eNB also supports enhanced recovery protection:

[0170] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause) to generate ResumeMAC-I.

[0171] 1> Otherwise:

[0172] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0173] Example 2: In another embodiment of this method disclosed herein, the operation for enhanced connection recovery (i.e., RCResumeRequest / RRCResumeRequest1 messages) protection is as follows:

[0174] The UE is in RRC_CONNECTED.

[0175] The UE receives the UECapabilityEnquiry message from the gNB / eNB.

[0176] If the UE supports Enhanced Resume Protection, it indicates to the gNB / eNB that it supports Enhanced Resume Protection; that is, the UE includes `enhancedResumeProtectionSupported` in the `UECapabilityInformation` message. Otherwise, `enhancedResumeProtectionSupported` is not included in the `UECapabilityInformation` message. The UE sends a `UECapabilityInformation` message to the gNB / eNB. In an alternative embodiment, if the UE supports Enhanced Resume Protection, it can indicate to the gNB / eNB that it supports Enhanced Resume Protection by including `enhancedResumeProtectionSupported` (also called `enhancedResumeProtectionEnabled`, or any other parameter indicating that the gNB / eNB enables / supports Enhanced Resume Protection) in another message such as the `UEAssistanceInformation` message or any other RRC or NAS message.

[0177] At some point, the gNB / eNB sends an RRCRelease message with suspendConfig to release the ongoing RRC connection. If the UE supports Enhanced Resume Protection, and the gNB / eNB also supports Enhanced Resume Protection, the gNB includes enhancedResumeProtectionEnabled in the RRCRelease message. enhancedResumeProtectionEnabled can be added to the suspendConfig IE. In an alternative embodiment, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in system information (e.g., in some SIBs). In an alternative embodiment, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in any other RRC message or NAS message.

[0178] Upon receiving an RRCRelease message with suspendConfig, the UE enters RRC_INACTIVE.

[0179] When the UE is in RRC_INACTIVE, if the criteria for restoring the RRC connection are met (e.g., the UE receives a paging message, or the UE has MO data to transmit, or the UE receives a paging message or a RAN update / location update is triggered, etc.) (or the criteria for performing a small data transmission procedure are met), the UE initiates RRC connection restoration (or RRC connection restoration for small data transmission).

[0180] If the UE supports enhanced recovery protection, and the last gNB the UE was connected to supports enhanced recovery protection (e.g., receiving enhancedResumeProtectionEnabled in the RRCRelease message when the last RRC connection was suspended, or receiving enhancedResumeProtectionEnabled from the last gNB the UE was connected to (in an SI, RRC, or NAS message), and the currently camped cell supports enhanced recovery protection (the current gNB can broadcast enhancedResumeProtectionEnabled in the SI): then the UE uses the enhanced method for recovery protection (operation 2 below) to generate ResumeMAC-I. Otherwise: the UE uses the current method (operation 1 below) to generate ResumeMAC-I.

[0181] The UE sends an RRRCResumeRequest with ResumeMAC-I to the gNB / eNB.

[0182] If the gNB / eNB to which the UE sends a recovery request is different from the gNB / eNB with the UE context, then the new gNB / eNB to which the UE sends the recovery request sends a context request to the old gNB / eNB with the UE context.

[0183] If the new gNB / eNB supports enhanced recovery protection, it will send the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends a context request along with the aforementioned information to the old gNB / eNB.

[0184] Alternatively, if the new gNB / eNB supports enhanced recovery protection and the UE has already generated resumeMAC-I using enhanced recovery protection (the new gNB can identify that the UE has generated resumeMAC-I using enhanced recovery protection based on the indication in the ResumeRequest message or the LCID used for the ResumeRequest; a different LCID can be used in the case of enhanced recovery protection, and the LCID is carried in the MAC subheader of the MAC PDU carrying the ResumeRequest): then the new gNB / eNB sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the aforementioned information.

[0185] Otherwise: The new gNB / eNB only sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the above information.

[0186] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection, and the old gNB / eNB also supports enhanced recovery protection, and if a recovery reason is received from the new gNB / eNB:

[0187] 2> Old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause) to generate ResumeMAC-I.

[0188] 1> Otherwise:

[0189] 2> Old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0190] If the gNB / eNB to which the UE sent the recovery request is the same as the gNB / eNB with the UE context:

[0191] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection and the gNB / eNB also supports enhanced recovery protection:

[0192] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause) to generate ResumeMAC-I.

[0193] 1> Otherwise:

[0194] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0195] ResumeMAC-I generation details:

[0196] Operation 1:

[0197] Security Key: KEY(K) RRCint BEARER: set to 1; DIRECTION: set to 1; and COUNT: set to 1.

[0198] MESSAGE:

[0199] Source PCI (set to the physical cell identifier of the PCell to which the UE connects before the RRC connection is suspended);

[0200] The target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in SIB1 of the cell to which the UE is sending a recovery request); and

[0201] Source C-RNTI (set to the C-RNTI that the UE has in its connected PCell before the RRC connection is suspended).

[0202] Use the security key (KEY) and the inputs set above (BEARER, DIRECTION, COUNT) to generate a MAC-I via a message (set above).

[0203] Operation 2:

[0204] Security Key: KEY(K) RRCint BEARER: set to 1; DIRECTION: set to 1; and COUNT: set to 1.

[0205] MESSAGE:

[0206] Source PCI (set to the physical cell identifier of the PCell to which the UE connects before the RRC connection is suspended);

[0207] Target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in the SIB1 of the cell to which the UE is sending a recovery request);

[0208] Source C-RNTI (set to the C-RNTI that the UE had in its connected PCell before the RRC connection was suspended); and

[0209] ResumeCause.

[0210] Use the security key (KEY) and the inputs set above (BEARER, DIRECTION, COUNT) to generate a MAC-I via a message (set above).

[0211] Method 3:

[0212] Example 1: In one embodiment of this method disclosed herein, the operation for enhanced connection recovery (i.e., RCResumeRequest / RRCResumeRequest1 messages) protection is as follows:

[0213] The UE is in RRC_CONNECTED.

[0214] The UE receives the UECapabilityEnquiry message from the gNB / eNB.

[0215] If the UE supports Enhanced Resume Protection, it indicates to the gNB / eNB that it supports Enhanced Resume Protection; that is, the UE includes `enhancedResumeProtectionSupported` in the UECapabilityInformation message. Otherwise, the UE does not include `enhancedResumeProtectionSupported` in the UECapabilityInformation message. The UE sends a UECapabilityInformation message to the gNB / eNB. In an alternative embodiment, if the UE supports Enhanced Resume Protection, it can indicate to the gNB / eNB that it supports Enhanced Resume Protection by including `enhancedResumeProtectionSupported` in another message, such as a UEAssistanceInformation message, or any other RRC or NAS message.

[0216] At some point, the gNB / eNB sends an RRCRelease message with suspendConfig to release the ongoing RRC connection. If the UE supports Enhanced Resume Protection and the gNB / eNB also supports Enhanced Resume Protection, the gNB includes enhancedResumeProtectionEnabled (also referred to as enhancedResumeProtectionEnabled, or it can be any other parameter indicating that the gNB / eNB enables / supports Enhanced Resume Protection) in the RRCRelease message. enhancedResumeProtectionEnabled can be added to suspendConfigIE. In alternative embodiments, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in system information (e.g., in some SIBs). In alternative embodiments, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in any other RRC message.

[0217] Upon receiving an RRCRelease message with suspendConfig, the UE enters RRC_INACTIVE.

[0218] When the UE is in RRC_INACTIVE, if the criteria for restoring the RRC connection are met (e.g., the UE receives a paging message, or the UE has MO data to transmit, or the UE receives a paging message or a RAN update / location update is triggered, etc.) (or the criteria for performing a small data transmission procedure are met), the UE initiates RRC connection restoration (or RRC connection restoration for small data transmission).

[0219] If the UE supports enhanced recovery protection, and the last gNB the UE was connected to also supports enhanced recovery protection (e.g., receiving enhancedResumeProtectionEnabled in the RRCRelease message when the last RRC connection is suspended, or receiving enhancedResumeProtectionEnabled from the last gNB the UE was connected to (in an SI, RRC, or NAS message): then the UE uses the enhanced method for recovery protection (operation 2 below) to generate ResumeMAC-I. Otherwise: the UE uses the current method (operation 1 below) to generate ResumeMAC-I.

[0220] The UE sends an RRRCResumeRequest with ResumeMAC-I to the gNB / eNB.

[0221] If the gNB / eNB to which the UE sends a recovery request is different from the gNB / eNB that has the UE context, then the new gNB / eNB to which the UE sends the recovery request sends a context request to the old gNB / eNB that has the UE context.

[0222] If the new gNB / eNB supports enhanced recovery protection, it will send the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends a context request along with the aforementioned information to the old gNB / eNB.

[0223] Alternatively, if the new gNB / eNB supports enhanced recovery protection and the UE has already generated resumeMAC-I using enhanced recovery protection (the new gNB can identify that the UE has generated resumeMAC-I using enhanced recovery protection based on the indication in the ResumeRequest message or the LCID used for the ResumeRequest; a different LCID can be used in the case of enhanced recovery protection, and the LCID is carried in the MAC subheader of the MAC PDU carrying the ResumeRequest): then the new gNB / eNB sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the aforementioned information.

[0224] Otherwise: The new gNB / eNB only sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the above information.

[0225] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection, and the old gNB / eNB also supports enhanced recovery protection, then the old gNB / eNB identifies whether it has received the recovery reason and standby bit from the new gNB / eNB.

[0226] 2> If the recovery reason and standby bit are received from the new gNB / eNB: the old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, standby bit, ResumeIdentity) to generate ResumeMAC-I.

[0227] 2> Otherwise, the ResumeMAC-I verification is considered to have failed, and the new gNB sends an RRCReject to the UE.

[0228] 1> Otherwise:

[0229] 2> Old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0230] If the gNB / eNB to which the UE sent the recovery request is the same as the gNB / eNB with the UE context:

[0231] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection and the gNB / eNB also supports enhanced recovery protection:

[0232] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, spare bit, ResumeIdentity) to generate ResumeMAC-I.

[0233] 1> Otherwise:

[0234] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0235] Example 2: In another embodiment of this method disclosed herein, the operation for enhanced connection recovery (i.e., RCResumeRequest / RRCResumeRequest1 messages) protection is as follows:

[0236] The UE is in RRC_CONNECTED.

[0237] The UE receives the UECapabilityEnquiry message from the gNB / eNB.

[0238] If the UE supports Enhanced Resume Protection, it indicates to the gNB / eNB that it supports Enhanced Resume Protection; that is, the UE includes `enhancedResumeProtectionSupported` in the UECapabilityInformation message. Otherwise, the UE does not include `enhancedResumeProtectionSupported` in the UECapabilityInformation message. The UE sends a UECapabilityInformation message to the gNB / eNB. In an alternative embodiment, if the UE supports Enhanced Resume Protection, it can indicate to the gNB / eNB that it supports Enhanced Resume Protection by including `enhancedResumeProtectionSupported` in another message, such as a UEAssistanceInformation message, or any other RRC or NAS message.

[0239] At some point, the gNB / eNB sends an RRCRelease message with suspendConfig to release the ongoing RRC connection. If the UE supports Enhanced Resume Protection and the gNB / eNB also supports Enhanced Resume Protection, the gNB includes enhancedResumeProtectionEnabled (also known as enhancedResumeProtectionSupported, or it can be any other parameter indicating that the gNB / eNB enables / supports Enhanced Resume Protection) in the RRCRelease message. enhancedResumeProtectionEnabled can be added to the suspendConfig IE. In alternative embodiments, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in system information (e.g., in some SIBs). In alternative embodiments, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in any other RRC or NAS message.

[0240] Upon receiving an RRCRelease message with suspendConfig, the UE enters RRC_INACTIVE.

[0241] When the UE is in RRC_INACTIVE, if the criteria for restoring the RRC connection are met (e.g., the UE receives a paging message, or the UE has MO data to transmit, or the UE receives a paging message or a RAN update / location update is triggered, etc.) (or the criteria for performing a small data transmission procedure are met), the UE initiates RRC connection restoration (or RRC connection restoration for small data transmission).

[0242] If the UE supports enhanced recovery protection, and the last gNB the UE was connected to supports enhanced recovery protection (e.g., receiving enhancedResumeProtectionEnabled in the RRCRelease message when the last RRC connection was suspended, or receiving enhancedResumeProtectionEnabled from the last gNB the UE was connected to (in an SI, RRC, or NAS message), and the currently camped cell supports enhanced recovery protection (the current gNB can broadcast enhancedResumeProtectionEnabled in the SI): then the UE uses the enhanced method for recovery protection (operation 2 below) to generate ResumeMAC-I. Otherwise: the UE uses the current method (operation 1 below) to generate ResumeMAC-I.

[0243] The UE sends an RRRCResumeRequest with ResumeMAC-I to the gNB / eNB.

[0244] If the gNB / eNB to which the UE sends a recovery request is different from the gNB / eNB that has the UE context, then the new gNB / eNB to which the UE sends the recovery request sends a context request to the old gNB / eNB that has the UE context.

[0245] If the new gNB / eNB supports enhanced recovery protection, it will send the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends a context request along with the aforementioned information to the old gNB / eNB.

[0246] Alternatively, if the new gNB / eNB supports enhanced recovery protection and the UE has already generated resumeMAC-I using enhanced recovery protection (the new gNB can identify that the UE has generated resumeMAC-I using enhanced recovery protection based on the indication in the ResumeRequest message or the LCID used for the ResumeRequest; a different LCID can be used in the case of enhanced recovery protection, and the LCID is carried in the MAC subheader of the MAC PDU carrying the ResumeRequest): then the new gNB / eNB sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, ResumeMAC-I, and spare bits from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the aforementioned information.

[0247] Otherwise: The new gNB / eNB only sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the above information.

[0248] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection, and the old gNB / eNB also supports enhanced recovery protection, and if resumeCause and standby bits are received from the new gNB / eNB:

[0249] 2> Old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, spare bit, ResumeIdentity) to generate ResumeMAC-I.

[0250] 1> Otherwise:

[0251] 2> Old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0252] If the gNB / eNB to which the UE sent the recovery request is the same as the gNB / eNB with the UE context:

[0253] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection and the gNB / eNB also supports enhanced recovery protection:

[0254] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, spare bit, ResumeIdentity) to generate ResumeMAC-I.

[0255] 1> Otherwise:

[0256] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0257] ResumeMAC-I generation details:

[0258] Operation 1:

[0259] Security Key: KEY(K) RRCint BEARER: set to 1; DIRECTION: set to 1; and COUNT: set to 1.

[0260] MESSAGE:

[0261] Source PCI (set to the physical cell identifier of the PCell to which the UE connects before the RRC connection is suspended);

[0262] The target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in SIB1 of the cell to which the UE is sending a recovery request); and

[0263] Source C-RNTI (set to the C-RNTI that the UE has in its connected PCell before the RRC connection is suspended).

[0264] Use the security key (KEY) and the inputs set above (BEARER, DIRECTION, COUNT) to generate a MAC-I via a message (set above).

[0265] Operation 2:

[0266] Security Key: KEY(K) RRCint BEARER: set to 1; DIRECTION: set to 1; and COUNT: set to 1.

[0267] MESSAGE:

[0268] Source PCI (set to the physical cell identifier of the PCell to which the UE connects before the RRC connection is suspended);

[0269] Target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in the SIB1 of the cell to which the UE is sending a recovery request);

[0270] Source C-RNTI (set to the C-RNTI that the UE had in its connected PCell before the RRC connection was suspended);

[0271] Resume Cause;

[0272] spare position; and

[0273] Restore the identifier.

[0274] Use the security key (KEY) and the inputs set above (BEARER, DIRECTION, COUNT) to generate a MAC-I via a message (set above).

[0275] Method 4:

[0276] Example 1: In one embodiment of this method disclosed herein, the operation for enhanced connection recovery (i.e., RCResumeRequest / RRCResumeRequest1 messages) protection is as follows:

[0277] The UE is in RRC_CONNECTED.

[0278] The UE receives the UECapabilityEnquiry message from the gNB / eNB.

[0279] If the UE supports Enhanced Resume Protection, it indicates to the gNB / eNB that it supports Enhanced Resume Protection; that is, the UE includes `enhancedResumeProtectionSupported` in the UECapabilityInformation message. Otherwise, the UE does not include `enhancedResumeProtectionSupported` in the UECapabilityInformation message. The UE sends a UECapabilityInformation message to the gNB / eNB. In an alternative embodiment, if the UE supports Enhanced Resume Protection, it can indicate to the gNB / eNB that it supports Enhanced Resume Protection by including `enhancedResumeProtectionSupported` in another message, such as a UEAssistanceInformation message, or any other RRC or NAS message.

[0280] At some point, the gNB / eNB sends an RRCRelease message with suspendConfig to release the ongoing RRC connection. If the UE supports Enhanced Resume Protection and the gNB / eNB also supports Enhanced Resume Protection, the gNB includes enhancedResumeProtectionEnabled (also known as enhancedResumeProtectionSupported, or it can be any other parameter indicating that the gNB / eNB enables / supports Enhanced Resume Protection) in the RRCRelease message. enhancedResumeProtectionEnabled can be added to the suspendConfig IE. In alternative embodiments, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in system information (e.g., in some SIBs). In alternative embodiments, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in any other RRC or NAS message.

[0281] Upon receiving an RRCRelease message with suspendConfig, the UE enters RRC_INACTIVE.

[0282] When the UE is in RRC_INACTIVE, if the criteria for restoring the RRC connection are met (e.g., the UE receives a paging message, or the UE has MO data to transmit, or the UE receives a paging message or a RAN update / location update is triggered, etc.) (or the criteria for performing a small data transmission procedure are met), the UE initiates RRC connection restoration (or RRC connection restoration for small data transmission).

[0283] If the UE supports enhanced recovery protection, and the last gNB the UE was connected to also supports enhanced recovery protection (e.g., receiving enhancedResumeProtectionEnabled in the RRCRelease message when the last RRC connection is suspended, or receiving enhancedResumeProtectionEnabled from the last gNB the UE was connected to (in an SI, RRC, or NAS message): then the UE uses the enhanced method for recovery protection (operation 2 below) to generate ResumeMAC-I. Otherwise: the UE uses the current method (operation 1 below) to generate ResumeMAC-I.

[0284] The UE sends an RRRCResumeRequest with ResumeMAC-I to the gNB / eNB.

[0285] If the gNB / eNB to which the UE sends a recovery request is different from the gNB / eNB that has the UE context, then the new gNB / eNB to which the UE sends the recovery request sends a context request to the old gNB / eNB that has the UE context.

[0286] If the new gNB / eNB supports enhanced recovery protection, it will send the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends a context request along with the aforementioned information to the old gNB / eNB.

[0287] Alternatively, if the new gNB / eNB supports enhanced recovery protection and the UE has already generated resumeMAC-I using enhanced recovery protection (the new gNB can identify that the UE has generated resumeMAC-I using enhanced recovery protection based on the indication in the ResumeRequest message or the LCID used for the ResumeRequest; a different LCID can be used in the case of enhanced recovery protection, and the LCID is carried in the MAC subheader of the MAC PDU carrying the ResumeRequest): then the new gNB / eNB sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the aforementioned information.

[0288] Otherwise: The new gNB / eNB only sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the above information.

[0289] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection, and the old gNB / eNB also supports enhanced recovery protection, then the old gNB / eNB identifies whether it has received a recovery reason from the new gNB / eNB.

[0290] 2> If a recovery reason is received from the new gNB / eNB: the old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, resumeIdentity) to generate ResumeMAC-I.

[0291] 2> Otherwise, the ResumeMAC-I verification is considered to have failed, and the new gNB sends an RRCReject to the UE.

[0292] 1> Otherwise:

[0293] 2> Old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0294] If the gNB / eNB to which the UE sent the recovery request is the same as the gNB / eNB with the UE context:

[0295] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection and the gNB / eNB also supports enhanced recovery protection:

[0296] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, resumeIdentity) to generate ResumeMAC-I.

[0297] 1> Otherwise:

[0298] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0299] Example 2: In another embodiment of this method disclosed herein, the operation for enhanced connection recovery (i.e., RRCresumeRequest / RRRCresumeRequest1 messages) protection is as follows:

[0300] The UE is in RRC_CONNECTED.

[0301] The UE receives the UECapabilityEnquiry message from the gNB / eNB.

[0302] If the UE supports Enhanced Resume Protection, it indicates to the gNB / eNB that it supports Enhanced Resume Protection; that is, the UE includes `enhancedResumeProtectionSupported` in the UECapabilityInformation message. Otherwise, the UE does not include `enhancedResumeProtectionSupported` in the UECapabilityInformation message. The UE sends a UECapabilityInformation message to the gNB / eNB. In an alternative embodiment, if the UE supports Enhanced Resume Protection, it can indicate to the gNB / eNB that it supports Enhanced Resume Protection by including `enhancedResumeProtectionSupported` in another message, such as a UEAssistanceInformation message, or any other RRC or NAS message.

[0303] At some point, the gNB / eNB sends an RRCRelease message with suspendConfig to release the ongoing RRC connection. If the UE supports Enhanced Resume Protection and the gNB / eNB also supports Enhanced Resume Protection, the gNB includes enhancedResumeProtectionEnabled (also known as enhancedResumeProtectionSupported, or it can be any other parameter indicating that the gNB / eNB enables / supports Enhanced Resume Protection) in the RRCRelease message. enhancedResumeProtectionEnabled can be added to the suspendConfig IE. In alternative embodiments, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in system information (e.g., in some SIBs). In alternative embodiments, the gNB can indicate its support for Enhanced Resume Protection by including enhancedResumeProtectionEnabled in any other RRC or NAS message.

[0304] Upon receiving an RRCRelease message with suspendConfig, the UE enters RRC_INACTIVE.

[0305] When the UE is in RRC_INACTIVE, if the criteria for restoring the RRC connection are met (e.g., the UE receives a paging message, or the UE has MO data to transmit, or the UE receives a paging message or a RAN update / location update is triggered, etc.) (or the criteria for performing a small data transmission procedure are met), the UE initiates RRC connection restoration (or RRC connection restoration for small data transmission).

[0306] If the UE supports enhanced recovery protection, and the last gNB the UE was connected to supports enhanced recovery protection (e.g., receiving enhancedResumeProtectionEnabled in the RRCRelease message when the last RRC connection was suspended, or receiving enhancedResumeProtectionEnabled from the last gNB the UE was connected to (in an SI, RRC, or NAS message), and the currently camped cell supports enhanced recovery protection (the current gNB can broadcast enhancedResumeProtectionEnabled in the SI): then the UE uses the enhanced method for recovery protection (operation 2 below) to generate ResumeMAC-I. Otherwise: the UE uses the current method (operation 1 below) to generate ResumeMAC-I.

[0307] The UE sends an RRRCResumeRequest with ResumeMAC-I to the gNB / eNB.

[0308] If the gNB / eNB to which the UE sends a recovery request is different from the gNB / eNB with the UE context, then the new gNB / eNB to which the UE sends the recovery request sends a context request to the old gNB / eNB with the UE context.

[0309] If the new gNB / eNB supports enhanced recovery protection, it will send the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends a context request along with the aforementioned information to the old gNB / eNB.

[0310] Alternatively, if the new gNB / eNB supports enhanced recovery protection and the UE has already generated resumeMAC-I using enhanced recovery protection (the new gNB can identify that the UE has generated resumeMAC-I using enhanced recovery protection based on the indication in the ResumeRequest message or the LCID used for the ResumeRequest; a different LCID can be used in the case of enhanced recovery protection, and the LCID is carried in the MAC subheader of the MAC PDU carrying the ResumeRequest): then the new gNB / eNB sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB receives the UE's recovery identifier (e.g., I-RNTI), target cell ID, resumeCause, and ResumeMAC-I from the UE in the RRCResumeRequest message. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the aforementioned information.

[0311] Otherwise: The new gNB / eNB only sends the UE's recovery identifier (e.g., I-RNTI), target cell ID, and ResumeMAC-I to the old gNB / eNB. The new gNB / eNB uses the recovery identifier to identify the old gNB / eNB and sends it a context request along with the above information.

[0312] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection and the legacy gNB / eNB also supports enhanced recovery protection:

[0313] 2> Old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, resumeIdentity) to generate ResumeMAC-I.

[0314] 1> Otherwise:

[0315] 2> Old gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0316] If the gNB / eNB to which the UE sent the recovery request is the same as the gNB / eNB with the UE context:

[0317] 1> If, based on the AS context stored by the UE, the UE supports enhanced recovery protection and the gNB / eNB also supports enhanced recovery protection:

[0318] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI, resumeCause, resumeIdentity) to generate ResumeMAC-I.

[0319] 1> Otherwise:

[0320] 2> gNB / eNB uses KEY, BEARER, DIRECTION, COUNT and MESSAGE (source PCI, target cell ID, source C-RNTI) to generate ResumeMAC-I.

[0321] ResumeMAC-I generation details:

[0322] Operation 1:

[0323] Security Key: KEY(K) RRCint BEARER: set to 1; DIRECTION: set to 1; and COUNT: set to 1.

[0324] MESSAGE:

[0325] Source PCI (set to the physical cell identifier of the PCell to which the UE connects before the RRC connection is suspended);

[0326] The target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in SIB1 of the cell to which the UE is sending a recovery request); and

[0327] Source C-RNTI (set to the C-RNTI that the UE has in its connected PCell before the RRC connection is suspended).

[0328] Use the security key (KEY) and the inputs set above (BEARER, DIRECTION, COUNT) to generate a MAC-I via a message (set above).

[0329] Operation 2:

[0330] Security Key: KEY(K) RRCint BEARER: set to 1; DIRECTION: set to 1; and COUNT: set to 1.

[0331] MESSAGE:

[0332] Source PCI (set to the physical cell identifier of the PCell to which the UE connects before the RRC connection is suspended);

[0333] Target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in the SIB1 of the cell to which the UE is sending a recovery request);

[0334] Source C-RNTI (set to the C-RNTI that the UE had in its connected PCell before the RRC connection was suspended);

[0335] ResumeCause; and

[0336] ResumeIdentity.

[0337] Use the security key (KEY) and the inputs set above (BEARER, DIRECTION, COUNT) to generate a MAC-I via a message (set above).

[0338] Small data transmission

[0339] In 5G wireless communication systems, small data transmission (SDT) is supported in the RRC_INACTIVE state. In the case of a 4-step random access (RA) procedure, uplink data can be transmitted in message 3 (Msg3), and in the case of a 2-step RA procedure, uplink data is transmitted in MSGA.

[0340] Figure 2 This is an example signaling stream using a 4-step RA for small data transmission according to embodiments of this disclosure.

[0341] If the criteria for initiating a 4-step RA for SDT are met, the UE selects a preamble / RO from the preamble / random access channel (RACH) timing (RO) for SDT. The UE transmits the random access preamble in operation 210 and receives a random access response (RAR) including UL permission for Msg3 transmission in operation 220.

[0342] In operation 230, the UE sends RRCResumeRequest / RRRCResumeRequest1 and uplink data to the gNB (identical to the last serving gNB) on Signalling Radio Bearer 0 (SRB0). This includes a full / short I-RNTI (resumeIdentity), a resume cause, and an authentication token (resumeMAC-I). The I-RNTI (short or full I-RNTI) is used for context identification, and its value should be the same as the I-RNTI received by the UE from the last serving gNB in ​​the RRCResume message with the suspendConfig message. The ResumeMAC-I is a 16-bit message authentication token, which the UE should use with the integrity algorithm from the stored Access Layer (AS) security context (either the 5G Integrity Algorithm (NIA) or the Evolved Packet System (EPS) Integrity Algorithm (EIA), negotiated between the UE and the last serving gNB) and the K from the stored AS security context. RRCint The following inputs are used to calculate the message authentication token:

[0343] -KEY: It should be set to the current key. RRCint ;

[0344] -BEARER: All its bits should be set to 1;

[0345] -DIRECTION: This bit should be set to 1;

[0346] -COUNT: All its bits should be set to 1; and

[0347] -MESSAGE: This should be set to VarResumeMAC-Input with the following input:

[0348] - Source PCI (set to the physical cell identifier of the PCell to which the UE connects before the RRC connection is suspended);

[0349] - Target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in SIB1 of the target cell (i.e., the cell to which the UE is sending small data); and

[0350] - Source C-RNTI (set to the C-RNTI that the UE has in its connected PCell before the RRC connection is suspended).

[0351] In an embodiment, the enhanced recovery protection method previously explained in this disclosure can be used to generate ResumeMAC-I.

[0352] The UE recovers one or more SRBs and one or more data radio bearers (DRBs), derives a new security key using the NextHopChainingCount provided in the RRCRelease message of the previous RRC connection, and rebuilds AS security. User data is encrypted and protected with integrity (only for DRBs configured with user plane (UP) integrity protection), and transmitted on a dedicated traffic channel (DTCH) multiplexed via RRCResumeRequest / RRCResumeRequest1 messages on the common control channel (CCCH) / CCCH1.

[0353] gNB verifies resumeMAC-I and delivers uplink data to the User Plane Function (UPF) in operation 240.

[0354] In operation 260, the gNB sends an RRCLease message to keep the UE in the RRC_INACTIVE state. The PDCCH is addressed to the temporary cell RNTI (TC-RNTI). If the downlink data received from the UPF in operation 250 is available, then in operation 260, the aforementioned downlink data is transmitted encrypted and protected with integrity on the DTCH multiplexed via the RRCLease message on the DCCH (only for DRBs configured with UP integrity protection).

[0355] In a gNB with a split architecture of Central Unit (CU) and Distributed Unit (DU), the CU includes gNB-CU-CP and gNB-CU-UP. The DU interacts with gNB-CU-CP via the F1-C interface. The DU interacts with gNB-CU-UP via the F1-U interface. The gNB-CU-CP interacts with gNB-CU-UP via the E1-C interface.

[0356] The DU receives the RRCResumeRequest / RRRCResumeRequest1 messages and uplink data from the UE. The DU sends the F1 Initial UL RRC Message Transmission message to the gNB-CU-CP. The F1 Initial UL RRC Message Transmission message includes the RRCResumeRequest / RRRCResumeRequest1 messages received from the UE.

[0357] In this embodiment, upon determining that the UE has initiated a small data transmission (this can be based on the received RA preamble or the presence of a Dedicated Control Channel (DCCH) / DTCH MAC Service Data Unit (SDU) in Msg3. Note that the RA preamble / RO used for SDT is different from the RA used for other purposes), the DU also includes uplink data in the initial UL RRC message transmission message. The gNB-CU-CP performs resumeMAC-I verification, and if the verification is successful, it sends the uplink data to the gNB-CU-UP via the E1 interface. The gNB-CU-UP processes the uplink data and sends the processed data to the UPF.

[0358] In another embodiment, the DU does not include uplink data in the initial UL RRC message transmission. This indicates that the UE has initiated a small data transmission recovery or that the UE has initiated a small data transmission. The DU can identify that the UE has initiated a small data transmission recovery based on the received RA preamble or based on the presence of the DCCH / DTCH MAC SDU in Msg3. Note that the RA preamble / RO used for SDT is different from the RA used for other purposes. It may also include the F1 downlink (DL) tunnel endpoint identifier (TEID) assigned to the DRB. The gNB-CU-CP performs the resumeMAC-I verification, and if the verification is successful, it sends an F1 UE context setting request message including the stored F1 UL TEID to create a UE context in the gNB-DU; the gNB-CU-CP also sends an E1 bearer context modification request with an RRC recovery indication (or an indication of small data transmission recovery) and the F1 DL TEID received from the DU. After receiving the context setting request from the gNB-CU-CP, the DU sends uplink data to the gNB-CU-UP via the F1-U interface.

[0359] Figure 3 The signaling stream for small data transmission using a 2-step RA is shown according to an embodiment of the present disclosure.

[0360] If the criteria for initiating a 2-step RA for SDT are met, the UE selects a preamble / RO / PO from the preamble / RO / paging timing (PO) for SDT. In operation 310, the UE transmits an MSGA including a random access preamble.

[0361] In Operation 320, within the MSGA payload, the UE sends RRCResumeRequest / RRRCResumeRequest1 and uplink data to the gNB (identical to the last serving gNB) on SRB0. This includes a full / short I-RNTI (resumeIdentity), a resume cause, and an authentication token (resumeMAC-I). The I-RNTI (short or full) is used for context identification, and its value should be the same as the I-RNTI received by the UE from the last serving gNB in ​​the RRCResume with the suspendConfig message. The ResumeMAC-I is a 16-bit message authentication token, which the UE should use with the integrity algorithm (NIA or EIA, negotiated between the UE and the last serving gNB) from the stored AS security context and the K from the stored AS security context. RRCint The following inputs are used to calculate the message authentication token:

[0362] -KEY: It should be set to the current key. RRCint ;

[0363] -BEARER: All its bits should be set to 1;

[0364] -DIRECTION: This bit should be set to 1;

[0365] -COUNT: All its bits should be set to 1; and

[0366] -MESSAGE: This should be set to VarResumeMAC-Input with the following input:

[0367] - Source PCI (set to the physical cell identifier of the PCell to which the UE connects before the RRC connection is suspended);

[0368] - Target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in SIB1 of the target cell (i.e., the cell to which the UE is sending small data); and

[0369] - Source C-RNTI (set to the C-RNTI that the UE has in its connected PCell before the RRC connection is suspended).

[0370] In an embodiment, the enhanced recovery protection method previously explained in this disclosure can be used to generate ResumeMAC-I.

[0371] The UE restores all SRBs and DRBs, derives a new security key using the NextHopChainingCount provided in the RRCLease message of the previous RRC connection, and rebuilds AS security. User data is encrypted and protected with integrity (only for DRBs configured with UP integrity protection) and transmitted on the DTCH multiplexed via the RRCResumeRequest / RRRCResumeRequest1 message on CCCH / CCCH1.

[0372] In operation 330, the gNB verifies resumeMAC-I and delivers uplink data to the UPF.

[0373] In operation 350, the gNB sends an RRCLease message in the MsgB to keep the UE in the RRC_INACTIVE state and sends a successRAR. The PDCCH is addressed to the C-RNTI. If downlink data received from the UPF in operation 340 is available, then in operation 350, on the DTCH multiplexed via the RRCLease message on the DCCH, they are transmitted encrypted and protected with integrity (only for DRBs configured with UP integrity protection).

[0374] In a CU-DU split architecture within a gNB, the CU comprises gNB-CU-CP and gNB-CU-UP. The DU interacts with gNB-CU-CP via the F1-C interface. The DU interacts with gNB-CU-UP via the F1-U interface. The gNB-CU-CP interacts with gNB-CU-UP via the E1-C interface.

[0375] The DU receives the RRCResumeRequest / RRRCResumeRequest1 messages and uplink data from the UE. The DU sends the F1 Initial UL RRC Message Transmission message to the gNB-CU-CP. The F1 Initial UL RRC Message Transmission message includes the RRCResumeRequest / RRRCResumeRequest1 messages received from the UE.

[0376] In this embodiment, upon determining that the UE has initiated a small data transmission (this can be based on the received RA preamble or the presence of the DCCH / DTCH MAC SDU in the MSGA. Note that the RA preamble / RO used for SDT is different from the RA used for other purposes), the DU also includes uplink data from the initial UL RRC message transmission message. The gNB-CU-CP performs resumeMAC-I verification, and if the verification is successful, it sends the uplink data to the gNB-CU-UP via the E1 interface. The gNB-CU-UP processes the uplink data and sends the processed data to the UPF.

[0377] In another embodiment, the DU does not include uplink data in the initial UL RRC message transmission message. This indicates that the UE has initiated a small data transmission recovery or that the UE has initiated a small data transmission. The DU can identify that the UE has initiated a small data transmission recovery based on the received RA preamble or based on the presence of the DCCH / DTCH MAC SDU in the MSGA. Note that the RA preamble / RO used for SDT is different from the RA used for other purposes. It may also include the F1 DL TEID assigned for the DRB. The gNB-CU-CP performs the resumeMAC-I verification, and if the verification is successful, it sends an F1 UE context setting request message including the stored F1 UL TEID to create a UE context in the gNB-DU; the gNB-CU-CP also sends an E1 bearer context modification request with an RRC recovery indication (or an indication of small data transmission recovery) and the F1 DL TEID received from the DU. After receiving the context setting request from the gNB-CU-CP, the DU sends uplink data to the gNB-CU-UP via the F1-U interface.

[0378] Preamble and Random Access Channel (RACH) Timing (RO) for Small Data Transmission

[0379] RO for small data transfers using 4-step random access (RA)

[0380] The RO used for small data transfers is not shared with the 4-step RO used for other purposes. However, the RO used for small data transfers (SDT) using the 4-step RA can be shared with the RO used for small data transfers using the 2-step RA. The gNB (in system information or dedicated RRC signaling (e.g., reconfiguration message)) sends the following parameters by signaling to configure the RO used for small data transfers using the 4-step RA.

[0381] prach-ConfigurationIndex-SDT refers to the physical RACH (PRACH) configuration index used for SDT using a 4-step RA. The gNB can choose not to signal prach-ConfigurationIndex-SDT. If the gNB does not signal prach-ConfigurationIndex-SDT, the UE can determine the PRACH timing for SDT based on msgA-PRACH-ConfigurationIndex-SDT (PRACH configuration index for SDT using a 2-step RA) configured / signaled by the gNB for SDT using a 2-step RA (i.e., in RACH-ConfigGenericTwoStepRA for SDT).

[0382] msg1-FDM-SDT refers to the number of times message 1 (Msg1) PRACH transmissions are performed for frequency division multiplexing of small data transmissions within a time instance. If this field is not present, the UE should use the value of msgA-RO-FDM-SDT from RACH-ConfigGenericTwoStepRA for SDT.

[0383] msg1-FrequencyStart-SDT refers to the offset of the lowest PRACH transmission timing in the frequency domain relative to Physical Resource Block (PRB) 0. If this field is not present, the UE should use the value of msgA-RO-FrequencyStart for SDT from RACH-ConfigGenericTwoStepRA for SDT.

[0384] For flexible signaling of RO used in SDT, the following parameters can be configured in the RACH configuration of SDT based on 4-step RA.

[0385]

[0386] When initiating a 4-step RA for small data transmission, the UE selects an RO from the ROs determined based on the parameters mentioned above.

[0387] RA preamble for SDT using 4-step RA

[0388] The following options are supported for determining the preamble for SDT using 4-step RA.

[0389] ssb-perRACH-Occasion-SDT(N1) is configured for SDT using 4-step RA.

[0390] CB-PreamblesPerSSB-SDT(X) is configured for use with 4-step RA in SDT.

[0391] The preamble used for the SDT with 4-step RA is determined as follows.

[0392] If N1 < 1, a Synchronization Signal (SS) / Physical Broadcast Channel (PBCH) block (SSB) is mapped to 1 / N1 consecutive valid PRACH opportunities, and the X-contention-based preamble with a consecutive index associated with the SS / PBCH block for each valid PRACH opportunity starts from preamble index 0. If N1 ≥ 1, the X-contention-based preamble with a consecutive index associated with the SS / PBCH block n (0 ≤ n ≤ N1-1) for each valid PRACH opportunity starts from preamble index 0. In the beginning, among them Provided by totalNumberOfRA-Preambles for the random access procedure used in SDT.

[0393] Alternatively:

[0394] CB-PreamblesPerSSB-SDT(X) is configured for use with 4-step RA in SDT.

[0395] ssb-perRACH-Occasion-SDT(N1) is configured for 4-step RA.

[0396] Configure the start preamble index (S) for using the 4-step RA in the SDT.

[0397] If N1 < 1, then an SS / PBCH block is mapped to 1 / N1 consecutive valid PRACH opportunities, and the X-contention-based preamble with a consecutive index associated with the SS / PBCH block for each valid PRACH opportunity starts from the preamble index S. If N1 ≥ 1, then the X-contention-based preamble with a consecutive index associated with the SS / PBCH block n (0 ≤ n ≤ N1 - 1) for each valid PRACH opportunity starts from the preamble index S. In the beginning, among them Provided by totalNumberOfRA-Preambles for the random access procedure used in SDT.

[0398] When initiating a 4-step RA for small data transmission, the UE selects a preamble from the preamble determined according to the parameters mentioned above.

[0399] The RACH parameters for small data transmission using 4-step RA are configured for the initial uplink (UL) bandwidth portion (BWP) (for Normal Uplink (NUL) and Supplementary Uplink (SUL) respectively). If any other UL BWP is used for SDT, the RACH parameters for small data transmission using 4-step RA can also be configured for these UL BWPs. If multiple preamble groups are supported for small data transmission using 4-step RA, information for determining the number of preambles per group is also configured in the RACH parameters for small data transmission using 4-step RA. Other parameters such as the Random Access Response (RAR) window, power ramp step size, and target received power can also be configured in the RACH parameters for small data transmission using 4-step RA, and if not configured, the corresponding parameters from the RAH configuration used for small data transmission using 2-step RA are applied to the UE. A separate BWP can be configured for SDT. Since the initial BWP may be narrow, while SDT may require a wider bandwidth (BW), alternatively, the UL grant in the RAR can indicate a resource block (RB) outside the initial BWP.

[0400] RO for SDT using 2-step RA

[0401] The RO used for small data transfers using 2-step RA is not shared with 2-step ROs used for other purposes. However, the RO used for small data transfers using 2-step RA (SDT) can be shared with the RO used for small data transfers using 4-step RA. The gNB (in system information or dedicated RRC signaling (e.g., reconfiguration message)) sends the following parameters by signaling to configure the RO used for small data transfers using 2-step RA.

[0402] msgA-PRACH-ConfigurationIndex-SDT refers to the PRACH configuration index used for SDT using a 2-step RA. The gNB can choose not to signal msgA-PRACH-ConfigurationIndex-SDT. If the gNB does not signal msgA-PRACH-ConfigurationIndex-SDT, the UE can determine the PRACH timing for the 2-step RA-based SDT based on the prach-ConfigurationIndex signaled by the gNB for SDT configuration / signaling using a 4-step RA.

[0403] msgA-RO-FDM-SDT refers to the number of times message A (MSGA) PRACH is transmitted within a time instance for frequency division multiplexing using SDT with 2-step RA. If this field is not present, the UE should use the value of msg1-RO-FDM sent by the gNB for SDT configuration / signaling with 4-step RA.

[0404] msgA-RO-FrequencyStart-SDT refers to the offset of the lowest PRACH transmission timing in the frequency domain relative to PRB 0. If this field is not present, the UE should use the value of msg1-FrequencyStart sent by the gNB for SDT configuration / signaling using 4-step RA.

[0405] For flexible signaling of RO used for SDT, the following parameters can be configured in the RACH configuration for SDT using 2-step RA.

[0406]

[0407] When initiating a 2-step RA for small data transmission, the UE selects an RO from the ROs determined according to the parameters mentioned above.

[0408] RA preamble for SDT using 2-step RA

[0409] The following options are supported for determining the preamble used for SDT.

[0410] Option 1: The 2-step RO for SDT using 2-step RA is the same as the 4-step RO for SDT using 4-step RA.

[0411] ssb-perRACH-Occasion(N1) is configured for use with 4-step RA in SDT.

[0412] CB-PreamblesPerSSB(R1) is configured for use with 4-step RA in SDT.

[0413] CB-PreamblesPerSSB-SDT(X) is configured for use with 2-step RA in SDT.

[0414] If N1 < 1, an SS / PBCH block is mapped to 1 / N1 consecutive valid PRACH opportunities, and the X-contention-based preamble with consecutive indices associated with the SS / PBCH block for each valid PRACH opportunity starts from preamble index R1. If N1 ≥ 1, the X-contention-based preamble with consecutive indices associated with SS / PBCH block n (0 ≤ n ≤ N1 - 1) for each valid PRACH opportunity starts from preamble index R1. In the beginning, among them Provided by totalNumberOfRA-Preambles for the random access procedure used in SDT. If totalNumberOfRA-Preambles is not configured, the UE is assumed to have a value of 64.

[0415] Alternatively:

[0416] CB-PreamblesPerSSB-SDT(X) is configured for use with 2-step RA in SDT.

[0417] ssb-perRACH-Occasion(N1) is configured for use with 4-step RA in SDT.

[0418] Configure the start preamble index (S) for using the 2-step RA in the SDT.

[0419] If N1 < 1, then an SS / PBCH block is mapped to 1 / N1 consecutive valid PRACH opportunities, and the X-contention-based preamble with a consecutive index associated with the SS / PBCH block for each valid PRACH opportunity starts from the preamble index S. If N1 ≥ 1, then the X-contention-based preamble with a consecutive index associated with the SS / PBCH block n (0 ≤ n ≤ N1 - 1) for each valid PRACH opportunity starts from the preamble index S. In the beginning, among them Provided by totalNumberOfRA-Preambles for the 2-step random access process.

[0420] Option 2: The RO used for SDT with 2-step RA is different from the RO used for SDT with 4-step RA.

[0421] CB-PreamblesPerSSB-SDT(X) is configured for use with 2-step RA in SDT.

[0422] ssb-perRACH-Occasion-SDT(Y) is configured for SDT using 2-step RA.

[0423] If Y < 1, an SS / PBCH block is mapped to 1 / Y consecutive valid PRACH opportunities, and the X-competition-based preamble with consecutive indices associated with the SS / PBCH block for each valid PRACH opportunity starts from preamble index 0. If Y ≥ 1, the X-competition-based preamble with consecutive indices associated with SS / PBCH block n (0 ≤ n ≤ Y - 1) for each valid PRACH opportunity starts from preamble index 0. In the beginning, among them Provided by totalNumberOfRA-Preambles used for the SDT 2-step random access procedure. If totalNumberOfRA-Preambles is not configured for the SDT 2-step random access procedure, the UE assumes a value of 64.

[0424] Simple options to cover shared (option 1) and non-shared (option 2)

[0425] Configure the start preamble index (S) for using the 2-step RA in the SDT.

[0426] CB-PreamblesPerSSB-SDT(X) is configured for use with 2-step RA in SDT.

[0427] ssb-perRACH-Occasion-SDT(Y) is configured for SDT using 2-step RA.

[0428] If Y < 1, an SS / PBCH block is mapped to 1 / Y consecutive valid PRACH opportunities, and the X-competition-based preamble with consecutive indices associated with the SS / PBCH block for each valid PRACH opportunity starts from the preamble index S. If Y ≥ 1, the X-competition-based preamble with consecutive indices associated with the SS / PBCH block n (0 ≤ n ≤ Y - 1) for each valid PRACH opportunity starts from the preamble index S. In the beginning, among them Provided by totalNumberOfRA-Preambles used for the SDT 2-step random access procedure. If totalNumberOfRA-Preambles is not configured for the SDT 2-step random access procedure, the UE assumes a value of 64.

[0429] When initiating a 2-step RA for small data transmission, the UE selects a preamble from the preamble determined according to the parameters mentioned above.

[0430] The RACH parameters for small data transmission using 2-step RA are configured for the initial UL BWP (for NUL and SUL respectively). If any other UL BWP is used for SDT, the RACH parameters for small data transmission using 2-step RA can also be configured for these UL BWPs. If multiple preamble groups are supported for small data transmission, information for determining the number of preambles per group is also configured in the RACH parameters for small data transmission using 2-step RA. Other parameters such as the message B (MSGB) window, power ramp step size, and target received power can also be configured in the RACH parameters for small data transmission using 2-step RA, and if not configured, the UE applies the corresponding parameters from RACH-ConfigGenericTwoStepRA used for 4-step RA.

[0431] A separate BWP can be configured for the SDT. Since the initial BWP may be narrow, the SDT may require a wider BW. Alternatively, the UL license in the RAR can indicate the RB in addition to the initial BWP.

[0432] Enhanced 4-step RA process for small data transfer

[0433] In the current small data transmission method using a 4-step RA, uplink data is transmitted in Msg3. This requires configuring different RACH preambles and / or RACH timings for small data transmission. Uplink transmission is also not contention-free, leading to wasted physical uplink shared channel (PUSCH) resources in the event of collisions. Therefore, an enhanced method is needed.

[0434] Figure 4 An enhanced 4-step RA process for SDT according to an embodiment of the present disclosure is shown.

[0435] During this process, the Msg3 MAC PDU includes a recovery identifier, a ResumeMAC-I, and the uplink data size (e.g., including the MAC PDU size from a MAC Service Data Unit (SDU) from a Dedicated Traffic Channel (DTCH) / DCCH or information about the buffer size in the DRB / Dedicated DTCH). Uplink data is not transmitted in Msg3. Uplink data is transmitted after contention resolution (i.e., reception of the contention resolution identifier). The UL clearance for the uplink data may be provided along with the contention resolution identifier message, or alternatively, it may be provided by the Physical Downlink Control Channel (PDCCH) addressed to the C-RNTI after contention resolution. Note that in embodiments, the UL data size may not be included in Msg3, and the UE may select a preamble from one of a preamble group, where each preamble group corresponds to a different MAC PDU (or uplink data) size.

[0436] The following options are supported for transmission in the Msg3 payload: {Resume Identifier, ResumeMAC-I, Uplink Data Size}.

[0437] Option 1: Defines a new RRC message: RCResumeRequestSDT / RRCResumeRequestSDT1.

[0438] RRCResumeRequestSDT / RRCResumeRequestSDT1 includes the recovery identifier, ResumeMAC-I, and uplink data size. No recovery reason is specified. ResumeMAC-I can be generated in the same way as in the RRCResumeRequest / RRCResumeRequest1 case.

[0439] Option 2: Use RRCResumeRequest / RRCResumeRequest1 by modification.

[0440] The spare bit indicator recovery is used for small data transmissions.

[0441] The recovery reason code point indicates the uplink data size.

[0442] Option 3: RRCResumeRequest / RRCResumeRequest1 includes the recovery identifier, ResumeMAC-I, and recovery reason.

[0443] Uplink data size is included in the MAC control element (CE). An example of a MAC CE could be a BSR MAC CE, which includes the buffer size of one or more logical channels (LCHs) or logical channel groups (LCGs) associated with a DRB / SRB that allows SDT.

[0444] Note that when initiating a small data transfer using the method described above, a Buffer Status Report (BSR) is not triggered in the MAC. In other words, the BSR is not included in Msg3. In another embodiment, for both Msg3 and MSGA MAC PDUs of the RA initiated for a small data transfer, a short BSR is triggered / included. The BSR can be determined as follows:

[0445] For regular and periodic BSRs, the MAC entity should:

[0446] 1> When constructing a MAC PDU that includes a BSR; and when the MAC PDU to be constructed is not a Msg3 or MSGA for small data transmission, if more than one Logical Channel Group (LCG) has data available for transmission:

[0447] 2> The report is for the long BSR of all LCGs that have data available for transmission.

[0448] 1> Otherwise:

[0449] 2> Report a short BSR.

[0450] Figure 4 The signaling flow for small data transmission using a 4-step RA is illustrated according to an embodiment of this disclosure. In this case, it is assumed that the gNB has the context of the UE.

[0451] 1. If the criteria for initiating a 4-step RA are met, the UE selects an SSB and then selects a preamble / RO for the selected SSB. The UE transmits the random access preamble in operation 410 and receives a RAR including UL clearance for Msg3 transmission in operation 420. For the RAR, the UE monitors the PDCCH addressed to RA-RNTI in the RAR search space. RA-RNTI is calculated as follows: RA-RNTI = 1 + s_id + 14 * t_id + 14 * 80 * f_id + 14 * 80 * 8 * ul_carrier_id, where s_id is the index of the first orthogonal frequency division multiplexing (OFDM) symbol of the PRACH timing, where the UE has transmitted Msg1, i.e., the RA preamble (0 ≤ s_id < 14); t_id is the index of the first time slot of the PRACH timing (0 ≤ t_id < 80); f_id is the index of the PRACH timing within the time slot in the frequency domain (0 ≤ f_id < 8), and ul_carrier_id is the UL carrier used for Msg1 transmission (0 for normal UL (NUL) carrier and 1 for supplementary UL (SUL) carrier).

[0452] 2. In Operation 430, within the Msg3 payload, the UE sends the full / short I-RNTI (resumeIdentity), ResumeMAC-I, and uplink data size, as described above, to the gNB (identical to the last serving gNB) on SRB 0, as included in the RRC message / MAC CE. The I-RNTI (short or full I-RNTI) is used for context identification, and its value should be the same as the I-RNTI received by the UE from the last serving gNB in ​​the RRC Release with the suspendConfig message. The ResumeMAC-I is a 16-bit message authentication token. The UE should use the integrity algorithm from the stored Access Layer (AS) security context (the Integrity Algorithm for 5G (NIA) or the Evolved Packet System (EPS) Integrity Algorithm (EIA), which is negotiated between the UE and the last serving gNB) and the K from the stored AS security context. RRCint The following inputs are used to calculate the message authentication token:

[0453] -KEY: It should be set to the current key. RRCint ;

[0454] -BEARER: All its bits should be set to 1;

[0455] -DIRECTION: This bit should be set to 1;

[0456] -COUNT: All its bits should be set to 1; and

[0457] -MESSAGE: This should be set to VarResumeMAC-Input with the following input:

[0458] - Source PCI (set to the physical cell identifier of the PCell to which the UE connects before the RRC connection is suspended);

[0459] - Target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in SIB1 of the target cell (i.e., the cell to which the UE is sending small data); and

[0460] - Source C-RNTI (set to the C-RNTI that the UE has in its connected PCell before the RRC connection is suspended).

[0461] Note that resumeCause and / or I-RNTI may also be included in the MESSAGE. In an embodiment, the enhanced recovery protection method previously explained in this disclosure can be used to generate ResumeMAC-I.

[0462] The UE restores one or more signaling radio bearers (SRBs) and one or more data radio bearers (DRBs), derives a new security key using the NextHopChainingCount provided in the RRCLease message of the previous RRC connection, and rebuilds AS security. User data is encrypted and protected for integrity (only for DRBs configured with user plane (UP) integrity protection).

[0463] 3. gNB verifies resumeMAC-I. After verification, in operation 440, the gNB sends Msg4, which includes the contention resolution identifier.

[0464] 4. The RA procedure is considered complete after receiving a contention resolution identifier that matches the Common Control Channel (CCCH) SDU transmitted in Msg3. The UE monitors the PDCCH addressed to the C-RNTI received in the RAR.

[0465] 5. In operation 450, the UE transmits uplink data with the received UL clearance. In operation 460, the gNB sends uplink data to the User Plane Function (UPF).

[0466] 6. In Operation 480, the gNB sends an RRCLease message to keep the UE in the RRC_INACTIVE state. The PDCCH of the downlink (DL) transport block (TB) carrying the RRCLease message is addressed to the C-RNTI. If downlink data from the UPF is available in Operation 470, then in Operation 480, the RRCLease message is transmitted encrypted and protected for integrity on the DTCH multiplexed over the dedicated control channel (DCCH) (only for DRBs configured with UP integrity protection). Alternatively, downlink data can be sent to the UE first, followed by the RRCLease message, but this will increase latency and PDCCH overhead.

[0467] Figure 5 The signaling flow for small data transmission using a 4-step RA is illustrated according to another embodiment of this disclosure. In this case, it is assumed that the gNB does not have the UE's context and obtains the context from the last serving gNB. A path handover is performed, and the context is released from the last serving gNB.

[0468] 1. If the criteria for initiating a 4-step RA are met, the UE selects an SSB and then selects a preamble / RO for the selected SSB. The UE transmits the random access preamble in operation 505 and receives a RAR including UL clearance for Msg3 transmission in operation 510. For the RAR, the UE monitors the PDCCH addressed to the RA-RNTI in the RAR search space. RA-RNTI is calculated as follows: RA-RNTI = 1 + s_id + 14 * t_id + 14 * 80 * f_id + 14 * 80 * 8 * ul_carrier_id, where s_id is the index of the first orthogonal frequency division multiplexing (OFDM) symbol of the PRACH timing, where the UE has transmitted Msg1, i.e., the RA preamble (0 ≤ s_id < 14); t_id is the index of the first time slot of the PRACH timing (0 ≤ t_id < 80); f_id is the index of the PRACH timing within the time slot in the frequency domain (0 ≤ f_id < 8), and ul_carrier_id is the UL carrier used for Msg1 transmission (0 for normal UL (NUL) carrier and 1 for supplementary UL (SUL) carrier).

[0469] 2. In Operation 515, within the Msg3 payload, the UE sends the full / short I-RNTI (resumeIdentity), ResumeMAC-I, and uplink data size, as described above, to the gNB (identical to the last serving gNB) on SRB 0, as included in the RRC message / MAC CE. The I-RNTI (short or full I-RNTI) is used for context identification, and its value should be the same as the I-RNTI received by the UE from the last serving gNB in ​​the RRC Release with the suspendConfig message. ResumeMAC-I is a 16-bit message authentication token. The UE should use the integrity algorithm (NIA or EIA) in the stored AS security context (negotiated between the UE and the last serving gNB) and the K from the stored AS security context. RRCint The following inputs are used to calculate the message authentication token:

[0470] -KEY: It should be set to the current key. RRCint ;

[0471] -BEARER: All its bits should be set to 1;

[0472] -DIRECTION: This bit should be set to 1;

[0473] -COUNT: All its bits should be set to 1; and

[0474] -MESSAGE: This should be set to VarResumeMAC-Input with the following input:

[0475] - Source PCI (set to the physical cell identifier of the PCell to which the UE connects before the RRC connection is suspended);

[0476] - Target cell ID (set to the cellIdentity of the first PLMN identifier included in the PLMN-IdentityInfoList broadcast in SIB1 of the target cell (i.e., the cell to which the UE is sending small data); and

[0477] - Source C-RNTI (set to the C-RNTI that the UE has in its connected PCell before the RRC connection is suspended).

[0478] Note that resumeCause and / or I-RNTI may also be included in the MESSAGE. In an embodiment, the enhanced recovery protection method previously explained in this disclosure can be used to generate ResumeMAC-I.

[0479] The UE restores one or more SRBs and one or more DRBs, uses the NextHopChainingCount provided in the RRCLease message of the previous RRC connection to derive a new security key, and rebuilds AS security. User data is encrypted and protected for integrity (only for DRBs configured with UP integrity protection).

[0480] 3. The gNB (i.e., the target gNB) identifies the gNB identifier of the last serving gNB (i.e., the source gNB) from the I-RNTI, and in operation 520, requests the source gNB to provide the UE's context data by sending a Retrieve UE Context Request message, including the following: I-RNTI, ResumeMAC-I, and Target Cell ID, to allow the source gNB to verify the UE request and retrieve the UE context. In an embodiment, the operation of verifying the UE request can be as defined in the enhanced recovery protection method previously explained in this disclosure.

[0481] 4. The last serving gNB (i.e., the source gNB) verifies the resumeMAC-I and provides the UE context data. The source gNB uses the I-RNTI to retrieve the stored UE context, including the UE 5G AS security context, from its database. The source gNB uses the current K stored in the retrieved UE 5G AS security context. RRCint The key is used to verify ResumeMAC-I (which is calculated in the same manner as described above). If the verification of ResumeMAC-I is successful (in embodiments, the operation of verifying ResumeMAC-I can be as defined in the enhanced recovery protection method previously explained in this disclosure), then the source gNB, based on whether the source gNB has unused {NCC, NH} pairs, uses the target cell PCI, target absolute radio frequency channel number (ARFCN)-DL, and K in the current UE 5G AS security context, according to whether the source gNB has unused {NCC, NH} pairs, based on horizontal key derivation or vertical key derivation. gNB / Next hop (NH) to calculate K NG-RAN * The parameter 'NCC' refers to the next-hop chain counter parameter. The source gNB can obtain the target PCI and target ARFCN-DL from the cell configuration database using the target cell ID received from the target gNB. Then, in operation 525, the source gNB should respond to the target gNB by retrieving a UE context response message using the Xn application protocol (AP), the message including the UE context containing the UE 5G AS security context. The UE 5G AS security context sent to the target gNB should include the newly derived K NG-RAN *、and K NG-RAN*The associated NCC, UE 5G security capabilities, UP security policies, UP security activation status with corresponding PDU session IDs, and encryption and integrity algorithms used by the UE and the source cell.

[0482] 5. After recovering the context from the last serving gNB, the gNB sends Msg4 in operation 530, including a contention resolution identifier. The gNB may include the UL license in or after Msg4. The gNB sends a PDCCH addressing to the C-RNTI of the UL license scheduled for uplink data transmission.

[0483] 6. After receiving a contention resolution flag that matches the CCCH SDU transmitted in Msg3, the RA procedure is considered complete. The UE monitors the PDCCH addressed to the C-RNTI received in the RAR.

[0484] 7. In operation 535, the UE transmits uplink data with the received UL permission. In operation 560, the gNB sends uplink data to the UPF.

[0485] 8. If it is necessary to prevent the loss of DL user data buffered in the last service gNB, then in operation 540, the gNB provides a forwarding address (i.e., an Xn-U address indication).

[0486] 9. gNB performs path switching. The gNB (i.e., the target gNB) transmits a path switching request message to the AMF in operation 545, and receives a path switching request response message from the AMF in operation 550.

[0487] 10. In operation 555, the gNB triggers the release of UE resources at the last serving gNB by transmitting a UE context release message.

[0488] 11. In operation 560, the gNB delivers uplink data to the UPF.

[0489] 12. In Operation 570, the gNB sends an RRCLease message to keep the UE in the RRC_INACTIVE state. The PDCCH of the DL TB carrying the RRCLease message is addressed to the C-RNTI. If downlink data from the UPF is available in Operation 565, then in Operation 570, the RRCLease message is transmitted encrypted and protected for integrity on the DTCH multiplexed over the DCCH (only for DRBs configured with UP integrity protection). Alternatively, downlink data can be sent to the UE first, followed by the RRCLease message, but this will increase latency and PDCCH overhead.

[0490] Steps 8 through 10 (i.e., operations 540, 545, 550, and 555) can also be performed after step 4 (i.e., operation 525).

[0491] In a CU-DU split architecture within a gNB, the CU comprises gNB-CU-CP and gNB-CU-UP. The DU interacts with gNB-CU-CP via the F1-C interface. The DU interacts with gNB-CU-UP via the F1-U interface. The gNB-CU-CP interacts with gNB-CU-UP via the E1-C interface.

[0492] The DU receives the RRCResumeRequest / RRRCResumeRequest1 messages and uplink data from the UE according to the enhanced small data transmission procedure described above. The DU sends an F1 Initial UL RRC Message Transmission message to the gNB-CU-CP. The F1 Initial UL RRC Message Transmission message includes the RRCResumeRequest / RRRCResumeRequest1 messages received from the UE.

[0493] In this embodiment, this indicates that the UE has initiated the resumption of small data transmission or that the UE has initiated small data transmission. The DU can identify that the UE has initiated the resumption of small data transmission based on the received RA preamble or based on the presence of the BSR MAC CE in MSGA / Msg3 or uplink data size information. Note that the RA preamble / RO used for SDT is different from the RA used for other purposes. It may also include the F1 DL TEID assigned for DRB. The gNB-CU-CP performs the verification of resumeMAC-I (as previously explained), and if the verification is successful, it sends an F1 UE context setting request message including the stored F1 UL TEID to create a UE context in the gNB-DU; the gNB-CU-CP also sends an E1 bearer context modification request with an RRC resumption indication (or indication of the resumption of small data transmission) and the F1 DL TEID received from the DU. After receiving the context setting request from the gNB-CU-CP, the DU sends the uplink data received from the UE to the gNB-CU-UP via the F1-U interface.

[0494] Figure 6 This is a block diagram of a terminal according to an embodiment of the present disclosure.

[0495] refer to Figure 6 The terminal includes a transceiver 610, a controller 620, and a memory 630. The controller 620 may refer to a circuit system, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or at least one processor. The transceiver 610, controller 620, and memory 630 are configured to execute... Figure 1Other parts of the diagram illustrate or describe the operation of the UE as described above. Although the transceiver 610, controller 620, and memory 630 are shown as separate entities, they can be integrated onto a single chip. The transceiver 610, controller 620, and memory 630 can also be electrically connected or coupled to each other.

[0496] Transceiver 610 can transmit signals to other network entities (e.g., a base station or another terminal) and receive signals from said other network entities.

[0497] The controller 620 can control the UE to perform functions according to the embodiments described above.

[0498] In this embodiment, the terminal operation can be implemented using a memory 630 that stores the corresponding program code. Specifically, the terminal may be equipped with a memory 630 to store program code that performs the desired operation. In order to perform the desired operation, the controller 620 can read and execute the program code stored in the memory 630 using a processor or a central processing unit (CPU).

[0499] Figure 7 This is a block diagram of a base station according to an embodiment of the present disclosure.

[0500] refer to Figure 7 The base station includes a transceiver 710, a controller 720, and a memory 730. The controller 720 may refer to a circuit system, an ASIC, an FPGA, or at least one processor. The transceiver 710, controller 720, and memory 730 are configured to perform the operations of the gNB shown in other parts of the figures or as described above. Although the transceiver 710, controller 720, and memory 730 are shown as separate entities, they can be integrated onto a single chip. The transceiver 710, controller 720, and memory 730 can also be electrically connected or coupled to each other.

[0501] Transceiver 710 can transmit signals to other network entities (e.g., terminals) and receive signals from said other network entities.

[0502] The controller 720 can control the gNB to perform functions according to the embodiments described above.

[0503] In this embodiment, the operation of the base station can be implemented using a memory 730 that stores corresponding program code. Specifically, the base station may be equipped with a memory 730 to store program code for implementing the desired operation. To perform the desired operation, the controller 720 can read and execute the program code stored in the memory 730 using a processor or CPU.

[0504] Although this disclosure has been shown and described with reference to various embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made therein without departing from the spirit and scope of this disclosure as defined by the appended claims and their equivalents.

Claims

1. A method for transmitting small data, performed by a terminal in a wireless communication system, the method comprising: Transmit a random access preamble to the target base station; Receive a random access response corresponding to the random access preamble from the target base station, wherein the random access response includes an uplink grant for transmission of message 3 Msg3; Based on the uplink permission used for Msg3 transmission, Msg3 is transmitted to the target base station, including a recovery identifier, a recovery integrity message authentication code MAC-I, and information about the uplink data size. If the recovery MAC-I is verified, a message 4Msg4 including a contention resolution identifier is received from the target base station, wherein the uplink grant for uplink data transmission is received in the Msg4 or after the Msg4 on the physical downlink control channel addressing the cell radio network temporary identifier C-RNTI received in the random access response. as well as Based on the uplink permission used for uplink data transmission, uplink data is transmitted to the target base station. Where the terminal and source base station support enhanced recovery protection, the recovery MAC-I is generated using a security key and inputs including bearer, direction, and count, through a first message containing the source physical cell identifier (PCI), target cell identifier (ID), source C-RNTI, recovery reason, and spare bits. Where the terminal and the source base station do not support enhanced recovery protection, the recovery MAC-I is generated using a security key and inputs including bearer, direction and count, through a second message containing the source PCI, the target cell ID and the source C-RNTI.

2. The method as described in claim 1, wherein, In the case where the Media Access Control (MAC) Protocol Data Unit (PDU) to be constructed, which includes a Buffer Status Report (BSR), is a Msg3 for small data transmission, the short BSR is included in the Msg3 for the small data transmission.

3. A method for transmitting small data by a target base station in a wireless communication system, the method comprising: Receive random access preamble from the terminal; A random access response corresponding to the random access preamble is transmitted to the terminal, wherein the random access response includes an uplink permission for transmission of message 3Msg3; Based on the uplink license used for Msg3 transmission, the terminal receives Msg3 including a recovery identifier, a recovery integrity message authentication code MAC-I, and information about the uplink data size. Verify the recovery of MAC-I; If the MAC-I recovery is verified, a message 4Msg4 including a contention resolution identifier is transmitted to the terminal, wherein an uplink grant for uplink data transmission is transmitted in Msg4 or, after Msg4, addressed to the physical downlink control channel of the Cell Radio Network Temporary Identifier (C-RNTI) transmitted in the random access response; and Based on the uplink license used for uplink data transmission, uplink data is received from the terminal. The recovery MAC-I is generated using a security key and inputs including bearer, direction, and count, when the terminal and source base station support enhanced recovery protection. This is achieved through a first message containing the source physical cell identifier (PCI), target cell identifier (ID), source C-RNTI, recovery reason, and spare bits. The recovery MAC-I is generated using a security key and inputs including bearer, direction, and count, through a second message containing the source PCI, the target cell ID, and the source C-RNTI, when the terminal does not support enhanced recovery protection.

4. The method of claim 3, wherein, The Msg3 used for the small data transmission includes a Short Buffer Status Report (BSR).

5. The method of claim 3, further comprising: Send a context retrieval request for the terminal to the source base station; as well as Receive the context of the terminal from the source base station.

6. A terminal for small data transmission in a wireless communication system, the terminal comprising: Transceiver (610); as well as Controller (620), the controller (620) being connected to the transceiver and configured to: Transmit a random access preamble to the target base station. Receive a random access response corresponding to the random access preamble from the target base station, wherein the random access response includes an uplink grant for transmission of message 3 (Msg3). Based on the uplink permission used for Msg3 transmission, Msg3 is transmitted to the target base station, including a recovery identifier, a recovery integrity message authentication code MAC-I, and information about the uplink data size. If the recovery MAC-I is verified, a message 4Msg4 including a contention resolution identifier is received from the target base station, wherein an uplink license for uplink data transmission is received in the Msg4 or received after the Msg4 on the physical downlink control channel addressing to the cell radio network temporary identifier C-RNTI received in the random access response. as well as Based on the uplink permission used for uplink data transmission, uplink data is transmitted to the target base station. Where the terminal and source base station support enhanced recovery protection, the recovery MAC-I is generated using a security key and inputs including bearer, direction, and count, through a first message containing the source physical cell identifier (PCI), target cell identifier (ID), source C-RNTI, recovery reason, and spare bits. Where the terminal and the source base station do not support enhanced recovery protection, the recovery MAC-I is generated using a security key and inputs including bearer, direction and count, through a second message containing the source PCI, the target cell ID and the source C-RNTI.

7. The terminal as described in claim 6, in, In the case where the Media Access Control (MAC) Protocol Data Unit (PDU) to be constructed, which includes a Buffer Status Report (BSR), is a Msg3 used for the small data transmission, the short BSR is included in the Msg3 used for the small data transmission.

8. A target base station for small data transmission in a wireless communication system, the target base station comprising: Transceiver (710); as well as Controller (720), which is connected to and configured with respect to transceiver (710): Receive random access preamble from the terminal. A random access response corresponding to the random access preamble is transmitted to the terminal, wherein the random access response includes an uplink permission for transmission of message 3 (Msg3). Based on the uplink license used for Msg3 transmission, Msg3 is received from the terminal via the transceiver, including a recovery identifier, a recovery integrity message authentication code (MAC-I), and information about the uplink data size. Verify the recovery of MAC-I. If the MAC-I recovery is verified, a message 4Msg4 including a contention resolution identifier is transmitted to the terminal, wherein an uplink grant for uplink data transmission is transmitted in Msg4 or, after Msg4, on the physical downlink control channel addressing to the Cell Radio Network Temporary Identifier (C-RNTI) transmitted in the random access response. Based on the uplink license used for uplink data transmission, uplink data is received from the terminal. The recovery MAC-I is generated using a security key and inputs including bearer, direction, and count, when the terminal and source base station support enhanced recovery protection. This is achieved through a first message containing the source physical cell identifier (PCI), target cell identifier (ID), source C-RNTI, recovery reason, and spare bits. The recovery MAC-I is generated using a security key and inputs including bearer, direction, and count, through a second message containing the source PCI, the target cell ID, and the source C-RNTI, when the terminal does not support enhanced recovery protection.

9. The target base station as described in claim 8, wherein, The Msg3 used for the small data transmission includes a Short Buffer Status Report (BSR).

10. The target base station as described in claim 8, wherein, The controller is also configured to: Send a context retrieval request for the terminal's context to the source base station; and Receive the context of the terminal from the source base station.

Images