CN115413059A - Apparatus and method for user equipment for resuming a small data transmission session - Google Patents

Abstract

The present disclosure provides methods and apparatus for a User Equipment (UE) for recovering a Small Data Transfer (SDT) session. The device includes: an interface; and a processor coupled with the interface and configured to: detecting an abnormal interruption of a first SDT session between the UE in RRC _ INACTIVE state and a first gNB; keeping the UE in an RRC _ INACTIVE state under the condition of detecting the abnormal interruption; a first recovery session for the first SDT session between the UE in RRC _ INACTIVE state and the second gNB is established based on a first NCC used in the first SDT session to continue SDT traffic transmission for the first SDT session, wherein the first NCC corresponds to the first gNB. Other embodiments are also disclosed and claimed.

Description

Apparatus and method for user equipment for recovering small data transmission sessions

Priority declaration

This application is based on U.S. provisional application serial No. 63/186,643, filed on 10/5/2021 and claiming priority from this application. The entire contents of this application are incorporated herein by reference in their entirety.

Technical Field

Embodiments of the present disclosure relate generally to wireless communications, and more particularly, to an apparatus and method for a User Equipment (UE) to resume a Small Data Transfer (SDT) session.

Background

Mobile communications have evolved significantly from early speech systems to today's highly sophisticated integrated communication platforms. Next generation wireless communication systems, fifth generation (5G) or New Radios (NR) will provide information access and data sharing through various terminals and applications anytime and anywhere. NR promises to be a unified network/system, aimed at meeting distinct and sometimes conflicting performance dimensions and services. This different multi-dimensional requirement is driven by different services and applications. In general, NRs can evolve based on third generation partnership project (3 GPP) Long Term Evolution (LTE) -advanced and other potential new Radio Access Technologies (RATs), enriching people's lives with better, simple, and seamless wireless connectivity solutions. The NR can enable everything over the wireless connection and provide fast, rich content and services.

Disclosure of Invention

An aspect of the present disclosure provides an apparatus, comprising: an interface; and a processor coupled with the interface and configured to: detecting an abnormal interruption of a first Small Data Transmission (SDT) session between a User Equipment (UE) in a Radio Resource Control (RRC) INACTIVE (RRC _ INACTIVE) state and a first next generation NodeB (gNB); keeping the UE in an RRC _ INACTIVE state when the abnormal interruption is detected; establishing a first recovery session for a first SDT session between the UE in RRC _ INACTIVE state and a second gNB based on a first next hop chain count (NCC) used in the first SDT session to continue SDT traffic transmission for the first SDT session, wherein the first NCC corresponds to the first gNB.

One aspect of the present disclosure provides a method, comprising: detecting an abnormal interruption of a first SDT session between the UE in RRC _ INACTIVE state and a first gNB; keeping the UE in an RRC _ INACTIVE state when the abnormal interruption is detected; establishing a first recovery session for the first SDT session between the UE in RRC _ INACTIVE state and a second gNB based on a first NCC used in the first SDT session to continue SDT traffic transmission for the first SDT session, wherein the first NCC corresponds to the first gNB.

Drawings

Embodiments of the disclosure will be described by way of example, and not limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

Fig. 1 illustrates an example architecture of a system according to some embodiments of the present disclosure.

Fig. 2 illustrates an example architecture of a system including a 5GC, according to some embodiments of the present disclosure.

Fig. 3 shows a flow diagram of an example of a conventional method for a Small Data Transfer (SDT) session.

Fig. 4 shows a flowchart of another example of a conventional method for an SDT session.

Fig. 5 shows an example of an abnormal interruption of an SDT session between a User Equipment (UE) and a gNB.

Fig. 6 shows a block diagram of an example of an apparatus for resuming an SDT session for a UE according to an embodiment of the present disclosure.

Fig. 7 shows a flowchart of an example of a method for resuming an SDT session for a UE according to an embodiment of the disclosure.

Figure 8 shows a schematic diagram of an example for a UE for resuming an SDT session, according to an embodiment of the disclosure.

Fig. 9 shows a schematic diagram of an example of an SDT session between a UE and a gNB, according to an embodiment of the disclosure.

Fig. 10 shows a schematic diagram of an example of a resume SDT session between a UE and a gNB, according to an embodiment of the disclosure.

Fig. 11 shows a schematic diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the disclosure.

Fig. 12 shows a schematic diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the disclosure.

Fig. 13 shows a schematic diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the disclosure.

Fig. 14 shows a schematic diagram of an example of a resume SDT session between a UE and a gNB, according to an embodiment of the disclosure.

Fig. 15 shows a schematic diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the disclosure.

Fig. 16 shows a schematic diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the disclosure.

Fig. 17 shows a schematic diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the disclosure.

Fig. 18 shows a schematic diagram of an example of a resume SDT session between a UE and a gNB, according to an embodiment of the disclosure.

Fig. 19 shows a schematic diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the disclosure.

Fig. 20 illustrates a network according to various embodiments of the disclosure.

Fig. 21 schematically illustrates a wireless network in accordance with various embodiments of the present disclosure.

Fig. 22 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium and performing any one or more of the methodologies discussed herein, according to some example embodiments.

Detailed Description

Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of the disclosure to others skilled in the art. However, it will be readily appreciated by those skilled in the art that many alternative embodiments may be practiced using portions of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to one skilled in the art that alternative embodiments may be practiced without the specific details. In other instances, well-known features may be omitted or simplified in order not to obscure the illustrative embodiments.

Further, various operations will be described as multiple discrete operations, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

The phrases "in an embodiment," "in one embodiment," and "in some embodiments" are used repeatedly herein. The phrase generally does not refer to the same embodiment; however, it may refer to the same embodiment. The terms "comprising," "having," and "including" are synonymous, unless the context dictates otherwise. The phrases "A or B" and "A/B" mean "(A), (B) or (A and B)".

Fig. 1 illustrates an example architecture of a system 100 according to some embodiments of the present disclosure. The following description is provided for an example system 100 operating in conjunction with the Long Term Evolution (LTE) system standard and the 5G or New Radio (NR) system standard provided by the 3GPP Technical Specification (TS). However, the example embodiments are not limited in this respect and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G)) systems, institute of Electrical and Electronics Engineers (IEEE) 802.16 protocols (e.g., wireless Metropolitan Area Network (MAN), worldwide Interoperability for Microwave Access (WiMAX), etc.), and so forth.

As shown in FIG. 1, the system 100 can include a UE101 a and a UE101b (collectively referred to as "UE(s) 101"). As used herein, the term "user equipment" or "UE" may refer to devices with radio communication capabilities and may describe remote users of network resources in a communication network. The terms "user equipment" or "UE" may be considered synonyms and may be referred to as a client, a mobile phone, a mobile device, a mobile terminal, a user terminal, a mobile unit, a mobile station, a mobile user, a subscriber, a user, a remote station, an access proxy, a user agent, a receiver, a radio, a reconfigurable mobile, and the like. Furthermore, the terms "user equipment" or "UE" may include any type of wireless/wired device or any computing device that includes a wireless communication interface. In this example, the UE101 is shown as a smartphone (e.g., a handheld touchscreen mobile computing device connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a consumer electronics device, a cellular phone, a smartphone, a feature phone, a tablet, a wearable computer device, a Personal Digital Assistant (PDA), a pager, a wireless handset, a desktop computer, a laptop computer, an in-vehicle infotainment system (IVI), an in-vehicle entertainment (ICE) device, a dashboard (Instrument Cluster, IC), a heads-up display (HUD) device, an in-vehicle diagnostics (OBD) device, a dashboard mobile Device (DME), a Mobile Data Terminal (MDT), an Electronic Engine Management System (EEMS), an electronic/Engine Control Unit (ECU), an electronic/Engine Control Module (ECM), an embedded system, a microcontroller, a control module, an Engine Management System (EMS), a networked or "smart" device, a Machine Type Communication (MTC) device, a machine-to-machine (M2M), an internet of things (IoT) device, and/or the like.

In some embodiments, any of the UEs 101 may include an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. IoT UEs may utilize technologies such as M2M or MTC to exchange data with MTC servers or devices via PLMNs, proximity-based services (ProSe) or device-to-device (D2D) communications, sensor networks, or IoT networks. The data exchange for M2M or MTC may be a machine-initiated data exchange. An IoT network describes interconnected IoT UEs that may include uniquely identifiable embedded computing devices (within the internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity of the IoT network.

UE101 may be configured to connect with (e.g., communicatively couple with) RAN 110. In an embodiment, RAN110 may be a Next Generation (NG) RAN or a 5G RAN, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), or a legacy RAN, such as a UTRAN (UMTS terrestrial radio access network) or a GERAN (GSM (global system for Mobile communications or group Sp specific Mobile) EDGE (GSM evolution) radio access network). As used herein, the term "NG RAN" or the like may refer to RAN110 operating in an NR or 5G system 100, and the term "E-UTRAN" or the like may refer to RAN110 operating in an LTE or 4G system 100. The UE101 utilizes connections (or channels) 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in further detail below). As used herein, the term "channel" may refer to any tangible or intangible transmission medium that communicates data or a stream of data. The term "channel" may be synonymous and/or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and/or any other similar term denoting a path or medium through which data is communicated. In addition, the term "link" may refer to a connection between two devices for the purpose of transmitting and receiving information over a Radio Access Technology (RAT).

In this example, connections 103 and 104 are shown as air interfaces to enable communicative coupling, and may be consistent with a cellular communication protocol, such as a global system for mobile communications (GSM) protocol, a Code Division Multiple Access (CDMA) network protocol, a push-to-talk (PTT) protocol, a cellular PTT (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and/or any other communication protocol discussed herein. In an embodiment, the UE101 may exchange communication data directly via the ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a Sidelink (SL) interface 105 and may include one or more logical channels including, but not limited to, a Physical Sidelink Control Channel (PSCCH), a physical sidelink shared channel (PSCCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

UE101b is shown configured to access an Access Point (AP) 106 (also referred to as "WLAN node 106", "WLAN terminal 106", or "WT106", etc.) via connection 107. The connection 107 may comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where the AP 106 would comprise a wireless fidelity (WiFi) router. In this example, the AP 106 is shown connected to the internet without being connected to the core network of the wireless system (described in further detail below). In various embodiments, UE101b, RAN110, and AP 106 may be configured to utilize LTE-WLAN aggregation (LWA) operations and/or WLAN LTE/WLAN radio level integration (LWIP) operations with IPsec tunneling. LWA operation may involve UE101b in RRC _ CONNECTED being configured by RAN node 111 to utilize radio resources of LTE and WLAN. The LWIP operation may involve the UE101b using WLAN radio resources (e.g., connection 107) via an internet protocol security (IPsec) protocol tunnel to authenticate and encrypt packets (e.g., internet Protocol (IP) packets) sent over the connection 107. An IPsec tunnel may include encapsulating the entire original IP packet and adding a new packet header to protect the original header of the IP packet.

RAN110 may include one or more RAN nodes 111a and 111b (collectively referred to as "RAN node(s) 111") that enable connections 103 and 104. As used herein, the terms "Access Node (AN)", "access point", "RAN node", and the like may describe a device that provides radio baseband functionality for data and/or voice connections between a network and one or more users. These access nodes may be referred to as Base Stations (BSs), next generation node BS (gnbs), RAN nodes, evolved nodebs (enbs), nodebs, road Side Units (RSUs), transmission receiving points (TRxP or TRP), etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the term "NG RAN node" or the like may refer to a RAN node 111 (e.g., a gNB) operating in the NR or 5G system 100, and the term "E-UTRAN node" or the like may refer to a RAN node 111 (e.g., an eNB) operating in the LTE or 4G system 100. According to various embodiments, the RAN node 111 may be implemented as one or more dedicated physical devices such as a macro cell base station and/or a Low Power (LP) base station for a femto cell, pico cell or other similar cell providing a smaller coverage area, smaller user capacity or higher bandwidth than a macro cell.

In some embodiments, all or part of the RAN node 111 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a Cloud Radio Access Network (CRAN) and/or a virtual baseband unit pool (vbbp). In these embodiments, the CRAN or vbbp may implement RAN functional partitioning, such as: PDCP partitioning, wherein RRC and PDCP layers are operated by the CRAN/vbbp, while other layer 2 (L2) protocol entities are operated by individual RAN nodes 111; MAC/PHY division, where RRC, PDCP, RLC and MAC layers are operated by the CRAN/vbup, and PHY layers are operated by individual RAN nodes 111; or "lower PHY" division, where the RRC, PDCP, RLC, MAC layers and upper parts of the PHY layers are operated by the CRAN/vbbp and the lower parts of the PHY layers are operated by the individual RAN node 111. The virtualization framework allows the processor cores of RAN node 111 to be freed up to execute other virtualized applications. In some implementations, the individual RAN nodes 111 may represent individual gNB-DUs that are connected to the gNB-CUs via individual F1 interfaces (not shown in fig. 1). In these implementations, the gNB-DUs may include one or more remote radio heads or radio front-end modules (RFEM), and the gNB-CUs may be operated by a server (not shown) located in the RAN110 or by a pool of servers in a similar manner to the CRAN/vbbp. Additionally or alternatively, one or more RAN nodes 111 may be next generation enbs (NG-enbs), which are RAN nodes that provide E-UTRA user plane and control plane protocol terminations towards the UE101 and which are connected to the 5GC via an NG interface.

In a V2X scenario, one or more RAN nodes 111 may be or act as RSUs. The term "roadside unit" or "RSU" may refer to any transportation infrastructure entity for V2X communication. The RSUs may be implemented in or by a suitable RAN node or a fixed (or relatively stationary) UE, where the RSUs implemented in or by the UE may be referred to as "UE-type RSUs," the RSUs implemented in or by the eNB may be referred to as "eNB-type RSUs," the RSUs implemented in or by the gNB may be referred to as "gNB-type RSUs," and so on. In one example, an RSU is a computing device coupled with radio frequency circuitry located at the roadside that provides connectivity support for a passing vehicle UE101 (vUE 101). The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications/software for sensing and controlling ongoing vehicular and pedestrian traffic. The RSU may operate on the 5.9GHz Direct Short Range Communication (DSRC) band to provide very low latency communications required for high speed events, such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU may operate on the cellular V2X frequency band to provide the low latency communications described above as well as other cellular communication services. Additionally or alternatively, the RSU may operate as a WiFi hotspot (2.4 GHz band) and/or provide a connection to one or more cellular networks to provide uplink and downlink communications. The computing device(s) and some or all of the radio frequency circuitry of the RSU may be enclosed in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide wired (e.g., ethernet) connectivity to a traffic signal controller and/or a backhaul network.

Any RAN node 111 may terminate the air interface protocol and may be the first point of contact for the UE 101. In some embodiments, any RAN node 111 may fulfill various logical functions of RAN110, including but not limited to Radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

In an embodiment, the UEs 101 may be configured to communicate with each other or any of the RAN nodes 111 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, orthogonal Frequency Division Multiple Access (OFDMA) communication techniques (e.g., for downlink communications) or single carrier frequency division multiple access (SC-FDMA) communication techniques (e.g., for uplink and ProSe or sidelink communications), using Orthogonal Frequency Division Multiplexing (OFDM) communication signals, although the scope of the embodiments is not limited in this respect. The OFDM signal may include a plurality of orthogonal subcarriers.

In some embodiments, the downlink resource grid may be used for downlink transmissions from any RAN node 111 to the UE101, while uplink transmissions may use similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is the physical resource in the downlink per slot. Such a time-frequency plane representation is common practice for OFDM systems, which makes radio resource allocation intuitive. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a set of resource elements; in the frequency domain, this may represent the minimum amount of resources that can currently be allocated. There are several different physical downlink channels transmitted using such resource blocks.

According to various embodiments, the UE101 and the RAN node 111 communicate (e.g., transmit and receive) data over a licensed medium (also referred to as "licensed spectrum" and/or "licensed band") and an unlicensed shared medium (also referred to as "unlicensed spectrum and/or" unlicensed band "). The licensed spectrum may include channels operating in a frequency range of about 400MHz to about 3.8GHz, while the unlicensed spectrum may include a 5GHz band.

To operate in unlicensed spectrum, the UE101 and RAN node 111 may operate using Licensed Assisted Access (LAA), enhanced LAA (eLAA), and/or other eLAA (feLAA) mechanisms. In these implementations, UE101 and RAN node 111 may perform one or more known medium sensing operations and/or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied prior to transmission in the unlicensed spectrum. The medium/carrier sensing operation may be performed according to a Listen Before Talk (LBT) protocol.

LBT is a mechanism in which a device (e.g., UE101, RAN node 111, etc.) senses a medium (e.g., a channel or carrier frequency) and transmits when the medium is sensed to be idle (or when a particular channel in the medium is sensed to be unoccupied). The medium sensing operation may include Clear Channel Assessment (CCA) that utilizes at least Energy Detection (ED) to determine whether other signals are present on the channel to determine whether the channel is occupied or clear. The LBT mechanism allows cellular/LAA networks to coexist with incumbent systems in unlicensed spectrum as well as with other LAA networks. ED may include sensing Radio Frequency (RF) energy over an expected transmission band for a period of time and comparing the sensed RF energy to a predetermined or configured threshold.

Generally, an incumbent system in the 5GHz band is a WLAN based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism known as carrier sense multiple access with collision avoidance (CSMA/CA). Here, when a WLAN node (e.g., a Mobile Station (MS) such as UE101, AP 106) intends to transmit, the WLAN node may first perform a CCA prior to the transmission. In addition, a back-off mechanism is used to avoid collisions in the case where more than one WLAN node senses the channel as idle and transmits at the same time. The back-off mechanism may be a counter drawn randomly within the Contention Window Size (CWS) that is exponentially increased when collisions occur and reset to a minimum value when the transmission is successful. The LBT mechanism designed for LAA is somewhat similar to CSMA/CA of WLAN. In some implementations, an LBT procedure for a DL or UL transmission burst including PDSCH or PUSCH transmissions, respectively, may have an LAA contention window of variable length between X and Y extended CCA (ECCA) slots, where X and Y are minimum and maximum values of a CWS for the LAA. In one example, the minimum CWS for LAA transmission may be 9 microseconds (μ β); however, the size of the CWS and the Maximum Channel Occupancy Time (MCOT) (e.g., transmission bursts) may be based on government regulatory requirements.

The LAA mechanism is established based on the Carrier Aggregation (CA) technique of the LTE-Advanced system. In CA, each aggregated carrier is referred to as a Component Carrier (CC). The CCs may have bandwidths of 1.4, 3, 5, 10, 15, or 20MHz, and may be aggregated for up to five CCs, and thus, the maximum aggregated bandwidth is 100MHz. In a Frequency Division Duplex (FDD) system, the number of aggregated carriers may be different for DL and UL, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, individual CCs may have different bandwidths than other CCs. In a Time Division Duplex (TDD) system, the number of CCs and the bandwidth of each CC are typically the same for DL and UL.

The CA also includes individual serving cells to provide individual CCs. The coverage of the serving cell may be different, e.g., because CCs on different frequency bands will experience different path losses. A primary serving cell or primary cell (PCell) may provide a primary CC (PCC) for both UL and DL and may handle Radio Resource Control (RRC) and non-access stratum (NAS) related activities. The other serving cells are referred to as secondary cells (scells), and each SCell may provide a separate secondary CC (SCC) for both UL and DL. SCCs may be added and removed as needed, while changing the PCC may require the UE101 to undergo handover. In LAA, eLAA, and feLAA, some or all scells may operate in unlicensed spectrum (referred to as "LAA scells"), and the LAA scells are assisted by pcells operating in licensed spectrum. When a UE is configured with more than one LAA SCell, the UE may receive a UL grant on the configured LAA SCell, the UL grant indicating different Physical Uplink Shared Channel (PUSCH) starting positions within the same subframe.

The Physical Downlink Shared Channel (PDSCH) may carry user data and higher layer signaling to the UE 101. A Physical Downlink Control Channel (PDCCH) may carry information on a transport format and resource allocation related to a PDSCH channel, and the like. It may also inform the UE101 of transport format, resource allocation and H-ARQ (hybrid automatic repeat request) information related to the uplink shared channel. In general, downlink scheduling (allocation of control and shared channel resource blocks to UEs 101b within a cell) may be performed at any RAN node 111 based on channel quality information fed back from any UE 101. The downlink resource allocation information may be sent on a PDCCH for (e.g., allocated to) each UE 101.

The PDCCH may use Control Channel Elements (CCEs) to convey control information. The PDCCH complex-valued symbols may first be organized into quadruplets before mapping to resource elements, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements called Resource Element Groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH may be transmitted using one or more CCEs, depending on the size of Downlink Control Information (DCI) and channel conditions. There may be four or more different PDCCH formats (e.g., aggregation levels, L =1, 2, 4, or 8) defined in LTE with different numbers of CCEs.

Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above-described concept. For example, some embodiments may use an Enhanced Physical Downlink Control Channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more Enhanced Control Channel Elements (ECCEs). Similar to the above, each ECCE may correspond to nine sets of four physical resource elements referred to as Enhanced Resource Element Groups (EREGs). In some cases, ECCE may have other numbers of EREGs.

The RAN nodes 111 may be configured to communicate with each other via an interface 112. In embodiments where system 100 is an LTE system, interface 112 may be an X2 interface 112. An X2 interface may be defined between two or more RAN nodes 111 (e.g., two or more enbs, etc.) connected to the EPC 120 and/or two enbs connected to the EPC 120. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user data packets transmitted over the X2 interface and may be used to communicate information about user data transfer between enbs. For example, the X2-U may provide specific sequence number information for user data transmitted from the master eNB (MeNB) to the secondary eNB (SeNB); information on successful in-sequence transmission of PDCP PDUs for user data from the SeNB to the UE 101; information of PDCP PDUs not delivered to the UE 101; information about the current minimum required buffer size at the SeNB for transmitting user data to the UE; and so on. X2-C may provide intra-LTE access mobility functions including context transfer from source eNB to target eNB, user plane transfer control, etc.; a load management function; and an inter-cell interference coordination function.

In embodiments where the system 100 is a 5G or NR system, the interface 112 may be an Xn interface 112. An Xn interface is defined between two or more RAN nodes 111 (e.g., two or more gnbs, etc.) connected to the 5GC 120, between a RAN node 111 (e.g., a gNB) connected to the 5GC 120 and an eNB, and/or between two enbs connected to the 5GC 120. In some implementations, the Xn interface can include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U can provide unsecured transport of user plane PDUs and support/provide data forwarding and flow control functionality. Xn-C may provide: management and error handling functions; managing the function of the Xn-C interface; mobility support for a UE101 in CONNECTED mode (e.g., CM-CONNECTED) includes functionality to manage CONNECTED mode UE mobility between one or more RAN nodes 111. Mobility support may include context transfer from the old (source) serving RAN node 111 to the new (target) serving RAN node 111; and control of user plane tunnels between the old (source) serving RAN node 111 and the new (target) serving RAN node 111. The protocol stack of the Xn-U may include a transport network layer established above an Internet Protocol (IP) transport layer and a GTP-U layer above UDP(s) and/or IP layers for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol, referred to as the Xn application protocol (Xn-AP), and a transport network layer built over SCTP. SCTP may be located above the IP layer and may provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transport is used to deliver signaling PDUs. In other implementations, the Xn-U protocol stack and/or the Xn-C protocol stack may be the same as or similar to the user plane and/or control plane protocol stack(s) shown and described herein.

RAN110 is shown communicatively coupled to a core network, in this embodiment, core Network (CN) 120.CN 120 may include a plurality of network elements 122 configured to provide various data and telecommunications services to clients/subscribers (e.g., users of UE 101) connected to CN120 through RAN 110. The term "network element" may describe a physical or virtualized device used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with and/or referred to as: networked computers, network hardware, network devices, routers, switches, hubs, bridges, radio network controllers, radio access network devices, gateways, servers, virtualized Network Functions (VNFs), network Function Virtualization Infrastructure (NFVI), and/or the like. The components of CN120 may be implemented in one physical node or separate physical nodes, including components that read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, network Function Virtualization (NFV) may be used to virtualize any or all of the above network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). The logical instantiation of a CN120 may be referred to as a network slice, and the logical instantiation of a portion of a CN120 may be referred to as a network subslice. The NFV architecture and infrastructure may be used to virtualize one or more network functions or be executed by dedicated hardware onto physical resources including industry standard server hardware, storage hardware, or a combination of switches. In other words, the NFV system may be used to perform a virtual or reconfigurable implementation of one or more EPC components/functions.

In general, the application server 130 may be an element that provides applications that use IP bearer resources with a core network (e.g., UMTS Packet Service (PS) domain, LTE PS data services, etc.). The application server 130 may also be configured to support one or more communication services (e.g., voice over internet protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UE101 via the EPC 120.

In an embodiment, the CN120 may be a 5GC (referred to as "5GC 120," etc.), and the RAN110 may be connected with the CN120 via the NG interface 113. In an embodiment, the NG interface 113 may be divided into two parts: an NG user plane (NG-U) interface 114 that carries traffic data between the RAN node 111 and a User Plane Function (UPF); and an S1 control plane (NG-C) interface 115, which is a signaling interface between the RAN node 111 and the AMF.

In embodiments, CN120 may be a 5G CN (referred to as "5GC 120," etc.), while in other embodiments, CN120 may be an Evolved Packet Core (EPC). In the case where CN120 is an EPC (referred to as "EPC 120," etc.), RAN110 may connect with CN120 via S1 interface 113. In an embodiment, the S1 interface 13 may be divided into two parts: an S1 user plane (S1-U) interface 114, which carries traffic data between RAN node 111 and serving gateway (S-GW); and S1-Mobility Management Entity (MME) interface 115, which is a signaling interface between RAN node 111 and the MME.

Fig. 2 illustrates an example architecture of a system 200 including a 5GC 220, according to some embodiments of the present disclosure.

The system 200 is shown as including: a UE 201, which may be the same as or similar to the UE101 previously discussed; (R) AN 210, which may be the same as or similar to RAN110 discussed previously, and which may include RAN node 111 discussed previously; and a Data Network (DN) 203, which may be, for example, an operator service, internet access, or third party service; and a 5G core network (5 GC or CN) 220.

The 5GC 220 may include an authentication server function (AUSF) 222; an access and mobility management function (AMF) 221; a Session Management Function (SMF) 224; a Network Exposure Function (NEF) 223; a Policy Control Function (PCF) 226; a Network Function (NF) repository function (NRF) 225; unified Data Management (UDM) 227; an Application Function (AF) 228; a User Plane Function (UPF) 202; and a Network Slice Selection Function (NSSF) 229.

The UPF 202 may serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session interconnect point to the DN 203, and a branch point to support multi-homed PDU sessions. The UPF 202 may also perform packet routing and forwarding, packet inspection, perform policy rules for the user plane part, lawful intercept packets (UP set), traffic usage reporting, perform QoS processing on the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS traffic mapping), transport level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 202 may include an uplink classifier to support routing of traffic flows to a data network. DN 203 may represent various network operator services, internet access, or third party services. The DN 203 may include or be similar to the application server 130 previously discussed. The UPF 202 may interact with the SMF 224 via an N4 reference point between the SMF 224 and the UPF 202.

The AUSF222 may store data for authentication of the UE 201 and process authentication related functions. The AUSF222 may facilitate a common authentication framework for various access types. The AUSF222 may communicate with the AMF221 via an N12 reference point between the AMF221 and the AUSF 222; and may communicate with UDM 227 via an N13 reference point between UDM 227 and AUSF 222. Additionally, the AUSF222 may expose a Nausf service based interface.

The AMF221 may be responsible for registration management (e.g., for registering the UE 201, etc.), connection management, reachability management, mobility management, and lawful interception of AMF-related events, as well as access authentication and authorization. The AMF221 may be the termination point of the N11 reference point between the AMF221 and the SMF 224. The AMF221 may provide transport for Session Management (SM) messages between the UE 201 and the SMF 224 and act as a transparent proxy for routing SM messages. The AMF221 may also provide for transmission of Short Message Service (SMS) messages between the UE 201 and an SMS function (SMSF) (not shown in fig. 2). The AMF221 may act as a security anchor function (SEA), which may include interactions with the AUSF222 and the UE 201, receiving intermediate keys established as a result of the UE 201 authentication procedure. In the case of using USIM-based authentication, the AMF221 may acquire security materials from the AUSF 222. The AMF221 may also include a Security Context Management (SCM) function that receives keys from the SEA that it uses to derive access network-specific keys. Further, the AMF221 may be a termination point of the RAN CP interface, which may include or be AN N2 reference point between (R) the AN 211 and the AMF 221; the AMF221 may be a termination point of NAS (N1) signaling and perform NAS ciphering and integrity protection.

The AMF221 may also support NAS signaling with the UE 201 through an N3 interworking function (IWF) interface. An N3IWF may be used to provide access to untrusted entities. The N3IWF may be the termination point of the N2 interface between the (R) AN 210 and the AMF221 for the control plane and may be the termination point of the N3 reference point between the (R) AN 210 and the UPF 202 for the user plane. In this way, AMF221 may process N2 signaling from SMF 224 and AMF221 for PDU sessions and QoS, encapsulate/decapsulate packets for IPSec and N3 tunneling, label N3 user plane packets in the uplink, and perform QoS corresponding to N3 packet labeling, which takes into account QoS requirements associated with such labeling received over N2. The N3IWF may also relay uplink and downlink control plane NAS signaling between UE 201 and AMF221 via the N1 reference point between UE 201 and AMF221, and uplink and downlink user plane packets between UE 201 and UPF 202. The N3IWF also provides a mechanism to establish an IPsec tunnel with the UE 201. The AMF221 may expose a Namf service based interface and may be a termination point of an N14 reference point between two AMFs 221 and an N17 reference point between the AMF221 and a 5G device identification register (5G-EIR) (not shown in fig. 2).

UE 201 may need to register with AMF221 to receive network services. The Registration Management (RM) is used to register or deregister the UE 201 with the network (e.g., the AMF 221) and establish a UE context in the network (e.g., the AMF 221). The UE 201 may operate in an RM registration state or an RM deregistration state. In the RM deregistration state, the UE 201 is not registered with the network and the UE context in the AMF221 does not maintain valid location or routing information of the UE 201, so the AMF221 cannot reach the UE 201. In the RM registration state, the UE 201 registers with the network, and the UE context in the AMF221 may maintain valid location or routing information of the UE 201 so that the UE 201 may be reached by the AMF 221. In the RM registration state, the UE 201 may perform a mobility registration update procedure, perform a periodic registration update procedure triggered by the expiration of a periodic update timer (e.g., to inform the network that the UE 201 is still active), and perform a registration update procedure to update UE capability information or renegotiate protocol parameters with the network, etc.

The AMF221 may store one or more RM contexts for the UE 201, where each RM context is associated with a particular access to the network. The RM context may be a data structure, database object, etc. that indicates or stores registration status and periodic update timers, etc. for each access type. The AMF221 may also store 5GC MM contexts, which may be the same as or similar to the (E) MM contexts discussed previously. In various embodiments, AMF221 may store CE mode B restriction parameters for UE 201 in an associated MM context or RM context. The AMF221 may also derive this value from the UE's usage setting parameters already stored in the UE context (and/or MM/RM context) when needed.

The Connection Management (CM) may be used to establish and release a signaling connection between the UE 201 and the AMF221 through the N1 interface. The signaling connection is used to enable NAS signaling exchange between the UE 201 and the CN120 and includes AN Access Network (AN) signaling connection (e.g., RRC connection or UE-N3IWF connection for non-3 GPP) between the UE and the AN and AN N2 connection for the UE 201 between the AN (e.g., RAN 210) and AMF 221. The UE 201 may operate in one of two CM states: a CM-IDLE (CM-IDLE) mode or a CM-CONNECTED (CM-CONNECTED) mode. When the UE 201 is operating in the CM-IDLE state/mode, the UE 201 may not have AN NAS signaling connection established with the AMF221 over the N1 interface, and there may be AN (R) AN 210 signaling connection (e.g., N2 and/or N3 connection) for the UE 201. When the UE 201 operates in the CM-CONNECTED state/mode, the UE 201 may have a NAS signaling connection established with the AMF221 over the N1 interface, and there may be AN (R) AN 210 signaling connection (e.g., N2 and/or N3 connection) for the UE 201. Establishing AN N2 connection between the (R) AN 210 and the AMF221 may cause the UE 201 to transition from the CM-IDLE mode to the CM-CONNECTED mode, and when releasing N2 signaling between the (R) AN 210 and the AMF221, the UE 201 may transition from the CM-CONNECTED mode to the CM-IDLE mode.

The SMF 224 may be responsible for: session Management (SM) (e.g., session establishment, modification, and release, including tunnel maintenance between UPF and AN nodes); UE IP address assignment and management (including optional authorization); selecting and controlling an UP function; configuring traffic steering at the UPF to route traffic to the correct destination; terminating the interface to the policy control function; controlling a portion of policy enforcement and QoS; lawful interception (for SM events and interface with the LI system); NAS message terminating SM part; a downlink data notification; the initiator of the AN-specific SM information is sent to the AN through the N2 via the AMF; the SSC pattern for the session is determined. SM may refer to the management of a PDU session, which may refer to a PDU connection service that provides or enables the exchange of PDUs between the UE 201 and a Data Network (DN) 203 identified by a Data Network Name (DNN). The PDU session may be established upon request by the UE 201, modified upon request by the UE 201 and the 5gc 220, and released upon request by the UE 201 and the 5gc 220 using NAS SM signaling exchanged over the N1 reference point between the UE 201 and the SMF 224. Based on the request from the application server, the 5GC 220 may trigger a specific application in the UE 201. In response to receiving the trigger message, the UE 201 may communicate the trigger message (or related portion/information of the trigger message) to one or more identified applications in the UE 201. The identified application(s) in the UE 201 may establish a PDU session to a particular DNN. The SMF 224 may check whether the UE 201 request conforms to the user subscription information associated with the UE 201. In this regard, the SMF 224 may retrieve and/or request to receive update notifications from the UDM 227 regarding SMF 224 level subscription data.

The SMF 224 may include the following roaming functions: processing the local enforcement to apply a QoS SLA (VPLMN); a charging data collection and charging interface (VPLMN); lawful interception (in the interface of VPLMN and LI systems for SM events); interaction with the foreign DN is supported to transmit signaling of PDU session authorization/authentication through the foreign DN. An N16 reference point between two SMFs 224 may be included in the system 200, which may be between another SMF 224 in the visited network and an SMF 224 in the home network in a roaming scenario. Additionally, the SMF 224 may expose an Nsmf service based interface.

The NEF223 may provide a means for securely exposing services and capabilities provided by 3GPP network functions for third parties, internal exposure/re-exposure, application functions (e.g., AF 228), edge computing or fog computing systems, and the like. In such embodiments, NEF223 may authenticate, authorize, and/or limit AF. NEF223 may also translate information exchanged with AF 228 and information exchanged with internal network functions. For example, the NEF223 may convert between the AF service identifier and the internal 5GC information. NEF223 may also receive information from other Network Functions (NFs) based on exposed capabilities of the other network functions. This information may be stored as structured data in the NEF223 or in the data storage NF using a standardized interface. The stored information may then be re-exposed by the NEF223 to other NFs and AFs, and/or used for other purposes, such as analysis. In addition, NEF223 may expose an interface based on the Nnef service.

NRF 225 may support a service discovery function, receive NF discovery requests from NF instances, and provide information of discovered NF instances to NF instances. NRF 225 also maintains information of available NF instances and the services it supports. As used herein, the term "instantiation" or the like may refer to the creation of an instance, and "instance" may refer to the specific occurrence of an object, which may occur, for example, during execution of program code. Additionally, NRF 225 may expose an interface based on the nrrf service.

PCF 226 may provide policy rules to control plane function(s) to enforce them, and may also support a unified policy framework to manage network behavior. The PCF 226 may also implement a Front End (FE) to access subscription information related to policy decisions in the UDR of the UDM 227. PCF 226 may communicate with AMF221 via an N15 reference point between PCF 226 and AMF221, which may include PCF 226 in a visited network and AMF221 in a roaming scenario. PCF 226 may communicate with AF 228 via an N5 reference point between PCF 226 and AF 228; and communicates with the SMF 224 via an N7 reference point between the PCF 226 and the SMF 224. The system 200 and/or the CN120 may also include an N24 reference point between the PCF 226 (in the home network) and the PCF 226 in the visited network. In addition, PCF 226 may expose Npcf service-based interfaces.

UDM 227 may process subscription related information to support processing of communication sessions by network entities and may store subscription data for UE 201. For example, subscription data may be transmitted between UDM 227 and AMF221 over an N8 reference point (not shown in fig. 2) between UDM 227 and AMF 221. UDM 227 may include two parts: an application FE and a User Data Repository (UDR) (FE and UDR are not shown in fig. 2). The UDR may store subscription data and policy data for UDM 227 and PCF 226, and/or structured data and application data for exposure (including Packet Flow Description (PFD) for application detection, application request information for multiple UEs 201) for NEF 223. UDR 221 may expose an Nudr service-based interface to allow UDM 227, PCF 226 and NEF223 to access a particular set of stored data, as well as read, update (e.g., add, modify), delete and subscribe to notifications of relevant data changes in the UDR. The UDM may include a UDM FE that is responsible for credential handling, location management, subscription management, and the like. Several different front ends may serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and executes authentication credential processing; user identification processing; an access authorization; registration/mobility management; and subscription management. The UDR may interact with the SMF 224 via an N10 reference point between the UDM 227 and the SMF 224. The UDM 227 may also support SMS management, where the SMS-FE implements similar application logic as previously described. In addition, UDM 227 may expose a numm service based interface.

The AF 228 can provide application impact on traffic routing, access Network Capability Exposure (NCE), and interact with the policy framework for policy control. The NCE may be a mechanism that allows the 5GC 220 and AF 228 to provide information to each other via the NEF223, which may be used for edge computing implementations. In such implementations, network operator and third party services may be hosted near the UE 201 access connection point to achieve efficient service delivery with reduced end-to-end delay and load on the transport network. For an edge calculation implementation, the 5GC may select a UPF 202 close to the UE 201 and perform traffic steering from the UPF 202 to the DN 203 via the N6 interface. This may be based on the UE subscription data, UE location and information provided by the AF 228. In this way, the AF 228 may affect UPF (re) selection and traffic routing. Based on operator deployment, the network operator may allow the AF 228 to interact directly with the relevant NFs when the AF 228 is considered a trusted entity. In addition, the AF 228 may expose a Naf service-based interface.

NSSF 229 may select a set of network slice instances that serve UE 201. NSSF 229 may also determine allowed Network Slice Selection Assistance Information (NSSAI) and a mapping to a single NSSAI (S-NSSAI) of the subscription, if needed. The NSSF 229 may also determine a set of AMFs or a list of candidate AMFs 221 for serving the UE 201 based on a suitable configuration and possibly by querying the NRF 225. The selection of a set of network slice instances for the UE 201 may be triggered by the AMF221 (which registers the UE 201 by interacting with the NSSF 229), which may result in a change in the AMF 221. NSSF 229 may interact with AMF221 via an N22 reference point between AMF221 and NSSF 229; and may communicate with another NSSF 229 in the visited network over an N31 reference point (not shown in fig. 2). Additionally, NSSF 229 may expose an interface based on the NSSF service.

As previously described, the 5GC 220 may include an SMSF, which may be responsible for SMS subscription checking and verification, and relaying SM messages from/to other entities, such as SMS-GMSC/IWMSC/SMS router, to/from the UE 201. The SMS may also interact with AMF221 and UDM 227 for notification procedures that UE 201 may use for SMS delivery (e.g., set a UE unreachable flag, and notify UDM 227 when UE 201 is available for SMS).

The 5GC 220 may also include other elements not shown in fig. 2, such as a data storage system/architecture, 5G device identity registers (5G-EIR), secure Edge Protection Proxies (SEPP), and so forth. The data storage system may include a structured data storage network function (SDSF), an unstructured data storage network function (UDSF), and so forth. Any NF may store unstructured data into or retrieve unstructured data (e.g., UE context) from the UDSF via an N18 reference point (not shown in fig. 2) between any NF and the UDSF. The individual NFs may share a UDSF for storing their respective unstructured data, or the individual NFs may each have their own UDSF located at or near the individual NFs. Additionally, the UDSF may expose an interface based on the Nudsf service (not shown in fig. 2). The 5G-EIR may be a NF that checks the status of a permanent device identifier (PEI) to determine if a particular device/entity is blacklisted from the network; the SEPP may be a non-transparent proxy that performs topology hiding, message filtering and policing on the inter-PLMN control plane interface.

Additionally, there may be more reference points and/or service-based interfaces between NF services in the NF; however, these interfaces and reference points are omitted from FIG. 2 for clarity. In one example, the 5GC 220 may include an Nx interface, which is an inter-CN interface between the MME and the AMF221 to enable interworking between the EPC and the 5GC 220. Other example interfaces/references these points may include an N5G-EIR service based interface exposed by 5G-EIR, an N27 reference point between the NRF in the visited network and the NRF in the home network; and an N31 reference point between the NSSF in the visited network and the NSSF in the home network.

The 5GC 220 may include a Location Management Function (LMF) (not shown in fig. 2) that may communicate with the (R) AN 210 and/or the UE 201 via the AMF 221. The LMF may manage support for different location services for target UEs (e.g., UE101 and UE 201), including positioning of the UEs and communicating assistance data to the UEs. The LMF may interact with a serving gNB (e.g., (R) AN 210) for the target UE to obtain location measurements and/or positioning-related information for the UE, including uplink measurements by the gNB and downlink measurements by the UE (which are provided to the gNB). The LMF may interact with the target UE to communicate assistance data when requesting a particular location service or to obtain a location estimate when requesting a location estimate.

NRPPa is a protocol used between the gNB and LMF for transmitting configuration information (e.g., for Downlink (DL) positioning method) and positioning measurement and configuration results (e.g., for Uplink (UL) positioning method). In some embodiments of the present disclosure, "positioning" and "location" may be interchanged. The procedure related to the configuration information exchange and the procedure related to the location measurement will be described in detail below.

Hereinafter, description will be made with respect to a user equipment (UE, e.g., UE101 a or 101b in fig. 1, or UE 201 in fig. 2) and a RAN (e.g., RAN110 in fig. 1, or (R) AN 210 in fig. 2, particularly, a gNB (next generation NodeB)). In particular, the present application will be described mainly from the UE side. It should be appreciated that operation of a respective gNB interacting with the UE should have a respective improvement.

For a fifth generation (5G) communication system, a UE in a Radio Resource Control (RRC) INACTIVE (RRC _ INACTIVE) state may engage in a Small Data Transfer (SDT) session with the gNB.

This SDT session is typically associated with the following portion of the Rel-17 SDT WID (Work item description) (RP-210870), which is intended to enable a small data transmission feature in the RRC _ INACTIVE state:

UL small data transmission for UE under RRC _ INACTIVE on RACH based scheme (i.e. 2-step and 4-step RACH):

o a general procedure for enabling the transmission of small data packets from the INACTIVE state (e.g., using MSGA or MSG 3),

o enable a flexible payload size larger than the Rel-16 CCCH message size, which is currently possible for the INACTIVE states of the MSGA and MSG3 to support UP data transmission in UL (the actual payload size may depend on the network configuration), and

o for RACH based schemes, context acquisition and data forwarding in INACTIVE state (with and without anchor relocation),

note 1: the security aspect of the above scheme should be checked using SA 3; and

-transmitting UL data on preconfigured PUSCH resources (i.e. reusing configured grant type 1), when TA is valid, for a UE at RRC _ INACTIVE:

o a general procedure for small data transfer from INACTIVE state by configured grant type 1 resources, and

o configure configured grant type 1 resources for small data transmission in the UL of INACTIVE state.

In addition, WIDs also indicate the following points that need to be considered:

no new RRC state should be introduced,

the small data transmission in the UL, the subsequent transmission of small data in the UL and DL, and the state transition decision shall be made under network control,

emphasis should be placed on licensed operators and the scheme can be repeated for NR-U (if applicable), and

-specifying the configuration of SRB1 and SRB2 for small data transmission of RRC _ INACTIVE state by reusing the framework of DRB.

In other words, the Rel-17 Small Data Transfer (SDT) feature is intended to allow a UE in RRC _ INACTIVE state to be able to exchange multiple UL (uplink) and DL (downlink) data packets between the network and the UE without the UE having to transition to RRC _ CONNECTED.

Fig. 3 shows a flow diagram of an example of a conventional method for an SDT session.

Figure 3 shows RRC 4-step RA-SDT. The UE is in RRC _ INACTIVE state.

In step S301, the UE transmits a RACH (random access channel) message to the gNB.

In step S302, the UE receives a RAR (random access response) message from the gNB in response to the RACH message.

In step S303, after the UE receives the RAR, it sends an rrcresemerequest (RRC resume request) message and UL data to the gNB.

In step S304-1, the UE transmits UL data to the gNB and/or receives DL data from the gNB. In other words, the UE and the gNB may exchange data with each other.

In step S304-2, the UE receives an RRCRelease message and DL data from the gNB. At this point, the SDT session between the UE in RRC _ INACTIVE state and the gNB is normally interrupted.

Fig. 4 shows a flowchart of another example of a conventional method for an SDT session.

Figure 4 shows an RRC 2-step RA-SDT or CG-SDT. The UE is also in RRC _ INACTIVE state.

The method of fig. 4 differs from the method of fig. 3 mainly in that: steps S301 and S302 in fig. 3 are replaced with step S401 in fig. 4.

In step S401, the UE transmits a RACH message, a RRCResumeRequest message, and UL data to the gNB.

Step S402-1 and step S402-2 are the same as step S304-1 and step S304-2 in FIG. 3, respectively, and are not described herein again.

As shown in fig. 3 or fig. 4, after the UE receives the rrcreelease message from the gNB, the SDT session between the UE in RRC _ INACTIVE state and the gNB may be normally interrupted.

However, in some cases, the UE may detect an SDT session failure during an ongoing SDT session (i.e., after sending one or more UL SDT transmissions (UL data)), i.e., the UE in RRC _ INACTIVE state may detect an abnormal interruption of the SDT session with the gNB.

An abnormal interruption of the SDT session may occur due to different triggering events on the UE side, such as:

-upon UE monitoring network response to previous UL transmission, SDT session failure detection timer and/or timer/window expires;

-cell reselection; and/or

Lower layer indication, e.g. MAC or PHY layer.

Further, there may also be a failure on the network side (e.g., the gNB). However, it is assumed that this may be notified to the UE by the gNB (e.g., when responding to the establishment of a new RRC connection with a RRCSetup msg (RRC setup message), i.e., a return scenario to establish a new connection), or the UE may automatically recognize that there are some problems when its SDT session failure detection timer expires.

Conventionally, when a UE in RRC _ INACTIVE state detects an abnormal interruption of the SDT session between the UE and the gNB (also referred to as "SDT failure" or "SDT session failure" in this disclosure), the UE will automatically transition to RRC _ IDLE state. This UE behavior will be similar to the conventional recovery procedure when the UE triggers a failure, e.g., due to cell reselection while T390 is running or when T390 times out to trigger a failure. However, a key difference in SDT operation is that the UE has an ongoing UL and possibly even DL data (even NAS messages).

It is considered how to recover a previously abruptly interrupted SDT session and minimize data loss and duplication without creating the associated security risks, considering normal SDT procedures/operations. A problem with SDT failure (or sudden (abnormal) interruption of an SDT session) is that the UE does not receive a new NCC for the next SDT session containing a new I-RNTI pointing to the current gNB for the next SDT session.

Fig. 5 illustrates an example of SDT session abort between UE and gNB.

Fig. 5 shows three different gnbs and one UE, assuming that the three gnbs are:

-gNB0: when the UE was previously in RRC _ CONNECTED, the UE context is stored in gNB0;

-gNB1: before detecting that the SDT session fails, the UE and the gNB1 are started and carry out SDT; and

-gNB2: the UE attempts to initiate a subsequent connected gNB (e.g., establish a new RRC connection, resume a suspended RRC connection, or start a new SDT session upon a previous SDT session failure) after the SDT session fails.

However, some or all of these gnbs may be the same (e.g., gNB1= gNB2= gNB0, or gNB1= gNB2 but different from gNB0, or gNB1= gNB0 but different from gNB2, or gNB2= gNB0 but different from gNB 1).

As shown in fig. 5, before the SDT session, the UE is in a CONNECTED state and CONNECTED with gNB 0.

In step S501, the UE receives an rrcreelease message (with suspend configuration) message and an SDT configuration (SDT-configuration) message from the gNB 0.

At this point, the UE transitions to the INACTIVE (RRC _ INACTIVE) state and has an SDT configuration message. The UE AS (Access stratum) context is stored in the gNB 0.

To start the SDT session, the UE in RRC _ INACTIVE state sends a first SDT UL RRC message for SDT and UL SDT traffic to the gNBl in step S502. This step S502 may correspond to steps S301 to S303 in fig. 3 or step S401 in fig. 4.

The SDT session may then be in an ongoing state. As shown in fig. 5, in step S503, the UE may transmit UL data to the gNB1 and/or receive DL data (traffic) from the gNB 1. This step S503 may correspond to step S304-1 in fig. 3 or step S402-1 in fig. 4.

In step S503, the UE may detect that the SDT session fails, i.e., the SDT session is aborted.

One common aspect of SDT failure (or sudden/abnormal interruption of an SDT session) for the triggering events listed above is that the UE does not receive an RRC Release message containing a new I-RNTI pointing to the current gNB1 (which may be assumed to be the first gNB) for the next SDT session, and a new NCC (which may be assumed to be the second gNB (i.e., gNB 2) for the next SDT session.

The problem now is how to recover the failed SDT session. It can be assumed that the UE is now located at gNB2.

Traditionally, as a baseline scheme, upon detecting an SDT session failure, the UE automatically transitions to an RRC IDLE state (also referred to as "RRC IDLE" in this disclosure):

-the UE stored SDT configuration will be released/discarded by entering the UE into RRC IDLE.

This UE behavior will be similar to the conventional recovery procedure when the UE triggers a failure, e.g. due to cell reselection while T390 is running or T390 expires. However, a key difference of SDT operation is that the UE has an ongoing UL and possibly even DL data (even NAS messages).

The following are potential advantages and disadvantages determined for this baseline scheme:

o advantage: there is no security risk because a new security key is generated to transmit subsequent data (i.e., after the UE establishes a new RRC connection).

Disadvantages are: the UE must establish a new connection, which may result in additional signaling and data loss/duplication (e.g., any available DL data in the gNB of an ongoing SDT session will be lost, the UE may have to retransmit some unacknowledged ULSDT data). Further, any data stored in the UE (or network) will be flashed when the UE is transitioned to RRC _ IDLE (or when the stored UE context is deleted from the network side). On the other hand, additional delay may be introduced for the UE to continue its data transmission.

In this case, the UE may need to autonomously perform the following operations (in order to transition to RRC _ IDLE legacy operation that may be followed) when triggering an SDT session failure:

-performing the operation specified in 5.3.11 of TS 38.331 (3 GPP Technical Specification (TS) 38.331v16.4.1 (2021-03)) for the release reason "RRC connection failure" upon entering RRC _ IDLE.

It should be noted that the handling of the SDT configuration may be defined in the old release section 5.3.11 of TS 38.331, "operation when entering RRC IDLE" or in a separate section performed when triggering the SDT session failure. In addition, a release cause specific to SDT session failures may also be defined to distinguish it from conventional RRC connection failures.

To prevent (or minimize) data loss and duplication of SDT traffic and to make the delay shorter than the conventional scheme described above (i.e., without a recovery mechanism), the present application provides an apparatus and method for a UE to recover an SDT session that can recover an abnormally terminated SDT session while keeping the UE in an RRC _ INACTIVE state.

During any given SDT session, the UE will follow similar actions as when the UE resumes any connection, except that for the first UL SDT, the UE will need to enable legacy actions related to transmission of rrcresemequest and reception of rrcreseme.

Actions that may be applicable to the first UL SDT relate to the conventional start of the recovery procedure, transmission of RRCResumeRequest and reception of RRCResume. The following references from TS 38.331 highlight (denoted by the symbol "{") the portion (in whole or in part) applicable to SDT operations:

from conventional operations associated with the start-up phase of the recovery procedure.

5.3.13.2 Start

The UE initiates this procedure when the suspended RRC connection is requested to resume by the upper layer or AS (either in response to RAN paging, triggering RNA update when the UE is in RRC _ INACTIVE, or for side link communication specified in subclause 5.3.13.1a).

The UE should ensure that there is valid and up-to-date basic system information specified in clause 5.2.2.2 before starting this procedure.

When starting the procedure, the UE should:

1> if the recovery of the RRC connection is triggered by responding to NG-RAN paging:

2> select "0" as the access category;

2> performing using the selected access category and one or more access identities provided by the upper layer

5.3.14 the unified access control procedure specified in;

3> if the access attempt is prohibited, the process ends;

1> otherwise, if recovery of RRC connection is triggered due to RNA update specified in 5.3.13.8:

2> if emergency services are ongoing:

and (3) annotation: how the RRC layer in the UE knows the emergency service that is ongoing depends on the UE implementation.

3> select "2" as the access category;

3> set the recovery reason to urgent;

2> otherwise:

3> select "8" as the access category;

2> performing the unified access control procedure specified in 5.3.14 using the selected access category and the one or more access identities specified in TS 24.501[23] to be applied;

3> if the access attempt is prohibited:

4> set variable pendingRNA-Update to true (true);

4, ending the program;

1> if the UE is at NE-DC or NR-DC:

2> if the UE does not support maintaining SCG configuration at connection recovery:

3> release MR-DC related configuration (i.e. AS specified in 5.3.5.10) from UE Inactive AS context (if stored);

1> if the UE does not support maintaining the MCG SCell configuration at connection recovery:

2> release MCG SCell from UE Inactive AS context (if stored);

1> release delayBudgetReportingConfig from UE Inactive AS context (if stored);

1> stop timer T342 (if running);

1> release of overheatassistence config from UE Inactive AS context (if stored);

1> stop timer T345 (if running);

1> release idc-AssistanceConfig from UE Inactive AS context (if stored);

1> release drx-PreferenceConfig for all configured cell groups from the UE Inactive AS context (if stored);

1> stop all instances of timer T346a (if running);

1> release maxBW-preferenceConfig for all configured cell groups from UE Inactive AS context (if already stored);

1> stop all instances of timer T346b (if running);

1> release maxCC-preferenceConfig for all configured cell groups from UE Inactive AS context (if stored);

1> stop all instances of timer T346c (if running);

1> release maxMIMO-layerprefferenceconfig for all configured cell groups from UE Inactive AS context (if stored);

1> stop all instances of timer T346d (if running);

1> release minschedulingOffsetPreferenceConfig for all configured cell groups from UE Inactive AS context (if stored);

1> stop all instances of timer T346e (if running);

1> release leasepreferenceconfig from UE Inactive AS context (if stored);

1> stop timer T346f (if running);

1> start timer T319;

1> set the variable pendingRNA-Update to false (false);

and 1> initiating RRCRESUMeRequest message or RRCRESUMeRequest1 transmission according to 5.3.13.3.

From the legacy operations related to the transmission of rrcresemequest or rrcresemequest 1 messages:

5.3.13.3 actions related to the transmission of RRCRESUMeRequest or RRCRESUMeRequest1 messages

The UE shall set the content of RRCResumeRequest or RRCResumeRequest1 message as follows:

1> if the field usefullresuld is signaled in SIB 1:

1> otherwise:

2> selecting RRCRESUMeRequest as a message to be used;

2> setting the resumediversity to a stored shortI-RNTI value;

stored QoS flow to DRB mapping rules and K _gNB And K _RRCint A key, except for:

-a master cell group;

-mrdc-SecondaryCellGroup (if stored); and

K _RRCint secret key and K _UPint The key applies integrity protection to all radio bearers except SRB0, i.e. integrity protection should be applied to all subsequent messages received and sent by the UE;

note 1: only DRBs with UP integrity protection configured before can restore integrity protection.

1> submit the selected message RRCResumeRequest or RRCResumeRequest1 for transmission to lower layers.

Note 2: only DRBs with UP encryption configured before can recover encryption.

If the lower layer indicates that the integrity check fails while T319 is running, then execution is performed

5.3.13.5.

The UE should continue cell reselection related measurements and cell reselection evaluation. If the conditions for cell reselection are met, the UE shall perform cell reselection as specified in 5.3.13.6.

-from a legacy action related to the UE receiving RRCResume.

5.3.13.4UE receives RRCResume

The UE shall:

1> stop timer T319;

1> stop timer T380 (if running);

1> if T331 is running:

2> stop timer T331;

2> perform the action specified in 5.7.8.3;

1> if RRCResume includes fullConfig:

2> perform the complete configuration process specified in 5.3.5.11;

1> otherwise:

2> if RRCRESUME does not include restoreMCG-SCells:

3> release MCG SCell from UE Inactive AS context (if stored);

2> if RRCResume does not include restoreSCG:

3> release MR-DC related configuration (i.e. AS specified in 5.3.5.10) from UE Inactive AS context (if stored);

1> if RRCResume includes masterCellGroup:

2, performing cell group configuration on the received masterCellGroup according to 5.3.5.5;

1> if RRCResume includes mrdc-SecondardaryCellGroup:

2> if the received mrdc-SecondaryCellGroup is set to nr-SCG:

3> performing RRC reconfiguration for the RRCReconfiguration message included in the nr-SCG in accordance with 5.3.5.3;

2> if the received mrdc-SecondaryCellGroup is set to eutra-SCG:

3> performing RRC connection reconfiguration specified in section 5.3.5.3 of TS 36.331[10], on the RRCConnectionReconfiguration message included in the eutra-SCG;

1> if RRCResume comprises a radioBearerConfig:

2> performing radio bearer configuration as per 5.3.5.6;

1> if the RRCResume message includes a sk-Counter:

2> perform the secure key update procedure specified in 5.3.5.7;

1> if the RRCResume message includes radioBearerConfig2:

2> performing radio bearer configuration as per 5.3.5.6;

1> if the rrcreesum message includes needfrogapsconfigugnr:

2> if needfrogapsconfigunr is set to setup:

3> consider it as measurement gap requirement information configured to provide an NR target band;

2> otherwise:

3> treat it as not configured to provide measurement gap requirement information for the NR target band;

1> discard cell reselection priority information provided by cellreselection priorities or inherited from another RAT (if stored);

1> stop timer T320 (if running);

1> if the RRCResume message includes measConfig:

2> performing the measurement configuration procedure specified in 5.5.2;

1> resume measurement (if suspended);

1> if T390 is running:

2> stop timer T390 for all access categories;

2> perform the action specified in 5.3.14.4;

1> if T302 is running:

2> stop timer T302;

2> perform the action specified in 5.3.14.4;

1> enter RRC _ CONNECTED;

2> if the upper layer provides a PLMN and the UE is allowed or instructed to access the PLMN through the cell broadcasting at least one CAG ID:

3> set selected PLMN-Identity from npn-IdentityInfoList;

2> otherwise:

3> setting selected PLMN-Identity as the PLMN selected by the upper layer from PLMN-IdentityList;

2> if the masterCellGroup contains reportuplinktxdiretcurrent:

3> including uplinkTxCerirecCurrentList for each MCG serving cell in UL;

3> include in the uplinkTxCerirecCurrentList the uplinkDirectCurrentBWP-SUL for each MCG serving cell configured with an SUL carrier (if present);

2> if the UE has idle/inactive measurement information on cells other than the PCell available in the varmeasldlerreport:

3> if the idlemodmeasurementreq is included in the RRCResume message:

4> set measresultideeutra in RRCResumeComplete message to the value of measreportideeutra in varmeasidereport (if available);

4> set measResultIdleNR in RRCResumeComplete message to the value of measReportIdleNR in VarMeasIdleReport (if available);

4, the lower layer confirms that RRCRESUMeComplete message is successfully transmitted and then discards VarMeasIdleReport;

3> otherwise:

4> if SIB1 contains idlemeasurementsnr and the UE has NR idle/inactive measurement information on cells other than PCell available in varmeasldlerport; or alternatively

4> if SIB1 contains idlemeasurementsEUTRA and the UE has available E-UTRA IDLEReport Idle >

Inactive measurement information:

5> includes idleMeasAvailable;

2> if the RRCReseme message includes mrdc-SecondaryCellGroupConfig and mrdc-SecondaryCellGroup is set to eutra-SCG:

3> including an E-UTRA RRCConnectionReconfigurationComplete message in the eutra-SCG-Response according to TS 36.331[ 2], [10] item 5.3.5.3;

2> if the RRCResume message includes mrdc-SecondaryCellGroupConfig and mrdc-SecondaryCellGroup is set to nr-SCG:

3> including the SCGRRCReconfiguration complete message in nr-SCG-Response;

2> if the UE records measurements available for NR, and RPLMN is included in the plmn-IdentityList stored in VarLogMeasReport:

3> include logMeasAvailable in RRCResumeComplete message;

3> if the bluetooth measurement result is included in the logged measurement that the UE can use for NR, and if the RPLMN is included in the plmn-identylist stored in VarLogMeasReport:

4> include logMeasAvailableBT in rrcresumecomple message;

3> if the WLAN measurement result is included in the logged measurement that the UE can use for NR, and if the RPLMN is included in the plmn-identylist stored in VarLogMeasReport:

4> include logMeasAvailableWLAN in RRCResumeComplete message;

2> if the UE has available connection setup failure or connection recovery failure information in the VarConnEstFailReport, and if RPLMN equals plmn-Identity stored in the VarConnEstFailReport:

3> including connEstFailInfoAvailable in RRCRESUMeComplete message;

2> if the UE has available radio link failure or handover failure information in VarRLF-Report, and if the RPLMN is included in the plmn-identylist stored in the VarRLF-Report; or

2> if the UE has available radio link failure or handover failure information in the VarRLF-Report of TS 36.331[10], and if the UE is capable of cross-raterlf reporting, and if RPLMN is included in plmn-identylist stored in the VarRLF-Report of TS 36.331[10 ]:

3> include rlf-InfoAvailable in rrcresumeconplete message;

2> if the UE supports storing the movement history information and the UE has the movement history information available in VarMobilityHistoryReport:

3> Inclusion of mobilityHistoryAvail in RRCResumeComplete

Performing neutralization;

2> if speedstateReselectionPars is configured in SIB 2:

3> including mobilityState in rrcresumecomple message and setting mobilityState to a mobility state of the UE just before entering RRC _ CONNECTED state (as specified in TS 38.304, [20 ]);

2> if the UE is configured to provide measurement gap requirement information for the NR target band:

3> includes needleforgapsinnfnr and settings as follows:

4, setting gap requirement information of co-frequency measurement aiming at each NR service cell including intraFreq-needfrogap;

4> if a requestdtargetbandfilternr is configured for each supported NR frequency band also included in the requestdtargetbandfilternr, then an entry is included in the interFreq-needfragap and gap requirement information is set for that frequency band; otherwise, an entry is contained in the interFreq-needfrogap, and corresponding gap requirement information is set for each supported NR frequency band;

1, submitting RRCRESUMeComplete message to a lower layer for transmission;

1> the process ends.

In summary, by applying the apparatus or method for UE for resuming SDT session according to the embodiments of the present application, the key actions of UE in sending the first UL SDT may include any one of the following. Possibly for use differently than in conventional recovery proceduresUnderliningThe marking is performed. The order of the actions may be different from the order listed below. Further, some of the operations listed herein may be distributed in different process portions of the SDT mechanism, such as the SDT start phase, the action at the time of the first ULSDT delivery, or the SDT interrupt phase.

1) When applicable, the unified access control process is performed using the access categories and one or more access identities provided by the upper layer.

a) Note-1:new SDT specific access categories may be defined。

2) A cause value is set (e.g., reuse resumecuse).

a) Note-2:the cause value may be by resumeCause or other new IE. In addition, its value may be One of the legacy values, or may be a new value defined for the SDT operation。

3)May not requireDefault configurations are applied for L1 parameters, SRB1 configuration, and MAC cell configuration. a) Note 3:network and other common or known configurations of any UE may also be used instead, e.g., instead of SDT operation specific configurations. For SDT In operation, the stored configuration may be used, in which case the default/general configuration need not be used。

4)Can be used forThe various configurations (if already stored in the UE Inactive AS context) are released, e.g., delayBudgetRecoveringConfig, overheataAsistingConfig, idc-AsistingConfig, drx-PreferrencConfig for all configured cell groups.

a) Note-4:the following is possible: the UE may not perform the release of some or all of these configurations because For SDT operation, the UE may restore only those configurations related to SDT operation。

5)Can do withoutVarious timers are stopped (if running), e.g., T346a/b/c/d/e/f.

a) Note-5:it is possible to dispense with stopping the timer unrelated to the SDT operation as described in the foregoing note-4。

6) The applications include CCCH configuration and timeAlignmentTimerCommon in SIB 1.

a) Note-15:the UE may use the stored TAT configuration instead of the broadcasted configuration。

7) The RRCmsg to be used during SDT operation is selected.

a) Note-6:it may be RRCRESUMeRequest1 or RRCRESUMeRequest or other existing or new RRC message of。

8) A UE identity to be communicated is selected.

a) Note-7:it may be set to a stored fullI-RNTI or shortI-RNTI value resurmediversity, or an identity different from C-RNTI。

9) Recovering RRC configuration, roHC-like, from stored UE Inactive AS contextState, stored QoS flow to DRB mapping rules and K _gNB And K _RRCint A key.

a)Including masterCellGroup

i) Note-8:part of the masterCellGroup configuration may be restored for SDT operation only (i.e., operation of the UE) Reduced as compared to the conventional UE in RRC _ CONNECTED, as described in the foregoing note-4). For example, previous NOTE-4 labeling Some configurations that may not be recovered (i.e., delayBudgetRecortionConfig for all configured cell groups, overheatAssistanceConfig、idc-AssistanceConfig、drx-PreferenceConfig)；

b)Including pdcp-Config；

c)Except for mrdc-SecondardaryCellGroup (if stored)；

i) Note-9:the mrdc-SecondaryCellGroup can be restored (partially or fully) if during SDT operation Use the configuration in a room)。

10 Configure the lower layers to account for the recovered MCG.

11 Set resume MAC-I (using K in UE Inactive AS Context) _RRCint Keys and previously configured integrity protection algorithms).

12 Derive a security key (and for K) using the stored nextHopChainingCountp _gNB 、K _RRCenc 、K _RRCint 、K _UPint And K _UPenc Same as for conventional restoration).

13 Lower layer is configured to apply integrity protection and ciphering for all radio bearers except SRB 0.

a) Note-10:for SDT operation, it is possible that only part of the RBs are used, or all RBs are stored by the UE as UE Part of the AS context. Thus, the action may be applicable to any stored RB, or only to that configured for SDT operations RB (which will be a subset of the previously configured UP integrity protected RB)。

14)For all radio bearers except SRB0The PDCP entity is re-established.

a) Note-10(same as above)。

15 Recovery ofAll radio bearers except SRB0。

a) Note-10(same as above)。

16)The stored UE Inactive AS context and suspendConfig can be kept。

a) Note-11:conventional recovery operations discard the UEInactive AS context upon receipt of the RRCResume message, but this may not be necessary for the SDT session because the UE remains in RRC _ INACTIVE. Similar processing may be applied For suspendeconfig that may consider the following options: option (a) suspenndconfig (except ran- Notifiationareinfo) is released when the first UL SDT is sent, or option (b) suspendConfig is in the SDT session Inter-hold and updated during the end of the SDT session if the network sends the relevant configuration via rrcreelease msg.

17)Treating the current cell as a PCell。

18)If the SRB is configured (or allowed) for SDT operation and the upper layer provides NAS PDUs, it may be in the first place Is transmitted in the UL SDT, e.g., as part of the ULInformationTransfermsg, or alternatively as being transmitted Part of a new IE (e.g., dedicatedinas-Message) defined in the first UL RRC msg.

19)Can be prepared byIndicating to the upper layer that the suspended RRC connection has been resumed.

a) Note-12:when the SDT session ends (or even begins), the upper layers may or may not be notified. In the event of a notification that it is, this may be done by reusing the indication of resume/pause type and/or by using a new SDT related indication。

20)SDT data can also be sent in the first UL SDT msg。

The above differences will be described in further detail below in connection with embodiments of an apparatus or method for resuming an SDT session for a UE according to the present application.

In general, the following points should be considered in the examples of the present application:

the RRC messages used during the SDT mechanism may be based on conventional messages (e.g. rrcresemequest, rrcresum, rrcreelease, rrcretastablistemrequest, etc.) or on new RRC messages, possibly defined. For example, the first UL RRC msg (message) may be referenced with RRCResumeRequest or other messages, which should not limit the scheme space.

When using legacy IEs or even configurations for SDT operations, new values may be defined that are specific or applicable to SDT operations.

For SDT operations, the scheme can be implemented with or without any interaction between AS and NAS.

The gnbs where the UE stores the UE AS context, the gnbs that triggered the SDT session failure, and the gnbs that implement the recovery mechanism after detecting the SDT session failure may be the same gNB or different gnbs.

For scenarios where the UE remains in INACTIVE after detecting an SDT session failure, a similar mechanism may be applicable in cases where the stored SDT configuration may be kept stored, or dropped/released, or marked as invalid (which would make it unusable until the connection is obtained and the network provides an updated/valid SDT configuration).

Some of the actions listed or explained herein may be implemented in a different order than suggested, e.g. within the same procedure or within different procedures. For SDT operations, new procedures may be defined, for example, processing when an SDT session failure is triggered or when an SDT session is started, or processing when an SDT session is started after an SDT session failure is detected. Further, some actions may be included in one or more processes related to SDT processing.

All schemes of the SDT session failure scenario may be equally applicable to other cases, such as:

when during a given SDT session, the UE in INACTIVE triggers an interruption of the SDT session for other reasons than failure, e.g. non-SDT traffic is detected or the criteria required for SDT operation are not met.

O during a given SDT session, the UE transitions to CONNECTED to continue the session. This may be triggered by the network (e.g., when a rrcreesume message is sent) or by the UE (e.g., when non-SDT traffic is detected autonomously or some basic criteria required for SDT operation are not met).

When a given SDT session is interrupted for other reasons (e.g. network rejection).

Any combination of the described schemes is possible, i.e. any of the schemes and options discussed herein may be used in combination or (partly or fully) applicable to the other schemes.

Fig. 6 illustrates a block diagram of an example of an apparatus for resuming an SDT session for a UE according to an embodiment of the application.

As shown in fig. 6, an apparatus 600 for resuming an SDT session for a UE according to the present application includes a processor 601 and an interface 602 coupled to each other.

Processor 601 is configured to detect an abnormal interruption of a first SDT session between a UE in an RRC _ INACTIVE state and a first gNB (e.g., the SDT session between the UE and gNB1 shown in fig. 5); keeping the UE in an RRC _ INACTIVE state under the condition of detecting the abnormal interruption; a first recovery session for the first SDT session between the UE in RRC _ INACTIVE state and the second gNB is established based on a first next hop chain count (NCC) used in the first SDT session to continue SDT traffic transmission for the first SDT session.

Hereinafter, for convenience of description, embodiments of the apparatus and method according to the present disclosure will be mainly described with respect to a resume SDT session for a first SDT session between a UE in an RRC _ INACTIVE state and a second gNB. However, it should be understood that the recovery session for the first SDT session may be a conventional recovery connection (e.g., resume session).

Processor 601 may be any type of processing unit that may perform operations according to embodiments of the application, for example, a processor in or for a UE. In other words, the processor 601 may perform the following operations: the operations may correspond to steps of a method for a recovery (SDT) session for a UE in accordance with embodiments of the application.

In this case, for convenience of description, operations performed by the processor 610 will be described below in conjunction with at least one flowchart of a method for resuming an SDT session for a UE according to an embodiment of the present application. That is, the processor 601 performs the following processing in cooperation with the interface 602.

Fig. 7 shows a flowchart of an example of a method for resuming an SDT session for a UE according to an embodiment of the application.

As shown in fig. 7, in step S710, an abnormal interruption of a first SDT session between a UE in RRC _ INACTIVE state and a first gNB is detected.

In step S720, if an abnormal interruption is detected, the UE is kept in the RRC _ INACTIVE state.

In step S730, a first recovery session for the first SDT session between the UE in RRC _ INACTIVE state and the second gNB is established based on the first NCC used in the first SDT session to continue SDT traffic transmission of the first SDT session. The first NCC corresponds to the first gNB.

In this way, the apparatus and method for resuming an SDT session for a UE according to the present application will allow the UE to continue its SDT data transmission with minimal impact and delay. Thus, upon detecting an SDT session failure, the UE remains in RRC _ INACTIVE.

By remaining in RRC _ INACTIVE, the stored SDT configuration of the UE can be reused or continued to be used, and even ongoing SDT traffic can be continued with minimal impact.

The following are potential advantages and disadvantages over the baseline scheme:

o the advantages: embodiments of the present application aim to prevent (or minimize) data loss and duplication of SDT traffic and to make the delay shorter than the baseline case.

O disadvantages: some problems related to keeping the UE in RRC _ INACTIVE are addressed:

a) If no new NCC is provided after an SDT session failure, then there is a security problem.

b) Some scenarios that should be noted for identifying potential confusion or additional delays of previous UE contexts stored in the network, such as:

if I-RNTI is used, I-RNTI confusion may occur if the UE's context is relocated (during the SDT session that triggered the failure). This is because the UE does not receive RRCrelease including the I-RNTI of the serving gNB (gNB 1). The I-RNTI that will be used will be the I-RNTI from the previous gNB (gNB 0). If the UE context is relocated to the serving gNB (gNB 1), there is no context in gNB0 and the UE-provided I-RNTI cannot be located to the UE context. But if serving gNB1 does not request gNB0 to release the UE context before sending rrcreelease, the UE context in gNB0 may be retained.

If C-RNTI is used, C-RNTI confusion may occur if the context of the UE is not relocated. This is because the C-RNTI used by the UE is from the serving gNB (gNB 1), while the UE context is in the original gNB0, and the C-RNTI provided by the UE cannot locate the UE context.

c) Potential considerations regarding NCC (if used) of the next rrcredume request to be used for the recovery process, i.e. after an SDT session failure.

The UE may use the original NCC for the Resume request, but it is either the original NCC or the NCC for the data.

If it is for data, this is "new" (not currently used for Resume request), in which case this is practically not a problem.

This will be discussed in more detail in fig. 8 below, which describes possible NCC operations assuming the use of the three different gnbs described above (as explained in the scenario of the previous example).

d) Potential problems associated with data PDCP count reset.

Safety issues: the same key cannot be used for the same count (if the PCI of gNB3 is different, there may be no problem). This consideration will be for the case if gNB2 is the same as gNB1, which is explained below.

Data duplication or loss may occur because it is not possible to use COUNT to identify lost or duplicated data packets in the INACTIVE session. Thus, suppose the UE always repeatedly transmits unacknowledged data: if the PDCP count is not reset, the network may detect any data duplication, however, if the PDCP count is reset, the network cannot detect data duplication.

In legacy recovery operation, PDCP count reset occurs during RRCRelease; however, it is not invoked during the failure.

To simplify the following fig. 8, a conventional recovery operation is used as an example to show how NCC is handled in relation to a given SDT session failure. However, other RRC messages may also be used for SDT operations. The previous explanations regarding gNB0, gNB1, and gBN2 apply to this figure and other discussions related to them in this section, since the improvements discussed below take this scenario as a basic assumption and the UE remains in RRC _ INACTIVE after detecting an SDT session failure.

Fig. 8 shows a schematic diagram of an example for resuming an SDT session for a UE according to an embodiment of the application.

In fig. 8, gNB0, gNB1, and gNB2 are similar to gNB0, gNB1, and gNB2 shown in fig. 5.

Prior to the SDT session, the UE is in a CONNECTED state, exchanging Data (Data) with gNB0 using NCC0 in step S801.

In step S802, the UE receives a Release (Release) message with NCC1 from the gNB 0. This step S802 may correspond to step S501 in fig. 5.

At this time, the UE transitions to an INACTIVE (RRC _ INACTIVE) state with SDT configuration (SDT config.) information. The UE AS Context (Context) is stored in the gNB 0.

Then, the SDT session starts. In step S803, the UE transmits a Resume request (Resume request) to the gNB1 using NCC 0; in step S804, the UE transmits Data (Data) to the gNB1 using NCC 1. These steps may correspond to a first UL SDT.

In step S805, the UE may transmit UL data to the gNBl and/or receive DL data from the gNBl using NCC 1. This step S805 may correspond to step S503 in fig. 5.

At this time, the UE (i.e., the processor of the apparatus of the present application) may perform the following operations:

-resummemac-I generated with previous keys (derived based on NCC 0);

-calculating a new key using NCC1 and used with SDT traffic;

note-a: the stored configuration is not actually updated/invoked (because there is no Release message); and

note-B: the stored UE AS context is only released when RRCResume is received.

Then, failure of the SDT session is detected and the UE remains in INACTIVE state with SDT configuration information.

The SDT session may be (re-) started, i.e. may be resumed after a SDT session failure (abort) is detected. In other words, the SDT session may be resumed based on the first NCC (NCC 1) (optionally, the second NCC (NCC 2)), as described in S730. Therefore, the transmission of the Resume request (Resume request) in step S806 and the transmission of the data in step S807 will use the first NCC1 (optionally, NCC0 and the new second NCC (NCC 2)). The use of the first NCC1 (and optionally NCC0 and second NCC (NCC 2)) will be described in further detail below.

In other words, fig. 8 shows the relevant operations in keeping the UE in INACTIVE while considering the handling of the NCC used in the failure scenario of SDT:

-a first part of the scene): [ gNB0], the UE uses NCC0 when in CONNECTED, and obtains a new NCC1 when released to INACTIVE;

-a second part of the scene): [ gNB1], UE initiates SDT session while INACTIVE

O resumeMAC-I: calculated based on the current security key (which is the old key generated based on NCC0 used with gNB 1),

generating a new key based on the new NCC1 (provided by the gNB0 in a previous release) and the gNB 1;

-a third part of the scene): the UE triggers the SDT session failure and remains in INACTIVE to recover from the SDT session failure (as described in the fourth section of this scenario below); and

-a fourth part of the scene): [ gNB2] UE initiates another (resume) SDT session (even a legacy resume)

O resumeMAC-I: based on the current security key (possibly a new security key used with the gNB1, NCC1, or a security key previously generated using NCC0 when the UE is in cooled),

o generate a new key based on NCC1 (provided in release via the gNB 0) and gNB2. It should be noted that other NCCs may be used, as discussed in some of the modifications below.

The following improvements are directed to the above scenario and are intended to provide a new/updated NCC (second NCC) for the fourth part of the scenario (i.e. during the recovery mechanism after detecting an SDT session failure) with the aim of reducing any potential security risks, delays and data duplication/loss as previously described.

In this section, the following embodiments assume that a UE in an inactive state may maintain a stored SDT configuration (SDT config.) after a failure to trigger an SDT session. Alternatively, the stored SDT configuration may be discarded or released or marked as invalid (i.e., to ensure that the UE does not continue to use the SDT feature at least until the UE resumes connection).

This means that the UE cannot use the SDT to continue its data exchange, but the UE should always resume RRC connection (i.e. move the UE to CONNECTED).

However, this alternative is not discussed in the following improved solution, although the alternative mechanism may be equally applicable.

This alternative will also allow the network to authenticate the UE (if available in the gNB) without losing any DL data, in addition. The solutions discussed in the examples of the present application are equally applicable to this alternative.

It should be noted that this alternative may be preferable from a network perspective if it is desired or anticipated that the stored configuration needs to be updated.

In one embodiment, referring back to fig. 7 or 8, a first SDT session between the ue and a first gNB (gNB 1) may include a first phase that may be used to initiate the first SDT session with RRC messages and a second phase that may be used to transport Uplink (UL) SDT traffic and Downlink (DL) SDT traffic for the first SDT session.

Further, a first recovery (SDT) session between the UE and a second gNB (gNB 2) may include a first recovery phase to initiate the first recovery (SDT) session with an RRC message. In one embodiment, the first recovery (SDT) session may further include a second recovery phase to transfer remaining UL SDT traffic and DL SDT traffic of the first SDT session.

An abort may be detected during the first phase or the second phase.

In one embodiment, in step S710 in fig. 7, the processor 601 may be configured to detect the presence of the abort in the first phase in case an RRC Reject (Reject) message for rejecting the first SDT session is received in the first phase via the interface 602. In one embodiment, the processor 601 may be configured to determine, in the second phase, that the abnormal interruption is detected in case an RRC Release (Release) message for normally interrupting the first SDT session is not received via the interface for a predetermined period of time, or in case a predetermined event is detected. The predetermined event may include at least one of: detecting available non-SDT traffic and triggering cell reselection (e.g., also including the triggering event described above).

In step S720 of fig. 7, or in a fourth part of the scenario of fig. 8, in a first implementation, the processor may be configured to, in case the abort is detected, keep the UE in the RRC _ INACTIVE state and also keep SDT configuration information of the first SDT session (e.g., SDT config. In fig. 5 or fig. 8), which may include the first NCC and the second NCC. The second NCC obtains from the first DL RRC response message, which is received from the first gNB via interface 602 in the first phase of the first SDT session.

In step S720 of fig. 7, or in a fourth part of the scenario of fig. 8, in a second implementation, the processor may be configured to, in case the abort is detected, keep the UE in the RRC _ INACTIVE state and also keep the SDT configuration information of the first SDT session, the SDT configuration information of the first SDT session including the first NCC.

The first and second first implementations will be described in more detail below.

First implementation mode

In a first implementation, the method for resuming an SDT session for a UE according to the present application may further include the following steps. Alternatively, the processor 601 of the apparatus for resuming an SDT session for a UE according to the present application may be further configured to: in a first phase (for each normal SDT session): generating a first UL SDT message including a first RRC message based on a previous NCC (e.g., NCC0 in fig. 5 or fig. 8); or generate a first UL SDT message including the first RRC message and the first UL SDT traffic for transmission to the first gNB based on the previous NCC and the first NCC (e.g., NCC1 in fig. 5 or fig. 8). The previous NCC corresponds to and is obtained from a previous gNB (e.g., gNB0 in fig. 5 or 8), which was the gNB with which the UE communicated prior to the first SDT session. The first NCC is obtained from the previous gNB, and the first RRC message indicates initiation of the first SDT session. Further, the processor 601 may be further configured to, in the first phase: a first DL RRC response message received from the first gNB via interface 602 in response to the first UL SDT message is analyzed to obtain a second NCC (e.g., NCC 2) corresponding to a second gNB (e.g., gNB 2) for the first resume SDT session or the next SDT session.

In this case, the processor may be further configured to, in the second phase: transmitting, via interface 602, UL SDT traffic and DL SDT traffic for the first SND session based on the first NCC (NCC 1); and analyzes the last DL RRC Release message received at the end point of the second stage via the interface 602 to normally interrupt the first SDT session. In one embodiment, the last DLRRC Release message does not include the new NCC. In one embodiment, the last DL RRC Release message may include a new NCC to replace the second NCC.

In one embodiment of the first implementation, the processor 601 may be further configured to analyze the first DL RRC response message to obtain an updated inactive radio network temporary identifier I-RNTI corresponding to the second gNB (gNB 2) in the first phase (for each normal SDT session); in a second phase, UL SDT traffic and dl SDT traffic for the first SND session are transmitted via the interface based on the first NCC and a current I-RNTI corresponding to the first gNB (gNB 1).

In other words, in the first implementation, in the first phase of each normal SDT session, a new NCC (i.e., the second NCC (NCC 2)) is received from the gNB (the first gNB, e.g., gNB 1) engaged in the current SDT session with the UE.

This embodiment explains that during any SDT mechanism, upon initiation of the SDT mechanism (i.e., the first DL SDT msg of any SDT session), the current gNB provides the UE with a new NCC via a given RRC msg (e.g., through rrcreesume or other type of RRC message, new or reused current message). FIG. 9 below describes example operations. It should be noted that in addition to the new NCC, other information may also be provided to the UE, e.g. an updated I-RNTI identifying the new gNB 1.

Fig. 9 shows a schematic diagram of an example of an SDT session between a UE and a gNB according to an embodiment of the application.

Fig. 9 shows a normal SDT session between the UE and the gNB 1. That is, the SDT session in fig. 9 may be interrupted normally (successfully).

Specifically, in step S901, the UE transmits a RACH message and a first UL SDT RRC message (msg) to the gNBl using NCC0, and transmits UL SDT traffic (traffic) to the gNBl using NCC 1. The RACH message, first UL SDT RRC message, and UL SDT traffic may be the first UL SDT message. This step S901 may correspond to steps S301 to S302 in fig. 3 or step S401 in fig. 4.

In step S902, the UE receives an RRC message with a new NCC2 (optionally, a new I-RNTI 2), which is a first DL RRC response message, from the gNBl. This step S902 is different from the conventional SDT session shown in fig. 3 and 4.

Steps S901 to S902 correspond to the first stage described above.

In step S903-1, the UE transmits UL traffic to and/or receives DL traffic from the gNBl using NCC 1. This step S903-1 may correspond to step S304-1 in fig. 3 or step S402-1 in fig. 4.

In step S903-2, the UE receives a RRCRelease message with or without NCC from the gNBl. At this point, the SDT session between the UE in RRC _ INACTIVE state and the gNB1 is normally interrupted.

In fig. 9, for the SDT session success scenario, "new NCC is provided upon initiation of SDT mechanism (i.e., first (1 st) DL SDT message for any SDT session":

the first UL SDT msg includes at least a first UL RRC message (e.g. RRCResumeRequest) of the UE to indicate the start of the session, and optionally UL SDT traffic (e.g. data or NAS msg). It may also include RACH related information (for 2-step RACH) or alternatively the RACH may be transmitted earlier (for 4-step RACH) or not included in case of CG access.

After the UE sends its first UL SDT msg, the first DL SDT msg may provide the UE with new information (e.g., new NCC or I-RNTI) related to future SDT sessions or recovery. Further, updated configurations may be provided to the UE, e.g., any configurations related to future (even current) SDT sessions. The UE may also then send an RRC response to the network if (re) configuration is provided.

The last DL SDT message may not need to provide any new NCC (since it was already provided to the UE in the first DL SDT). Alternatively, this message includes a new NCC3 or even repeats a previously provided new message (NCC 2), for example, if a suspendConfig is included in this message to keep up with the conventional suspend (suspend) procedure.

In this case, in one embodiment, if an abnormal interruption of the SDT session between the UE and the gNBl is detected (in step S730 of fig. 7, or in step S903-1 of fig. 9), the processor 601 of the apparatus for resuming the SDT session for the UE may be configured to establish a first resumed SDT session between the UE in RRC _ INACTIVE state and a second gNB (e.g., assuming that the UE is now in gNB 2) by: in a first recovery phase (of a first recovery SDT session): generating a first recovery UL SDT message comprising a first recovery RRC message based on the first NCC (NCC 1), or generating a first recovery UL SDT message comprising the first recovery RRC message and first recovery UL SDT traffic based on the first NCC (NCC 1) and the second NCC (NCC 2), for transmission to the second gNB (gNB 2), wherein the first recovery RRC message indicates initiation of the first recovery SDT session; and analyzing a first resume DL RRC response message received from the second gNB via the interface in response to the first resume UL SDT message to obtain a third NCC (e.g., NCC3 (not shown)) as part of the SDT configuration information for the first resume SDT session, wherein the third NCC corresponds to a third gNB (e.g., gNB3 (not shown)) for a next session. In this case, the processor may be further configured to: in a second recovery phase, the remaining ULSDT traffic and DL SDT traffic of the first SDT session are transmitted via the interface based on the second NCC.

In one embodiment, the SDT configuration information for the first SDT session further includes: an updated inactive radio network temporary identifier (I-RNTI) corresponding to the second gNB (gNB 2), the updated I-RNTI obtained from the first DL RRC response message. In this case, the processor 601 may be further configured to: generating a first recovery UL SDT message based on the updated I-RNTI; in a second recovery phase, the remaining UL SDT traffic and DL SDT traffic of the first SDT session are transmitted via the interface based on the second NCC and the new I-RNTI. Further, the processor may be further configured to: the first resume DL RRC response message is analyzed to obtain another updated I-RNTI corresponding to the third gbb (gbb 3). Fig. 10 below will describe an example of the above-described embodiment.

Fig. 10 shows a schematic diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the application.

Steps S1001, S1002, and S1003-1 of fig. 10 may correspond to steps S901, S902, and S903-1 of fig. 9, respectively, and are not described herein again. Steps S1004, S1005, S1006-1, and S1006-2 may correspond to step S730 in fig. 7, and are similar to steps S901, S902, S903-1, and S903-2.

In step S1004, the UE transmits a RACH message and a first UL SDT RRC message to gNB2 (second gNB) using NCC1, and transmits UL SDT traffic (traffic) to gNB2 using NCC 1. The RACH message, first UL SDT RRC message, and UL SDT traffic may be a first resume UL SDT message.

In step S1005, the UE receives an RRC message (msg), which may be a first recovery DL RRC response message, with a new NCC3 (and optionally a new I-RNTI 3) from the gNB2.

Steps S1004 to S1005 correspond to the first recovery phase described above.

In step S1006-1, the UE transmits UL traffic to the gNB2 and/or receives DL traffic from the gNB2 using NCC2.

In step S1006-2, the UE receives an RRCRelease message with or without NCC from the gNB2. At this point, the resume SDT session between the UE in RRC _ INACTIVE state and the gNB2 is normally interrupted.

In fig. 10, for an SDT session failure scenario with a corresponding recovery mechanism, "new NCC is provided when the SDT mechanism (i.e., the first DL SDT message of any SDT session) is started". It should be noted that the focus is on the difference from the successful (normal) scenario already explained.

After the UE detects the SDT session failure, the UE remains in RRC _ INACTIVE and can (re) start the SDT session (after detecting the SDT session failure).

The first UL SDT message (after SDT failure) may include a short MAC-I calculated based on NCC1 used during the SDT session between triggered failures, while the UL data will use the new NCC2 provided previously. Alternatively, NCC0 may also be used to calculate MAC-I (instead of NCC 1). The use of NCC1 or NCC0 may add some complexity (or no increase) depending on whether the context is relocated, e.g., if the UE context is completely relocated to gNB1 before an SDT session failure occurs, then using NCC1 may always be feasible, while NCC0 may not.

Second implementation mode

In a second implementation, in step S730 of fig. 7, the processor 601 may be configured to establish a first resume SDT session between the UE in RRC _ INACTIVE state and the second gNB by: in a first recovery phase, generating a first recovery UL SDT message comprising a first recovery RRC message based on the first NCC (NCC 1) for transmission to the second gNB, wherein the first recovery RRC message indicates initiation of the first recovery SDT session; and analyzing a first resume DL RRC response message received from the second gNB via the interface in response to the first resume UL SDT message to obtain a second NCC (NCC 2) as part of the SDT configuration information for the first resume SDT session (between the UE and the gNB 2), wherein the second NCC corresponds to the second gNB.

This embodiment explains that after the UE fails to trigger an SDT session and the UE re-enables another subsequent SDT session, a new NCC is provided by the network (in the first DL SDT msg of an SDT session initiated after the SDT session failed before the UE triggered) as shown in the example scenario of fig. 11 below. It should be noted that the gNB during the initiation of the SDT session may be different from the gNB during the failure recovery process. Fig. 11 below shows an example of the above embodiment.

Fig. 11 shows a schematic diagram of an example of a resume SDT session between a UE and a gNB according to an embodiment of the application.

During initiation of the first recovery phase of the recovery SDT session, i.e., the first recovery SDT session between the UE and the gNB (which may indicate the first gNB1 and/or the second gNB 2), in step S1101, the UE sends a RACH message and a first RRC SDT message, which may be a first recovery UL SDT message, to the gNB.

Then, in step S1102, the UE receives an RRC SDT message with new NCC2 from the gNB, which may be a first resume DL RRC response message.

Fig. 11 above describes an example operation of the second scenario "new NCC is provided by the network after a UE triggered SDT session failure (i.e., the first DL SDT msg of an SDT session initiated after an SDT session failure before the UE triggered)", considering the following possible consequences:

scheme (2. A): the SDT session terminates, making the UE behavior consistent with RRC Release message operation.

Scheme (2. B): the SDT session continues with the UE behavior consistent with the RRC Reestablishment message operation. To this end, two approaches are shown, depending on the behavior of the UE after detecting an SDT session failure:

a method (x): the UE remains in RRC _ INACTIVE to continue the SDT session.

O is close to (y): the UE transitions or falls back to RRC _ CONNECTED to continue the SDT session.

The following sections discuss the following options in more detail: it is assumed that the UE follows characteristics similar to rrcreelease operation (referred to as a solution space of 2.a) or sequential rrcreestablshment operation (referred to as a solution space of 2.b), however, this level of detail is not shown in the above figure. Furthermore, for simplicity, the figure shows a single gNB for which an SDT failure is triggered and the UE also initiates the next transmission (i.e. gNB1= gNB2 in following the scenario where different gnbs are assumed in the previous figure). But the scheme is equally applicable to different gnbs.

For the above scheme (2.a), in one embodiment, the first resume DL RRC response message (received in S1102 of fig. 11) is an RRC Release message for normally interrupting communication between the UE in RRC _ INACTIVE state and the second gNB, and the UE may choose to normally interrupt the resume SDT session, which means that the SDT session will be interrupted upon receiving the RRC SDT message with the new NCC2 as shown in fig. 11. Fig. 12 below shows an example of the above embodiment.

Fig. 12 shows a schematic diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the application.

In fig. 12, step S1201 is the same as step S1101 of fig. 11, and is not described again here.

In step S1202, the RRC SDT message with NCC2 received by the UE from the gNB is the last RRC SDT message in the recovery SDT session. Then, the communication between the UE and the gNB may be interrupted normally.

As another example of the above aspect (2.a), the first resume DL RRC response message is an RRC Release message for normally interrupting communication between the UE in RRC _ INACTIVE state and the second gNB, and the UE may choose to continue the resume SDT session. In this case, the second recovery phase for recovering the SDT session may include a first sub-recovery phase for further initiating the first recovery SDT session and a second sub-recovery phase for transferring the remaining UL SDT traffic and DL SDT traffic of the first SDT session.

In this case, in one example, the processor 601 may be further configured to: in the first sub-recovery phase, generating a second recovery UL SDT message comprising a second recovery RRC message based on the first NCC (NCC 1), or generating a second recovery UL SDT message comprising the second recovery RRC message and the first recovery UL SDT traffic based on the first NCC (NCC 1) and the second NCC (NCC 2), for transmission to a second gNB (gNB 2, shown as gNB in the following diagram for simplicity), wherein the second recovery RRC message indicates further initiation of the first recovery SDT session; in the second sub-recovery phase, transmitting, via the interface, remaining UL SDT traffic and DL SDT traffic of the first SDT session based on the second NCC, and analyzing a last DL RRC Release message received at an end point of the second sub-recovery phase via the interface to normally interrupt the first recovery SDT session, wherein the last DL RRC Release message includes a third NCC (NCC 3), wherein the third NCC corresponds to a third gNB for a next session. The above process may be similar to a normal SDT session.

For scheme (2. B) above, in one embodiment of method (x), the first resume DL RRC response message (received in S1102 of fig. 11) is not used to interrupt communication between the UE and the second gNB. In this case, the processor 601 may be further configured to: in a second recovery phase, transmitting, via the interface, the remaining UL SDT traffic and DL SDT traffic of the first SDT session based on the second NCC while keeping the UE in the RRC _ INACTIVE state; and analyzing a last DL RRC Release message received at an end point of the second recovery phase via the interface to normally interrupt the first recovery SDT session. The last DL RRC Release message includes the third NCC,. The third NCC corresponds to a third gNB for the next session. Fig. 13 below shows an example of the above embodiment.

Fig. 13 shows a schematic diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the application.

In fig. 13, step S1301 is the same as step S1101 of fig. 11, and is not repeated here.

In step S1302, the UE receives a first RRC SDT message with a new NCC2 from the second gNB (gNB 2), which may be a first recovery DL RRC response message.

In step S1303-1, the UE receives DL traffic from the gNB and/or transmits UL traffic to the gNB using the new NCC2.

Resume SDT session is ongoing with UL/DL SDT traffic while UE is still in RRC _ INACTIVE state.

In step S1303-2, the UE receives the last RRC SDT message with the new NCC 3. At this point, the resume SDT session between the UE in RRC _ INACTIVE state and the gNB is normally interrupted.

For method (y) of scenario (2. B) above, in one embodiment, the first resume DL RRC response message (received in S1102 of fig. 11) is not used to interrupt communication between the UE and the second gNB. In this case, the processor 601 may be further configured to: switching the state of the UE from an RRC _ INACTIVE state to an RRC CONNECTED (RRC _ CONNECTED) state at the start of the second recovery phase; in a second recovery phase, transmitting, based on the second NCC, the remaining UL SDT traffic and DL SDT traffic for the first SDT session via the interface while maintaining the UE in an RRC _ CONNECTED state; and analyzing a last DL RRC Release message received at an end point of the second recovery phase via the interface to normally interrupt the first recovery SDT session. The last DL RRC Release message includes the third NCC (NCC 3). The third NCC corresponds to a third gNB for the next session. Fig. 14 below shows an example of the above embodiment.

Fig. 14 shows a schematic diagram of an example of a resume SDT session between a UE and a gNB according to an embodiment of the application.

In fig. 14, step S1401 is the same as step S1101 of fig. 11, and is not described again here.

In step S1402, the UE receives a first RRC SDT message with a new NCC2, which may be a first resume DL RRC response message, from a second gNB (gNB 2).

The UE then switches to the RRC _ CONNECTED state.

In step S1403-1, the UE receives DL traffic from and/or transmits UL traffic to the gNB using the new NCC2.

The resume SDT session is ongoing with UL/DL SDT traffic while the UE is still in RRC _ CONNECTED state.

In step S1403-2, the UE receives the last RRC SDT message with the new NCC 3. At this point, the recovery SDT session between the UE and the gNB is normally interrupted.

Further, for the embodiments described for the various aspects, the processor may be further configured to: analyzing the first recovery DL RRC response message to obtain an updated I-RNTI corresponding to the second gNB (gNB 2); and transmitting, in a second recovery phase, the remaining UL SDT traffic and dl SDT traffic of the first SND session via the interface based on the second NCC (NCC 2) and the updated I-RNTI.

With respect to the above solution (2.a) and solution (2.b), the focus of the following problem is the difference between the possible options, i.e., solution (2.a), (2.b-x), or (2.b-y):

problem 1) action of the UE in failure to trigger an ongoing SDT session;

problem 2) UE action when starting the next SDT session again (i.e. first UL SDT after failure to trigger ongoing SDT session);

problem 3) how the network provides updated NCC; and

problem 4) action of the UE when receiving a new NCC.

It is important to emphasize that at the start of an SDT operation (i.e., when an SDT session is started after an SDT session failure), SRB1 will always re-establish PDCP (i.e., PDCP count reset) assuming legacy operation for SRB1 processing. Further, some of the UE actions listed herein may be implemented in a different order than suggested, e.g., upon failure to trigger or initiation of an SDT session, or may even be repeated in both parts of the procedure.

For simplicity, this discussion focuses on the new NCC2 provided to the UE after the failure to trigger the SDT session, however, the network may provide other configurations, e.g., a new I-RNTI as previously described.

For the following discussion, it is important to note the application of actions by the UE when a given SDT session is started and ongoing, as discussed above.

The following discussion focuses on the operation of the UE, however, the network behavior needs to be consistent. Furthermore, this becomes more critical for the solution space 2.b), which is similar to what happens in conventional reconstruction operations.

Scheme 2. A): the behavior of the UE is consistent with the RRC Release message operation

Scheme space 2.a) assume that the UE behavior is consistent with the release operation. This means that RRC messages providing a new NCC will be ciphered using the old key (integrity protection and ciphering).

Problem 1) actions of a UE in triggering an ongoing SDT Session failure

The following presents a list of possible new UE actions when a triggered ongoing SDT session fails for scheme space 2.a). Comments added above in the related items/actions may also apply here (in this case reference). Furthermore, all of these actions when an SDT session failure is detected will be new operations related to the SDT procedure. For relevant information see the following summary table 1 for schemes 1) and 2).

1) The SDT session failure timer (if running) is stopped.

a) Note-13: if other timers are started during the SDT session, they are also stopped. Thus, other conventional timers, such as the timer for a periodic RNAU, will always run.

2) For the stored UE AS context, different behaviors may be considered depending on how the configuration and/or other information used by the UE is handled during the SDT session with the gNB1 (i.e., before triggering the SDT session failure):

a) The method comprises the following steps Option a) updates all or part of the information in the stored UE AS context (which was created when the UE released from gNB 0) with the current/up-to-date information used during the SDT session with gNB1 (i.e., before triggering the SDT session failure). For example, the following information may be replaced from the stored UE AS context (consistent with the conventional recovery procedure when sending rrcreelease in response to RRCResumeRequest):

i. will K _gNB And _KRRCint key replacement with current K _gNB And K _RRCint A key.

Replace the C-RNTI with a temporary C-RNTI in the cell in which the RRCRelease message was received by the UE.

Replace cellIdentity with cellIdentity of the cell where the UE received the rrcreelease message.

Replacing the physical cell identity with the physical cell identity of the cell for which the UE received the rrcreelease message.

b) The method comprises the following steps Option b) creates a new temporary UE AS context using the new current/up-to-date information used during the SDT session with the gNB1 (i.e., before triggering the SDT session failure). This may be similar to the legacy UE AS context, or a subset of applicable information related to the current SDT session, and possibly also for resumed SDT sessions that may be initiated in the future.

c) The method comprises the following steps Option c) new current/up-to-date information used during the SDT session with the gNB1 (i.e., before the SDT session failure was triggered) is released or discarded. However, for this option c), the UE still retains the original version of the stored UE AS context (which was created when the UE released from gNB 0). The stored temporary or in-use information of the UE AS Context is discarded. This may include dropping or releasing any of the following (it should be appreciated that the originally stored UE AS context is kept the same AS before the SDT session was initiated):

i. deriving new security keys (e.g., K) based on stored NCC _gNB 、K _RRCenc 、K _RRCint 、K _UPint And K _Upenc )；

All radio resources including RLC entity, BAP entity, MAC configuration and associated PDCP entity and all established for SDT session

SDAP of the RB immediately (or resumed); rrc configuration, roHC state, stored QoS flow to DRB mapping rules, masterCellGroup and pdcp-Config.

It should be noted that combinations of these options are also possible,and may also include those specific to or related to the SDT mechanism Additional information/configuration。

3) All SRBs and DRBs are paused except SRB 0.

a) Note-10 above may also be applicable here.

b) Note-: reference to transmitting and receiving RBs may need to be explicitly mentioned (similar to "pausing transmission and reception of all DRBs in a source MCG" for RLF, aiming to prevent undesired behavior of ongoing traffic).

4) The PDCP suspension is indicated to the lower layers of all SRBs and DRBs except for SRB0 (which will reset the PDCP COUNT).

a) Note-10 above may also be applicable here.

5) The suspension of the RRC connection is indicated to the upper layer.

a) The above note-12 may also be applied here.

6) Any segment of the segmented RRC message stored in the buffer may be discarded.

a) Note-14: this may refer to RRC messages in DL (e.g., DLDedicatedMessageSegment, or dlinformation transfer) and UL (e.g., ULInformationTransfer). This may help in the following cases: for example, if some of the RRC messages are long and require segmentation (e.g., for a positioning scenario), or if the UE has RRC messages in the buffer when the SDT session is triggered to fail.

7) Reset the MAC and release the default MAC cell group configuration.

a) Note-3 above may also be applied to this.

8) Information relating to SDT session failures may be stored. E.g., by radio link failure information (e.g., in VarRLF reports) or similar mechanisms. Thus, a new failure cause and failure content determination may be defined for an SDT session failure, or some possible failure triggers that may occur during an ongoing SDT session. If so, this may be updated in TS 38.331 at section 5.3.10.4 for RLF cause determination and at section 5.3.10.5 for RLF report content determination. Such information may be primarily relevant to SON-type scenarios.

Problem 2) action of the UE when starting the next SDT session again (i.e., the first UL SDT after the failure to trigger the ongoing SDT session)

For scenario space 2.a, the list of possible UE actions when the next SDT session is initiated again (i.e., the first UL SDT after the failure to trigger the ongoing SDT session) is similar to that described above with respect to the new UE actions during the SDT session (including the start-up phase). The relevant information can be seen in the following summary table 1 for schemes 1) and 2). This may also be a conventional recovery operation if the UE happens to have data on the non-SDT DRBs at this time.

In the related UE actions described above with respect to the new UE actions during the SDT session (including the start-up phase), it is possibleIs not limited toActions in problem 2) that are appropriate (or different) to the solution space 2. A) are as follows:

-11) set resummemac-I (using K in UE Inactive AS Context) _RRCint Keys and previously configured integrity protection algorithms).

Annotation-16: step 2) described above (related to problem 1) explains the possible handling of the configuration used. It is applicable here. Thus, the UE may use NCC0 or NCC1 when generating a short MAC-I for starting a new SDT session after failure.

-12) derive a security key (and for K) using the stored nextHopChainingCountp _gNB 、K _RRCenc 、K _RRCint 、K _UPint And K _UPenc Same as conventional recovery).

O annotation-17: this step may be done in the UE, however, this key may not be used, since after an SDT session failure, the gNB will always update the NCC to be used (i.e., provide a new NCC2 in the first DL SDT msg, as described earlier).

-18) if the SRB is configured (or allowed) for SDT operation and the upper layer provides NASPDU, it may be transmitted in the first UL SDT, e.g., as part of the UL informationtransfer msg, or alternatively as part of a new IE defined in the transmitted first UL RRC msg (e.g., dedicatedinas-Message).

Annotation-18: sending UL SDT traffic (data or NAS messages) in the first UL SDT may not be beneficial since the gNB will provide the new NCC2 in the first DL SDT message. Since if the UE sends UL SDT traffic, the UE may need to retransmit it again with the updated new NCC2.

-20) SDT data can also be sent in the first UL SDT msg.

O annotation-18.

Problem 3) how the network provides updated NCC

The scheme space 2.a) is characterized in that RRC messages providing the new NCC2 will be ciphered (integrity protected and ciphered) using the old key (which is generated based on the stored NCC, which may be NCC1 or NCC0 as described earlier). For relevant information see the following summary table 1 for schemes 1) and 2).

Problem 4) actions of the UE when receiving a new NCC

For scenario 2.a), the SDT session that started after the previous SDT session failed is always interrupted by the gNB. In this way, the UE updates the information stored in the UE AS context to the new information provided by the gNB (e.g., NCC, I-RNTI). Thus, whether/how to trigger any immediate or subsequent attempts (e.g., restoration of the connection through legacy or SDT mechanisms) may depend on the UE implementation.

Scheme 2.B) UE behavior consistent with RRC recovery message operation

Solution space 2.b) assumes that the behavior of the UE is consistent with the re-establishment operation. This would mean that the RRC messages providing the new NCC2 would be integrity protected but would not be ciphered. Integrity protection uses the same NCC2 carried in this message.

Problem 1) actions of a UE in triggering an ongoing SDT Session failure

For scenario space 2.b) the list of possible UE actions for the UE when the triggered ongoing SDT session fails, may be similar, if not identical, to the related list provided above for scenario 2.a) for similar problem 1). For simplicity and to reduce repetition, the parts of the list in the part of scheme 2.a) for similar problem 1) that do not apply to scheme 2.b) will be discussed below. For relevant information see the following summary table 1 for schemes 1) and 2).

Possibilities in scheme space 2.A)Is not limited toRelevant UE actions applicable to problem 1) of (or different) scheme 2.b) are as follows:

-2) option c) new current/up-to-date information used during the SDT session with the gNB1 (i.e. before triggering the SDT session failure) is released or discarded. However, for this option c), the UE still retains the original version of the stored UE AS context (which was created when the UE released from gNB 0). The stored temporary or in-use information of the UE AS Context is discarded. This may include dropping or releasing any of the following (it should be appreciated that the originally stored UE AS context is kept the same AS before the SDT session was initiated):

a) Deriving new security keys (e.g., K) based on stored NCC _gNB 、K _RRCenc 、K _RRCint 、K _UPint And K _Upenc )；

b) All radio resources including RLC entity, BAP entity, MAC configuration and associated PDCP entity and SDAP for all established (or recovered) RBs for SDT session; and

c) RRC configuration, roHC state, stored QoS flow to DRB mapping rules, masterCellGroup, and pdcp-Config.

-4) indicate PDCP suspension to the lower layers of all SRBs and DRBs except SRB0 (which will reset PDCP COUNT).

-6) discarding any segments of the segmented RRC message stored in the buffer.

Problem 2) action of the UE when starting the next SDT session again (i.e., the first UL SDT after the failure to trigger the ongoing SDT session)

For scheme space 2.b), the list of possible UE actions when the next SDT session is initiated again (i.e. the first UL SDT after triggering the ongoing SDT session failure) is similar to the list included above with respect to the new UE actions during the SDT session (including the start-up phase) and above for problem 2) of scheme 2.a), except for the part related to the re-establishment operation. For relevant information see the following summary table 1 for schemes 1) and 2).

In the related UE actions described above with respect to the new UE actions during the SDT session (including the start-up phase) and the actions of the related UE in problem 2) above for scheme 2.a), it is possible to do soIs not limited toIs suitable for (or not)Same as) solution space 2. B) the actions in problem 2) are as follows:

2.13) configure lower layers to apply integrity protection and ciphering for all radio bearers except SRB 0.

O annotation-: this should not apply to SRB1 until a new NCC2 is provisioned, since for the rebuild method it is sent through the first DL SDT message, which will be integrity protected but not encrypted.

Problem 3) how the network provides updated NCC

This solution space 2. B) is characterized in that the RRC messages providing the new NCC2 will be integrity protected but not ciphered. Integrity protection uses the same NCC2 carried in this message.

The relevant information can be seen in the following summary table 1 for schemes 1) and 2).

Problem 4) actions of the UE when receiving a new NCC

For scheme 2. B), the UE needs to generate new security keys and apply them to the RBs used. Furthermore, for the scenario where the UE transitions to CONNECTED (solution 2. B-y), the UE also needs to handle all non-SDT details that need to be restored or released or updated to be used.

Scheme 2.C) New UE behavior to implement partial/temporary suspension operation

It is also possible to use a hybrid or combined approach between scheme 2.a) and scheme 2.b). E.g., scheme 2.a) using C-RNTI and similar release, or scheme 2.b) using I-RNTI and similar reconstruction, or scheme 2.a) continuing to use similar release (i.e., PDUs are not discarded).

Scenario spaces 2A) and 2B), where a new NCC is provided by the network after the UE triggers an SDT session failure

Table 1 below summarizes the different steps associated with the various protocol spaces (2.a, 2.b-x, 2.b-y), including the key details explained above.

Table 1 has different parts created for the different problem associations discussed, which may be mapped to example steps that may occur after the UE detects an SDT session failure (to enable a corresponding recovery mechanism):

step 1) (problem 1) actions of the UE in triggering an ongoing SDT session failure;

step 2) (problem 2) action when the UE starts an SDT session after detecting the previous SDT session failure (send the first UL SDT);

step 3) (problem 3) how the network provides updated NCC (note that other information may be updated, e.g., I-RNTI, but is not shown below for simplicity); and

step 4) (problem 4) actions of the UE when receiving a new NCC.

It should be noted that the following summary table 1 for scenarios 1) and 2) does not include all of the details explained above for each item and is labeled:

- "x": actions that may be applicable and common to all schemes (i.e., 2.A, 2.B-x, 2.B-y);

- "o": scheme 2.A, scheme 2.B-x, scheme 2. B-y; and

- "-": the point at which the UE initiates a normal SDT session may be different between the actions at which the UE initiates the SDT session (as described above) and the point at which the UE initiates the SDT session after detecting a previous SDT session failure.

Note that "na" is added for items that may not be applicable to a given scheme.

TABLE 1

As another implementation (third implementation), in one embodiment, the processor 601 in the apparatus for resuming an SDT session may be further configured to: under the condition that the abnormal interruption is detected, generating a security key by using a horizontal key derivation method and utilizing a first NCC; in a second recovery phase, the remaining UL SDT traffic and DL SDT traffic of the first SDT session are transmitted based on the security key.

In this case, in one example, the processor 601 may be further configured to switch the state of the UE from the RRC _ INACTIVE state to the RRC IDLE RRC _ IDLE state if the count value for the number of times the security key is generated reaches a predetermined value. Fig. 15 to 17 below show some examples of this embodiment.

Fig. 15-17 show schematic diagrams of examples of resuming an SDT session between a UE and a gNB according to embodiments of the application.

Fig. 15-17 may be similar to fig. 12-14, respectively, with the main difference between them being the calculation of the new key and the possibility of using the new key to transmit UL/DL traffic.

In particular, steps S1501, S1601, and S1701 may be similar to steps S1201, S1301, and S1401, respectively, except that UL SDT data is also transmitted in steps S1501, S1601, and S1701.

Steps S1502, S1602-2, and S1703-2 may be similar to steps S1202, S1303-2, and S1403-2, respectively, and will not be described herein again.

Steps S1602-1 and S1703-1 may be similar to steps S1303-1 and S1403-1, respectively, except that the new key is used to transmit UL/DL traffic in steps S1602 and S1703-1.

Further, in step S1702, the UE receives an RRC Resume message from the gNB.

For the above-described embodiments shown in fig. 15-17:

the UE may trigger this event when SDT or even legacy recovery is initiated; and

an indication of the number of completed horizontal key derivations may be provided in the first UL SDT. This will help synchronize the UE with the number of horizontal key derivatives that the network completes if the UE performs an unsuccessful access attempt and the network is not aware of. Which may be a single flag or number indicating the actual value or completion of the increment. The UE may autonomously transition to RRC _ IDLE (as described previously) when the UE reaches a maximum number of subsequent SDT session failures. For example, if only a single flag is indicated by UE0, a second subsequent SDT session failure will trigger the UE to transition to RRC _ IDLE.

Further details regarding how the embodiments of fig. 15-17 may work are provided below

Problem a) how to trigger horizontal key derivation

A new trigger may be defined for the UE to apply horizontal key derivation if:

a) When an SDT session is initiated after detecting a previous SDT session failure; and/or

b) non-SDT traffic becomes available when an SDT session is started after a suspension or interruption of a previous SDT session is detected, e.g., due to a rejection or while the SDT session is ongoing.

It should be noted that more than one of the above options may be applied together.

Problem B) frequency of update level Key derivation

The specification may define or allow for configuring how often the UE needs to perform a horizontal key derivation. For example, assume an SDT failure scenario:

a) Starting an SDT session whenever an SDT session is started after a previous SDT session failure is detected;

b) When an SDT session is initiated in a new/different cell (after detecting a previous SDT session failure);

c) When an SDT session is started in a cell where UE AS Inactive context is not available (after detecting a previous SDT session failure) (without a need for a full or temporary relocation); and/or

d) When an SDT session is initiated in a cell that does not belong to the UE-configured RNA (after detecting a previous SDT session failure).

It should be noted that more than one of the above options may be applied together, and that these options are equally applicable to the other triggering scenarios discussed earlier.

Problem C) how to use the key in the first RRC request message and the first SDT data

This new key is used instead of the stored key (which is NCC1 based) to encrypt the data/traffic exchanged during a given SDT session. The reason is because the key corresponding to NCC1 has been used in a previously abruptly interrupted SDT session. And the same key cannot be used for another gNB or the same gNB with the same COUNT. However, the short MAC-I can be calculated using NCC0, NCC1 or the new key.

FIG. 18 below shows an example flow of how these embodiments work. It should be noted that the indication of the number of horizontal key derivations is denoted as # keyCount and may be provided as part of one RRC msg, e.g. the first RRC msg sent (e.g. rrreecumerequest) or a different message (based on an existing or possibly created new message). Further, # keyCount may be provided by other means, for example, as an indication in the header. Alternatively, this # keyCount may not be defined or may be optionally included only when needed.

Fig. 18 shows a schematic diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the application.

The left diagram (a) in fig. 18 shows a normal SDT session between the UE and the gNB.

In step S1801, the UE transmits the RACH message and RRCResumeRequest to the gNB using NCC0, and transmits UL SDT data to the gNB using NCC 1.

In step S1802-1, the UE transmits UL data to the gNB and/or receives DL data from the gNB using NCC 1. That is, the UE and the gNB may exchange data with each other.

In step S1802-2, the UE receives a RRCRelease message with NCC2 (and I-RNTI 2) from the gNB. At this point, the SDT session between the UE and the gNB is normally interrupted.

If an abort occurs during S1802-1, the SDT session may be resumed through steps S1803, S1804-1, and S1804-2, referring to the right diagram (b) in FIG. 18.

Step S1803 is similar to step S1801, except that # keyCount is also sent to the gNB.

Step S1804-1 is similar to step S1802-1, except that DL/UL SDT data may be transmitted using the key _ x obtained for the recovery session.

Step S1804-2 is similar to step S1802-2 and will not be described herein.

Further, in some cases, the abort may be triggered by a network corresponding to the first gNB in a second phase of the first SDT session for transfer of an Access Stratum (AS) context of the UE from one gNB to another gNB.

At this time, as a fourth implementation, the processor 601 may be further configured to: keeping the UE in an RRC _ INACTIVE state under the condition that abnormal termination is detected; keeping the UE in an RRC _ INACTIVE state under the condition that the abnormal interruption is detected; establishing a first recovery SDT session between the UE in RRC _ INACTIVE state and a second gNB based on a first NCC and an updated first NCC, wherein the updated first NCC is received from a network via an interface after an abort and corresponds to the first gNB. At this time, the second gNB is identical to the first gNB.

For the various implementations described above, processor 602 may also be configured to report an abort to a network corresponding to the first gNB.

In particular, the network may desire to know whether the SDT session that the UE requested to be initiated is a recovery from a sudden interruption or failure of a previous SDT session, as discussed in previous schemes. Thus, the network will be able to distinguish UE-initiated normal SDT sessions from previously abruptly stopped SDT sessions that the UE desires to continue. The UE may indicate this in different ways, e.g., using a different/new RRC msg, using an indication in the RRC msg, or using a header for a normal SDT session (e.g., rrcresemequest or rrcreseme-SDT-Request), using an indication on MAC, etc.

Returning to the fourth implementation, this implementation may be used in conjunction with other implementations explained above.

SDT session termination may occur at:

-upon reception of a RRCReject message; or alternatively

-upon reception of an RRCSetup message.

This scenario would only occur when the SDT session starts and the network just receives a ResumeRequest with SDT data. An SDT session is considered to be interrupted when the network controls the end of the SDT session or the specified conditions to initiate CG-SDT are not valid. For all these cases, the next attempt will be considered as a new attempt. Thus, for UL data processing when the SDT session is interrupted, the gNB does not know the actual data that was sent (or intended to be sent) in the first UL SDT of the UE. Therefore, the retransmission of data will be handled by the UE control.

The scenario where the UE returns to establishing a new connection may not require much discussion, however, a reject scenario (reject) will be discussed because the SDT mechanism will recover all bearers for the SDT session (unlike conventional recovery where only SRB1 recovers at this point).

Rejection scenario: actions by a UE when detecting an interruption of an SDT session

TS 38.331 section 5.3.15.2 "reception of RRCReject by UE" needs to be updated for SDT mechanism. For SDT operation, the same conventional steps defined at the time of receiving RRCReject apply (as shown below in the reference taken from TS 38.331).

5.3.15.2UE receives RRCRreject

The UE shall:

1> stop timer T300 (if running);

1> stop timer T319 (if running);

1> stop timer T302 (if running);

1> resetting the MAC and releasing the default MAC cell group configuration;

1> if waitTime is configured in RRCReject:

2> starting a timer T302, and setting the timer value as waitTime;

1> if RRCRreject is received in response to a request from an upper layer:

2> notify the upper layer that the access barring applies to all access categories except categories "0" and "2";

1> if RRCRreject is received in response to RRCSetupRequest:

2, informing the upper layer of RRC connection establishment failure, and ending the process;

1> otherwise, if RRCRELEject is received in response to RRCRESUMeRequest or RRCRESUMeRequest 1:

2> if the recovery is triggered by the upper layer:

3> notifying the upper layer of the failure of recovering RRC connection;

2> if recovery is triggered by RNA turnover:

3> setting a variable pendingRNA-Update to true;

2>discard the current K _gNB Secret key, K _RRCenc Secret key, K _RRCint Secret key, K _UPint Secret key and K derived according to 5.3.13.3 _UPenc A key;

2> suspending SRB1, and ending the process;

when the timer T302 runs, the RRC _ INACTIVE UE will continue to monitor for pages.

Note that: if the timer T331 is running, the UE continues to perform idle/inactive measurements as per 5.7.8.

Furthermore, new SDT-specific operations may also be handled for the SDT mechanism, e.g., operations related to SDT failure detection timer, SDT configuration, recovery of other Radio Bearers (RBs), and handling of ULSDT traffic, as described above. For example:

any RB resumed when the SDT mechanism is started also needs to be suspended for rejection cases or released for setup. This may be only a portion of the RBs configured for a given UE, e.g., those configured for SDT operation (i.e., the case where the UE only reverts these RBs to send the first UL SDT), or all RBs configured for a given UE, which are part of the stored UE AS context (i.e., the case where the UE has reverted all RBs to send the first UL SDT),

o the above note-10 may also be applicable here;

-stopping the SDT fault detection timer (similar to the legacy T319) and other running SDT related timers (if any);

-discarding SDT related configurations/information in use; and

-may indicate to the upper layer that the suspended RRC connection has resumed;

the above note-12 is also applicable here.

Details of a scenario in which UE context is relocated in the middle of an SDT session

This scenario occurs when the network decides not to relocate the UE context for an SDT session, but during an ongoing SDT session, it triggers a return recovery, as shown in fig. 19 below. This may be triggered when non-SDT traffic is detected, or for other reasons caused by network decisions (e.g., if an SDT session gets longer).

Fig. 19 illustrates a diagram of an example of resuming an SDT session between a UE and a gNB according to an embodiment of the application.

Referring to fig. 19, in the previous session, RAN2 agreed that the handover between SDT to non-SDT was achieved by the network providing RRCResume msg. Then, the potential impact of the UE context being relocated has not been discussed.

One simple option here may be to release the updated SDT configuration and NCC that the UE has. When the UE issues a new RRCResumeRequest, it may be supported in the current gbb without anchor. This comes at the cost of the Release message and some extra delay in starting a new access. In the case where an anchor point is used and it is necessary to move the anchor point, this situation is unlikely to occur frequently. This is more likely to occur in case of CU DU splitting. Therefore, such a delay is acceptable.

According to SA3 requirements, the same key is not allowed to be reused in both nodes. Thus, a change of anchor point requires a change of security key. Changing the key requires resetting L2 to prevent data confusion with the old and new keys. Currently, when the user plane is suspended/not established (re-establishment, SMC, resume) or when RACH procedure + L2 reset is used as a handover point, a change of key is made if there is an ongoing data transmission (handover). The release and addition of RLC bearers may also be used to refresh L2. In addition, the PDCP must be re-established. However, none of the existing NR procedures support this specific behavior.

In summary, to support anchor point changes during an SDT session, at a high level, a new procedure should be defined to support key changes, including: provide new NCC to UE, suspend data transmission, reset L2, re-establish PDCP, resume data transmission.

This is done by extending existing messages or using new messages, which may be based on actual needs.

On the network side, the following points need to be noted: which node triggered the anchor change and which node generated the RRC message with NCC. This depends on the network architecture, including how the CUDU splitting is done for anchoring.

Fig. 20 shows a diagram of a network 2000, according to various embodiments of the present disclosure. The network 2000 may operate in a manner consistent with the 3GPP technical specifications for LTE or 5G/NR systems. However, the example embodiments are not limited in this respect, and the described embodiments may be applied to other networks, such as future 3GPP systems and the like, that benefit from the principles described herein.

The network 2000 may include a UE2002, which may include any mobile or non-mobile computing device designed to communicate with the RAN 2004 via an over-the-air connection. The UE2002 may be, but is not limited to, a smartphone, a tablet, a wearable computer device, a desktop computer, a laptop computer, an in-vehicle infotainment device, an in-vehicle entertainment device, an instrument cluster, a heads-up display device, an in-vehicle diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic/engine control unit, an electronic/engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networked appliance, a machine-type communication device, an M2M or D2D device, an internet of things device, and/or the like.

In some embodiments, the network 2000 may include multiple UEs directly coupled to each other through edge link interfaces. The UE may be an M2M/D2D device that communicates using a physical side link channel (e.g., without limitation, a physical side link broadcast channel (PSBCH), a physical side link discovery channel (PSDCH), a physical side link shared channel (PSSCH), a physical side link control channel (PSCCH), a physical side link fundamental channel (PSFCH), etc.).

In some embodiments, the UE2002 may also communicate with the AP 2006 over an over-the-air connection. The AP 2006 may manage WLAN connections, which may be used to offload some/all network traffic from the RAN 2004. The connection between the UE2002 and the AP 2006 can be consistent with any IEEE 802.11 protocol, where the AP 2006 can be wireless fidelity

A router. In some embodiments, the UE2002, RAN 2004, and AP 2006 may utilize cellular WLAN aggregation (e.g., LTE-WLAN aggregation (LWA)/lightweight IP (LWIP)). Cellular WLAN aggregation may involve a UE2002 configured by a RAN 2004 to utilize both cellular radio resources and WLAN resources.

The RAN 2004 may include one or more access nodes, e.g., AN 2008. The AN 2008 can terminate the air interface protocols of the UE2002 by providing access stratum protocols including RRC, packet Data Convergence Protocol (PDCP), radio Link Control (RLC), medium Access Control (MAC), and L1 protocols. In this manner, the AN 2008 may enable data/voice connectivity between the CN 2020 and the UE 2002. In some embodiments, AN 2008 may be implemented in a separate device or as one or more software entities running on a server computer, as part of a virtual network, for example, which may be referred to as a CRAN or virtual baseband unit pool. The AN 2008 may be referred to as a Base Station (BS), a gNB, a RAN node, AN evolved node B (eNB), a next generation eNB (ng-eNB), a node B (NodeB), a roadside unit (RSU), a TRxP, a TRP, and the like. The AN 2008 can be a macro cell base station or a low power base station that provides a micro cell, pico cell, or other similar cell with a smaller coverage area, less user capacity, or higher bandwidth than a macro cell.

In embodiments where the RAN 2004 includes multiple ANs, they may be coupled to each other over AN X2 interface (in the case where the RAN 2004 is AN LTE RAN) or AN Xn interface (in the case where the RAN 2004 is a 5G RAN). The X2/Xn interface, which may be separated into a control plane interface/user plane interface in some embodiments, may allow the AN to communicate information related to handover, data/context transfer, mobility, load management, interference coordination, etc.

The AN of the RAN 2004 may each manage one or more cells, groups of cells, component carriers, etc., to provide the UE2002 with AN air interface for network access. The UE2002 may be simultaneously connected with multiple cells provided by the same or different ANs of the RAN 2004. For example, the UE2002 and the RAN 2004 may use carrier aggregation to allow the UE2002 to connect with multiple component carriers, each corresponding to a primary cell (Pcell) or a secondary cell (Scell). In a dual connectivity scenario, the first AN may be a primary node providing a Master Cell Group (MCG) and the second AN may be a secondary node providing a Secondary Cell Group (SCG). The first/second AN can be any combination of eNB, gNB, ng-eNB, etc.

The RAN 2004 may provide an air interface over a licensed spectrum or an unlicensed spectrum. To operate in unlicensed spectrum, a node may use a Licensed Assisted Access (LAA), enhanced LAA (eLAA), and/or further enhanced LAA (feLAA) mechanism based on Carrier Aggregation (CA) technology with PCell/Scell. Prior to accessing the unlicensed spectrum, the node may perform a media/carrier sensing operation based on, for example, a Listen Before Talk (LBT) protocol.

In a vehicle-to-everything (V2X) scenario, the UE2002 or AN 2008 may be or function as a Road Side Unit (RSU), which may refer to any transport infrastructure entity for V2X communication. The RSU may be implemented in or by AN appropriate AN or a stationary (or relatively stationary) UE. An RSU implemented in or by a UE may be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU"; RSUs implemented in or by a next generation NodeB (gNB) may be referred to as "gNB-type RSUs"; and so on. In one example, the RSU is a computing device coupled with radio frequency circuitry located at the curb side that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications/software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may provide very low latency communications required for high speed events, e.g., collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU may provide other cellular/WLAN communication services. The components of the RSU may be enclosed in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide a wired connection (e.g., ethernet) to a traffic signal controller or backhaul network.

In some embodiments, RAN 2004 may be LTE RAN 2010, including an evolved node B (eNB), e.g., eNB 2012.LTE RAN 2010 may provide an LTE air interface with the following characteristics: SCS at 15 kHz; a CP-OFDM waveform for DL and an SC-FDMA waveform for UL; turbo codes for data and TBCC for control, etc. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; relying on a PDSCH/PDCCH demodulation reference signal (DMRS) for PDSCH/PDCCH demodulation; and relying on CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operate on the sub-6 GHz band.

In some embodiments, the RAN 2004 may be a Next Generation (NG) -RAN 2014 with a gNB (e.g., gNB 2016) or gn-eNB (e.g., NG-eNB 2018). The gNB 2016 may connect with a 5G-enabled UE using a 5G NR interface. The gNB 2016 may be connected to the 5G core via an NG interface, which may include an N2 interface or an N3 interface. The Ng-eNB 2018 may also connect with the 5G core over the Ng interface, but may connect with the UE over the LTE air interface. The gNB 2016 and ng-eNB 2018 may be connected to each other via an Xn interface.

In some embodiments, the NG interface may be divided into two parts, a NG user plane (NG-U) interface, which carries traffic data between nodes of the NG-RAN 2014 and the UPF 2048, and a NG control plane (NG-C) interface, which is a signaling interface (e.g., N2 interface) between the NG-RAN 2014 and nodes of the access and mobility management function (AMF) 2044.

NG-RAN 2014 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM for UL, and DFT-s-OFDM; polar, repetition, simplex, and Reed-Muller (Reed-Muller) codes for control, and LDPC for data. The 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS similar to the LTE air interface. The 5G-NR air interface may not use CRS, but may use PBCH DMRS for PBCH demodulation; performing phase tracking of the PDSCH using the PTRS; and time tracking using the tracking reference signal. The 5G-NR air interface may operate over the FR1 band, which includes the sub-6 GHz band, or the FR2 band, which includes the 24.25GHz to 52.6GHz band. The 5G-NR air interface may include SSBs, which are regions of a downlink resource grid including PSS/SSS/PBCH.

In some embodiments, the 5G-NR air interface may use BWP for various purposes. For example, BWP may be used for dynamic adaptation of SCS. For example, the UE2002 may be configured with multiple BWPs, where each BWP configuration has a different SCS. When the BWP change is indicated to the UE2002, the transmitted SCS also changes. Another use case for BWP is related to power saving. In particular, the UE2002 may be configured with multiple BWPs with different numbers of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. BWPs containing a smaller number of PRBs may be used for data transmission with smaller traffic load while allowing power saving at the UE2002 and in some cases the gNB 2016. BWPs containing a large number of PRBs may be used in scenarios with higher traffic loads.

The RAN 2004 is communicatively coupled to a CN 2020, which includes network elements, to provide various functions to support data and telecommunications services to customers/subscribers (e.g., users of the UE 2002). The components of CN 2020 may be implemented in one physical node or in different physical nodes. In some embodiments, NFV may be used to virtualize any or all functions provided by network elements of CN 2020 onto physical computing/storage resources in servers, switches, and the like. Logical instances of CN 2020 may be referred to as network slices, and logical instantiations of portions of CN 2020 may be referred to as network subslices.

In some embodiments, CN 2020 may be LTE CN 2022, which may also be referred to as Evolved Packet Core (EPC). LTE CN 2022 may include Mobility Management Entity (MME) 2024, serving Gateway (SGW) 2026, serving GPRS Support Node (SGSN) 2028, home Subscriber Server (HSS) 2030, proxy Gateway (PGW) 2032, and policy control and charging rules function (PCRF) 2034, which are coupled to each other by an interface (or "point of reference") as shown. The functions of the elements of LTE CN 2022 can be briefly introduced as follows.

The MME 2024 may implement mobility management functions to track the current location of the UE2002 to facilitate patrol, bearer activation/deactivation, handover, gateway selection, authentication, etc.

SGW 2026 may terminate the S1 interface towards the RAN and route data packets between the RAN and LTE CN 2022. SGW 2026 may be a local mobility anchor for inter-RAN node handovers and may also provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

The SGSN 2028 may track the location of the UE2002 and perform security functions and access control. In addition, the SGSN 2028 may perform EPC inter-node signaling for mobility between different RAT networks; PDN and S-GW selection specified by MME 2024; MME selection for handover, etc. The S3 reference point between the MME 2024 and the SGSN 2028 may enable user and bearer information exchange for inter-3 GPP access network mobility in idle/active state.

HSS 2030 may include a database for network subscribers that includes subscription related information that supports network entities handling communication sessions. HSS 2030 may provide support for routing/roaming, authentication, admission, naming/addressing resolution, location dependency, etc. An S6a reference point between HSS 2030 and MME 2024 may enable the transmission of subscription and authentication data to authenticate/grant a user access to LTECN 2020.

PGW 2032 may terminate the SGi interface towards Data Network (DN) 2036, which may include application/content server 2038. PGW 2032 may route data packets between LTE CN 2022 and data network 2036. PGW 2032 may be coupled with SGW 2026 through an S5 reference point to facilitate user plane tunneling and tunnel management. PGW 2032 may also include nodes (e.g., PCEFs) for policy enforcement and charging data collection. Additionally, the SGi reference point between PGW 2032 and data network 2036 may be, for example, an operator external public, private PDN, or operator internal packet data network for providing IMS services. PGW 2032 may be coupled to PCRF 2034 via a Gx reference point.

PCRF 2034 is the policy and charging control element of LTE CN 2022. The PCRF 2034 may be communicatively coupled to the application/content server 2038 to determine the appropriate QoS and charging parameters for the service flow. The PCRF 2032 may provide the associated rules to the PCEF with the appropriate TFT and QCI (via the Gx reference point).

In some embodiments, CN 2020 may be a 5G core network (5 GC) 2040.5GC 2040 may include an authentication server function (AUSF) 2042, an access and mobility management function (AMF) 2044, a Session Management Function (SMF) 2046, a User Plane Function (UPF) 2048, a Network Slice Selection Function (NSSF) 2050, a network open function (NEF) 2052, an NF storage function (NRF) 2054, a Policy Control Function (PCF) 2056, a Unified Data Management (UDM) 2058, and an Application Function (AF) 2060, which are coupled to one another by interfaces (or "reference points") as shown. The function of the elements of 5GC 2040 can be briefly described as follows.

The AUSF 2042 may store data for authentication of the UE2002 and process authentication related functions. AUSF 2042 may facilitate a common authentication framework for various access types. AUSF 2042 may also exhibit a Nausf service based interface in addition to communicating with other elements of the 5GC 2040 through reference points as shown.

The AMF 2044 may allow other functions of the 5GC 2040 to communicate with the UE2002 and the RAN 2004, and subscribe to notifications about mobility events for the UE 2002. The AMF 2044 may be responsible for registration management (e.g., registering the UE 2002), connection management, reachability management, mobility management, lawful interception of AMF related events, and access authentication and permissions. The AMF 2044 may provide for the transmission of Session Management (SM) messages between the UE2002 and the SMF 2046 and act as a transparent proxy for routing SM messages. The AMF 2044 may also provide for the transmission of SMS messages between the UE2002 and the SMSF. The AMF 2044 may interact with the AUSF 2042 and the UE2002 to perform various security anchoring and context management functions. Further, AMF 2044 may be a termination point for the RAN CP interface, which may include or be an N2 reference point between RAN 2004 and AMF 2044; the AMF 2044 may act as a termination point for NAS (N1) signaling and perform NAS ciphering and integrity protection. The AMF 2044 may also support NAS signaling with the UE2002 over the N3IWF interface.

The SMF 2046 may be responsible for SM (e.g., session establishment, tunnel management between UPF 2048 and AN 2008); UE IP address assignment and management (including optional permissions); selection and control of the UP function; configuring flow control at the UPF 2048 to route the flow to the appropriate destination; termination of the interface to the policy control function; controlling a portion of policy enforcement, charging, and QoS; lawful interception (for SM events and interface to the LI system); terminate the SM part of the NAS message; a downlink data notification; initiating AN specific SM message (sent to AN 2008 over N2 through AMF 2044); and determining the SSC pattern for the session. SM may refer to the management of PDU sessions, and a PDU session or "session" may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE2002 and the data network 2036.

The UPF 2048 may serve as an anchor point for intra-and inter-RAT mobility, an external PDU session point to interconnect with the data network 2036, and a branch point to support multi-homed PDU sessions. The UPF 2048 may also perform packet routing and forwarding, perform packet inspection, perform the user plane part of policy rules, lawful intercepted packets (UP collection), perform traffic usage reporting, perform QoS processing for the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), transport level packet marking in uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. UPF 2048 may include an uplink classifier to support routing of traffic flows to a data network.

The NSSF 2050 may select a set of network slice instances that serve the UE 2002. The NSSF 2050 may also determine allowed Network Slice Selection Assistance Information (NSSAI) and mapping to a single NSSAI (S-NSSAI) of the subscription, if desired. The NSSF 2050 may also determine the set of AMFs to be used to serve the UE2002, or determine a list of candidate AMFs, based on a suitable configuration and possibly by querying the NRF 2054. The selection of a set of network slice instances for the UE2002 may be triggered by the AMF 2044 (with which the UE2002 registers by interacting with the NSSF 2050), which may result in a change in the AMF. NSSF 2050 may interact with AMF 2044 via N22 reference points; and may communicate with another NSSF in the visited network via an N31 reference point (not shown). Further, NSSF 2050 may expose interfaces based on NSSF services.

NEF2052 may securely expose services and capabilities provided by 3GPP network functions for third parties, internal disclosure/re-disclosure, AF (e.g., AF 2060), edge computing or fog computing systems, and the like. In these embodiments, NEF2052 may authenticate, license, or throttle AFs. NEF2052 can also translate information exchanged with AF2060 and information exchanged with internal network functions. For example, the NEF2052 may translate between the AF service identifier and the internal 5GC information. NEF2052 may also receive information from other NFs based on the public capabilities of the other NFs. This information may be stored as structured data at NEF2052 or at data store NF using a standardized interface. NEF2052 may then re-disclose the stored information to other NFs and AFs, or for other purposes such as analysis. In addition, NEF2052 may expose an interface based on the Nnef service.

The NRF 2054 may support a service discovery function, receive NF discovery requests from NF instances, and provide information of discovered NF instances to NF instances. The NRF 2054 also maintains information on available NF instances and the services that it supports. As used herein, the terms "instantiate," "instance," and the like may refer to creating an instance, "instance" may refer to a specific occurrence of an object, which may occur, for example, during execution of program code. Further, NRF 2054 may expose an interface based on an nrrf service.

PCF 2056 may provide policy rules to control plane functions to enforce them and may also support a unified policy framework to manage network behavior. The PCF 2056 may also implement a front end to access subscription information related to policy decisions in the UDR of the UDM 2058. In addition to communicating with functions through reference points as shown, PCF 2056 also presents an interface based on Npcf services.

The UDM 2058 may process subscription-related information to support network entities handling communication sessions and may store subscription data for the UE 2002. For example, subscription data may be communicated via an N8 reference point between UDM 2058 and AMF 2044. The UDM 2058 may include two parts: front end and UDR are applied. The UDR may store policy data and subscription data for UDM 2058 and PCF 2056, and/or structured data and application data for disclosure (including PFD for application detection, application request information for multiple UEs 2002) for NEF 2052. UDR 221 may expose a Nudr service-based interface to allow UDM 2058, PCF 2056, and NEF2052 to access a particular collection of stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notifications of relevant data changes in the UDR. The UDM may include a UDM-FE that is responsible for handling credentials, location management, subscription management, and the like. Several different front ends may serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and performs authentication credential processing, user identification processing, access permission, registration/mobility management, and subscription management. The UDM 2058 may also expose a Nudm service based interface in addition to communicating with other NFs through reference points as shown.

The AF2060 may provide application impact on traffic routing, provide access to NEF, and interact with the policy framework for policy control.

In some embodiments, 5GC 2040 may enable edge computation by selecting an operator/third party service that is geographically close to the point at which UE2002 attaches to the network. This may reduce latency and load on the network. To provide an edge calculation implementation, the 5GC 2040 may select the UPF 2048 near the UE2002 and perform traffic steering from the UPF 2048 to the data network 2036 over the N6 interface. This may be based on UE subscription data, UE location, and information provided by the AF 2060. In this way, the AF2060 may affect UPF (re-) selection and traffic routing. Based on operator deployment, the network operator may allow AF2060 to interact directly with the relevant NFs when AF2060 is considered a trusted entity. In addition, the AF2060 may expose an interface based on the Naf service.

The data network 2036 may represent various network operator services, internet access, or third party services that may be provided by one or more servers, including, for example, an application/content server 2038.

Fig. 21 schematically illustrates a wireless network 2100 in accordance with various embodiments. The wireless network 2100 can include a UE2102 in wireless communication with AN 2104. The UE2102 and the AN 2104 can be similar to and substantially interchangeable with the conflicting components described elsewhere herein.

The UE2102 can be communicatively coupled with the AN 2104 via a connection 2106. The connection 2106 is shown as an air interface to enable communicative coupling and may be consistent with a cellular communication protocol operating at millimeter wave (mmWave) or sub-6 GHz frequencies, such as the LTE protocol or the 5G NR protocol.

The UE2102 may include a host platform 2108 coupled with a modem platform 2110. Host platform 2108 can include application processing circuitry 2112, which can be coupled with protocol processing circuitry 2114 of modem platform 2110. The application processing circuitry 2112 may run various applications of the source/receiver application data for the UE 2102. The application processing circuitry 2112 may also implement one or more layers of operations to send/receive application data to/from a data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.

The protocol processing circuitry 2114 may implement one or more layers of operations to facilitate the transmission or reception of data over the connection 2106. Layer operations implemented by the protocol processing circuit 2114 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

The modem platform 2110 may further include digital baseband circuitry 2116, the digital baseband circuitry 2116 may implement one or more layer operations "below" the layer operations performed by the protocol processing circuitry 2114 in the network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/demapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, wherein these functions may include one or more of: space-time, space-frequency, or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, blind control channel signal decoding, and other related functions.

The modem platform 2110 can further include transmit circuitry 2118, receive circuitry 2120, RF circuitry 2122, and RF front-end (RFFE) circuitry 2124, which can include or be connected to one or more antenna panels 2126. Briefly, the transmit circuit 2118 may include a digital-to-analog converter, a mixer, an Intermediate Frequency (IF) component, and the like; the receiving circuit 2120 may include an analog-to-digital converter, a mixer, IF components, and the like; RF circuitry 2122 may include low noise amplifiers, power tracking components, and the like; the RFFE circuitry 2124 may include filters (e.g., surface/bulk acoustic wave filters), switches, antenna tuners, beam-forming components (e.g., phased-array antenna components), and so forth. The selection and arrangement of components of the transmit circuitry 2118, receive circuitry 2120, RF circuitry 2122, RFFE circuitry 2124, and antenna panel 2126 (collectively "transmit/receive components") may be specific to details of a particular implementation, e.g., whether the communication is TDM or FDM, at mmWave or sub-6 GHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, and may be arranged in the same or different chips/modules, etc.

In some embodiments, the protocol processing circuitry 2114 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit/receive components.

UE reception may be established by and via antenna panel 2126, RFFE circuitry 2124, RF circuitry 2122, receive circuitry 2120, digital baseband circuitry 2116, and protocol processing circuitry 2114. In some embodiments, the antenna panels 2126 may receive transmissions from AN 2104 by receiving beamformed signals received by multiple antennas/antenna elements of one or more antenna panels 2126.

UE transmissions may be established via and through protocol processing circuitry 2114, digital baseband circuitry 2116, transmit circuitry 2118, RF circuitry 2122, RFFE circuitry 2124, and antenna panel 2126. In some embodiments, the transmit component of the UE2102 may apply a spatial filter to the data to be transmitted to form the transmit beams transmitted by the antenna elements of the antenna panel 2126.

Similar to the UE2102, the AN 2104 may include a host platform 2128 coupled to a modem platform 2130. The host platform 2128 may include an application processing circuit 2132 coupled to a protocol processing circuit 2134 of the modem platform 2130. The modem platform may also include digital baseband circuitry 2136, transmit circuitry 2138, receive circuitry 2140, RF circuitry 2142, RFFE circuitry 2144, and an antenna panel 2146. The components of the AN 2104 can be similar to, and substantially interchangeable with, the homonymous components of the UE 2102. In addition to performing data transmission/reception as described above, the components of AN 2104 may also perform various logical functions including, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

Fig. 22 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, according to some example embodiments. In particular, fig. 22 shows a diagrammatic representation of hardware resources 2200 including one or more processors (or processor cores) 2210, one or more memory/storage devices 2220, and one or more communication resources 2230, each of which may be communicatively coupled by a bus 2240. Hardware resources 2200 may be part of any entity or non-entity (e.g., service or function) described in this disclosure. For embodiments utilizing node virtualization (e.g., NFV), hypervisor 2202 may be executed to provide an execution environment for one or more network slices/subslices to utilize hardware resources 2200.

Processor 2210 (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP) such as a baseband processor, an Application Specific Integrated Circuit (ASIC), a Radio Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 2212 and processor 2214.

Memory/storage 2220 may include main memory, disk storage, or any suitable combination thereof. The memory/storage 2220 may include, but is not limited to, any type of volatile or non-volatile memory, such as Dynamic Random Access Memory (DRAM), static Random Access Memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid state storage, and the like.

The communication resources 2230 can include interconnect or network interface components or other suitable devices to communicate with one or more peripheral devices 2204 or one or more databases 2206 via a network 2208. For example, the communication resources 2230 can include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, bluetooth components (e.g., bluetooth low energy), wi-Fi components, and other communication components.

The instructions 2250 may include software, programs, applications, applets, apps, or other executable code for causing at least any processor 2210 to perform any one or more of the methods discussed herein. The instructions 2250 may reside, completely or partially, within at least one of the processor 2210 (e.g., within a processor's cache memory), the memory/storage 2220, or any suitable combination thereof. Further, any portion of instructions 2250 may be transferred to hardware resources 2200 from any combination of peripherals 2204 or databases 2206. Thus, the processor 2210, the memory/storage 2220, the peripherals 2204, and the memory of the database 2206 are examples of computer-readable and machine-readable media.

The following paragraphs describe examples of various embodiments.

Example 1 includes an apparatus comprising: an interface; and a processor coupled with the interface and configured to: detecting an abnormal interruption of a first Small Data Transmission (SDT) session between a User Equipment (UE) in a Radio Resource Control (RRC) INACTIVE (RRC _ INACTIVE) state and a first next generation NodeB (gNB); keeping the UE in an RRC _ INACTIVE state if the abnormal interruption is detected; establishing a first recovery session for a first SDT session between the UE in RRC _ INACTIVE state and a second gNB based on a first next hop chain count (NCC) used in the first SDT session to continue SDT traffic transmission for the first SDT session, wherein the first NCC corresponds to the first gNB.

Example 2 includes the apparatus of example 1, wherein a first SDT session between the UE and a first gNB includes a first phase to initiate the first SDT session using RRC messages and a second phase to transmit uplink UL SDT traffic and downlink DL SDT traffic for the first SDT session, wherein a first recovery session between the UE and a second gNB includes a first recovery phase to initiate the first recovery session using RRC messages, wherein the abnormal interruption is detected during the first phase or the second phase.

Example 3 includes the apparatus of example 1 or 2, wherein the first recovery session further includes a second recovery phase to communicate remaining UL SDT traffic and DL SDT traffic of the first SDT session.

Example 4 includes the apparatus of any one of examples 1 to 3, wherein the processor is configured to: in a second phase, the abnormal interruption is detected in case no RRC release message for normally interrupting the first SDT session is received via the interface for a predetermined period of time, or in case a predetermined event is detected, wherein the predetermined event comprises at least one of: detecting available non-SDT traffic and triggering cell reselection.

Example 5 includes the apparatus of any one of examples 1 to 4, wherein the processor is configured to: in a first phase, the presence of the abnormal interruption is detected in case an RRC reject message for rejecting the first SDT session is received in the first phase via the interface.

Example 6 includes the apparatus of any one of examples 1 to 5, the processor configured to: and in the case of detecting the abnormal interruption, also maintaining the SDT configuration information of the first SDT session, wherein the SDT configuration information of the first SDT session comprises the first NCC.

Example 7 includes the apparatus of any one of examples 1 to 6, wherein the processor is configured to: and in the event that the abnormal interruption is detected, also maintaining SDT configuration information of the first SDT session, wherein the SDT configuration information of the first SDT session includes a first NCC and a second NCC, wherein the second NCC corresponds to the second gNB, and the second NCC is obtained from a first DL RRC response message received from the first gNB via the interface in the first stage of the first SDT session.

Example 8 includes the apparatus of any one of examples 1 to 7, wherein the processor is configured to establish a first recovery session between the UE in RRC _ INACTIVE state and a second gNB in a first recovery phase by: generating a first recovery UL message comprising the first recovery RRC message based on the first NCC, or generating a first recovery UL message comprising the first recovery RRC message and first recovery UL traffic based on the first NCC and the second NCC, for transmission to the second gNB, wherein the first recovery RRC message indicates initiation of the first recovery session; and analyzing a first recovery DLRRC response message received from the second gNB via the interface in response to the first recovery UL message to obtain a third NCC, the third NCC corresponding to a third gNB for a next session.

Example 9 includes the apparatus of any one of examples 1 to 8, wherein the SDT configuration information for the first SDT session further comprises: an updated inactive radio network temporary identifier (I-RNTI) corresponding to the second gNB, the updated I-RNTI obtained from the first DL RRC response message, wherein the processor is further configured to: generating a first recovery UL message based also on the updated I-RNTI; transmitting, in a second recovery phase, remaining UL SDT traffic and DL SDT traffic for the first SDT session via the interface based on the second NCC and the updated I-RNTI.

Example 10 includes the apparatus of any one of examples 1 to 9, wherein the processor is further configured to: the first resume DL RRC response message is analyzed to obtain another updated I-RNTI corresponding to the third gbb.

Example 11 includes the apparatus of any one of examples 1 to 10, wherein the processor is configured to establish a first recovery session between the UE in an RRC _ INACTIVE state and a second gNB in a first recovery phase by: generating, based on the first NCC, a first recovery UL message comprising a first recovery RRC message for transmission to the second gNB, wherein the first recovery RRC message indicates initiation of the first recovery session; and analyzing a first recovery DL RRC response message received from the second gNB via the interface in response to the first recovery UL message to obtain a second NCC, the second NCC corresponding to the second gNB.

Example 12 includes the apparatus of any one of examples 1 to 11, wherein the first recovery session further includes a second recovery phase to transport remaining ULSDT traffic and DL SDT traffic of the first SDT session.

Example 13 includes the apparatus of any one of examples 1 to 12, wherein the first resume dl RRC response message is an RRC release message to normally interrupt communication between the UE in RRC _ INACTIVE state and the second gNB.

Example 14 includes the apparatus of any one of examples 1 to 13, wherein a first resume dl rrc response message is not used to interrupt communication between the UE and a second gNB, wherein the processor is further configured to: in a second recovery phase, transmitting, via the interface, remaining UL SDT traffic and DL SDT traffic of a first SDT session based on a second NCC while keeping the UE in an RRC _ INACTIVE state; and analyzing a last DL RRC release message received at an end point of the second recovery phase via the interface to normally interrupt the first recovery session, wherein the last DL RRC release message includes a third NCC, wherein the third NCC corresponds to a third gNB for a next session.

Example 15 includes the apparatus of any one of examples 1 to 14, wherein a first resume dl rrc response message is not used to interrupt communication between the UE and a second gNB, wherein the processor is further configured to: switching the state of the UE from an RRC _ INACTIVE state to an RRC CONNECTED (RRC _ CONNECTED) state at the start of a second recovery phase; in a second recovery phase, transmitting, via the interface, remaining UL SDT traffic and DL SDT traffic for a first SDT session based on a second NCC while keeping the UE in an RRC _ CONNECTED state; and analyzing a last DL RRC release message received at an end point of the second recovery phase via the interface to normally interrupt the first recovery session, wherein the last DL RRC release message includes a third NCC, and wherein the third NCC corresponds to a third gNB for a next session.

Example 16 includes the apparatus of any one of examples 1 to 15, wherein the processor is further configured to: analyzing the first recovery DL RRC response message to obtain an updated I-RNTI corresponding to the second gNB; and transmitting, in a second recovery phase, remaining UL SDT traffic and DL SDT traffic of the first SND session via the interface based on the second NCC and the updated I-RNTI.

Example 17 includes the apparatus of any one of examples 1 to 16, wherein the processor is further configured to: under the condition that the abnormal interruption is detected, generating a safety key by using a horizontal key derivation method and utilizing a first NCC; in a second recovery phase, the remaining UL SDT traffic and DL SDT traffic of the first SDT session are transmitted based on the security key.

Example 18 includes the apparatus of any one of examples 1 to 17, wherein the processor is further configured to: in a second recovery phase, the remaining UL SDT traffic and DL SDT traffic for the first SDT session are also transmitted based on an I-RNTI received via the interface, the I-RNTI corresponding to the second gNB.

Example 19 includes the apparatus of any one of examples 1 to 18, wherein the processor is further configured to: switching the state of the UE from an RRC _ INACTIVE state to an RRC IDLE (RRC _ IDLE) state when a count value for a number of times the security key is generated reaches a predetermined value.

Example 20 includes the apparatus of any one of examples 1 to 19, wherein the processor is further configured to: establishing a first recovery session between the UE in an RRC _ INACTIVE state and a second gNB based on a first NCC and an updated first NCC, wherein the updated first NCC is received from the network via the interface after the abort and corresponds to the first gNB, wherein the second gNB is identical to the first gNB.

Example 21 includes the apparatus of any one of examples 1 to 20, wherein the first, second, and third gnbs are different gnbs or at least two of the first, second, and third gnbs are the same gNB.

Example 22 includes the apparatus of any one of examples 1 to 21, wherein the processor is further configured to report the abort to a network corresponding to the first gNB.

Example 23 includes a method comprising: detecting an abnormal interruption of a first Small Data Transmission (SDT) session between a User Equipment (UE) in a Radio Resource Control (RRC) INACTIVE (RRC _ INACTIVE) state and a first next generation NodeB (gNB); keeping the UE in an RRC _ INACTIVE state when the abnormal interruption is detected; establishing a first recovery session for a first SDT session between the UE in RRC _ INACTIVE state and a second gNB based on a first next hop chain count (NCC) used in the first SDT session to continue SDT traffic transmission for the first SDT session, wherein the first NCC corresponds to the first gNB.

Example 24 includes the method of example 23, wherein the first SDT session between the UE and the first gNB includes a first phase to initiate the first SDT session using RRC messages and a second phase to communicate uplink UL SDT traffic and downlink DL SDT traffic for the first SDT session, wherein the first recovery session between the UE and the second gNB includes a first recovery phase to initiate the first recovery session using RRC messages, wherein the abnormal interruption is detected during the first phase or the second phase.

Example 25 includes the method of example 23 or 24, wherein the first recovery session further includes a second recovery phase to communicate remaining UL SDT traffic and DL SDT traffic of the first SDT session.

Example 26 includes the method of any one of examples 23 to 25, wherein detecting the abnormal interruption of the first SDT session between the UE in the RRC _ INACTIVE state and the first gNB includes: in a second phase, the abnormal interruption is detected in case an RRC Release (Release) message for normally interrupting the first SDT session is not received within a predetermined time period, or in case a predetermined event is detected, wherein the predetermined event comprises at least one of: detecting available non-SDT traffic and triggering cell reselection.

Example 27 includes the method of any one of examples 23 to 26, wherein detecting the abnormal interruption of the first SDT session between the UE in RRC _ INACTIVE state and the first gNB comprises: in the first phase, the presence of the abort is detected in case an RRC Reject (Reject) message for rejecting the first SDT session is received in the first phase.

Example 28 includes the method of any one of examples 23 to 27, further including: and in the event that the abnormal interruption is detected, also maintaining the SDT configuration information of the first SDT session, wherein the SDT configuration information of the first SDT session comprises the first NCC.

Example 29 includes the method of any one of examples 23 to 28, wherein the method further comprises: and in the event that the abnormal interruption is detected, also maintaining SDT configuration information of the first SDT session, wherein the SDT configuration information of the first SDT session includes a first NCC and a second NCC, wherein the second NCC corresponds to the second gNB, and the second NCC is obtained from a first DL RRC response message received from the first gNB in the first phase of the first SDT session.

Example 30 includes the method of any one of examples 23 to 29, wherein establishing the first recovery session between the UE in RRC _ INACTIVE state and the second gNB includes: in a first recovery phase, generating a first recovery UL message comprising the first recovery RRC message based on the first NCC, or generating a first recovery UL message comprising the first recovery RRC message and first recovery UL traffic based on the first NCC and the second NCC, for transmission to the second gNB, wherein the first recovery RRC message indicates initiation of the first recovery session; and analyzing a first recovery DL RRC response message received from the second gNB in response to the first recovery UL message to obtain a third NCC, the third NCC corresponding to a third gNB for a next session.

Example 31 includes the method of any one of examples 23 to 30, wherein the SDT configuration information for the first SDT session further includes: an updated inactive radio network temporary identifier (I-RNTI) corresponding to the second gNB, the updated I-RNTI obtained from the first DL RRC response message, wherein the method further comprises: generating a first recovery UL message based also on the updated I-RNTI; transmitting, in a second recovery phase, remaining UL SDT traffic and DL SDT traffic for the first SDT session based on the second NCC and the updated I-RNTI.

Example 32 includes the method of any one of examples 23 to 31, wherein the method further comprises: the first resume DL RRC response message is analyzed to obtain another updated I-RNTI corresponding to the third gNB.

Example 33 includes the method of any one of examples 23 to 32, wherein establishing the first recovery session between the UE in RRC _ INACTIVE state and the second gNB includes: in a first recovery phase, generating, based on the first NCC, a first recovery UL message comprising a first recovery RRC message for transmission to the second gNB, wherein the first recovery RRC message indicates initiation of the first recovery session; and analyzing a first recovery DL RRC response message received from the second gNB in response to the first recovery UL message to obtain a second NCC, the second NCC corresponding to the second gNB.

Example 34 includes the method of any one of examples 23 to 33, wherein the first recovery session further includes a second recovery phase to transport remaining ULSDT traffic and DL SDT traffic of the first SDT session.

Example 35 includes the method of any one of examples 23 to 34, wherein the first resume dl RRC response message is an RRC release message for normally interrupting communication between the UE in RRC _ INACTIVE state and the second gNB.

Example 36 includes the method of any one of examples 23 to 35, wherein a first resume dl rrc response message is not used to interrupt communication between the UE and a second gNB, wherein the method further comprises: in a second recovery phase, based on a second NCC, transmitting remaining UL SDT traffic and DL SDT traffic for a first SDT session while keeping the UE in an RRC _ INACTIVE state; and analyzing a last DL RRC release message received at an end point of the second recovery phase to normally interrupt the first recovery session, wherein the last DL RRC release message includes a third NCC, and wherein the third NCC corresponds to a third gNB for a next session.

Example 37 includes the method of any one of examples 23 to 36, wherein a first resume dl rrc response message is not used to interrupt communication between the UE and a second gNB, wherein the method further comprises: switching the state of the UE from an RRC _ INACTIVE state to an RRC CONNECTED (RRC _ CONNECTED) state at the start of a second recovery phase; in a second recovery phase, based on a second NCC, transmitting remaining UL SDT traffic and DL SDT traffic for the first SDT session while maintaining the UE in an RRC _ CONNECTED state; and analyzing a last DL RRC release message received at an end point of the second recovery phase to normally interrupt the first recovery session, wherein the last DL RRC release message includes a third NCC, and wherein the third NCC corresponds to a third gNB for a next session.

Example 38 includes the method of any one of examples 23 to 37, wherein the method further comprises: analyzing the first recovery DL RRC response message to obtain an updated I-RNTI corresponding to the second gNB; and transmitting, in a second recovery phase, remaining UL SDT traffic and DL SDT traffic of the first SND session based on the second NCC and the updated I-RNTI.

Example 39 includes the method of any one of examples 23 to 38, wherein the method further comprises: under the condition that the abnormal interruption is detected, generating a safety key by using a horizontal key derivation method and utilizing a first NCC; in a second recovery phase, the remaining UL SDT traffic and DL SDT traffic of the first SDT session are transmitted based on the security key.

Example 40 includes the method of any one of examples 23 to 39, wherein the method further comprises: in a second recovery phase, the remaining UL SDT traffic and DL SDT traffic of the first SDT session are also transmitted based on the received I-RNTI, which corresponds to the second gNB.

Example 41 includes the method of any one of examples 23-40, wherein the method further includes: switching the state of the UE from an RRC _ INACTIVE state to an RRC IDLE (RRC _ IDLE) state when a count value for a number of times the security key is generated reaches a predetermined value.

Example 42 includes the method of any one of examples 23 to 41, wherein the method further comprises: establishing a first recovery session between the UE in RRC _ INACTIVE state and a second gNB based on a first NCC and an updated first NCC, wherein the updated first NCC is received from the network after the abort and corresponds to the first gNB, wherein the second gNB is the same as the first gNB.

Example 43 includes the method of any one of examples 23 to 42, wherein the first, second, and third gnbs are different gnbs or at least two of the first, second, and third gnbs are the same gNB.

Example 44 includes the method of any one of examples 23 to 43, wherein the method further includes reporting the abort to a network corresponding to the first gNB.

Example 45 includes an apparatus comprising: means for detecting an abnormal interruption of a first Small Data Transmission (SDT) session between a User Equipment (UE) in a Radio Resource Control (RRC) INACTIVE (RRC _ INACTIVE) state and a first next generation NodeB (gNB); means for maintaining the UE in an RRC _ INACTIVE state if the abort is detected; means for establishing a first recovery session for a first SDT session between the UE in RRC _ INACTIVE state and a second gNB based on a first next hop chain count (NCC) used in the first SDT session, wherein the first NCC corresponds to the first gNB, to continue SDT traffic transmission for the first SDT session.

Example 46 includes the apparatus of example 45, wherein a first SDT session between the UE and a first gNB includes a first phase to initiate the first SDT session using RRC messages and a second phase to communicate uplink UL SDT traffic and downlink DL SDT traffic for the first SDT session, wherein a first recovery session between the UE and a second gNB includes a first recovery phase to initiate the first recovery session using RRC messages, wherein the abnormal interruption is detected during the first phase or the second phase.

Example 47 includes the apparatus of examples 45 or 46, wherein the first recovery session further includes a second recovery phase to communicate remaining UL SDT traffic and DL SDT traffic of the first SDT session.

Example 48 includes the apparatus of any one of examples 45 to 47, wherein the means for detecting the abnormal interruption of the first SDT session between the UE in RRC _ INACTIVE state and the first gNB comprises: means for detecting the abnormal interruption in the second phase in the event that an RRC Release (Release) message for normally interrupting the first SDT session is not received within a predetermined period of time, or in the event that a predetermined event is detected, wherein the predetermined event comprises at least one of: detecting available non-SDT traffic and triggering cell reselection.

Example 49 includes the apparatus of any one of examples 45 to 48, wherein the means for detecting the abnormal interruption of the first SDT session between the UE in the RRC _ INACTIVE state and the first gNB comprises: means for detecting the presence of the abort in the first phase upon receipt of a RRC Reject (Reject) message for rejecting the first SDT session.

Example 50 includes the apparatus of any one of examples 45 to 49, the apparatus further comprising: means for maintaining SDT configuration information for the first SDT session if the anomalous interrupt is detected, wherein the SDT configuration information for the first SDT session includes the first NCC.

Example 51 includes the apparatus of any one of examples 45 to 50, wherein the apparatus further comprises: means for maintaining SDT configuration information for the first SDT session if the abnormal interruption is detected, wherein the SDT configuration information for the first SDT session includes a first NCC and a second NCC, wherein the second NCC corresponds to the second gNB, and the second NCC is obtained from a first DL RRC response message received from the first gNB in the first phase of the first SDT session.

Example 52 includes the apparatus of any one of examples 45 to 51, wherein the means for establishing the first recovery session between the UE in RRC _ INACTIVE state and the second gNB comprises: means for generating, in a first recovery phase, a first recovery UL message comprising the first recovery RRC message based on the first NCC, or generating, for transmission to the second gNB, a first recovery UL message comprising the first recovery RRC message and first recovery UL traffic based on the first NCC and the second NCC, wherein the first recovery RRC message indicates initiation of a first recovery session; and means for analyzing a first recovery DL RRC response message received from the second gNB in response to the first recovery UL message to obtain a third NCC, the third NCC corresponding to the third gNB for the next session.

Example 53 includes the apparatus of any one of examples 45 to 52, wherein the SDT configuration information for the first SDT session further comprises: an updated inactive radio network temporary identifier (I-RNTI) corresponding to the second gNB, the updated I-RNTI obtained from the first DL RRC response message, wherein the apparatus further comprises: means for generating a first recovery UL message based also on the updated I-RNTI; means for transmitting remaining UL SDT traffic and DL SDT traffic for the first SDT session based on the second NCC and the updated I-RNTI in a second recovery phase.

Example 54 includes the apparatus of any one of examples 45 to 53, wherein the apparatus further comprises: means for analyzing the first resume DL RRC response message to obtain another updated I-RNTI corresponding to the third gNB.

Example 55 includes the apparatus of any one of examples 45 to 54, wherein the means for establishing a first recovery session between the UE in RRC _ INACTIVE state and a second gNB comprises: means for generating, in a first recovery phase based on the first NCC, a first recovery UL message comprising a first recovery RRC message for transmission to the second gNB, wherein the first recovery RRC message indicates initiation of a first recovery session; and means for analyzing a first recovery DL RRC response message received from a second gNB in response to the first recovery UL message to obtain a second NCC, the second NCC corresponding to the second gNB.

Example 56 includes the apparatus of any one of examples 45 to 55, wherein the first recovery session further includes a second recovery phase to transport remaining ULSDT traffic and DL SDT traffic of the first SDT session.

Example 57 includes the apparatus of any one of examples 45 to 56, wherein the first resume dl RRC response message is an RRC release message to normally interrupt communication between the UE in RRC _ INACTIVE state and the second gNB.

Example 58 includes the apparatus of any one of examples 45 to 57, wherein a first resume dl rrc response message is not used to interrupt communication between the UE and a second gNB, wherein the apparatus further comprises: means for transmitting remaining UL and DL SDT traffic for the first SDT session based on the second NCC while maintaining the UE in an RRC _ INACTIVE state in a second recovery phase; and means for analyzing a last DL RRC release message received at an end point of the second recovery phase to normally interrupt the first recovery session, wherein the last DL RRC release message includes a third NCC, wherein the third NCC corresponds to a third gNB for a next session.

Example 59 includes the apparatus of any one of examples 45 to 58, wherein a first resume dl rrc response message is not used to interrupt communication between the UE and a second gNB, wherein the apparatus further comprises: means for switching a state of the UE from an RRC _ INACTIVE state to an RRC _ CONNECTED state at a start of a second recovery phase; means for transmitting, in a second recovery phase, remaining UL SDT traffic and DL SDT traffic for a first SDT session based on a second NCC while maintaining the UE in an RRC _ CONNECTED state; and means for analyzing a last DL RRC release message received at an end point of the second recovery phase to normally interrupt the first recovery session, wherein the last DL RRC release message includes a third NCC, wherein the third NCC corresponds to a third gNB for a next session.

Example 60 includes the apparatus of any one of examples 45 to 59, wherein the apparatus further comprises: a component for analyzing the first resume DL RRC response message to obtain an updated I-RNTI corresponding to the second gNB; and means for transmitting remaining UL SDT traffic and DL SDT traffic for the first SND session based on the second NCC and the updated I-RNTI in a second recovery phase.

Example 61 includes the apparatus of any one of examples 45-60, wherein the apparatus further comprises: a component for generating a security key with a first NCC using horizontal key derivation if the abnormal interruption is detected; means for transmitting, in a second recovery phase, remaining UL SDT traffic and DL SDT traffic of the first SDT session based on the security key.

Example 62 includes the apparatus of any one of examples 45 to 61, wherein the apparatus further comprises: means for transmitting remaining UL SDT traffic and DL SDT traffic for the first SDT session in a second recovery phase further based on a received I-RNTI corresponding to the second gNB.

Example 63 includes the apparatus of any one of examples 45 to 62, wherein the apparatus further comprises: means for switching a state of the UE from an RRC _ INACTIVE state to an RRC IDLE (RRC _ IDLE) state if a count value for a number of times the security key is generated reaches a predetermined value.

Example 64 includes the apparatus of any one of examples 45 to 63, wherein the apparatus further comprises: means for establishing a first recovery session between the UE in an RRC _ INACTIVE state and a second gNB based on a first NCC and an updated first NCC, wherein the updated first NCC is received from the network after the abort and corresponds to the first gNB, wherein the second gNB is identical to the first gNB.

Example 65 includes the apparatus of any one of examples 45 to 64, wherein the first, second, and third gnbs are different gnbs or at least two of the first, second, and third gnbs are the same gNB.

Example 66 includes the apparatus of any one of examples 45 to 65, wherein the apparatus further comprises means for reporting the abort to a network corresponding to the first gNB.

For one or more embodiments, at least one of the components set forth in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth in the example section. For example, baseband circuitry as described above in connection with one or more of the foregoing figures may be configured to operate in accordance with one or more of the examples set forth herein. For another example, circuitry associated with a UE, base station, network element, etc., as described above in connection with one or more of the preceding figures, can be configured to operate in accordance with one or more of the examples set forth herein.

Although certain embodiments have been illustrated and described herein for purposes of description, various alternative and/or equivalent embodiments or implementations calculated to achieve the same purposes may be substituted for the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that the embodiments described herein be limited only by the claims and the equivalents thereof.

Claims (23)

1. An apparatus, comprising:

an interface; and

a processor coupled with the interface and configured to:

detecting an abnormal interruption of a first SDT session between the UE in RRC _ INACTIVE state and a first gNB;

keeping the UE in an RRC _ INACTIVE state when the abnormal interruption is detected;

establishing a first recovery session for the first SDT session between the UE in RRC _ INACTIVE state and the second gNB based on a first next hop chain count, i.e., a first NCC, used in the first SDT session to continue SDT traffic transmission for the first SDT session,

wherein the first NCC corresponds to the first gNB.

2. The apparatus of claim 1, wherein a first SDT session between the UE and a first gNB comprises a first phase to initiate the first SDT session with RRC messages and a second phase to transport Uplink (UL) SDT traffic and Downlink (DL) SDT traffic for the first SDT session,

wherein a first recovery session between the UE and the second gNB includes a first recovery phase to initiate the first recovery session using an RRC message,

wherein the abort is detected during the first phase or the second phase.

3. The apparatus of claim 2, wherein the first recovery session further comprises a second recovery phase to transport remaining UL SDT traffic and DL SDT traffic of the first SDT session.

4. The apparatus of claim 2 or 3, wherein the processor is configured to: in a second phase, the abnormal interruption is detected in case no RRC Release message for normally interrupting the first SDT session is received via the interface for a predetermined period of time, or in case a predetermined event is detected,

wherein the predetermined event comprises at least one of: detecting available non-SDT traffic and triggering cell reselection.

5. The apparatus of claim 2 or 3, wherein the processor is configured to: in a first phase, the presence of the abnormal interruption is detected in case an RRC reject message for rejecting the first SDT session is received in the first phase via the interface.

6. The apparatus of claim 2, the processor configured to: and in the event that the abnormal interruption is detected, also maintaining the SDT configuration information of the first SDT session, wherein the SDT configuration information of the first SDT session comprises the first NCC.

7. The apparatus of claim 3, wherein the processor is configured to: and in the event that the abnormal interruption is detected, also maintaining the SDT configuration information of the first SDT session, wherein the SDT configuration information of the first SDT session includes a first NCC and a second NCC, wherein the second NCC corresponds to the second gNB, and the second NCC is obtained from a first DL RRC response message received from the first gNB via the interface in the first phase of the first SDT session.

8. The apparatus of claim 7, wherein the processor is configured to establish a first recovery session between the UE in RRC _ INACTIVE state and a second gNB in a first recovery phase by:

generating a first recovery UL message comprising the first recovery RRC message based on the first NCC, or generating a first recovery UL message comprising the first recovery RRC message and first recovery UL traffic based on the first NCC and the second NCC, for transmission to the second gNB, wherein the first recovery RRC message indicates initiation of the first recovery session; and

analyzing a first recovery DL RRC response message received from the second gNB via the interface in response to the first recovery UL message to obtain a third NCC corresponding to the third gNB for a next session.

9. The apparatus of claim 8, wherein the SDT configuration information for the first SDT session further comprises: an updated I-RNTI corresponding to the second gNB, the updated I-RNTI obtained from the first DL RRC response message,

wherein the processor is further configured to:

generating the first recovery UL message further based on the updated I-RNTI;

transmitting, in a second recovery phase, remaining UL SDT traffic and DL SDT traffic for the first SDT session via the interface based on the second NCC and the updated I-RNTI.

10. The apparatus of claim 9, wherein the processor is further configured to: the first resume DL RRC response message is analyzed to obtain another updated I-RNTI corresponding to the third gbb.

11. The apparatus of claim 6, wherein the processor is configured to establish a first recovery session between the UE in RRC _ INACTIVE state and a second gNB in a first recovery phase by:

generating, based on the first NCC, a first recovery UL message comprising a first recovery RRC message for transmission to the second gNB, wherein the first recovery RRC message indicates initiation of the first recovery session; and

analyzing a first recovery DL RRC response message received from the second gNB via the interface in response to the first recovery UL message to obtain a second NCC, the second NCC corresponding to the second gNB.

12. The apparatus of claim 11, wherein the first recovery session further comprises a second recovery phase for communicating remaining UL SDT traffic and DL SDT traffic of the first SDT session.

13. The apparatus of claim 11, wherein the first resume DL RRC response message is an RRC release message for normally interrupting communication between the UE in RRC _ INACTIVE state and the second gNB.

14. The apparatus of claim 12, wherein a first resume DL RRC response message is not used to interrupt communication between the UE and a second gNB,

wherein the processor is further configured to:

in a second recovery phase, based on a second NCC, transmitting, via the interface, remaining UL SDT traffic and DL SDT traffic for a first SDT session while keeping the UE in an RRC _ INACTIVE state; and

analyzing a last DL RRC release message received at an end point of a second recovery phase via the interface to normally interrupt the first recovery session, wherein the last DL RRC release message comprises a third NCC, wherein the third NCC corresponds to a third gNB for a next session.

15. The apparatus of claim 12, wherein a first resume DL RRC response message is not used to interrupt communication between the UE and a second gNB,

wherein the processor is further configured to:

switching the state of the UE from an RRC _ INACTIVE state to an RRC _ CONNECTED state at the start of a second recovery phase;

in a second recovery phase, transmitting, via the interface, remaining UL SDT traffic and DL SDT traffic for a first SDT session based on a second NCC while keeping the UE in an RRC _ CONNECTED state; and

analyzing a last DL RRC release message received at an end point of a second recovery phase via the interface to normally interrupt the first recovery session, wherein the last DL RRC release message comprises a third NCC, wherein the third NCC corresponds to a third gNB for a next session.

16. The apparatus of any one of claims 11-15, wherein the processor is further configured to:

analyzing the first recovery DL RRC response message to obtain an updated I-RNTI corresponding to the second gNB; and

transmitting, in a second recovery phase, remaining UL SDT traffic and DL SDT traffic of the first SND session via the interface based on the second NCC and the updated I-RNTI.

17. The apparatus of claim 3, wherein the processor is further configured to:

under the condition that the abnormal interruption is detected, generating a safety key by using a horizontal key derivation method and utilizing a first NCC;

in a second recovery phase, the remaining UL SDT traffic and DL SDT traffic of the first SDT session are transmitted based on the security key.

18. The apparatus of claim 17, wherein the processor is further configured to: in a second recovery phase, the remaining UL SDT traffic and DL SDT traffic of the first SDT session are also transmitted based on an I-RNTI received via the interface, the I-RNTI corresponding to the second gNB.

19. The apparatus of claim 17, wherein the processor is further configured to:

switching the state of the UE from an RRC _ INACTIVE state to an RRC _ IDLE state when a count value for a number of times the security key is generated reaches a predetermined value.

20. The apparatus of claim 1, wherein the processor is further configured to:

establishing a first recovery session between the UE in RRC _ INACTIVE state and a second gNB based on a first NCC and an updated first NCC, wherein the updated first NCC is received from the network via the interface after the abort and corresponds to the first gNB,

wherein the second gNB is identical to the first gNB.

21. The apparatus of any of claims 8-10, 14-15, wherein the first, second, and third gNB are different gNBs or at least two of the first, second, and third gNB are the same gNB.

22. The apparatus of claim 1, wherein the processor is further configured to report the abort to a network corresponding to the first gNB.

23. A method, comprising:

detecting an abnormal interruption of a first Small Data Transfer (SDT) session between the UE in an RRC _ INACTIVE state and a first gNB;

keeping the UE in an RRC _ INACTIVE state when the abnormal interruption is detected;

establishing a first recovery session for the first SDT session between the UE in RRC _ INACTIVE state and the second gNB based on a first Next hop chain count, NCC, used in the first SDT session to continue SDT traffic transmission for the first SDT session,

wherein the first NCC corresponds to the first gNB.

Images