Method for reporting timing advance in inactive state

Abstract

A method in a radio access network using a satellite and a wireless communication device operating as a user equipment (UE) selectively transmit timing advance information when resuming a connection while in an inactive state or when performing a small data transmission (SDT) procedure. A method (2200) performed by a UE includes, when in an inactive state after connecting to a radio access network (RAN) via a non-terrestrial network (NTN), determining (2205) to resume a connection with the RAN, and selectively transmitting (2230) a timing advance (TA) report during a procedure for resuming the connection based on an evaluation of a predetermined rule.

Description

Technical Field

[0001] This document generally describes wireless communication methods and apparatus for communicating using a non-terrestrial network (NTN). More specifically, the described embodiments relate to timing advance (TA) information for a user equipment (UE) to transition from an inactive state to a connected state or to perform a small data transfer (SDT). Background Art

[0002] This background description is provided for the purpose of generally presenting the context of the disclosed technology. The work of the presently named inventors, to the extent that it is described in this background section, and aspects of the specification that otherwise may not be considered prior art at the time of filing, are neither explicitly nor implicitly admitted to be prior art to the present disclosure.

[0003] The goals behind developing fifth-generation (5G) technology include providing a unified framework for communication types such as enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC).

[0004] 5G technology mainly relies on traditional (legacy) terrestrial networks. However, the Third Generation Partnership Project (3GPP) organization has proposed to extend 5G communications to non-terrestrial networks (NTNs) using 5G New Radio (NR) technology or using Long Term Evolution (LTE) technology customized for narrowband Internet of Things (NB-IoT) or enhanced machine type communication (eMTC) scenarios. In NTNs, RF transceivers are installed on satellites, unmanned aerial vehicle systems (UAS) (also known as drones, balloons, airplanes), or other suitable devices. For simplicity, the following discussion refers to all such devices as satellites. In addition to satellites, NTNs may also include satellite gateways (sat-gateways) that connect the NTN to a public data network, feeder links between satellite gateways and satellites, service links between satellites, and inter-satellite links (ISLs) when satellites form a satellite constellation.

[0005] Satellites belong to one of several types based on altitude, orbit, and beam footprint size. The types include low earth orbit (LEO) satellites, medium earth orbit (MEO) satellites, geostationary orbit (GEO) satellites, UAS platforms (including high altitude platform stations (HAPS)), and highly elliptical orbit (HEO) satellites. GEO satellites are also called geosynchronous orbit (GSO) satellites, and LEO / MEO satellites are also called non-GSO (NGSO) satellites.

[0006] GSO satellites can communicate with one or several satellite gateways deployed over the satellite's target coverage area (e.g., a region or even a continent). Non-GSO satellites can communicate with one or several serving satellite gateways at different times. NTN is designed to ensure service and feeder link continuity between successive serving satellite gateways, with sufficient duration for mobile anchoring and handover.

[0007] Satellites can support transparent or regenerative (with onboard processing) payloads and typically generate several beams for a given service area defined by the field of view. The coverage area of ​​the beam typically has an elliptical shape and depends on the onboard antenna configuration and elevation angle. For transparent payload implementations, the satellite can apply RF filtering as well as frequency conversion and amplification without changing the waveform signal. For regenerative payload implementations, the satellite can apply RF filtering, frequency conversion and amplification, demodulation and decoding, routing, and encoding / modulation. This approach is effectively equivalent to the satellite performing most of the functions of a base station (e.g., gNB).

[0008] A UE communicating via an NTN experiences propagation delay when communicating with a terrestrial network entity NE of a radio access network RAN ​​via a satellite. In this document, a network entity NE is a physical device operating as a base station BS, a distributed unit DU of a BS, or a physical device hosting core network CN functionality. In this case, the UE and the RAN can collaborate to compensate for propagation delays based on the location information of the UE and the satellite. The RAN includes terrestrial NEs and satellites, i.e., non-terrestrial networks NTN. The RAN knows the serving satellite of the UE, but may not know the exact UE location within the area (cell) served by the satellite. The UE is able to evaluate the satellite-to-UE delay and report the delay to the RAN, thereby enabling the RAN to accurately estimate the round-trip delay for scheduling UL transmissions. Without knowing the satellite-to-UE delay, the RAN must assume that the UE is at the edge of the cell (i.e., assume the longest possible round-trip delay of the cell) to schedule each UL transmission. Such scheduling can significantly delay UL transmissions, especially when a UE in the RRC_INACTIVE (RRC is an acronym for radio resource control) state performs an RRC connection recovery procedure or a small data transfer (SDT) procedure to transmit data. In these cases, such scheduling prolongs the entire RRC connection recovery / SDT process and thus increases latency.

[0009] Conventionally, there is no adequate strategy for the UE to provide TA reporting when the connection to the RAN is restored after an inactive state or when a small data transfer SDT procedure is performed (without leaving the inactive state). On the one hand, during the UE's inactive state, the UE-to-satellite / satellite-to-UE path may have changed. On the other hand, if the UE-to-satellite / satellite-to-UE path has changed only by a negligible amount, automatic TA reporting wastes communication resources and time. Summary of the invention

[0010] In general, the techniques described in this document allow a UE to selectively transmit a timing advance (TA) report according to a predetermined rule when resuming connection with the RAN or when performing an SDT. The predetermined rule for determining whether the UE transmits a TA report may depend on: (A) the difference between the current UE-specific TA (which is due to UE-to-satellite / satellite-to-UE propagation and is re-evaluated for resuming UE-to-RAN connection) and the UE-specific TA before the UE entered the inactive state; (B) an indication provided by the RAN; and / or (C) whether the UE has moved to a cell different from the anchor cell used before entering the inactive state. The predetermined rule may also take into account the size of small data transfers (SDTs). Selectively transmitting a TA report avoids wasting time on TA-related overhead and resources for unnecessary reporting, while supporting both the UE and the RAN to use TA information efficiently. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1A is a block diagram of a wireless communication system in which a user equipment and a network entity implement a TA reporting technique according to various embodiments.

[0012] Figure 1B is a block diagram of a distributed base station BS having a centralized unit CU and a distributed unit DU, the distributed BS being configured to Figure 1A operating in the system.

[0013] Figure 2A is a block diagram illustrating a protocol stack for communication between a UE and a terrestrial BS.

[0014] Figure 2B It is shown for Figure 1A A block diagram of a protocol stack for UE to communicate with CU and DU;

[0015] Figure 3A is a block diagram of the transparent payload NTN architecture;

[0016] Figure 3B is a block diagram of a transparent payload NTN architecture, where a BS is connected to multiple satellites via the same satellite gateway;

[0017] Figure 4AShown with Figure 3A The user plane protocol stack used in conjunction with the NTN architecture shown;

[0018] Figure 4B Shown with Figure 3A The control plane protocol stack used with the architecture;

[0019] Figure 5A The relationship between TA and propagation delay for UE-BS communication via satellite is shown.

[0020] Figure 5B The relationship between TA and propagation delay for two different UEs served by the same satellite is shown.

[0021] Figure 6 The components of a complete TA are shown as applied by a UE using satellite (ie communicating via the NTN).

[0022] Figure 7 shows the result that the UE obtains N for UL transmission TA A series of messages.

[0023] FIG. 8A to FIG. 8D is a message passing diagram illustrating scenarios in which a UE configured with a TA reporting configuration determines whether to send a TA report to a DU of a BS during an RRC connection recovery procedure.

[0024] 9A to 9D is a message passing diagram for scenarios in which, when the broadcasted (satellite-related) system information does not include an affirmative indication for the UE to provide a TA report, the UE determines, when performing an RRC connection recovery procedure, whether to send a TA report to a new cell (NE / BS) that is different from the cell (NE / BS) to which the UE was connected before entering the inactive state.

[0025] FIG. 10A to FIG. 10D is a message passing diagram for scenarios in which, when the broadcasted system information includes a positive indication for the UE to send a TA report, the UE determines whether to send a TA report to a new cell (NE / BS) different from the cell (NE / BS) to which the UE was connected before entering the inactive state when performing an RRC connection recovery procedure.

[0026] FIG. 11A to FIG. 11C is a message passing diagram for scenarios in which a UE previously configured with a TA report configuration determines whether to send a TA report during a small data transfer (SDT) procedure.

[0027] FIG. 12A to FIG. 12Bis a message passing diagram for scenarios in which, when the broadcast system information of the new cell includes an affirmative indication for the UE to provide a TA report when establishing / reestablishing / resuming an RRC connection with the new cell, the UE determines whether to send a TA report to a new cell (NE / BS) different from the cell (NE / BS) to which the UE was connected before entering the inactive state when initiating an SDT procedure with the new cell.

[0028] Fig.13 is a message passing diagram for exemplary scenarios in which, when the system information broadcast by the new cell does not include an affirmative indication for the UE to report the TA when establishing / reestablishing / resuming an RRC connection with the new cell, the UE determines not to report the TA to a new cell (NE / BS) different from the cell (NE / BS) to which the UE was connected before entering the inactive state when initiating the SDT procedure with the new cell.

[0029] Fig.14A is a flowchart of a method performed by a UE for reporting a TA and obtaining a differential k_offset value during an RRC recovery procedure according to an embodiment.

[0030] Fig. 14B is a flowchart of a method performed by a UE for obtaining a differential k_offset value without reporting a second complete TA in an RRC recovery procedure according to an embodiment.

[0031] Fig.15 is a flowchart of a method performed by a UE for determining whether to report a TA after receiving an RRC recovery message according to an embodiment.

[0032] Fig.16 is a flowchart of a method performed by a UE for determining whether to report a TA in an RRC recovery procedure based on an indication broadcast in system information according to an embodiment.

[0033] Fig.17 is a flow chart of a method performed by a UE for determining whether to report a TA in an RRC recovery procedure based on an indication broadcast in system information and also based on whether the UE remains in an anchor cell according to an embodiment.

[0034] Fig.18 is a flowchart of a method performed by a UE for determining whether to report its TA during an SDT procedure according to an embodiment.

[0035] Fig.19 is a flowchart of a method performed by a UE for determining whether to report a TA in an SDT procedure based on whether the UE remains in an anchor cell according to an embodiment.

[0036] Fig. 20is a flow chart of a method performed by a UE for determining whether to report a TA in an SDT procedure based on an indication broadcast in system information and also based on whether the UE remains in an anchor cell according to an embodiment.

[0037] Fig.21 is a flowchart of a method performed by a UE for determining not to report its TA during an SDT process according to an embodiment.

[0038] Fig. 22 is a flowchart of a method of reconnecting to a RAN performed by a UE according to an embodiment.

[0039] Fig.23 is a flowchart of a method for SDT performed by a UE according to an embodiment.

[0040] Fig.24 is a block diagram of a UE configured to perform a method for selectively transmitting a TA report during a procedure for recovering a RAN connection and / or in an SDT procedure according to an embodiment. DETAILED DESCRIPTION

[0041] As discussed in more detail below, when a user equipment (UE) transitions from an inactive state to an active state of a radio resource control protocol between the UE and a radio access network (RAN), and / or when the UE performs a small data transfer (SDT), the network nodes of the UE and / or the RAN manage TA reporting using the techniques described in this section.

[0042] First reference Figure 1A , the wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106, and a core network (CN) 110. The base stations 104 and 106 operate in a RAN 105 connected to the core network (CN) 110. For example, the CN 110 may be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160. In another example, the CN 110 may also be implemented as a sixth generation (6G) core.

[0043] Base station 104 provides services for UEs within cell 124, and base station 106 provides services for UEs within cell 126. If base station 104 and / or 106 are gNBs, then cells 124 and / or 126 are NR cells accordingly. If base station 104 and / or 106 are ng-eNBs or eNBs, cells 124 and / or 126 are Evolved Universal Terrestrial Radio Access (E-UTRA) cells. Cells 124 and 126 may be located in the same radio access network notification area (RNA) or in different RNAs. In general, RAN 105 includes any number of base stations, and each of the base stations covers (i.e., provides services for UEs within) one, two, three, or any other suitable number of cells. For example, base station 104 may also cover cell 125. UE 102 supports at least one of 5G NR (or simply "NR") or E-UTRA air interfaces to communicate with one or two base stations 104 and 106. Each of the base stations 104, 106 is connected to the CN 110 via an interface (e.g., an S1 or NG interface). The base stations may also be interconnected via an interface (e.g., an X2 or Xn interface for interconnecting NG RAN nodes).

[0044] CN 110 can be hosted by one or more physical devices that can be co-located. In this document, base stations and physical devices that host core network functions / modules can be referred to as network entities NE. Among other components, EPC 111 includes a service gateway (SGW) 112, a mobility management entity (MME) 114, and a packet data network gateway (PGW) 116. In general, SGW 112 is configured to transmit user plane packets related to audio calls, video calls, Internet traffic, etc. MME 114 is configured to manage authentication, registration, paging and other related functions. PGW 116 provides connectivity from UE to one or more external packet data networks (e.g., Internet networks and / or Internet Protocol (IP) Multimedia Subsystem (IMS) networks). Similarly, among other components, 5GC 160 includes a user plane function (UPF) 162, an access and mobility management function (AMF) 164, and / or a session management function (SMF) 166. Generally speaking, UPF 162 is configured to transmit user plane packets associated with audio calls, video calls, Internet traffic, etc., AMF 164 is configured to manage authentication, registration, paging and other related functions, and SMF 166 is configured to manage PDU sessions.

[0045] like Figure 1AAs shown, base station 104 supports cell 124 (i.e., covers cell 124 and provides services for UEs within cell 124), and base station 106 supports cell 126. Cells 124 and 126 may partially overlap, so that UE 102 selects, reselects, or switches from one of cells 124 and 126 to the other. In order to directly exchange messages or information, base station 104 and base station 106 support an X2 or Xn interface. In general, CN 110 is connected to any suitable number of base stations that support NR cells and / or EUTRA cells.

[0046] As discussed in detail below, the techniques described in this section may be utilized by the UE 102 and / or the NE of the RAN 105 (e.g., BS 104 and / or 106) when the radio connection between the UE 102 and the RAN 105 is suspended—e.g., when the UE 102 is operating in an inactive state including the RRC_IDLE and RRC_INACTIVE states of the RRC protocol.

[0047] The base station 104 is equipped with processing hardware 130, which includes one or more general-purpose processors 132 (e.g., CPUs) and a non-transitory computer-readable memory 134 storing instructions executed by the one or more general-purpose processors. In addition or alternatively, the processing hardware 130 may include a dedicated processing unit. The processor 132 is configured to process data received in the uplink direction or data transmitted in the downlink direction by the base station 104 according to the various techniques described in this section. The processing hardware 130 also includes a transceiver 136 (the term also represents antennas and RF front-end electronic devices not shown separately in this figure) configured to transmit data in the downlink direction and receive data in the uplink direction. The base station 106 includes substantially similar components. Specifically, the components 140, 142, 144, and 146 of the base station 106 are similar to the components 130, 132, 134, and 136, respectively.

[0048] UE 102 is equipped with processing hardware 150, which includes one or more general-purpose processors 152 such as CPUs and non-transitory computer-readable memory 154 storing machine-readable instructions that can be executed on one or more general-purpose processors, and / or dedicated processing units. Processor 152 is configured to process data transmitted in the uplink direction and / or data received in the downlink direction by UE 102. Processing hardware 150 may also include a transceiver 156 (the term also refers here to antennas and RF front-end electronic devices that are not separately shown in this figure) that is configured to transmit and receive data.

[0049] Figure 1B is a block diagram of a distributed base station 170 . Figure 1A Any one or both base stations 104 and 106 may use a distributed BS architecture. Base station 170 includes a centralized unit CU 172 and one or more distributed units DU 174 (only one is shown). CU 172 includes processing hardware such as one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions that can be executed on a general-purpose processor, and / or a dedicated processing unit. For example, CU 172 may include a packet data convergence protocol (PDCP) controller, an RRC controller, and / or an RRC inactive controller. In some implementations, CU 172 may include a radio link control RLC controller that is configured to manage or control one or more RLC operations or processes. In a further implementation, CU 172 does not include an RLC controller.

[0050] In some implementations (such as Figure 1B ), CU 172 includes a logical node CU-CP 172A that hosts the control plane portion of the PDCP protocol of CU 172. CU 172 may also include a logical node CU-UP 172B that hosts the user plane portion of the PDCP protocol and / or the Service Data Adaptation Protocol (SDAP) protocol of CU 172. CU-CP 172A may transmit control information (e.g., RRC messages, F1 application protocol messages), and CU-UP 172B may transmit data packets (e.g., SDAPPDUs or Internet Protocol packets).

[0051] CU-CP 172A may be connected to multiple CU-UPs 172B via an E1 interface. CU-CP 172A selects an appropriate CU-UP 172B for the requested service of UE 102. In some implementations, a single CU-UP 172B may be connected to multiple CU-CPs 172A via an E1 interface. CU-CP 172A may be connected to one or more DUs 174 via an F1-C interface. CU-UP 172B may be connected to one or more DUs 174 via an F1-U interface under the control of the same CU-CP 172A. In some implementations, one DU 174 may be connected to multiple CU-UPs 172B under the control of the same CU-CP 172A. In such implementations, connectivity between CU-UP 172B and DU 174 is established by CU-CP 172A using a BearerContext Management function.

[0052] DU 174 (which may be one of multiple DUs of a distributed base station) includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on one or more general-purpose processors, and / or dedicated processing units. For example, the processing hardware may include: a media access control MAC controller and / or an RLC controller, the MAC controller is configured to manage or control one or more MAC operations or processes (e.g., random access processes), and the RLC controller is configured to manage or control one or more RLC operations or processes. The processing hardware may also include a physical layer controller, which is configured to manage or control one or more physical layer operations or processes.

[0053] In some embodiments, the RAN 105 supports integrated access and backhaul (IAB) functionality. In some implementations, the DU 174 operates as an IAB node and the CU 172 operates as an IAB donor. For the embodiments described in this section, the RAN 105 supports non-terrestrial network (NTN) functionality.

[0054] Figure 2A is shown for use with a UE such as (for example, Figure 1A Block diagram of a protocol stack 200 for communication between ground base stations (eNB / ng-eNB 203 and gNB / en-gNB 205) corresponding to the base stations 104 and / or 106 in the figure.

[0055] The physical layer PHY 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 may in turn provide data transfer services to the Service Data Adaptation Protocol SDAP 212 or the Radio Resource Control RRC sublayer ( Figure 2A (not shown) provides data transmission services. In some implementations, such as Figure 2A As shown, UE 102 supports both EUTRA and NR stacks to support switching between EUTRA and NR base stations and / or support DC through EUTRA and NR interfaces. Figure 2AAs shown, the UE 102 can support NR PDCP 210 layered on EUTRARLC 206A, and the SDAP sublayer 212 layered on the NR PDCP sublayer 210.

[0056] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets, which may be referred to as service data units (SDUs) (e.g., from an Internet Protocol (IP) layer layered directly or indirectly on the PDCP layer 208 or 210), and output packets, which may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). Except for cases where the difference between SDUs and PDUs is relevant, for simplicity, this document refers to both SDUs and PDUs as "packets".

[0057] On the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide signaling radio bearers (SRBs) or RRC sublayers ( Figure 2A The NR PDCP sublayer 210 may be a SDAP PDU, an IP packet, or an Ethernet packet.

[0058] Figure 2B An example protocol stack 250 by which the UE 102 may communicate with the DU 174 and the CU 172 is shown in a simplified manner. Figure 2A The radio protocol stack 200 in FIG. 1 is functionally split, as shown by Figure 2B 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support the connection to the 5GC, the NR PDCP 210 provides SRBs to the RRC 214, and the NR PDCP 210 provides DRBs to the SDAP 212 and provides SRBs to the RRC 214.

[0059] Figure 3AA certain type of NTN deployment, referred to as a transparent payload architecture, is shown, which involves a satellite gateway 302 and a "transparent" satellite 304 for extending the range of the Uu interface. The satellite 304 implements frequency conversion and radio frequency (RF) amplifiers in both the uplink direction and the downlink direction. The satellite functions similarly to the functions of an analog RF repeater. Therefore, the satellite 304 relays the Uu radio interface from the feeder link (between the NTN gateway and the satellite) to the service link (between the satellite and the UE) in the downlink direction, and vice versa in the uplink direction. The satellite radio interface (SRI) on the feeder link is Uu, and the NTN gateway 302 supports all functions necessary to forward the signals of the Uu interface. The NTN gateway 302 can be placed at the same location as the base station (e.g., eNB or gNB) 104, or connected to the base station 104 via a wired link. More than one NTN gateway can also be connected to the base station. Different transparent satellites can be connected to the same base station on the ground via the same NTN gateway or via different NTN gateways.

[0060] Figure 3B A different type of NTN deployment is shown in which two different satellites (304 and 306) are connected to the same base station 104 via the same NTN gateway 302, and the two satellites (304 and 306) cover areas on the Earth's surface (which may partially overlap) using two different physical cell IDs (PCIs).

[0061] exist Figure 4A 104, the NTN user plane protocol stack UPPS involving UE 102, satellite 304, NTN gateway 302, NR base station (i.e. gNB) 104 and UPF 162 is shown in FIG. The diagram of NTN UPPS is similar to that of the terrestrial network TN, with the addition of two new nodes, namely satellite 304 and NTN gateway 302, placed in the middle of the NR-Uu interface. UE to gNB / gNB to UE communication uses physical layer 402, MAC layer 404 and radio link control RLC layer 406. Further, UE to gNB / gNB to UE communication uses packet data convergence protocol PDCP 408 and service data adaptation protocol SDAP 410. gNB to UPF / UPF to gNB communication uses L1 layer 401 (i.e. 5G physical layer), L2 layer 402 (i.e. 5G data link layer) and Internet protocol IP 405. Further, gNB to UPF / UPF to gNB communications employ the User Datagram Protocol UDP 407 and the GPRS Tunneling Protocol GTP-U 409 for carrying user data (here the acronym GPRS stands for General Packet Radio Service).

[0062] Figure 4BThe NTN control plane protocol stack CPPS shown is also similar to the TN protocol stack. Figure 4A UPPS and Figure 4B Unlike SDAP 410 in UPPS, CPPS includes RRC layer 411. Further, UDP 407 and NGAP 409 are replaced by Stream Control Transmission Protocol SCTP 413 and Next Generation Application Protocol NGAP 414. Descriptions of these protocols and communication layers can be found in the 3GPP technical specifications of the same period.

[0063] In terms of satellite mobility patterns, there are three types of service links supported in NTN: ● Geofixed, for satellites that provide continuous beam coverage of the same geographical area (e.g., GEO / GSO satellites), ● Quasi-Earth Fixed, for satellites that provide a beam covering one geographic area for a limited period of time and a different geographic area during another period of time (e.g., LEO / MEO satellites capable of using steerable beams), • Earth mobile, for satellites providing a beam whose coverage area slides over the surface of the Earth (eg, LEO / MEO satellites using fixed or unsteerable beams).

[0064] Therefore, the eNB connected via the NTN can provide quasi-Earth fixed cell coverage or Earth mobile cell coverage using LEO / MEO satellites. The eNB provides Earth fixed cell coverage using GEO satellites.

[0065] although Figure 3A / Figure 3B The transparent payload architecture shown is the current focus of 3GPP development, but a regenerative payload architecture with the BS functionality installed on the satellite is also a possible NTN deployment. In such an architecture, the Uu exists only between the satellite and the UE. In general, the techniques of this document can be applied to both the transparent payload architecture as well as the regenerative payload architecture.

[0066] When allocating time domain resources in TN, the interval between DCI scheduling UL data transmission and PUSCH carrying UL data is indicated via the k2 value, where the k2 value is indicated in the DCI in units of time slots. Similarly, the interval between PDSCH carrying DL data and PUCCH carrying the UE's HARQ feedback related to the received DL data is indicated via the k1 value, where the k1 value is indicated in the DCI scheduling DL data (also in units of time slots). When allocating time domain resources in NTN, in addition to the above k1 and k2 values, the UE needs to further delay the PUCCH or PUSCH transmission to compensate for the signal propagation time. This additional delay is called the scheduling delay "k_offset", and it takes into account the round-trip delay between the UE and the base station. Figure 5A An example showing the relationship between k_offset and UE to BS / BS to UE propagation time in an NTN scenario is shown. In this example, the DL signal propagation time corresponds to 4 slots, and therefore the UE DL timing lags behind the BS DL timing by 4 slots. In order to align the BS DL timing with the BS UL timing, the UE needs to perform any PUSCH / PUCCH transmission with a timing advance (TA) equal to 8 slots (i.e., round trip delay or twice the propagation time, since the UL propagation time is the same as the DL propagation time). In this case, when the BS schedules an UL transmission for the UE, it must ensure that the shortest interval between the UL transmission and the PDCCH scheduled UL transmission is 8 slots, otherwise the UE does not have enough time to prepare / perform the UL transmission by applying a TA of 8 slots. That is, in this case, k_offset must be at least 8 slots long.

[0067] Figure 5B Another example is shown involving two different UEs, UE1 and UE2, served by the same BS / satellite. In this example, UE2 is closer to the BS than UE1, and therefore the propagation delay from the BS to UE2 (3 slots) is also smaller than the propagation delay from the BS to UE1 (4 slots). Therefore, UE1 and UE2 need to apply a TA equal to 8 slots and 6 slots, respectively, to align the BS UL timing with the BS DL timing. Since UE1 and UE2 apply different TAs, the k_offset values ​​of UE1 and UE2 are also different. In this example, the k_offset value of UE1 is 8 slots, while the k_offset value of UE2 is 6 slots.

[0068] In an NTN environment, in addition to the k1 and k2 values ​​signaled in the PDCCH, the BS also needs to signal the k_offset value to the UE before PDCCH delivery so that the UE can perform UL transmission at the correct time (e.g., k1+k_offset or k2+k_offset) instructed by the BS. k_offset is delivered to the UE via two components: 1) a cell-specific scheduling offset "cell-specific k_offset" and 2) a UE-specific scheduling offset "differential k_offset". "Cell-specific k_offset" is the common part of the k_offset value, which is the same for all UEs within the same cell. "Differential k_offset" is the difference value between the UE's actual k_offset value and the cell-specific k_offset value, and it is signaled to each UE individually. In one implementation, a cell-specific k_offset value is broadcast in the (satellite-related) system information, which reflects the actual k_offset value of the UE farthest from the satellite; a differential k_offset value is signaled separately to the UE via a special MAC CE named "Differential Koffset MAC CE", which is then subtracted from the cell-specific k_offset value to obtain the actual k_offset value (i.e., the farther the UE is from the satellite, the smaller the differential k_offset).

[0069] In order to provide an accurate differential k_offset value to the UE, the BS needs to know exactly the round trip delay between the UE and the BS. Since the round trip delay is equivalent to the TA applied by the UE when performing UL transmission, the BS can determine the differential k_offset value of the UE by obtaining the TA applied by the UE. Figure 6 As shown, when communicating via the NTN (ie, satellite 304), the UE applies a TA having three components: 1) a common TA, 2) a UE-specific TA, and 3) a TA correction N TA . If the uplink time synchronization reference point is located at BS 104, the common TA (i.e., common to all UEs communicating with the same BS via the same satellite) is equal to twice the BS-to-satellite / satellite-to-BS propagation time (i.e., 2*D1 / c, where c is the speed of light, for co-located NTN Gateway 302 and BS 104). The UE-specific TA is equal to twice the satellite-to-UE / UE-to-satellite propagation time, depending on the distance D3 between satellite 304 and UE 102: UE-specific TA = 2*D3 / c. The common TA is known to the BS and may be broadcast in the system information block. The UE-specific TA is known to the UE but not to the BS. The UE may report TA information so that the BS is aware of the UE-specific TA.

[0070] After receiving TA correction N from BS TA Previously, the UE performed UL transmission (eg, random access preamble transmission, PUSCH transmission, or PUCCH transmission) by applying both a common TA and a UE-specific TA. Figure 7 The figure shows how the UE obtains N when performing UL transmission. TA Example. In this example, the propagation delay is 4 time slots long and therefore the UE DL timing lags behind the BS DL timing by 4 time slots. The UE first determines the UE-specific TA by obtaining the distance between the UE and the connected satellite, which can be calculated based on the GNSS information available on the UE side and the ephemeris information provided by the network. The UE then obtains the common TA by acquiring system information related to the satellite and applies both the common TA and the UE-specific TA when performing UL transmission. In this example, even after the UE applies both the common TA and the UE-specific TA, the BS UL timing is still slightly behind the BS DL timing. Therefore, the BS sends a timing advance command (TAC) MAC CE to inform the UE of the amount of timing advance that it needs to additionally apply in order to align the BS DL timing with the BS UL timing. The additional timing advance provided in the TAC MAC CE becomes the N of the UE. TA , and needs to be applied by the UE starting from the next UL transmission. Although in this example, since the BS UL timing lags behind the BS DL timing, N TA is positive, but when the BS UL timing is ahead of the BS DL timing, N TA Can be negative. TA After that, the UE can know the complete TA (common TA + UE-specific TA + N TA ) and applies the full TA when performing UL transmission.

[0071] Unlike terrestrial BSs, NTN BSs send timing advance commands MAC CE (i.e. N TA ), the complete TA applied by the UE is also unknown because the BS is unaware of the UE-specific TA (i.e., part of the complete TA) compensated by the UE. Therefore, the NTN BS cannot estimate the round-trip delay and must schedule UL transmissions with an additional delay (i.e., k_offset) equivalent to the worst-case (i.e., longest) round-trip delay between the UE and the BS. In order for the NTN BS to know the complete TA of the UE, the 3GPP UE is now configured to report the complete TA by sending a TA report MAC CE to the BS. In several cases, the UE reports its complete TA to the BS. For example, the UE may receive an RRC message including a TA reporting configuration (i.e., including the tar-Config information element). The TA reporting configuration may include an offset value X offset, the offset value is used by the UE to determine whether to send another TA report, i.e. when the TA currently applied by the UE differs from the last reported TA by more than X offset In another example, when being handed over to another BS or when re-establishing an RRC connection to another BS, the UE sends a TA report to the new BS if instructed (ie, receives an indication) in a handover command or a system information broadcast message.

[0072] However, conventional strategies are unclear whether and under what conditions a UE in RRC_INACTIVE state reports its complete TA when attempting to resume its RRC connection (i.e., after sending an RRC Connection Resumption Request message to the BS). If the UE does not report its complete TA during the RRC Connection Resumption procedure, the BS is unaware of the round trip delay and must assume the worst case (i.e., the longest round trip delay) when scheduling UL grants during the RRC Connection Resumption procedure, which will prolong the entire RRC Connection Resumption procedure and thus increase the latency of mobile originated (MO) or mobile terminated (MT) data. On the other hand, forcing every UE to report its complete TA during the RRC Connection Resumption procedure is not resource efficient because it will require the network to globally allocate larger MSG3 grants or MSGA PUSCH resources, which may ultimately waste resources because the TA of a specific UE (e.g., a fixed UE) may not have changed since the UE last reported its TA.

[0073] Conventional methods are also unclear whether a UE in RRC_INACTIVE state reports its complete TA to the BS when initiating the SDT process or during the SDT process. If the UE transmits all SDT data in one-shot, it is inefficient for the UE to report its TA because the UE immediately returns to the RRC_INACTIVE state and therefore will not be able to utilize / apply the UE-specific scheduling offset (i.e., differential k_offset) determined by the BS. On the other hand, if the UE has subsequent data transmissions after the first small data transmission, preventing the UE from reporting its complete TA results in a more conservative scheduling of subsequent data transmissions than necessary, and thus increases the overall data delay. This document proposes techniques to minimize UL data delay and avoid unnecessary signaling overhead for determining whether and when to report the UE's TA.

[0074] FIG. 8A to FIG. 13 Several scenarios are shown in which a UE and / or a network element NE (e.g., a BS, DU, or CU) performs techniques related to TA reporting for a UE in an inactive state. In these figures, time flows from the top to the bottom of the page, that is, a first action (such as signal transmission) occurs before a second action represented below the first action. FIG. 8A to FIG. 13Similar events in the RRC_INACTIVE or RRC_IDLE state are labeled with similar reference numerals, with differences discussed below where appropriate. For example, event 802 is similar to events 902, 1002, 1102, 1202, 1302. To simplify the following description, the term "inactive state" refers to the RRC_INACTIVE or RRC_IDLE state, and the term "connected state" or "active state" refers to the RRC_CONNECTED state.

[0075] Fig. 8A 800A is a message passing diagram for a scenario in which a UE 102 communicates with a BS 104 (more precisely, with a DU 174 of the BS 104) via a satellite 304. The BS 104 includes a CU 172 and a DU 174. The UE 102 initially operates 802 in a connected state and is connected to the BS 104 via a service link provided by the satellite 304. Then, the UE 102 receives 804 system information from the DU 174 containing NTN-specific information, the NTN-specific information including ephemeris, a common TA, and a cell-specific k_offset (i.e., cellSpecificKoffset). The UE 102 may receive the system information before transitioning to the connected state. Thereafter, the UE 102 obtains its GNSS coordinates, calculates the distance between the UE 102 and the satellite 304 based on the obtained ephemeris information and the GNSS coordinates, and determines 806 a UE-specific TA based on the calculated distance. Later, the UE 102 applies both the common TA and the UE-specific TA when transmitting 808 a random access (RA) preamble or UL data to the DU 174. After receiving the RA preamble or UL data, the DU 174 first forwards 810 the UL data (if not the RA preamble) to the CU 172, determines the N of the UE 102, and transmits 810 the UE-specific TA to the DU 174. TA The value of N is then transmitted 812 to the UE 102 including the determined N TA Events 804, 806, 808, 812 and optional 810 are in Fig. 8A are collectively referred to as the method for obtaining common TA, UE-specific TA and N TA 811 (and shown uniformly in the following figures).

[0076] Later, the CU 172 generates an RRC reconfiguration message including a TA report configuration (e.g., tar-Config) for the UE 102, and transmits 814 a CU-to-DU message (e.g., a DL RRC Message Transfer message) including the RRC reconfiguration message (e.g., an RRCReconfiguration message) to the DU 174. Then, the DU 174 transmits 816 the RRC reconfiguration message to the UE 102. In some implementations, the CU 172 receives a DU-to-CU message (e.g., a UE Context Modification Required message or a UE Context Modification Response message) including the TA report configuration from the DU 174. In response to the TA reporting configuration, the UE 102 transmits 818 a UL MAC PDU including a Timing Advance Report MAC CE to the DU 174, wherein the Timing Advance Report MAC CE includes a first complete TA value (i.e., common TA + UE-specific TA + N TA ). After receiving the timing advance report MAC CE (e.g., in response to receiving the timing advance report MAC CE), the DU 174 transmits 820 a differential Koffset MAC CE including a first differential k_offset value to the UE 102. In some implementations, the DU 174 determines the first differential k_offset value based on the first full TA value reported by the UE 102 and the cell-specific k_offset value. Events 814, 816, 818, and 820 are described in detail in detail in detail. Fig. 8A are collectively referred to as the difference k_offset (N TA ) process 821 (and shown uniformly in the following figures).

[0077] In response to the RRC reconfiguration message, UE 102 transmits an RRC reconfiguration complete message to DU 174, which in turn transmits the RRC reconfiguration complete message to CU 174. In some implementations, UE 102 includes the RRC reconfiguration complete message in the UL MAC PDU of event 818. In other implementations, UE 102 transmits the RRC reconfiguration complete message to DU 174 in a UL MAC PDU that is different from the UL MAC PDU of event 818.

[0078] After DU 174 transmits the first differential k_offset value to UE 102, CU 172 determines that UE 102 is data inactive (i.e., UE 102 in a connected state has no data exchange with BS 104). In response to the determination, CU 172 sends 822 a CU to DU message (e.g., a UE Context Release Command message) including an RRC release message (e.g., an RRCRelease message) to transition UE 102 to an inactive state. In some implementations, the RRC release message includes a SuspendConfig information element (IE) that configures UE 102 to transition to an inactive state. Then, DU 174 transmits 824 the RRC release message to UE 102, and in some implementations, the DU may transmit 825 a DU to CU message to CU 172 including the first complete TA value and / or the first differential k-offset value of UE 102. After transmitting 825 the DU to CU message including the first TA value and / or the first differential k-offset value of the UE 102 to the CU 172, the DU may release / discard the first complete TA value and / or the first differential k-offset value of the UE 102. In response to the RRC release message or the SuspendConfig IE, the UE 102 then retains the TA reporting configuration (e.g., the X provided in the tar-Config IE). offset value) and transition 826 to the inactive state.

[0079] Later, the UE 102 in the inactive state determines 805 to resume the active state, that is, the UE initiates an RRC connection resumption procedure to transmit UL data, respond to a paging message received from the DU 174, or perform a RAN-based area notification update (RNAU). At the same time, the UE 102 determines 879A that the difference between the full TA value currently applied by the UE (i.e., the second full TA value) and the first full TA value reported at event 818 is equal to or greater than the X configured in the TA reporting configuration. offsetThe UE 102 determines that the RA preamble group is a RA preamble group of the selected RA preamble group. In response to the determination, the UE 102 initiates 828A a random access (RA) procedure with the DU 174 and selects a RA preamble group by taking into account the size of the TA report MAC (TA Report MAC). In some implementations, the RA procedure is a four-step RA procedure. In other implementations, the RA procedure is a two-step RA procedure. In response to initiating the RA procedure, the UE 102 transmits the RA preamble of the selected RA preamble group to the DU 174. In the case of the four-step RA procedure, the DU 174 transmits an RA response to the UE 102 in response to the RA preamble, wherein the RA response includes an UL grant, which is used by the UE 102 to transmit 830A an UL MAC PDU (MPDU) to the DU 174, the MPDU including an RRC recovery request message (e.g., an RRCResumeRequest message) and a TA report MAC CE including the second complete TA value. In case of a two-step RA procedure, the UE 102 transmits 830A to the DU 174 an MPDU including an RRC resume request message and a TA report MAC CE containing a second complete TA value using the UL grant indicated in the system information broadcast by the DU 174 .

[0080] After receiving the UL MPDU including the RRC recovery request message and the TA report MAC CE, DU 174 transmits 832A a DU-to-CU message (e.g., an Initial UL RRC Message Transfer message) including the RRC recovery request message to CU 172, and also transmits 834A a DL MPDU including a Contention Resolution ID MAC CE to UE 102 for contention resolution. In some implementations, DU 174 may include a differential Koffset MAC CE in the DL MPDU at event 834A, which includes a second differential k_offset value. Alternatively, DU 174 may transmit the differential Koffset MAC CE at event 838A. In some implementations, DU 174 determines the second differential k_offset value based on the second complete TA value reported by UE 102 and the cell-specific k_offset value.

[0081] In response to the RRC RECOVERY REQUEST message, CU 172 transmits 836A a CU-to-DU message including an RRC RECOVERY message (e.g., an RRCResume message) to DU 174, wherein the RRC RECOVERY message sets a new TA reporting configuration for UE 102 (i.e., includes a SetupRelease {TAR-Config} type with a selection of “setup”). The new TA reporting configuration at event 836A may be similar to or different from the TA reporting configuration at event 814. DU 174 then transmits 838A an RRC RECOVERY message to UE 102. Upon receiving the new TA reporting configuration, UE 102 replaces the TA reporting configuration received at event 814 with the TA reporting configuration received at event 838A. In some implementations, DU 174 receives the CU-to-DU message before transmitting a contention resolution ID MAC CE to UE 102. In this case (i.e., event 836A occurs before event 834A), DU 174 may transmit a DL MAC PDU including a contention resolution ID MAC CE and an RRC recovery message to UE 102 (i.e., 834A and 838A may be combined), and may also include a differential Koffset MAC CE in the DL MAC PDU. In some implementations, the RRC recovery message in 836A / 838A does not include a TA reporting configuration (i.e., does not include a tar-Config IE), which causes UE 102 to apply the TA reporting configuration that it retained before transitioning to the inactive state in event 824.

[0082] After receiving the RRC recovery message including the new TA reporting configuration or not including the tar-Config IE, the UE 102 transitions 840 to the connected state and transmits 842A to the DU 174 an UL MPDU including an RRC recovery complete message (e.g., an RRCResumeComplete message) and a TA report MAC CE including the third complete TA value. The DU 174 then transmits 844 a DU to CU message (e.g., an UL RRC Message Transfer message) including the RRC recovery complete message to the CU 174. After receiving the TA report MAC CE, the DU 174 determines a third differential k_offset value based on the third complete TA value reported by the UE 102 and the cell-specific k_offset value. In some implementations, the DU 174 may transmit 846 the differential Koffset MAC CE to the UE 102. In some implementations, if the determined third differential k_offset value is similar to the second differential k_offset value transmitted by DU 172 at event 834A, DU 172 may omit event 846 (i.e., not transmit a differential Koffset MAC CE). Note that steps 842A, 844, and 846 are possible, but not required.

[0083] In some implementations, in response to event 838A, UE 102 transmits 842A to DU 174 an UL MPDU that does not include a third complete TA value because UE 102 has reported a second complete TA value in the same RRC recovery procedure and the difference between the third complete TA and the second complete TA is less than X configured in the TA reporting configuration. offset .

[0084] Figure 8B is with Fig. 8A The message passing diagram for scenario 800B is similar to scenario 800A shown in FIG. Fig. 8A and Figure 8B In response to transmitting 832A a DU-to-CU message including an RRC resume request message to CU 172, DU 174 receives 836B a CU-to-DU message including an RRC resume message that releases the first TA reporting configuration (i.e., includes a SetupRelease {TAR-Config} type with a selection of “release”). DU 174 then transmits 838B an RRC resume message to UE 102 with an indication to release the first TA reporting configuration.

[0085] After receiving the RRC recovery message with an indication to release the first TA reporting configuration, UE 102 transitions 840 to a connected state and transmits 842B a UL MPDU including only an RRC recovery complete message (e.g., an RRCResumeComplete message) to DU 174. Unlike event 842A, in this scenario, UE 102 does not transmit a complete TA value in event 842B because UE 102 has discarded the first TA reporting configuration. DU 174 then transmits 844 a DU to CU message (e.g., an UL RRC messaging message) that forwards the RRC recovery complete message to CU 174.

[0086] Figure 8C is with Fig. 8A The message passing diagram for scenario 800C is similar to scenario 800A shown in FIG. Fig. 8A and Figure 8C After the UE 102 in the inactive state determines 805 to resume the active state (i.e., initiates an RRC connection resumption procedure to transmit UL data, responds to a paging message received from the DU 174, or performs an RNAU), the UE 102 determines 879C the difference between the full TA value currently applied by the UE (i.e., the second full TA value) and (i.e., Fig. 8A The difference between the first complete TA value reported at event 818 is less than X configured in the first TA reporting configuration. offset (i.e., the threshold criteria are not met). Therefore, unlike scenario 800A, the UE determines not to transmit the second complete TA value to the BS in the RRC connection recovery process. In view of this determination, the UE 102 initiates 828C a random access (RA) procedure with the DU 174 and selects a RA preamble group by excluding the size of the TA report MAC CE. To initiate the RA procedure, the UE 102 transmits a RA preamble belonging to the selected RA preamble group to the DU 174. In the case of a four-step RA procedure, the DU 174 transmits a RA response to the UE 102 in response to the RA preamble, wherein the RA response includes a UL grant that is used by the UE 102 to transmit 830C a UL MAC PDU (MPDU) that includes only an RRC recovery request message (e.g., an RRCResumeRequest message). In the case of a two-step RA procedure, the UE 102 uses the UL grant indicated in the system information broadcast by the DU 174 to transmit 830C a MPDU that includes only an RRC recovery request message.

[0087] Upon receiving 830C the UL MPDU including only the RRC resume request message, DU 174 transmits 832C a DU to CU message (e.g., an initial UL RRC messaging message) that forwards the RRC resume request message to CU 172. The DU to CU message further includes an IE / field "Request TA" that is used to retrieve the pre-inactive state TA information of the UE retained in the CU, i.e., requesting the first complete TA value and / or the first differential k_offset value of UE 102 from CU 174. In response to the DU to CU message, CU 172 transmits 836C a CU to DU message to DU 174 that includes the RRC message (e.g., an RRCResume message), the first complete TA value of UE 102, and / or the first differential k_offset value of UE 102. When a TA reporting configuration is included, the message may set a new TA reporting configuration for UE 102.

[0088] After receiving the CU-to-DU message at event 836C, DU 174 transmits 834C a DL MPDU including a Contention Resolution ID MAC CE to UE 102 for contention resolution, and then transmits 838C an RRC recovery message to UE 102. DU 174 may include a differential Koffset MAC CE conveying a second differential k_offset value for UE 102 in the DL MPDU transmitted at event 834C. Alternatively, DU 174 may transmit the differential Koffset MAC CE in the message transmitted at event 838C. DU 174 may transmit 834C a DL MPDU including a Contention Resolution ID MAC CE, a differential Koffset MAC CE, and an RRC recovery message to UE 102. DU 174 may determine a second differential k_offset value for UE 102 based on the first differential k_offset value received at event 836C. Alternatively, DU 174 may determine a second differential k_offset value for UE 102 based on the first full TA value and the cell-specific k_offset value received in event 836C.

[0089] Fig.8D is with Figure 8C The message passing diagram for scenario 800D is similar to scenario 800C shown in FIG. Fig.8D and Figure 8CIn scenario 800D, after transmitting 832C a DU-to-CU message including an RRC recovery request message to CU 172, DU 174 receives 836C a CU-to-DU message including an RRC recovery message that releases the previous TA report configuration (i.e., including a SetupRelease {TAR-Config} type with an option "release"). DU 174 then forwards 838D the RRC recovery message to UE 102.

[0090] After receiving the RRC recovery message, UE 102 transitions 840 to a connected state and transmits 842B a DL MPDU including only an RRC recovery complete message (e.g., an RRCResumeComplete message) to DU 174. Compared to event 842A, UE 102 in this scenario does not transmit a complete TA value in event 842B because UE 102 has discarded the TA reporting configuration. DU 174 then transmits 844 a DU to CU message (e.g., an UL RRC messaging message) that forwards the RRC recovery complete message to CU 174.

[0091] Fig.9A 900A, in which the UE 102 is configured to report the TA before entering the inactive state when moving from the initial cell (i.e., communicating with the base station 104 using the satellite 304) to the new cell (i.e., communicating with the base station 104 using the satellite 304). In this scenario 900A, the new cell does not broadcast an affirmative indication in the system information requiring the UE to report the TA when establishing / reestablishing / resuming the RRC connection with the new cell. The UE 102 initially operates in the connected state 902 and is connected to the BS 104 via a serving link for the first cell provided by the satellite 304. The UE 102 and the base station 104 then perform a procedure for obtaining a common TA, a UE-specific TA, and an N TA Process 911, and for reporting TA and obtaining differential k_offsett (ie, N TA ) process 921. Processes 911 and 921 are Fig. 8A104 is similar to processes 811 and 821 in , where BS 104 is not necessarily a distributed base station. For example, in process 921, UE 102 receives a first TA reporting configuration from BS 104 in an RRC reconfiguration message, transmits a first complete TA value to BS 104, and receives a first differential k_offset value from BS 104. After performing processes 911 and 921, UE 102 receives 924 an RRC release message from BS 104 and transitions to an inactive state in response to the RRC release message. Later, UE 102 selects or reselects a second cell (e.g., Figure 1A927 the UE 102 camping on the second cell. The BS 106 broadcasts 950 system information that does not include a positive indication for the UE to report the TA when establishing / reestablishing / resuming an RRC connection when camping on the second cell (i.e., flag_TA_report is not present or indicates a "false" value). The UE 102 camping on the second cell determines to initiate a resumption of active state via an RRC resumption procedure with the BS 106 to transmit UL data, respond to a paging message received from the BS 106, or perform a RAN notification area update. To initiate the RRC connection resumption procedure, the UE 102 initiates 928 a RA procedure (e.g., a two-step RA or a four-step RA procedure) with the BS 106 and transmits 930 an RRC resumption request message to the BS 106. In this scenario, UE 102 determines not to report the second complete TA value to BS 106 during the RRC connection recovery procedure because the system information of the new cell (satellite 306, BS 106) does not include an affirmative indication to report the TA when performing an RRC connection establishment / reestablishment / recovery procedure with the new cell. In response to selecting, reselecting, or camping on the second cell, or initiating an RRC connection recovery procedure on the second cell, UE 102 may release the first TA reporting configuration received from BS 104. Therefore, UE 102 transmits 930 to BS 106 an UL MAC PDU including an RRC recovery request message but not a TA reporting MAC CE. In response to receiving the RRC recovery request, BS 106 (or a CU of BS 106) transmits 932 a Retrieve UE Context Request message to BS 104 (or a CU of BS 104). Then, BS 106 receives 936 a Retrieve UE Context Response message from BS 104 (or from a CU of BS 104). BS 106 may include an IE / field "Request TA" in the Retrieve UE Context Request message for requesting a first complete TA value, a first differential k_offset value, and / or a first TA reporting configuration for UE 102. BS 104 may include the first complete TA value, the first differential k_offset value, and / or the first TA reporting configuration in the Retrieve UE Context Response message as a response to the IE / field "Request TA" included in the Retrieve UE Context Request message. Regardless of the content of the Retrieve UE Context Request message, BS 104 may include the first complete TA value, the first differential k_offset value, and / or the first TA reporting configuration in the Retrieve UE Context Response message. BS 106 may release the first TA reporting configuration.The BS 104 may avoid including the first TA reporting configuration in the retrieve UE context response message, and the BS 104 may release the first TA reporting configuration after transmitting the retrieve UE context response message.

[0092] After receiving the retrieve UE context response message, the BS 106 transmits 938A an RRC resume message that sets a new (i.e., second) TA reporting configuration (e.g., tar-Config) for the UE 102. The second TA reporting configuration may be similar to or different from the first TA reporting configuration. The BS 106 may generate the second TA reporting configuration based on the first TA reporting configuration, or may generate the second TA reporting configuration regardless of the first TA reporting configuration. In response to the RRC resume message, the UE 102 transitions 940 to a connected (i.e., active) state and transmits 942A an RRC resume complete message to the BS 106. The UE 102 may generate a TA report MAC CE including a second complete TA value of the UE 102 in response to the second TA reporting configuration. The UE 102 may transmit 942A an UL MPDU including the RRC resume complete message and the TA report MAC CE to the BS 106, or may transmit an UL MPDU including the TA report MAC CE to the BS 106 after transmitting the RRC resume complete message. After receiving the TA-report MAC CE from the UE 102 , the BS 106 determines a second differential k_offset value for the UE 102 , and then transmits 946 a DL MPDU including a differential Koffset MAC CE including the second differential k_offset value to the UE 102 .

[0093] Fig. 9B is with Fig.9A The message passing diagram for scenario 900B is similar to scenario 900A shown in FIG. Fig.9A and Fig. 9BAfter receiving 936 the Retrieve UE Context Response message, the BS 106 determines not to obtain TA information from the UE. In view of this determination, the BS 106 releases the first TA reporting configuration of the UE 102 in the RRC Recovery message (i.e., includes the SetupRelease {TAR-Config} type with the selection "release"). Then, the BS 106 transmits 938B the RRC Recovery message to the UE 102. In response to receiving the RRC Recovery message to release the TA reporting configuration, the UE 102 avoids reporting TA information (e.g., the second complete TA value) to the BS 106. If the UE 102 has released the first TA reporting configuration when selecting, reselecting, or camping on the second cell, or when initiating the RRC connection recovery procedure on the second cell, the BS 106 can omit the release indication in the RRC Recovery message.

[0094] Fig. 9C is with Fig.9A The message passing diagram for scenario 900C is similar to scenario 900A shown in FIG. Fig.9A and Fig. 9C In scenario 900C, the UE 102 retains the first TA reporting configuration in response to selecting, reselecting, or camping on the second cell or initiating an RRC connection recovery procedure on the second cell. In this scenario, the BS 104 includes 936 the first TA reporting configuration in the retrieve UE context response message, and the BS 106 determines to retain the first TA reporting configuration for the UE 102. Therefore, after receiving the retrieve UE context response message, the BS 106 transmits 938C an RRC recovery message to the UE 102 that does not include any TA reporting configuration (i.e., does not include tar-Config). After receiving the RRC recovery message that does not include the TA reporting configuration (e.g., in response to the RRC recovery message that does not include the TA reporting configuration), the UE 102 transitions 940 to the connected state, continues to use the first TA reporting configuration, and determines 979C whether the difference between the first complete TA value reported in process 921 and the complete TA value currently applied by the UE 102 (i.e., the second complete TA value) is equal to or greater than the threshold value X included in the first TA reporting configuration. offset In this scenario, since the TA difference is equal to or greater than (or alternatively, just greater than) the threshold value X offsetThe threshold criteria are met, and thus the UE 102 determines to report the second complete TA value to the BS 106. The UE 102 transmits 942A a UL MPDU including an RRC recovery complete message and a TA report MAC CE including the second complete TA value of the UE 102 to the BS 106. After transmitting the RRC recovery complete message, the UE 102 may transmit a UL MPDU including a TA report MAC CE to the BS 106. The BS 106 then (after receiving the TA report MAC CE from the UE 102) determines a second differential k_offset value for the UE 102 and transmits 946 a DL MPDU including a differential Koffset MAC CE to the UE 102, the differential Koffset MAC CE including the second differential k_offset value.

[0095] Fig.9D is with Fig. 9C The message passing diagram for scenario 900D is similar to scenario 900C shown in FIG. Fig. 9C and Fig.9D In scenario 900D, UE 102 determines 979D that the TA difference is less than threshold value X. offset , and therefore the UE determines not to report the second complete TA value to BS 106. In view of this determination, UE 102 transmits 942B a UL MPDU including only the RRC recovery complete message to BS 106. BS 106, after receiving the RRC recovery complete message, determines a second differential k_offset value for UE 102 based on the first differential k_offset value of UE 102 received in event 936, and then transmits 946 a DL MPDU including a differential Koffset MAC CE to UE 102, the differential Koffset MAC CE including the second differential k_offset value.

[0096] Fig. 10A 100A is a message transfer diagram for a scenario in which a UE 102 previously configured with a TA reporting configuration moves to a new cell, where the new cell broadcasts an affirmative indication in system information for the UE to report TA information when establishing / reestablishing / resuming an RRC connection with the new cell. In scenario 1000A, the UE 102 initially operates in a connected (active) state 1002, connected to a BS 104 in a first cell via a serving link provided by a satellite 304. The UE 102 and the base station 104 then perform a process for obtaining a common TA, a UE-specific TA, and an N cell. TA1021, UE 102 receives 1024 an RRC release message from BS 104 and transitions 1026 to an inactive state in response to the RRC release message. Later, UE 102 selects or reselects a second cell (e.g., a cell supported by BS 106 via satellite 306) supported by BS 106. Figure 1A 1027 on the second cell. BS 106 broadcasts 1050 system information including a positive indication for the UE to report the TA when establishing / reestablishing / resuming an RRC connection with the second cell (i.e., flag_TA_report is present and indicates a "true" value). UE 102 camping on the second cell determines 1005 to initiate an RRC connection resumption procedure with BS 106 to transmit UL data, respond to a paging message received from BS 106, or perform a RAN notification area update. After the determination, UE 102 checks the difference between the first complete TA value reported in procedure 1021 and the complete TA value currently applied by UE 102 (i.e., the second complete TA value), and determines 1079A that the difference is equal to or greater than a threshold value X included in the first TA reporting configuration. offset. Then further to events 1005 and 1079A, UE 102 initiates 1028 an ARA procedure (e.g., a two-step RA or a four-step RA procedure) and selects an RA preamble group by taking into account the size of the TA report MAC. Then, UE 102 transmits 1030A an UL MPDU including an RRC recovery request message and a TA report MAC CE including a second complete TA value to BS 106 using the UL resources obtained by initiating the RA procedure. In response to receiving the RRC recovery request message and the TA report MAC CE, BS 106 (or the CU of BS 106) transmits 1032A a retrieve UE context request message to BS 104 (or the CU of BS 104), and also transmits 1034A a DL MPDU including a contention resolution ID MAC CE to UE 102 for contention resolution. BS 106 (or a CU of BS 106) may include a differential Koffset MAC CE in the DL MPDU at event 1034A, the differential Koffset MAC CE including the second differential k_offset value. Alternatively, BS 106 (or a CU of BS 106) may transmit a differential Koffset MAC CE at event 1038A. BS 106 (or a CU of BS 106) may determine the second differential k_offset value based on the second complete TA value reported by UE 102 and the cell-specific k_offset value of the cell currently selected by UE 102 (e.g., cell 126).

[0097] In response to the RRC recovery request message, BS 104 (or a CU of BS 104) transmits 1036A a retrieve UE context response message to BS 106. BS 104 may include the first complete TA value, the first differential k_offset value, and / or the first TA reporting configuration in the retrieve UE context response message. BS 106 may release the first TA reporting configuration. BS 104 may avoid including the first TA reporting configuration in the retrieve UE context response message. Then, BS 104 may release the first TA reporting configuration in response to transmitting the retrieve UE context response message.

[0098] After receiving the retrieve UE context response message, BS 106 transmits 1038A an RRC recovery message that sets a new (i.e., second) TA reporting configuration (e.g., tar-Config) for UE 102. The second TA reporting configuration may be similar to or different from the first TA reporting configuration. That is, BS 106 may generate the second TA reporting configuration based on the first TA reporting configuration, or may generate the second TA reporting configuration regardless of the first TA reporting configuration. In some implementations, the BS does not include the TA reporting configuration in the RRC recovery message. In response to the RRC recovery message, UE 102 transitions 1040 to a connected (i.e., active) state and transmits 1042A an RRC recovery complete message to BS 106. In response to the RRC recovery message including the second TA reporting configuration or not including the TA reporting configuration, UE 102 may generate a TA report MAC CE including a third complete TA value for UE 102. UE 102 may transmit 1042A a UL MPDU including an RRC recovery complete message and a TA report MAC CE to BS 106, or may transmit a UL MPDU including a TA report MAC CE after transmitting the RRC recovery complete message to BS 106. After receiving the TA report MAC CE from UE 102, BS 106 determines a third differential k_offset value for UE 102, and then transmits 1046A a DL MPDU including a differential Koffset MAC CE to UE 102, the differential Koffset MAC CE including the third differential k_offset value.

[0099] When UE 102 has reported a second complete TA value in the same RRC recovery procedure, and the difference between the third complete TA and the second complete TA is less than X configured in the TA reporting configuration offset In response to event 1038A, UE 102 transmits 1042A to BS 106 a DL MPDU that does not include a third complete TA value.

[0100] Fig. 10B is with Fig. 10A The scenario 1000A shown in FIG. is similar to the message passing diagram for scenario 1000B. Fig. 10A and Fig. 10B In scenario 1000B, after receiving 1036A the Retrieve UE Context Response message, BS 106 (or a CU of BS 106) transmits 1038B an RRC Resume message to UE 102, which releases the first TA reporting configuration (i.e., includes a SetupRelease {TAR-Config} type with an option "release").

[0101] After receiving the RRC recovery message, UE 102 transitions 1040 to a connected (active) state and transmits 1042B a UL MPDU including only an RRC recovery complete message (e.g., an RRCResumeComplete message) to BS 106. Unlike event 1042A, UE 102 in this scenario does not transmit a complete TA value in event 1042B because UE 102 has discarded the TA reporting configuration.

[0102] Fig. 10C is with Fig. 10A The message passing diagram for scenario 1000C is similar to scenario 1000A shown in FIG. Fig. 10A and Fig. 10C After the UE 102 in the inactive state determines 1005 to resume the active state (to transmit UL data, respond to a paging message received from the BS 106, or perform RNAU), the UE 102 determines 1079C that the difference between the full TA value currently applied by the UE (i.e., the second full TA value) and the first full TA value reported in process 1021 is less than the value X configured in the TA reporting configuration. offset . Then, the UE 102 does not transmit the second complete TA value to the BS during the RRC connection recovery procedure. The UE 102 initiates 1028C a random access (RA) procedure with the BS 106 and selects a RA preamble group that does not include the size of the TA report MAC CE. The UE 102 initiates the RA procedure by transmitting a RA preamble of the selected RA preamble group to the BS 106. In the case of a four-step RA procedure, the BS 106 transmits a RA response to the RA preamble, wherein the RA response includes a UL grant that is used by the UE 102 to transmit 1030C a UL MAC PDU (MPDU) that includes only an RRC recovery request message (e.g., an RRCResumeRequest message). In the case of a two-step RA procedure, the UE 102 uses the UL grant indicated in the system information broadcast by the DU 174 to transmit 1030C an MPDU that includes only an RRC recovery request message.

[0103] After receiving the UL MPDU including only the RRC resume request message, BS 106 transmits 1032C a retrieve UE context request message to BS 104. The retrieve UE context request message further includes an IE / field "Request TA" for requesting BS 104 to provide a first (pre-inactive state) complete TA value and / or a first differential k_offset value of UE 102. In response to the retrieve UE context request message, BS 104 transmits 1036C a retrieve UE context response message including the first complete TA value of UE 102, the first differential k_offset value, and / or the first TA reporting configuration of UE 102 to BS 106. After receiving the retrieve UE context response message, BS 106 determines a second differential k_offset value for UE 102 based on the first complete TA value of UE 102 and a cell-specific k_offset value of a cell currently selected by UE 102 (e.g., cell 126). Alternatively, BS 106 determines a second differential k_offset value for UE 102 based on the first (pre-inactive state) differential k_offset value for UE 102. BS 106 then transmits 1034C a DL MPDU including a contention resolution ID MAC CE for contention resolution. BS 106 may include a differential Koffset MAC CE in the DL MPDU at event 1034C, the differential Koffset MAC CE including the second differential k_offset value for UE 102. Alternatively, BS 106 may transmit a differential Koffset MAC CE at event 1038A, wherein an RRC resume message including a second TA reporting configuration or not including a TA reporting configuration is transmitted to UE 102 in response to the RRC resume request message.

[0104] Fig. 10D is with Fig. 10C The scenario 1000C shown in FIG. is similar to the message passing diagram for scenario 1000D. Fig. 10D and Fig. 10C After receiving 1036C the Retrieve UE Context Response message from BS 104, BS 106 transmits 1038C an RRC Resume message to UE 102, which releases the previous TA reporting configuration (ie, includes a SetupRelease {TAR-Config} type with option "release").

[0105] After receiving the RRC recovery message, UE 102 transitions 1040 to a connected (active) state and transmits 1042B a UL MPDU including only an RRC recovery complete message (e.g., an RRCResumeComplete message) to BS 106. Unlike event 1042A, UE 102 in this scenario does not transmit a complete TA value in event 1042B because UE 102 has discarded the first TA reporting configuration.

[0106] Fig.11A 1 is a message passing diagram for scenario 1100A in which a UE configured with a TA reporting configuration performs a small data transfer (SDT) with a network using a one-time data transfer. In scenario 1100A, UE 102 initially operates in a connected state 1102, communicating with BS 104 via a serving link provided by satellite 304 for a first cell. Then, UE 102 and base station 104 perform a process for obtaining a common TA, a UE-specific TA, and a N TA Process 1111 (similar to 811), and process 1021 (similar to 821) for reporting TA and obtaining a differential k_offset value. In process 1121, UE 102 receives a first TA reporting configuration from BS 104 in an RRC reconfiguration message, and transmits a first complete TA value to BS 104. Then, UE 102 receives a first differential k_offset value from BS 104. After performing processes 1111 and 1121, CU 172 determines that UE 102 is data inactive (i.e., UE 102 in a connected state has no data activity with BS 104). In response to the determination, CU 172 sends 1122 a CU to DU message (e.g., a UE context release command message), which includes an RRC release message (e.g., an RRCRelease message) to trigger UE 102 to transition to an inactive state. The RRC release message may include a SuspendConfig information element (IE) that configures UE 102 to transition to an inactive state. In this case, the RRC release message further includes an SDT configuration that allows UE 102 to transmit user data in the inactive data. DU 174 then transmits 1124 the RRC release message to UE 102. DU 174 may transmit 1125 a DU to CU message including the first complete TA value and / or the first differential k-offset value of UE 102 to CU 172.

[0107] Later, in the inactive state, due to the arrival of UL traffic belonging to the SDT DRB / SRB, the UE 102 determines 1152 to perform an SDT procedure. In view of this determination, the UE 102 initiates 1128 a 2-step or 4-step random access (RA) procedure by sending an RA preamble allocated for SDT purposes to the DU 174 of the BS 104. After receiving the UL grant / resources in response to the RA preamble transmission, the UE 102 checks whether the UL grant / resources are large enough to accommodate all pending SDT data (i.e., pending UL data belonging to the SDT DRB / SRB) and the RRC resume request message. In this scenario, because the UL grant / resources are large enough to accommodate all pending SDT data and the RRC resume request, the UE 102 determines to transmit all pending SDT data at once, and therefore determines 1154A not to send a buffer status report (BSR) MAC CE in the UL grant / resources. After this determination, the UE 102 transmits 1130A to the DU 174 an MPDU including the RRC recovery request message and the pending SDT data but not including the BSR MAC CE or the TA report MAC CE.

[0108] After receiving the UL MPDU including the RRC recovery request message and the UL data, DU 174 transmits 1132 a DU to CU message (e.g., an initial UL RRC message transfer message) including the RRC recovery request message to CU 172, and then transmits 1156 the UL data to CU 172. DU 174 also transmits 1134A a DL MPDU including a contention resolution ID MAC CE to UE 102 for contention resolution. In response to the RRC recovery request message, CU 172 retrieves the context of UE 102 and transmits 1158 a CU to DU message including an RRC release message (e.g., an RRCRelease message) to DU 174, wherein the RRC release message may further include a SuspendConfig IE and an SDT configuration. Then, DU 174 transmits 1160 the RRC release message to UE 102. Although in this example, DU 174 receives the CU-to-DU message including the RRC release message after transmitting the contention resolution ID MAC CE to UE 102, it is also possible that DU 174 receives the CU-to-DU message before transmitting the contention resolution ID MAC CE to UE 102. In this case (i.e., 1158 occurs earlier than 1134A), DU 174 can transmit the contention resolution ID MAC CE together with the RRC release message to UE 102 (i.e., 1134A and 1160 can be combined). Then, UE 102 transitions 1162 to the inactive state upon receiving the RRC release message.

[0109] Fig. 11B is with Fig.11A The message passing diagram for scenario 1100B is similar to scenario 1100A shown in FIG. Fig.11A and Fig. 11B As in scenario 1100A, in scenario 1100B, upon receiving the UL grant / resources in response to the RA preamble transmission in event 1128, the UE 102 checks whether the UL grant / resources are large enough to accommodate all pending SDT data (i.e., pending UL data belonging to the SDT DRB / SRB) and the RRC resume request message. In scenario 1100B, since the UL grant / resources are not large enough to accommodate all pending SDT data and the RRC resume request, the UE 102 determines 1154B to segment the pending SDT data and sends a BSR MAC CE using the available UL grant / resources to notify the network of subsequent SDT data transmission. The UE 102 then checks 1179B whether the difference between the full TA value currently applied by the UE (i.e., the second full TA value) and the first full TA value reported in process 1121 is equal to or greater than the value X configured in the first TA reporting configuration. offsetIn scenario 1100B, since the TA difference is equal to or greater than the threshold value X offset The threshold criteria are met, so UE 102 transmits 1130B a UL MPDU including an RRC recovery request message, a BSR MAC CE, and a TA report MAC CE including a second full TA value to DU 174. If the UL grant / resources can accommodate a segment of the SDT data, UE 102 may further include the segment in the MPDU transmitted in event 1130B.

[0110] Upon receiving the UL MPDU at event 1130B, DU 174 (A) transmits 1132 a DU-to-CU message (e.g., an initial UL RRC messaging message) including an RRC recovery request message to CU 172, (B) determines a second differential k_offset value for UE 102 based on the received second complete TA value for UE 102, and (C) transmits 1134B a DL MPDU including a contention resolution ID MAC CE and a differential Koffset MAC CE including the second differential k_offset value to UE 102. If DU 174 has received a segment of SDT data at event 1130B, the segment of the SDT data may also be transmitted 1156 to CU 172.

[0111] In response to the RRCResumeRequest message, CU 172 retrieves the context of UE 102 (e.g., first / pre-inactive state TA information) and transmits 1158 a CU-to-DU message including a RRCRelease message to DU 174. The RRCRelease message may further include a SuspendConfig IE and an SDT configuration. After receiving the CU-to-DU message including the RRC release message, DU 174 transmits 1164 a PDCCH including a UL grant of the UE to UE 102 to accommodate subsequent data transmission indicated by the BSRMAC CE received in step 1130B. In response to receiving the UL grant, UE 102 rechecks whether the UL grant is large enough to accommodate all pending SDT data. In this example, because the UL grant provided in step 1164 is large enough to accommodate all pending SDT data, UE 102 determines to transmit all pending SDT data at once, and therefore determines 1166 not to send a BSR MAC CE in the UL grant. After this determination, the UE 102 transmits 1168 a UL MPDU including only the UL data and not the BSR MAC CE or the TA report MAC CE to the DU 174. After receiving the UL data, the DU 174 transmits 1170 the UL data to the CU 172 and then transmits 1160 an RRC release message to the UE 102. The UE 102 remains 1162 in an inactive state after receiving the RRC release message.

[0112] Fig. 11C is with Fig. 11B The message passing diagram for scenario 1100C is similar to scenario 1100B shown in FIG. Fig. 11C and Fig. 11B Similar to scenario 1100B, in scenario 1100C, UE 102 determines 1154B to segment the pending SDT data and sends a BSR MAC CE in the available UL grant / resources to inform the network of the subsequent SDT data transmission. UE 102 then checks whether the difference between the full TA value currently applied by the UE (i.e., the second full TA value) and the first full TA value reported in process 1121 is equal to or greater than the value X configured in the first TA reporting configuration. offset Unlike scenario 1100B, since the TA difference in 1179C is less than the threshold value X offset, therefore the TA difference does not meet the threshold criteria, and the UE transmits 1130C a UL MPDU including an RRC recovery request message and a BSR MAC CE (i.e., not including a TA report MAC CE) to DU 174. If the UL grant / resources can accommodate segmentation of the SDT data, the UE 102 may further include such segmentation in the MPDU transmitted in event 1130C.

[0113] Upon receiving the UL MPDU in event 1130C, DU 174 transmits 1132C a DU-to-CU message (e.g., an initial UL RRC messaging message) including an RRC recovery request message to CU 172. The DU-to-CU message further includes an IE / field "Request TA" for requesting a first complete TA value and / or a first differential k_offset value for UE 102 from CU 174.

[0114] In response to the DU to CU message, CU 172 transmits 1158C a CU to DU message including an RRC release message (e.g., an RRCRelease message), a first complete TA value of UE 102, and / or a first differential k_offset value of UE 102 to DU 174, wherein the RRC release message may also include a SuspendConfig IE and an SDT configuration.

[0115] After receiving the CU-to-DU message at event 1158C, DU 174 transmits 1134C a DL MPDU including a contention resolution ID MAC CE to UE 102 for contention resolution, and then transmits 1164 a PDCCH providing an UL grant for the UE to UE 102. DU 174 may include a differential Koffset MAC CE in the DL MPDU at event 1134C that communicates a second differential k_offset value for UE 102, wherein the second differential k_offset value is determined based on the first differential k_offset value or the first complete TA value received at event 1158C.

[0116] Fig. 12A 1200A is a message passing diagram for a scenario in which a UE configured with a TA reporting configuration moves to a new cell and performs an SDT procedure with the new cell. In this scenario, the new cell broadcasts a positive indication in the system information for the UE to report TA information when establishing / reestablishing / resuming an RRC connection with the new cell. The UE 102 initially operates in a connected state 1202 and is connected to the BS 104 via a serving link provided by the satellite 304 for the first cell. The UE 102 and the base station 104 then perform a procedure for obtaining a common TA, a UE-specific TA, and an N TA1221, UE 102 receives 1224 an RRC Release message from BS 104 and transitions 1226 to an inactive state in response to the RRC Release message. The RRC Release message in event 1224 may further include a suspendConfig IE and an SDT configuration. Later, UE 102 selects or reselects a second cell supported by BS 106 (e.g., Figure 1A The BS 106 locates a cell 126 in the second cell and resides 1227 on the second cell, the BS 106 broadcasts 1250 system information including a positive indication (ie, flag_TA_report exists and indicates a "true" value) for the UE to report the TA when establishing / reestablishing / resuming an RRC connection with the second cell.

[0117] After camping on the second cell, due to the arrival of UL traffic belonging to the SDT DRB / SRB, the UE 102 determines 1252 to perform an SDT procedure. In view of this determination, the UE 102 initiates 1228 a 2-step or 4-step random access (RA) procedure by sending an RA preamble allocated for SDT purposes to the BS 106. After receiving the UL grant in response to the RA preamble transmission, the UE 102 determines whether the UL grant / resources are large enough to accommodate all pending SDT data (i.e., pending UL data belonging to the SDT DRB / SRB) and the RRC resume request message. In this example, since the UL grant / resources are not large enough to accommodate all pending SDT data and the RRC resume request, the UE 102 determines 1254 to segment the pending SDT data and send a BSR MAC CE in the UL grant / resources to notify the network of subsequent SDT data transmission. Then, the UE 102 checks whether the difference between the full TA value currently applied by the UE (ie, the second full TA value) and the first full TA value reported in process 1221 is equal to or greater than the value X configured in the first TA reporting configuration. offset In this scenario, since the 1279A TA difference is equal to or greater than the threshold value X offset(i.e., the threshold criteria are met), so the UE transmits 1230A to the BS 106 an UL MPDU including an RRC recovery request message, a BSR MAC CE, and a TA report MAC CE including a second complete TA value. If the UL grant / resources can accommodate segmentation of the SDT data, the UE 102 may further include such segmentation in the MPDU transmitted in event 1230A.

[0118] Upon receiving the UL MPDU at event 1230A, BS 106 (A) transmits 1232A a Retrieve UE Context Request message to BS 104, (B) determines a second differential k_offset value for UE 102 based on the received second complete TA value for UE 102, and (C) transmits 1234A a DL MPDU including a Contention Resolution ID MAC CE and a Differential Koffset MAC CE including the second differential k_offset value to UE 102. In response to the Retrieve UE Context Request message, BS 104 returns the context of UE 102 by transmitting 1236A a Retrieve UE Context Response message that does not include the pre-inactive state TA information of the UE.

[0119] After receiving the retrieve UE context response message, BS 106 transmits 1264 a PDCCH providing an UL grant for the UE to UE 102, because BS 106 already knows that UE 102 needs subsequent data transmission after receiving the BSR MAC CE in step 1230A. In response to receiving the UL grant, UE 102 rechecks whether the UL grant is large enough to accommodate all pending SDT data. Because the UL grant provided in step 1264 is large enough to accommodate all pending SDT data, UE 102 determines 1266 to transmit all pending SDT data at once, and therefore determines 1266 not to send a BSR MAC CE in the UL grant. After this determination, UE 102 transmits 1268 a UL MPDU including only UL data but not a BSR MAC CE or a TA report MAC CE to BS 106. After receiving the UL data, the BS 106 transmits 1260 an RRC release message to the UE 102, wherein the RRC release message may further include the SuspendConfig IE and the SDT configuration. The UE 102 remains 1262 in an inactive state after receiving the RRC release message.

[0120] Fig. 12B is with Fig. 12A The message passing diagram for scenario 1200B is similar to scenario 1200A shown in FIG. Fig. 12B and Fig. 12ASimilar to scenario 1200A, in scenario 1200B, UE 102 determines 1254 to segment pending SDT data and sends a BSR MAC CE in the available UL grant / resources to inform the network of subsequent SDT data transmission. After this determination, UE 102 checks whether the difference between the full TA value currently applied by the UE (i.e., the second full TA value) and the first full TA value reported in process 1221 is equal to or greater than the value X configured in the first TA reporting configuration. offset In this scenario, since the 1279B TA difference is less than the threshold value X offset (i.e., the threshold criteria are not met), the UE transmits 1230B a UL MPDU including an RRC recovery request message and a BSR MAC CE (i.e., excluding a TA report MAC CE) to the BS 106. If the UL grant / resources can accommodate the segmentation of the SDT data, the UE 102 may further include the segmentation in the MPDU transmitted in event 1230B.

[0121] After receiving the UL MPDU in event 1230B, BS 106 transmits 1232B a retrieve UE context request message to BS 104. The retrieve UE context request message further includes an IE / field "Request TA" for requesting the first complete TA value and / or the first differential k_offset value of UE 102 from BS 104.

[0122] In response to the retrieve UE context request message, BS 104 transmits 1236B to BS 106 a retrieve UE context response message including the first complete TA value of UE 102 and / or the first differential k_offset value of UE 102. Upon receiving the retrieve UE context response message in event 1236B, BS 106 transmits 1234B to UE 102 a DLMPDU including a contention resolution ID MAC CE for contention resolution, and then transmits 1264 to UE 102 a PDCCH for scheduling UL grant for the UE. In some implementations, BS 106 may include in the DL MPDU, at event 1234B, a Differential Koffset MAC CE that includes a second differential k_offset value for UE 102, wherein the second differential k_offset value is determined based on the first (pre-inactive state) full TA value received at event 1236B and a cell-specific k_offset value for a cell (e.g., cell 126) selected by UE 102. In some implementations, the second different k_offset value transmitted at event 1234B is determined by BS 106 based on the first (pre-inactive state) differential k_offset value for UE 102 received at event 1236B.

[0123] Fig.13 is with Fig. 12A The message passing diagram of scenario 1300 is similar to scenario 1200A shown in FIG. Fig.13 and Fig. 12A Similar to 1227, in scenario 1300, UE 102 selects or reselects a second cell supported by BS 106 (e.g., Figure 1A 1254) and camps 1327 on the second cell. Unlike scenario 1200A, in scenario 1300, BS 106 broadcasts 1350 system information that does not include an affirmative indication for the UE to report the TA when establishing / reestablishing / resuming an RRC connection with the second cell (i.e., flag_TA_report is absent or indicates a "false" value). Therefore, UE 102 does not report its full TA to BS 106, and subsequently it does not receive a second differential k_offset value for the upcoming SDT procedure from BS 106. Therefore, after a determination 1354 similar to 1254, UE 102 does not check whether the difference between the full TA value currently applied by the UE (i.e., the second full TA value) and the first full TA value reported in process 1321 has exceeded the value X configured in the first TA reporting configuration. offset. Further, UE 102 does not include the TA report MAC CE in the RRCResume message, and then UE 102 will not receive the differential Koffset MAC CE in event 1334.

[0124] Fig.14A 14 is a flow chart of a method 1400A performed by a UE (e.g., UE 102) for reporting TA and obtaining a differential k_offset value during an RRC recovery procedure according to an embodiment. Initially, the UE receives 1404 system information including a cell-specific k_offset value from a BS. Then, the UE receives 1416 an RRC message (e.g., RRCReconfiguration) from the BS containing a TA reporting configuration including a TA threshold value X offset In response to the TA reporting configuration, the UE transmits 1418 to the BS a TA reporting MAC CE including a first complete TA value currently applied by the UE when performing UL transmission. After transmitting the TA reporting MAC CE, the UE receives 1420 from the BS a differential Koffset MAC CE including a first differential k_offset value. Operations 1416, 1418, and 1420 are grouped together and collectively referred to as a process 1421 for "reporting TA and obtaining differential k_offset".

[0125] Later, after receiving the differential Koffset MAC CE from the BS, the UE receives 1424 an RRC message for suspending the RRC connection (e.g., an RRCRelease message with a suspendConfig IE). The UE then suspends all SRBs / DRBs, resets its MAC layer, retains the TA reporting configuration including the first complete TA value, and transitions to the inactive state at block 1426. Operations 1424 and 1426 are grouped together and collectively referred to as a process 1480 for "transitioning to the inactive state."

[0126] Later, after transitioning to the inactive state, the UE determines 1405 to initiate an RRC connection recovery procedure when it is paged, detects MO data arrival, or performs RNAU.

[0127] Then, the UE determines 1479A that the difference between the TA currently applied by the UE (ie, the second complete TA) and the first complete TA is equal to or greater than X. offsetvalue (TA threshold included in the TA reporting configuration). In view of the determination, the UE selects 1428A a preamble group taking into account the size of the TA reporting MAC CE and initiates a RA procedure for resuming the RRC connection based on the selected preamble group. The UE transmits 1430A an UL MPDU including an RRC recovery request message and a TA reporting MAC CE to the BS in a MSG3 grant or in a MSGA PUSCH resource, wherein the TA reporting MAC CE conveys the second complete TA value of the UE.

[0128] The UE then receives 1434 from the BS a Contention Resolution ID MAC CE repeating the first / upper 40 bits of the RRC Recovery Request message transmitted at 1430A and a Differential Koffset MAC CE containing the second differential k_offset value.

[0129] Finally, the UE receives 1438 an RRC resume message including a configuration for resuming the UE connection from the BS. Operations 1479A, 1428A, 1430A, 1434, and 1438 are grouped together and collectively referred to as a process 1481 for "obtaining a second differential k_offset by reporting a second complete TA."

[0130] Fig. 14B 14 is a flow chart of a method 1400B performed by a UE (eg, UE 102) for obtaining a differential k_offset value in an RRC recovery procedure without reporting a second complete TA according to another embodiment. Fig.14A Similar to the method 1400A shown in , in the method 1400B, the UE first receives 1404 system information including a cell-specific k_offset value from the BS. Then, the UE performs a process 1421 for reporting the TA and obtaining the differential k_offset, thereby obtaining a first differential k_offset value.

[0131] The UE further performs a process 1480 for transitioning to an inactive state. In the inactive state, the UE determines 1405 to initiate an RRC connection recovery process when being paged, detecting the arrival of MO data, or performing RNAU. Then, the UE determines 1479B that the difference between the TA currently applied by the UE (i.e., the second complete TA) and the first complete TA is less than X. offset value (TA threshold included in the TA reporting configuration). Further, the UE selects 1428B a preamble group that does not include the size of the TA reporting MAC CE and initiates a RA procedure for recovering the RRC connection based on the selected preamble group. In view of the determination 1479B, the UE transmits 1430B only a single RRC recovery request message to the BS in a MSG3 grant or in a MSGA PUSCH resource.

[0132] As in method 1400A, in method 1400B, the UE then receives 1434 from the BS a contention resolution ID MAC CE repeating the first / highest 40 bits of the RRC recovery request message transmitted at 1430B and a differential Koffset MAC CE containing a second differential k_offset value. Finally, the UE receives 1438 from the BS an RRC recovery message for recovering the UE's connection. Operations 1479B, 1428B, 1430B, 1434, and 1438 are grouped together and collectively referred to as a process 1482 for "obtaining a second differential k_offset without reporting a second complete TA."

[0133] Fig.15 1 is a flow chart of a method 1500 performed by a UE (e.g., UE 102) for determining whether to report a TA upon receiving an RRC recovery message according to an embodiment. Similar to operation 1404, first, the UE receives 1504 system information including a cell-specific k_offset value from a BS. Then, the UE performs a process 1421 for reporting a TA and obtaining a differential k_offset, thereby obtaining a first differential k_offset value.

[0134] Then, the UE performs a process 1480 for transitioning to an inactive state. In the inactive state, the UE determines 1505 to initiate an RRC connection recovery process when being paged, detecting the arrival of MO data, or performing RNAU. Then, the method 1500 determines whether the TA difference has exceeded the X configured in the TA reporting configuration. offset The value is used to continue process 1481 or 1482. After completing process 1481 or 1482, the UE determines 1539 whether the RRC resume message received at the end of 1481 or 1482 releases the TA reporting configuration.

[0135] If the UE determines that the RRC recovery message does not release the TA report configuration (i.e., the No branch of 1539, for example, the RRC recovery message includes the SetupRelease {TAR-Config} type with the option 'setup', or does not include the tar-Config IE), the UE transmits 1542A to the BS an UL MPDU including the RRC recovery complete message and the TA report MAC CE including the complete TA value currently applied by the UE. The UE then receives 1546A from the BS a differential Koffset MAC CE including the UE's third differential k_offset value.

[0136] On the other hand, if the UE determines that the RRC recovery message does release the TA reporting configuration (ie, the yes branch of 1539, e.g., the RRC recovery message includes the SetupRelease {TAR-Config} type with the option "release"), the UE transmits 1542B to the BS a UL MPDU including only the RRC recovery complete message.

[0137] Processes and operations 1481 / 1482, 1539, 1542A, 1542B, and 1546A are grouped together and collectively referred to as process 1584 for "reporting TA and obtaining differential k_offset during RRC recovery procedure."

[0138] Fig.16 1 is a flow chart of a method 1600 performed by a UE (e.g., UE 102) for determining whether to report a TA in an RRC recovery procedure based on an indication broadcast in system information according to an embodiment. Similar to operations 1404 and 1504, the UE first receives 1604 system information including a cell-specific k_offset value from a BS. Then, the UE performs a process 1421 for reporting a TA and obtaining a differential k_offset, thereby obtaining a first differential k_offset value. Further, the UE performs a process 1480 for transitioning to an inactive state.

[0139] In the inactive state, the UE determines 1605 (similar to 1405 and 1505) to initiate the RRC connection recovery procedure when being paged, detecting the arrival of MO data, or performing RNAU. Then, the UE receives 1650 system information including a positive indication for reporting the TA during the RRC connection establishment / reestablishment / recovery procedure from the BS. Finally, the UE performs the Fig.15 Process 1584 is shown in FIG.

[0140] Fig.17 17 is a flowchart of method 1700 performed by a UE (e.g., UE 102) according to an embodiment for determining whether to report a TA during an RRC recovery process based on an indication broadcast in system information and also based on whether the UE remains in the same cell as before entering an inactive state (e.g., its RRC connection is suspended).

[0141] Fig.17 Method 1700 and Fig.16 The method 1600 in is similar. Fig.17 and Fig.16difference between. After 1704 (similar to 1404, 1504 and 1604), processes 1421 and 1480, the UE determines 1705 to initiate an RRC connection recovery procedure. Then, the UE does not directly proceed to operation 1750 (similar to 1650), but checks 1727 whether the UE is to be connected via another cell different from the anchor cell used before entering the inactive state. If the UE has moved to another cell (i.e., the yes branch of 1727), the UE proceeds to 1750, which is similar to 1650 of method 1600. On the other hand, if the UE is reconnected to the anchor cell (i.e., the no branch of 1727), the UE performs process 1584 for reporting TA and obtaining differential k_offset in the RRC recovery process (regardless of whether the system information includes a positive indication for reporting TA).

[0142] Fig.18 18 is a flow chart of a method 1800 performed by a UE (e.g., UE 102) for determining whether to report its TA during an SDT process according to an embodiment. Initially, the UE receives 1804 system information including a cell-specific k_offset value from a BS. Then, the UE performs a process 1421 for reporting the TA and obtaining a differential k_offset, thereby obtaining a first differential k_offset value. The UE performs a process 1480 for transitioning to an inactive state.

[0143] In the inactive state, when UL data belonging to the SDT DRB / SRB arrives, the UE initiates 1828 a random access procedure for performing SDT in the inactive state. After initiating the RA procedure, the UE receives 1891 UL resources from the BS and then constructs an RRC recovery request message. The UE then checks 1854 whether the UL resources (e.g., MSG3 grant or MSGA PUSCH resources) are large enough to transmit all pending SDT data.

[0144] If the UE determines that the UL resources are insufficient to transmit all pending SDT data (ie, the No branch of 1854), the UE optionally constructs 1892 a TA report MAC CE including a second complete TA value. If the UE has reported its TA in the ongoing SDT procedure and the TA difference does not exceed the threshold value X offset , the UE skips operation 1892 and performs only operation 1893. The UE segments the SDT data to be processed and constructs 1893 a BSR MAC CE, which is then sent to the multiplexer. The UE then constructs 1894A a UL MPDU from the multiplexer that can fit into the UL resources obtained in block 1891. The UE then transmits 1830A a UL MPDU to the BS.

[0145] After the UE has transmitted the TA report MAC CE to the BS, the UE may receive 1834 a differential Koffset MAC CE from the BS containing the second differential k_offset value. After operation 1834 (or 1830A if 1834 is skipped), the UE receives 1864 an UL grant from the BS for transmitting pending SDT data. Thereafter, the method loops back to decision block 1854.

[0146] On the other hand, if the UE determines 1854 that the UL resources are large enough to transmit all pending SDT data (i.e., the yes branch of 1854), the UE constructs 1894B a UL MPDU including all pending SDT data, and then transmits 1830B the constructed UL MPDU to the BS. Finally, the UE receives 1860 an RRC message (e.g., RRCRelease or RRCResume message) from the BS to terminate the small data transmission process.

[0147] Operations 1891, 1854, 1892, 1893, 1894A, 1830A, 1834, 1864, 1894B, 1830B, and 1860 are grouped together and collectively referred to as a process 1885 for "reporting TA during SDT process."

[0148] Fig.19 19 is a flow chart of a method 1900 performed by a UE (e.g., UE 102) for determining whether to report a TA during an SDT process based on whether the UE remains in an anchor cell to which it was connected before entering an inactive state according to an embodiment. Initially, the UE receives 1904 system information including a cell-specific k_offset value from a BS. Then, the UE performs a process 1421 for reporting a TA and obtaining a differential k_offset, thereby obtaining a first differential k_offset value.

[0149] Then, the UE performs a procedure for transitioning to the inactive state 1480. In the inactive state, when UL data belonging to the SDT RB / SRB arrives, the UE initiates 1928 the RA procedure by sending the RA preamble allocated for SDT purposes. Thereafter, the UE checks 1927 whether it uses the anchor cell or another cell to resume connection with the RAN.

[0150] If the UE determines that it still stays / remains in the anchor cell (ie, the No branch of 1927 ), the UE performs a procedure 1885 for reporting the TA in the SDT procedure.

[0151] On the other hand, if the UE determines that it has moved to another cell different from the anchor cell (ie, the yes branch of 1927 ), the UE performs 1986 a modified version of process 1885 that does not include optional operations 1892 and 1834 .

[0152] Fig. 20 is a flow chart of a method 2000 performed by a UE (eg, UE 102) for determining whether to report a TA during an SDT process based on an indication broadcast in system information and also based on whether the UE remains in an anchor cell used before entering an inactive state according to an embodiment. Fig. 20 The method in 2000 and Fig.19 The method 1900 in is similar. Fig. 20 and Fig.19 When the UE determines 2027 that it has moved to another cell (which is a branch) different from the anchor cell, the UE checks 2050 whether the system information broadcast by the new cell includes a positive indication for reporting the TA.

[0153] When the UE determines 2050 that the system information includes a positive indication for reporting the TA, the UE performs a procedure 1885 for reporting the TA in the SDT procedure (in Fig.18 On the other hand, when the UE determines 2050 that the system information does not include a positive indication for reporting the TA, the UE performs 2085 a version of process 1885 that does not include operations 1892 and 1834.

[0154] Fig.21 is a flow chart of a method 2100 performed by a UE (eg, UE 102) for determining not to report a TA during an SDT procedure according to an embodiment. Fig.21 Method 2100 and Fig.18 The method 1800 in is similar. Fig.21 and Fig.18 After initiating the RA procedure 2128, the UE performs a version of the procedure 1885 without operations 1892 and 1834 (ie, the UE does not report a TA value nor receive a differential k_offset value during the SDT procedure).

[0155] Fig. 22 2200 is a flow chart of a wireless communication method 2200 performed by a UE according to an embodiment. The method 2200 includes: after the UE in an inactive state is connected to the RAN via the NTN, determining 2205 (similar to 1405, 1505, etc.) to restore the connection with the RAN. The method 2200 further includes: during the process for restoring the connection, selectively transmitting 2230 (similar to 1430A, 1430B, 1539, 1727, etc.) a TA report based on a predetermined rule.

[0156] Fig.23 23 is a flowchart of a wireless communication method 2300 performed by a UE according to another embodiment. The method 2300 includes: when the UE is in an inactive state after connecting via a non-terrestrial network, without restoring the connection to the radio access network RAN, during a small data transmission SDT process, based on an evaluation of a predetermined rule, selectively transmitting 2354 (similar to 1854, 1927, etc.) a TA report to the RAN according to a predetermined rule.

[0157] Fig.24 1 is a block diagram of a wireless communication device 2400 (e.g., UE 102) configured to perform the above-described method for selectively transmitting a TA report during a process for restoring a RAN connection and / or during an SDT process according to an embodiment. The wireless communication device 2400 includes an antenna 2402 connected to a radio frequency (RF) front end 2404, and at least one RF transceiver (such as an LTE transceiver 2406, a 5G NR transceiver 2408, or another transceiver) for connecting and communicating via a RAN (NTN). The antenna and the RF front end may be tuned to, for example, one or more frequency bands (e.g., subcarriers) as defined by 3GPP LTE, 5G NR, and 6G communication standards and implemented by corresponding transceivers. The wireless communication device 2400 also includes one or more processors 2410, and a computer-readable storage medium CRM 2412. The processor 2410 may be a single-core processor or a multi-core processor, and the CRM 2412 includes any suitable memory / storage other than a propagated signal. For example, memory / storage may include random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), and / or flash memory that may be used to store device data 2414 and TA reporting manager 2416 for implementing the various techniques described in this document. CRM 2412 stores instructions executable by processor 2410 to facilitate user plane communications, control plane signaling, and user interaction. TA reporting manager 2416, which may be implemented not only as software but also as hardware logic and / or circuitry, causes various steps and actions associated with TA reporting.

[0158] In the above figure, the description for one of the above figures may apply to the other in the above figure. Any of the above events or operations may be optional. For example, events or operations with dashed lines may be optional. In some implementations, "message" is used, and "information element (IE)" may be substituted for "message", and vice versa. In some implementations, "IE" is used, and "field" may be substituted for "IE", and vice versa. In some implementations, "configuration" or "configuration parameter" may be substituted for "configuration", and vice versa.

[0159] The user device (e.g., UE 102) in which the technology of the present disclosure can be implemented can be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile game console, a point of sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smart watch, a wireless hotspot, a femtocell or a broadband router. Further, in some cases, the user device can be embedded in an electronic system, such as a head unit of a vehicle or an advanced driver assistance system (ADAS). Further, the user device can be operated as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0160] Certain embodiments are described in the present disclosure as including logic or multiple components or modules. A module may be a software module (e.g., a code or machine-readable instruction stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit that is capable of performing certain operations and may be configured or arranged in a particular manner. A hardware module may include a dedicated circuit system or logic that is permanently configured to perform certain operations (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.). A hardware module may also include programmable logic or circuit systems that are temporarily configured by software to perform certain operations (e.g., as contained in a general-purpose processor or other programmable processor). The decision to implement a hardware module with a dedicated and permanently configured circuit system or with a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

[0161] When implemented in software, the techniques may be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software may be executed by one or more general-purpose processors or one or more special-purpose processors.

Claims

1. A wireless communication method (2200) performed by a user equipment UE, the method comprising: When in an inactive state after being connected to a radio access network RAN ​​via a non-terrestrial network, determining (2205) to restore connection with the RAN; as well as Based on an evaluation of a predetermined rule, a timing advance TA report is selectively transmitted (2230) during a procedure for recovering the connection.

2. The wireless communication method according to claim 1, further comprising: Calculate the current full TA based on updating the UE-specific TA corresponding to the UE-to-satellite signal propagation, The predetermined rule requires that the TA report conveying the complete TA be transmitted when a difference between the current complete TA and a pre-inactive state complete TA stored before the UE enters the inactive state meets a threshold criterion.

3. The wireless communication method according to claim 2, further comprising: Prior to entering the inactive state, the threshold criteria are received (821) together with a TA reporting configuration for the TA report.

4. The wireless communication method according to any one of claims 1 to 3, further comprising: When the UE transmits the TA report, a preamble group to be used in a random access procedure for resuming the connection is selected by taking into account the size of the TA report.

5. The wireless communication method according to any one of claims 1 to 4, further comprising: After the UE transmits the TA report, a TA correction is received to update the complete TA.

6. The wireless communication method according to any one of claims 1 to 5, further comprising: Upon receiving a TA report configuration release, avoiding transmission of the TA report.

7. The wireless communication method according to any one of claims 1 to 5, wherein the predetermined rule requires that the TA report be transmitted after receiving a positive indication to report the TA.

8. The wireless communication method according to any one of claims 1 to 7, wherein: Determining to restore the connection with the RAN includes: System information associated with a satellite is received that is associated with another satellite that is different from the satellite used by the UE before entering the inactive state.

9. The wireless communication method according to any one of claims 1 to 8, further comprising: TA-related information is retained when entering the inactive state.

10. A wireless communication method (2300) performed by a user equipment UE, the method comprising: When the UE is in an inactive state after connecting via a non-terrestrial network, without resuming connection to a radio access network RAN, during a small data transfer SDT procedure, a timing advance TA report is selectively transmitted (2330) to the RAN based on an evaluation of a predetermined rule.

11. The wireless communication method of claim 10, wherein the predetermined rule requires selectively avoiding transmission of the TA report.

12. The wireless communication method according to claim 10, further comprising: Transmitting an SDT-specific random access RA preamble code for initiating the SDT process; as well as receiving an uplink UL resource grant in response to the SDT-specific RA preamble, The predetermined rule requires avoiding transmission of the TA report when the UL resources allocated via the UL grant are sufficient to transmit the SDT, and transmitting the TA report conveying the complete TA when the UL resources allocated via the UL grant are insufficient to transmit the SDT.

13. The wireless communication method according to claim 10, further comprising: When the UL resources allocated via the UL grant are insufficient to transmit the SDT, a complete TA is calculated based on updating a UE-specific TA corresponding to UE-to-satellite signal propagation, Wherein the predetermined rule requires that the TA report conveying the complete TA be transmitted when a difference between the complete TA and a previous complete TA reported before entering an inactive state exceeds a predetermined threshold.

14. The wireless communication method according to any one of claims 10, 12 and 13, further comprising: After determining that the SDT is transmitted via another satellite different from the satellite used by the UE before entering the inactive state, receiving satellite-related system information related to the another satellite, The predetermined rule requires avoiding transmitting the TA report when the satellite-related system information does not include a positive indication of requesting the TA report.

15. A wireless communication device (2400), comprising: A transceiver (2406, 2408), a processor (2410), and a computer-readable storage medium (2412) storing executable instructions for the processor to perform any one of the methods according to claims 1 to 14 using the transceiver.

Images