Patent Description:
Various efforts have been made to improve different aspects of wireless communication for cellular wireless communication systems, such as <NUM>th Generation (<NUM>) New Radio (NR), by improving data rate, latency, reliability, and mobility. The <NUM> NR system is designed to provide flexibility and configurability to optimize network services and types, accommodating various use cases, such as enhanced Mobile Broadband (eMBB), massive Machine-Type Communication (mMTC), and Ultra-Reliable and Low-Latency Communication (URLLC). However, as the demand for radio access continues to increase, there exists a need for further improvements in the art.

<CIT> describes methods for configurations for small data transmission by which a user equipment transmits, to a base station, user data within a random access message in a radio resource control inactive state. The user equipment may receive, via broadcast system information and/or unicast messages from the base station, a configuration on support capability or parameters for small data transmission. Based on the received configuration, the user equipment may transmit user data to the base station. The user equipment may transmit a random access preamble on a resource separately reserved for small data transmission.

<CIT> describes a method for access control in a wireless communication system are provided. The method includes while attempting to initiate an UL data transmission procedure with a serving cell during an RRC Inactive state of the UE, receiving a radio resource configuration from the serving cell and transmitting one or more UL packets to the serving cell based on the radio resource configuration when a plurality of conditions is fulfilled. The plurality of conditions includes, at least: an attempt to transmit UL data is not barred by the serving cell, and an amount of pending UL data to be transmitted is less than or equal to a data volume threshold.

<CIT> describes a method for a user equipment (UE) connected to a serving cell associated with a first satellite is provided. The method receives a measurement configuration including a plurality of synchronization signal block (SSB) measurement timing configurations (SMTCs). Each SMTC may have at least one offset value and a first SMTC in the plurality of SMTCs has a first offset value that is different from a second offset value of a second SMTC of the plurality of SMTCs. The method further receives a signal to perform a measurement procedure for a second cell associated with a second satellite and performs the measurement procedure based on the received plurality of SMTCs.

The above and other objects are achieved by a method performed by a User Equipment for mobility enhancement and a User Equipment as defined in the independent claims, respectively.

Aspects of the present disclosure are best understood from the following detailed disclosure when read with the accompanying drawings. Various features are not drawn to scale. Dimensions of various features may be arbitrarily increased or reduced for clarity of discussion.

Some of the abbreviations used in this disclosure include:.

The following contains specific information related to implementations of the present disclosure. The drawings and their accompanying detailed disclosure are merely directed to implementations. However, the present disclosure is not limited to these implementations. Other variations and implementations of the present disclosure will be obvious to those skilled in the art.

For consistency and ease of understanding, like features may be identified (although, in some examples, not illustrated) by the same numerals in the drawings. However, the features in different implementations may be different in other respects and shall not be narrowly confined to what is illustrated in the drawings.

References to "one implementation," "an implementation," "example implementation," "various implementations," "some implementations," "implementations of the present application," etc., may indicate that the implementation(s) of the present application so described may include a particular feature, structure, or characteristic, but not every possible implementation of the present application necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrase "in one implementation," or "in an example implementation," "an implementation," do not necessarily refer to the same implementation, although they may. Moreover, any use of phrases like "implementations" in connection with "the present application" are never meant to characterize that all implementations of the present application must include the particular feature, structure, or characteristic, and should instead be understood to mean "at least some implementations of the present application" includes the stated particular feature, structure, or characteristic. The term "coupled" is defined as connected, whether directly or indirectly through intervening components, and is not necessarily limited to physical connections. The term "comprising," when utilized, means "including, but not necessarily limited to"; it specifically indicates open-ended inclusion or membership in the so-described combination, group, series, and the equivalent.

The expression "at least one of A, B and C" or "at least one of the following: A, B and C" means "only A, or only B, or only C, or any combination of A, B and C. " The terms "system" and "network" may be used interchangeably. The term "and/or" is only an association relationship for describing associated objects and represents that three relationships may exist such that A and/or B may indicate that A exists alone, A and B exist at the same time, or B exists alone. The character "/" generally represents that the associated objects are in an "or" relationship.

For the purposes of explanation and non-limitation, specific details, such as functional entities, techniques, protocols, and standards, are set forth for providing an understanding of the disclosed technology. In other examples, detailed disclosure of well-known methods, technologies, systems, and architectures are omitted so as not to obscure the present disclosure with unnecessary details.

Persons skilled in the art will immediately recognize that any network function(s) or algorithm(s) disclosed may be implemented by hardware, software, or a combination of software and hardware. Disclosed functions may correspond to modules which may be software, hardware, firmware, or any combination thereof.

A software implementation may include computer executable instructions stored on a computer-readable medium, such as memory or other type of storage devices. One or more microprocessors or general-purpose computers with communication processing capability may be programmed with corresponding executable instructions and perform the disclosed network function(s) or algorithm(s).

The microprocessors or general-purpose computers may include Application-Specific Integrated Circuits (ASICs), programmable logic arrays, and/or one or more Digital Signal Processor (DSPs). Although some of the disclosed implementations are oriented to software installed and executing on computer hardware, alternative implementations implemented as firmware, as hardware, or as a combination of hardware and software are well within the scope of the present disclosure. The computer-readable medium includes but is not limited to Random Access Memory (RAM), Read Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory, Compact Disc Read-Only Memory (CD-ROM), magnetic cassettes, magnetic tape, magnetic disk storage, or any other equivalent medium capable of storing computer-readable instructions.

A radio communication network architecture such as a Long-Term Evolution (LTE) system, an LTE-Advanced (LTE-A) system, an LTE-Advanced Pro system, or a <NUM> NR Radio Access Network (RAN) typically includes at least one base station (BS), at least one UE, and one or more optional network elements that provide connection within a network. The UE communicates with the network such as a Core Network (CN), an Evolved Packet Core (EPC) network, an Evolved Universal Terrestrial RAN (E-UTRAN), a <NUM> Core (5GC), or an internet via a RAN established by one or more BSs.

A UE may include, but is not limited to, a mobile station, a mobile terminal or device, or a user communication radio terminal. The UE may be a portable radio equipment that includes, but is not limited to, a mobile phone, a tablet, a wearable device, a sensor, a vehicle, or a Personal Digital Assistant (PDA) with wireless communication capability. The UE is configured to receive and transmit signals over an air interface to one or more cells in a RAN.

The BS may be configured to provide communication services according to at least a Radio Access Technology (RAT) such as Worldwide Interoperability for Microwave Access (WiMAX), Global System for Mobile communications (GSM) that is often referred to as <NUM>, GSM Enhanced Data rates for GSM Evolution (EDGE) RAN (GERAN), General Packet Radio Service (GPRS), Universal Mobile Telecommunication System (UMTS) that is often referred to as <NUM> based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), LTE, LTE-A, evolved LTE (eLTE) that is LTE connected to 5GC, NR (often referred to as <NUM>), and/or LTE-A Pro. However, the present disclosure is not limited to these protocols.

The BS may include, but is not limited to, a node B (NB) in the UMTS, an evolved node B (eNB) in LTE or LTE-A, a radio network controller (RNC) in UMTS, a BS controller (BSC) in the GSM/GERAN, an ng-eNB in an Evolved Universal Terrestrial Radio Access (E-UTRA) BS in connection with 5GC, a next generation Node B (gNB) in the <NUM>-RAN, or any other apparatus capable of controlling radio communication and managing radio resources within a cell. The BS may serve one or more UEs via a radio interface.

Each cell (often referred to as a serving cell) provides services to serve one or more UEs within its radio coverage such that each cell schedules the DL and optionally UL resources to at least one UE within its radio coverage for DL and optionally UL packet transmissions. The BS may communicate with one or more UEs in the radio communication system via the plurality of cells.

A cell may allocate sidelink (SL) resources for supporting Proximity Service (ProSe) or Vehicle to Everything (V2X) service. Each cell may have overlapped coverage areas with other cells.

In Multi-RAT Dual Connectivity (MR-DC) cases, the primary cell of a Master Cell Group (MCG) or a Secondary Cell Group (SCG) may be called a Special Cell (SpCell). A Primary Cell (PCell) may refer to the SpCell of an MCG. A Primary SCG Cell (PSCell) may refer to the SpCell of an SCG. MCG may refer to a group of serving cells associated with the Master Node (MN), including the SpCell and optionally one or more Secondary Cells (SCells). An SCG may refer to a group of serving cells associated with the Secondary Node (SN), including the SpCell and optionally one or more SCells.

As previously disclosed, the frame structure for NR supports flexible configurations for accommodating various next generation (e.g., <NUM>) communication requirements, such as Enhanced Mobile Broadband (eMBB), Massive Machine Type Communication (mMTC), and Ultra-Reliable and Low-Latency Communication (URLLC), while fulfilling high reliability, high data rate, and low latency requirements. The Orthogonal Frequency-Division Multiplexing (OFDM) technology in the 3GPP may serve as a baseline for an NR waveform. The scalable OFDM numerology, such as adaptive sub-carrier spacing, channel bandwidth, and Cyclic Prefix (CP), may also be used.

At least DL transmission data, a guard period, and a UL transmission data should be included in a transmission time interval (TTI) of a single NR frame. The respective portions of the DL transmission data, the guard period, and the UL transmission data should also be configurable based on, for example, the network dynamics of NR. SL resources may also be provided in an NR frame to support ProSe services or V2X services.

Any two or more than two of the following paragraphs, (sub)-bullets, points, actions, behaviors, terms, or claims described in the present disclosure may be combined logically, reasonably, and properly to form a specific method.

Any sentence, paragraph, (sub)-bullet, point, action, behaviors, terms, or claims described in the present disclosure may be implemented independently and separately to form a specific method.

Dependency, e.g., "based on", "more specifically", "preferably", "in one embodiment", "in some implementations", etc., in the present disclosure is just one possible example which would not restrict the specific method.

"A and/or B" in the present disclosure may refer to either A or B, both A and B, at least one of A and B.

The introduction of NTNs into the 3GPP <NUM> NR/E-UTRA system aims to enhance <NUM> communications. However, this introduction brings forth various technical challenges that require attention for seamless integration with existing <NUM> systems, including TNs. This disclosure outlines analysis, and proposed solutions, for:.

It should be noted that this disclosure is, however, not limited to the NTN-TN integration, or to the UE mobility enhancements.

In some implementations, a UE may have different UE capabilities for the TN and the NTN. For example, depending on the UE capability, the UE may support initiating/performing an SDT procedure associated with a TN cell selected by the UE, but may not support initiating/performing the SDT procedure associated with an NTN cell selected by the UE. In another example, the UE may support initiating/performing the SDT procedure associated with the NTN cell, but not for the TN cell. In some implementations, the UE may further report the different UE capabilities to the serving RAN (e.g., via UE Assistance Information transmission in the uplink transmission while the serving RAN of the UE changes from a TN to an NTN or vice versa). In some implementations, the UE may have the same UE capabilities towards TN/NTN but the UE's capability (to one specific function, such as whether the UE supports RRC Inactive state or Small Data Transmission) may change with time. Under such a condition, the UE may also report the latest UE capabilities to the serving RAN (e.g., to a serving TN cell or NTN cell). In some implementations, the UE may need to report the functionality which the UE does not support to the serving RAN.

The IE NTN-Parameters may be used to convey a subset of the UE Radio Access Capability Parameters that are applicable to the NTN access when the parameters differ from those that are applicable to the TN access. Table <NUM> below presents an example of the data structure of the IE NTN-Parameters, which is represented using ASN.

The descriptions for the fields presented in the IE NTN-Parameters are provided in Table <NUM> below.

It should be noted that in the present disclosure, certain parameters/fields are appended with suffixes like "-r17" or "-r16" to indicate their correspondence with specific 3GPP technical specification versions (e.g., mac-ParametersNTN-r17, fdd-Add-UE-NR-CapabilitiesNTN-r17, ue-BasedPerfMeas-Parameters-r16, etc.). References to the parameters/fields without such suffixes are to be understood as equally applicable to the corresponding parameters/fields that include the suffixes. For example, the mac-ParametersNTN in Table <NUM> can also refer to the mac-ParametersNTN-r17 in Table <NUM>, the fdd-Add-UE-NR-CapabilitiesNTN in Table <NUM> can also refer to the fdd-Add-UE-NR-CapabilitiesNTN-r17 in Table <NUM>, and so on.

In some implementations, a UE may receive an SDT configuration (e.g., SDT-config) from its serving cell (e.g., a TN cell) via DL control signaling, such as through an RRC Release message. The SDT configuration may enable the UE to implement an SDT procedure. However, challenges may arise when the UE transitions from a TN cell to an NTN cell. Specifically, the UE might retain the original SDT configuration (e.g., by storing the SDT configuration at the UE side) but may be incapable of initiating an SDT procedure that is compatible with the new serving NTN cell. In the present disclosure, an SDT procedure may include at least one of the following: a CG-based SDT (CG-SDT) procedure, an RA-based SDT (RA-SDT) procedure, and an SRB-based SDT (SRB-SDT) procedure.

<FIG> is a diagram illustrating the transition of a UE from a TN cell to an NTN cell, according to an example implementation of the present disclosure. As illustrated in <FIG>, UE <NUM> may first receive a (UE-specific) SDT configuration (e.g., SDT-config) from its serving TN cell <NUM> through UE-specific control signaling (e.g., an RRC Release message, which also refers to an "RRCRelease message" in the present disclosure). Subsequently, UE <NUM> may transition from the coverage area of TN cell <NUM> to that of NTN cell <NUM>, resulting in NTN cell <NUM> becoming the current serving cell of UE <NUM>. NTN cell <NUM> may support the execution of an SDT procedure by configuring its served UE(s) (e.g., UE <NUM>) with an RA-SDT configuration (e.g., SDT-ConfigCommon) and configuring the physical resources for initiating the SDT procedure. For example, NTN cell <NUM> may broadcast the SDT configuration (e.g., SDT-ConfigCommon) in the system information, such as SIB1. In addition, according to 3GPP specifications, the UE's upper layers may be capable of initiating an SDT procedure (e.g., an RA-SDT procedure by jointly based on the random access resource included in the SDT-ConfigCommon and/or the SDT-config stored by the UE) with the serving NTN cell. An example of the conditions for initiating an SDT procedure is shown in Table <NUM> below.

In certain situations, the UE (e.g., UE <NUM>) may be incapable of initiating an SDT procedure associated with an NTN cell (e.g., NTN cell <NUM>). To address this issue, certain mechanisms are proposed below.

In some implementations, the UE may assess its own capabilities when the UE is triggered (e.g., by the NAS layer or by the RRC layer) to implement an SDT procedure. As illustrated in <FIG>, the UE may camp on an NTN cell. Additionally, the NTN cell may support an SDT procedure (e.g., an RA-SDT procedure, a CG-SDT procedure, and/or an SRB-SDT procedure) by broadcasting the SDT-ConfigCommon in the system information. For example, the SDT-ConfigCommon may be broadcast by a TN cell or an NTN cell using a SIB1 delivery approach (e.g., via a broadcasting approach or via a UE-specific dedicated control signaling approach).

An example of the data structure of the SIB1 is provided in Table <NUM> below.

An example of the data structure of the SDT-ConfigCommonSIB (e.g., which is denoted as SDT-ConfigCommonSIB-r17 in Table <NUM>) is provided in Table <NUM> below. It should be noted that the term "SDT-ConfigCommonSIB" and the term "SDT-ConfigCommon" may be used interchangeably in the present disclosure.

From the perspective of the UE, however, support for an SDT procedure associated with an NTN cell may or may not be present. In some implementations, the UE may choose to initiate an SDT procedure associatedwith an NTN cell (only) in a case that the UE supports the SDT procedure associated with the NTN cell. Conversely, in a case that the UE does not support an SDT procedure (e.g., with the NTN cell), the UE may choose not to initiate the SDT procedure associated with the NTN cell. Otherwise, the UE may be triggered to initiate a procedure which the UE fails to support. In some implementations, this mechanism may be implemented as a kind of UE capability check when/after the UE receives a service request from the upper layer of the UE side (e.g., an UL packet transmission request from the upper layer while the UE is staying in RRC Inactive state). In some implementations, the UE capability to one specific function may change with time or with different frequency carriers and so the UE may need to implement UE capability check (towards one specific service/function) while the UE receives the service request from the upper layers of the UE.

It should be noted that in the present disclosure, an SDT procedure may refer to an RA-SDT procedure, a CG-SDT procedure, an SRB-SDT procedure, or a combination of thereof (e.g., including at least one of the RA-SDT procedure, the CG-SDT procedure and the SRB-SDT procedure). Additionally, when a UE is said to support an (RA-/CG-/SRB-) SDT (procedure), this may mean that the UE is capable of initiating and/or performing the (RA-/CG-/SRB-) SDT (procedure). For example, if a UE supports an SDT procedure with (or 'associated with') an NTN cell, this could mean that the UE is capable of initiating the SDT procedure associated with the NTN cell and/or performing the SDT procedure in conjunction with the NTN cell. On the other hand, when a UE is said not to support an SDT procedure (e.g., a CG-SDT/RA-SDT/SRB-SDT procedure), this may mean that the UE is incapable of initiating and/or performing the SDT procedure. For example, if a UE supports an SDT procedure associated with an NTN cell, this could mean that the UE is incapable of initiating the SDT procedure associated with the NTN cell and/or performing the SDT procedure in conjunction with the NTN cell.

In some implementations, the UE may choose to initiate an RA-SDT procedure associated with an NTN cell (only) if the UE supports the RA-SDT procedure. Conversely, the UE may choose not to initiate an RA-SDT procedure associated with an NTN cell if the UE does not support the RA-SDT procedure. In some implementations, the UE may choose to initiate an SRB-SDT procedure associated with an NTN cell (only) if the UE supports the SRB-SDT procedure. Conversely, the UE may choose not to initiate an SRB-SDT procedure associated with an NTN cell if the UE does not support the SRB-SDT procedure.

In some implementations, the UE may choose to initiate a CG-SDT procedure associated with an NTN cell (only) if the UE supports the CG-SDT procedure. Conversely, the UE may choose not to initiate a CG-SDT procedure associated with an NTN cell if the UE does not support the CG-SDT procedure. In some implementations, the UE may report its capability for CG-SDT (e.g., whether the UE supports a CG-SDT procedure) in NTN-parameters. In some implementations, the NTN-parameters may also be used to report the UE capability of whether the UE supports the RA-SDT procedure.

In some implementations, the UE (e.g., the RRC entity of the UE) may notify the upper layers (e.g., the NAS layer responsible for instructing or initiating the SDT procedure) that the prerequisites for executing an SDT procedure are not met. This may occur due to the UE not supporting the SDT procedure associated with the serving RAN (e.g., a serving NTN cell), thereby preventing the triggering of the SDT procedure. In some implementations, the lower layers (e.g., the RRC layer or the MAC layer) may communicate a failure cause (e.g., the UE does not support RA-SDT with the serving network) to the upper layers of the UE (e.g., the NAS layer).

In some implementations, the UE may release its stored SDT configuration (e.g., the SDT-config received from the serving TN or NTN cell of the UE) if the UE (re)selects to camp on an NTN cell and does not support the SDT/RA-SDT/CG-SDT/SRB-SDT procedures associated with the camped NTN cell.

In some implementations, the UE may release its stored SDT configuration (e.g., the SDT-config received from the serving TN or NTN cell of the UE) after being triggered by the upper layers to initiate an SDT/RA-SDT/CG-SDT/SRB-SDT procedure associated with an NTN cell on which the UE is camping, provided the UE does not support the SDT/RA-SDT/CG-SDT/SRB-SDT procedures associated with the camped NTN cell.

In some implementations, the UE may keep (or retain) the stored SDT configuration (e.g., the SDT-config) that, for example, the UE has received from its serving RAN (e.g., at least one of NTN cells, TN cells, TN BSs, NTN BSs, NTN gateways, and NTN payloads) after/at the time the UE (re)selects an NTN cell, provided that the UE supports the SDT/CG-SDT/RA-SDT/SRB-SDT procedures associated with the NTN cell (e.g., the UE's capability regarding the SDT/CG-SDT/RA-SDT/SRB-SDT procedures in the NTN-parameters is marked as "supported").

In some implementations, the UE may not receive/store (or release) the common/cell specific SDT configuration transmitted by the serving cell (e.g., SDT-ConfigCommon, which may be transmitted by the serving RAN via broadcasting system information and/or UE-specific DL Radio Resource Control signaling) if the UE does not support the SDT/CG-SDT/RA-SDT/SRB-SDT service with the serving RAN. In some implementations, the UE may receive/store/retain the common/cell specific SDT configuration transmitted by the serving cell (e.g., SDT-ConfigCommon, which may be transmitted by the serving RAN via broadcasting system information and/or UE-specific DL Radio Resource Control signaling) if the UE does not support the SDT/CG-SDT/RA-SDT/SRB-SDT service with the serving RAN.

In some implementations, the UE may continue to keep (or retain) the stored SDT configuration (e.g., the SDT-config received from the serving RAN of the UE) even after (or at the same time that) the UE (re)selects an NTN cell to camp on, regardless of whether the UE supports the SDT/CG-SDT/RA-SDT/SRB-SDT procedures associated with the NTN cell (e.g., the UE's capability regarding the SDT/CG-SDT/RA-SDT/SRB-SDT procedures in the NTN-parameters is absent).

In some implementations, the UE may continue to keep (or retain) the stored SDT configuration (e.g., the SDT-config received from the serving TN cell or NTN cell of the UE) after the UE is triggered by the upper layers to initiate an SDT/RA-SDT/CG-SDT/SRB-SDT procedure in association with the current NTN cell, even if the UE does not support the SDT/RA-SDT/CG-SDT/SRB-SDT procedures associated with the NTN cell.

In some implementations, the UE may release the stored SDT configuration (e.g., the SDT-config received from the serving RAN of the UE) if the UE is configured to prioritize the NTN cells over the TN cells (e.g., by giving the NTN cells a higher priority value than the TN cells) during a cell (re)selection procedure and does not support the SDT/RA-SDT/CG-SDT/SRB-SDT procedures associated with the NTN cells.

In some implementations, the UE may retain the stored SDT configuration (e.g., the SDT-config received from its serving RAN) even if the UE is configured to prioritize the NTN cells over the TN cells during the cell (re)selection procedure and does not support the SDT/RA-SDT/CG-SDT/SRB-SDT procedures associated with the NTN cells.

In some implementations, if the UE does not support the SDT/RA-SDT/CG-SDT/SRB-SDT procedures associated with an NTN cell (e.g., the UE's capability regarding the SDT/RA-SDT/CG-SDT/SRB-SDT procedures is marked as "not supported" or is absent in the NTN-parameters), the UE may remain in the RRC INACTIVE state after/at the time the UE (re)selects to camp on the NTN cell. In this scenario, the UE may choose to retain or release the stored SDT configuration that was previously received from the serving RAN (e.g., via a previous serving (TN/NTN) cell). In some implementations, the UE may reapply (or reuse) the stored SDT configuration to initiate/perform an SDT procedure the next time the UE transitions from the NTN cell to a TN cell that supports the SDT/RA-SDT/CG-SDT procedures.

In some implementations, If the UE chooses to keep/retain the stored SDT configuration, the UE may choose to release its stored SDT configuration (only) upon receiving instructions from the upper layers to initiate an SDT/CG-SDT/RA-SDT/SRB-SDT procedure that the UE may not support with the current serving NTN cell. In some implementations, if the UE chooses to keep/retain the stored SDT configuration, the UE may also choose not to release the SDT configuration, even after receiving instructions from the upper layers to initiate an SDT/RA-SDT/CG-SDT/SRB-SDT procedure that the UE does not support.

In some implementations, if the UE (re)selects to camp on an NTN cell while it lacks support for the SDT/RA-SDT/CG-SDT/SRB-SDT procedures associated with the NTN cell (e.g., the UE's capability regarding the SDT/RA-SDT/CG-SDT/SRB-SDT procedures in the NTN-parameters is marked as "not supported" or is absent), the UE may transition to the (NR/E-UTRA) RRC IDLE state. Moreover, if the UE (re)selects to camp on an NTN cell and does not support the SDT/CG-SDT/RA-SDT/SRB-SDT procedures associated with the NTN cell (e.g., the UE's capability regarding the SDT/RA-SDT/CG-SDT/SRB-SDT procedures in the NTN-parameters is marked as "not supported" or is absent), the UE may release the stored SDT configuration that the UE has received from the serving RAN (e.g., NR RAN and/or E-UTRA) of the UE.

In some implementations, the UE may use a UE capability enquiry procedure or a UE Assistance Information (or "UEAssistanceInformation") delivery procedure to inform the serving RAN (e.g., which may be a combination of one or more TN cells and one or more NTN cells) whether the UE supports the SDT/CG-SDT/RA-SDT/SRB-SDT procedures associated with the NTN cells.

<FIG> is a diagram illustrating a UE capability enquiry procedure, according to an example implementation of the present disclosure. As illustrated in <FIG>, in action <NUM>, the UE may receive a UE capability enquiry (or "UECapabilityEnquiry") message from the network (e.g., the serving RAN of the UE). In action <NUM>, the UE may transmit the UE capability information (or "UECapabilitylnformation") to the network in response to receiving the UECapabilityEnquiry message. In some implementations, the UE may transmit the assistance information without receiving an explicit inquiry, as shown in <FIG>, from the network. For example, as shown in <FIG>, the UE may transmit the assistance information to the network after receiving a reconfiguration message.

<FIG> is a diagram illustrating a UE Assistance Information delivery procedure, according to an example implementation of the present disclosure. As illustrated in <FIG>, in action <NUM>, the UE may receive an RRC reconfiguration (or "RRCreconfiguration") message from the network (e.g., the serving RAN of the UE). In action <NUM>, the UE may transmit UE assistance information (or "UEAssistanceInformation") to the network in response to receiving the RRCreconfiguration message.

In the present disclosure, the term "network" may refer to a network that includes at least one TN cell and/or at least one NTN cell, or may refer to a network that includes at least one of an eNB, a gNB, an NTN gateway, and an NTN payload.

In some implementations, the UE may either support or not support the CG-SDT/RA-SDT procedures associated with the NTN cells. In some implementations, the UE may automatically switch to support the CG-SDT/RA-SDT procedures associated with the NTN cells if the UE has already delivered its capabilities regarding the SDT procedures to the network.

In some implementations, the UE's capability may temporarily change due to various factors such as a manual operation, overheating, serving frequency change, or hardware co-existence issues. The UE may change its capability/support for the SDT/CG-SDT/RA-SDT/SRB-SDT procedures associated with the serving NTN cell or the serving TN cell to "supported" or "not supported.

Under such a condition, the UE may present at least one of the following behaviors (<NUM>) and (<NUM>):.

In some implementations, the UE may not release (e.g., may refrain from releasing) the stored SDT-Config if/at the time/after its capability status changes from "SDT/RA-SDT/CG-SDT/SRB-SDT supported" to "SDT/RA-SDT/CG-SDT/SRB-SDT not supported. " In some implementations, the UE may release the stored SDT-Config if/at the time/after its capability status changes from "SDT/RA-SDT/CG-SDT/SRB-SDT supported" to "SDT/RA-SDT/CG-SDT/SRB-SDT not supported.

In some implementations, the UE may transition from the RRC INACTIVE state to the RRC IDLE state if/at the time/after the UE changes its capability status from "SDT/RA-SDT/CG-SDT/SRB-SDT supported" to "SDT/RA-SDT/CG-SDT/SRB-SDT not supported. " In some implementations, the UE may stay/remain in the RRC INACTIVE state if/after/at the time the UE changes its capability status from "SDT/RA-SDT/CG-SDT/SRB-SDT supported" to "SDT/RA-SDT/CG-SDT/SRB-SDT not supported.

In some implementations, if the UE does not support the SDT/CG-SDT/RA-SDT/SRB-SDT procedures associated with the NTN cells, the NTN cell may not configure or transmit the SDT/CG-SDT/RA-SDT/SRB-SDT configuration information to the UE via an RRC Release message.

In some implementations, the UE may not expect to receive an SDT-config (e.g., which may include configurations/parameters for the CG-SDT procedure, the RA-SDT procedure, or the SRB-SDT procedure) from a serving NTN cell (e.g., during the RRC (Connection) Release message reception) if the UE does not support the SDT/CG-SDT/RA-SDT/SRB-SDT procedure associated with the NTN cells. In some implementations, if the UE does not support the SDT/CG-SDT/RA-SDT/SRB-SDT procedures associated with the NTN cells, the UE may not expect to receive the SDT-config, which may include configurations/parameters for the SDT/CG-SDT/RA-SDT/SRB-SDT procedures, in an RRC (Connection) Release message from a serving NTN cell.

In some implementations, an NTN cell may still transmit an SDT configuration (e.g., a configuration for at least one of a CG-SDT procedure, an RA-SDT procedure, and an SRB-SDT procedure) to the UE via the UE-specific DL control signaling (e.g., through an RRC Release message), regardless of whether the UE supports the SDT/CG-SDT/RA-SDT/SRB-SDT procedures associated with the NTN cells. Under such a circumstance, the UE may apply the received SDT configuration to initiate/perform an SDT procedure once the UE becomes capable of supporting the SDT/CG-SDT/RA-SDT/SRB-SDT procedures. In some implementations, the SDT configuration provided by the NTN cell may be associated with a TN cell. In such cases, the UE may store the SDT configuration associated with the TN cell. In some such implementations, the next time the UE moves to or selects a TN cell that supports the SDT/CG-SDT/RA-SDT/SRB-SDT procedures to camp on, the UE may initiate the corresponding SDT procedure based on the stored SDT configuration (e.g., which is provided by the previous serving (NTN) cell on which the UE was camping) and/or the SDT-ConfigCommon transmitted by the selected TN cell (e.g., via broadcasting system information, such as SIB1). Additionally, in some implementations, the UE may (re)select a TN cell to camp on based on the instructions received from the current serving NTN cell of the UE (e.g., via redirected carrier information (or "re-directedcarrierinformation"), UE-specific control signaling, or broadcast system information from the current serving NTN cell).

In some implementations, the received SDT/CG-SDT/RA-SDT/SRB-SDT configuration may be associated with a validity period. In some such implementations, the UE may store or keep the SDT/CG-SDT/RA-SDT/SRB-SDT configuration (only) for the duration of the validity period. In some implementations, the UE may release/drop/remove/erase the stored SDT/CG-SDT/RA-SDT/SRB-SDT configuration(s) after the validity period (or while the validity period expires).

In some implementations, the NTN cell may transmit a CG-SDT configuration to the UE, allowing the UE to initiate a CG-SDT procedure associated with the same serving (NTN) cell while the UE is in the RRC INACTIVE state. This may be applicable if, for example, the UE does not support the RA-SDT procedures associated with the NTN cells but does support the CG-SDT procedures. In some implementations, the NTN cell may transmit a RA-SDT configuration to the UE, allowing the UE to initiate a RA-SDT procedure associated with the same serving (NTN) cell while the UE is in the RRC INACTIVE state. This would be applicable if, for example, the UE does not support the CG-SDT procedures associated with the NTN cells but does support the RA-SDT procedures.

In some implementations, the UE may be configured (e.g., through pre-configuration, pre-installation in a USIM, broadcast system information, or UE-specific DL control signaling) with high priority (e.g., a high priority value or other NTN prioritization rules) to the NTN cells or NTN access during a cell (re)selection procedure. The UE may also be configured with an SDT-config for an SDT procedure. Under such a condition, the UE may present at least one of the following behaviors (<NUM>) to (<NUM>):.

In some implementations, a cell/eNB/gNB/BS (e.g., a TN cell or TN BS) may not transmit the SDT-related configurations associated with a specific UE (e.g., the SDT-config as per 3GPP spec) to an NTN cell or an NTN BS if the UE is not capable of implementing an SDT procedure (e.g., including at least one of a CG-SDT procedure, an RA-SDT procedure, and an SRB-SDT procedure) on the NTN cell or the NTN B S.

In some implementations, the cell/eNB/gNB/BS (e.g., a TN cell or TN BS) may transmit the SDT-related configurations associated with a specific UE (e.g., the SDT-config as per 3GPP spec) to an NTN cell or an NTN BS, even if the UE may not be capable of implementing an SDT procedure (e.g., including at least one of a CG-SDT procedure, an RA-SDT procedure, and an SRB-SDT procedure) on the NTN cell or the NTN BS.

Table <NUM> below shows an example of conditions for initiating an SDT procedure. As illustrated in Table <NUM>, the UE's capability to support the SDT procedures is taken into account when the UE is requested to resume an RRC connection for initiating the SDT procedure.

In some implementations, a UE may receive an SDT configuration via DL control signaling (e.g., an RRC Release message) from its serving cell (e.g., a TN cell). The SDT configuration may enable the UE to implement an SDT procedure with an activated Signaling Radio Bearer (e.g., SRB2). For example, the UE may receive an SDT-Config with an IE sdt-SRB2-Indication-r17={allowed}, enabling the UE to initiate or reactivate its SRB2 after the UE chooses to initiate an SDT procedure. An example of the data structure of the SDT-Config (e.g., which is denoted as SDT-Config-r17 in Table <NUM>) is provided in the below Table <NUM>.

IE sdt-SRB2-Indication (which is denoted as "sdt-SRB2-Indication-r17" in Table <NUM>) may indicate whether the SRB2 is configured for SDT (procedures) or not in some implementations.

When the UE moves from a TN cell to an NTN cell, a problematic scenario may arise because the UE may have still stores the SDT-config and may not support initiating an SDT procedure associated with its serving cell (e.g., an NTN cell) using an activated SRB2. To address this issue, certain mechanisms are proposed below. It should be noted that in the present disclosure, an SRB-SDT procedure may refer to an SDT procedure (e.g., a CG-SDT procedure or an RA-SDT procedure) that is initiated by a UE with an activated SRB <NUM> or SRB2.

In some implementations, the UE may initiate an SRB-SDT procedure while the UE has one or more pending packets associated with the SRB(s) (e.g., SRB <NUM> and/or SRB2).

In some implementations, in addition to the one or more pending packets associated with the SRBs, the UE may have one or more packets associated with other radio bearers (e.g., one or more DRBs) while initiating an SRB-SDT procedure. In some implementations, the UE may initiate an SRB-SDT procedure only if all pending packets are associated with the SRBs (e.g., SRB <NUM> and/or SRB2 and/or SRB3 and/or SRB4).

In some implementations, implementing an SRB-SDT procedure may imply that at least one SRB (e.g., SRB1 or SRB2) is resumed by the UE during the SDT/RA-SDT/CG-SDT procedure for packet exchange. In some implementations, implementing an SRB-SDT procedure may imply that only the SRB <NUM> or the SRB2 is resumed by the UE during the SDT/RA-SDT/CG-SDT procedure for packet exchange.

In some implementations, the IE sdt-SRB2-Indication may be configured as an area-specific indicator (e.g., per cell or per RAN Notification Area). As such, the UE may release or remove this IE after the UE leaves the associated area. For example, the UE may release the stored sdt-SRB2-Indication upon leaving the cell that provides the SDT-config. In some implementations, the UE may release the stored sdt-SRB2-Indication after the UE (re)selects an NTN cell to camp on if the UE does not support the SRB-SDT procedures.

In some implementations, the UE may assess its capability for SRB resumption if the UE is triggered (e.g., by the NAS layer or by the RRC layer) to implement an SDT procedure.

In some implementations, the UE may camp on an NTN cell, which may support the SDT procedures (e.g., the RA-SDT procedures and/or the CG-SDT procedures) by broadcasting a corresponding SDT configuration (e.g., SDT-ConfigCommon) in the system information.

In some implementations, the SDT-ConfigCommon may be transmitted by a TN cell or an NTN cell via a SIB1 (e.g., through a broadcasting approach or a UE-specific dedicated control signaling delivery approach).

An example of the data structure of an SDT-Config is provided in Table <NUM> below.

From the UE's perspective, support for an SRB-SDT procedure associated with an NTN cell may be variable. Therefore, in some scenarios, the UE may choose to initiate an SDT/RA-SDT/CG-SDT/SRB-SDT procedure associated with an NTN cell without resuming or re-activating the SRB <NUM>/SRB2/SRB3/SRB4, if the UE does not support using the SRB <NUM>/SRB2/SRB3/SRB4 during the SDT/RA-SDT/CG-SDT/SRB-SDT procedure associated with the NTN cell.

In some implementations, the UE may be configured with an IE sdt-SRB2-Indication set to "allowed" (e.g., sdt-SRB2-Indication = {allowed}), which may enable the UE to resume or reactivate the pending or stored SRB1/SRB2 during an SDT/RA-SDT/CG-SDT/SRB-SDT procedure associated with an NTN cell. The UE may be configured with sdt-SRB2-Indication= {allowed} by receiving the SDT-config via UE-specific RRC signaling or by receiving the SDT-configCommon via broadcast system information.

The UE, however, may or may not have the capability to transmit or receive the SRB <NUM>/SRB2/SRB3/SRB4 during an SDT/CG-SDT/RA-SDT procedure associated with an NTN cell. In such conditions, if the stored SDT-config includes an IE sdt-SRB2-Indication-r17 set to ENUMERATED { allowed} (e.g., sdt-SRB2-Indication-r17 = ENUMERATED { allowed}), the UE may be prohibited from initiating the SDT/CG-SDT/RA-SDT procedure associated with the NTN cell. Additionally, the UE that does not support the SRB-SDT procedures may be able to (or be allowed to) initiate an SDT/CG-SDT/RA-SDT procedure associated with an NTN cell (<NUM>) if the stored SDT-config does not include an IE sdt-SRB2-Indication (e.g., the IE sdt-SRB2-Indication-r17 as per the 3GPP specifications) or (<NUM>) if the stored SDT-config includes the IE sdt-SRB2-Indication that is set to ENUMERATED{not allowed}. In some implementations, the UE may be prohibited from initiating an SDT/RA-SDT/CG-SDT procedure associated with the serving NTN cell if there are any pending packets associated with the SRB <NUM>/SRB2. In other words, a UE that does not support the SRB-SDT procedures may be able to initiate an SDT/CG-SDT/RA-SDT procedure if none of the pending packets is associated with the SRB1 and/or the SRB2.

In some implementations, a UE that does not support the SRB-SDT procedures may need to resume the RRC connection to transition to the RRC CONNECTED state for packet transmission if there is any pending packets associated with the SRB1/SRB2. In some implementations, the UE may not (or may not be allowed/enabled to) initiate an SDT/CG-SDT/RA-SDT/SRB-SDT procedure associated with its serving NTN cell if the UE does not support the SRB-SDT procedures. In some implementations, the UE (e.g., the RRC entity of the UE) may inform the upper layers (e.g., the NAS layer, which instructs/initiates the SDT procedure or the UL packet transmission request) that the prerequisites for initiating/performing an SDT procedure are not met because the UE does not support the SRB-SDT procedures associated with the serving RAN (e.g., the serving NTN cell). As a result, the SDT procedure may not be triggered. In some implementations, the lower layer (e.g., the RRC layer or the MAC layer) may transmit a failure cause (e.g., such as 'the UE does not support the SRB-SDT procedures associated with the serving network') to the upper layers of the UE (e.g., the NAS layer).

In some implementations, a UE that does not support the SRB-SDT procedures associated with an NTN cell may initiate an SDT/RA-SDT/CG-SDT procedure associated with the serving NTN cell (only) if there are no pending packets associated with the SRB1/SRB2/SRB3/SRB4. In some implementations, the pending packets (associated with the SRB1/SRB2) may be considered as 'not configured for the SDT procedures,' even if the UE is configured with the sdt-SRB2-Indication = ENUMERATED {allowed} in the stored SDT-config. It should be noted that the UE may transition between the NTN and the TN cells within the same serving Radio Access Network. Therefore, after the UE switches from an NTN cell to a serving TN cell, such as during a cell (re)selection, any pending packets associated with the SRB <NUM>/SRB2/SRB3/SRB4 may be considered by the UE as 'configured for the SDT procedures,' even if the UE is configured with the sdt-SRB2-Indication = ENUMERATED {allowed} in the stored SDT-config.

In some implementations, the UE may ignore the sdt-SRB2-Indication stored in the SDT-Config if the UE chooses to initiate an SDT/RA-SDT/CG-SDT procedure associated with an NTN cell. The UE may consider that the SRB1/SRB2/SRB3/SRB4 is not initiated with the SDT/RA-SDT/CG-SDT procedure associated with the serving NTN cell if the UE does not support the SRB-SDT procedures. In such cases, the UE may not consider/count the pending packets associated with the SRB1/SRB2 when calculating the total number of pending packets for the SDT initiation. In some implementations, the UE may resume the SRB <NUM>/SRB2 for an SDT/RA-SDT/CG-SDT procedure only if the UE supports the SRB-SDT procedures. In such cases, the UE may consider or count the pending packets associated with the SRB <NUM>/SRB2 when calculating the total number of pending packets for the SDT initiation.

In some implementations, the UE may be configured with an sdt-SRB2-Indication ={allowed}, which enables the UE to resume/re-activate the pending/stored SRB1/SRB2 if the UE initiates an SDT/RA-SDT/CG-SDT procedure associated with a serving NTN cell but the UE does not support packet transmissions/receptions via the SRB1/SRB2 to the serving NTN cell during the SDT/RA-SDT/CG-SDT procedure. In some implementations, the UE may further release or remove the stored SDT-Config after/at the time the UE reselects an NTN cell to camp on. In some implementations, the UE may release or remove the stored SDT-Config after/at the time the UE is requested/configured by the upper layers to initiate an SDT/CG-SDT/RA-SDT/SRB-SDT procedure (e.g., regardless of whether there are any pending packets associated with the SRB1/SRB2). In some implementations, the UE may release or remove the stored SDT-Config after/at the time the UE is requested/configured by the upper layers to initiate an SDT/CG-SDT/RA-SDT/SRB-SDT procedure (only) if there are any pending packets associated with the SRB <NUM>/SRB2.

In some implementations, if one or more new packets associated with the SRB1/SRB2/SRB3/SRB4 arrive in the UE's buffer and the UE does not support SRB1/SRB2 resumption with an NTN cell during an SDT procedure, the UE may terminate the active/activated SDT/CG-SDT/RA-SDT procedure.

By referring to 3GPP technical specifications, in some implementations, Signaling Radio Bearers" (SRBs) are defined as Radio Bearers (RBs) that are used only for the transmission of RRC and NAS messages. More specifically, the following SRBs are defined:.

In some implementations, the UE may keep or retain the stored SDT configuration (e.g., the stored SDT-config received from the UE's serving RAN, which may include at least one of the following: one or more NTN cells, one or more TN cells, one or more TN BSs, one or more NTN BSs, one or more NTN gateways, and one or more NTN payloads) after/at the time the UE reselects an NTN cell to camp on (only) if the UE does support the SRB-SDT procedures associated with the NTN cell (e.g., the UE's capability regarding the SRB-SDT procedures in the NTN-parameters is marked as "supported").

In some implementations, the UE may keep or retain the stored SDT configuration (e.g., the stored SDT-config received from the UE's serving RAN) after/at the time the UE reselects an NTN cell to camp on, despite the UE not supporting the SRB-SDT procedures associated with the NTN cell (e.g., the UE's capability regarding the SRB-SDT procedures in the NTN-parameters is absent or is marked as "not supported").

In some implementations, the UE may keep or retain the stored SDT configuration (e.g., the stored SDT-config received from the UE's serving TN or NTN cell) after the UE is triggered by the upper layers to initiate an SDT/RA-SDT/CG-SDT/SRB-SDT procedure associated with its current serving cell (e.g., the currently camped NTN cell), even if the UE does not support the SRB-SDT procedures associated with the current serving cell.

In some implementations, the UE may release the stored SDT configuration (e.g., the stored SDT-config received from the UE's serving RAN) if the UE is configured to prioritize the NTN cells over the TN cells (e.g., by giving a higher priority to the NTN cells compared to the TN cells) for a cell (re)selection procedure and the UE does not support the SRB-SDT procedures associated with the NTN cells.

In some implementations, the UE may keep or retain the stored SDT configuration (e.g., the stored SDT-config received from the UE's serving RAN) even if the UE is configured to prioritize the NTN cells over the TN cells (e.g., by giving higher priority to the NTN cells compared to the TN cells) for a cell (re)selection procedure and if the UE does not support the SRB-SDT procedures associated with the NTN cells.

In some implementations, the UE may be configured with an sdt-SRB2-Indication ={allowed}, which enables the UE to resume/re-activate the pending/stored SRB1/SRB2 if the UE initiates an SDT/RA-SDT/CG-SDT procedure associated with an NTN cell and does not support packets transmission/reception via the SRB1/SRB2/SRB3/SRB4 to a serving NTN cell during the SDT/RA-SDT/CG-SDT/SRB-SDT procedure. In some implementations, the UE may transition to the RRC IDLE state after/at the time the UE reselects an NTN cell to camp on. In some implementations, the UE may transition to the (E-UTRA/NR) RRC IDLE state after/at the time the UE is requested/configured by the upper layers to initiate an SDT/CG-SDT/RA-SDT procedure (e.g., regardless of whether there are any pending packets associated with the SRB1/SRB2). In some implementations, the UE may transition to the RRC IDLE state after/at the time the UE is requested/configured by the upper layers to initiate an SDT/CG-SDT/RA-SDT procedure (only) if there are any pending packets associated with the SRB <NUM>/SRB2/SRB3/SRB4.

In some implementations, a UE, that does not support the SRB-SDT procedures associated with the NTN cells (e.g., the UE's capability in the NTN-parameters regarding the SRB-SDT procedures is marked as "not supported" or is absent), may stay in the RRC INACTIVE state after/at the time the UE (re)selects an NTN cell to camp on. In such cases, the UE may or may not release the stored SDT configuration received from the serving RAN. In some implementations, the UE may reapply/reuse the stored SDT configuration next time the UE switches from the NTN cell to a TN cell with which the UE supports the SDT procedures. Additionally, in some implementations, if the stored SDT configuration (e.g., the SDT-config) has been kept/stored by the UE, the stored SDT configuration may be released by the UE (only) if the UE, that does not support an SRB-SDT procedure associated with the serving NTN cell, receives instructions from the upper layers to initiate the SRB-SDT procedure (e.g., for SRB1/SRB2/SRB3/SRB4 control signaling transmission). In some implementations, if the stored SDT configuration (e.g., the SDT-config) has been kept/stored by the UE, the UE, that does not an SDT/RA-SDT/CG-SDT/SRB-SDT procedure, may not release the stored SDT configuration even if the UE receives instructions from the upper layers to initiate the SDT/RA-SDT/CG-SDT procedure.

In some implementations, a UE, which does not support the SRB-SDT procedures associated with an NTN cell (e.g., the UE's capability in the NTN-parameters regarding the SRB-SDT procedures is marked as "not supported" or is absent), may transition to the RRC IDLE state after/at the time the UE (re)selects the NTN cell to camp on. Additionally, in some implementations, the UE may release the stored SDT configuration (e.g., the stored SDT-config received by the UE from the UE's serving RAN) after/at the time the UE (re)selects the NTN cell to camp on.

In some implementations, the UE may inform the serving RAN (e.g., including a combination of at least one TN cell and at least one NTN cell) whether the UE supports the SRB-SDT procedures associated with the NTN cells via a UE capability enquiry procedure (e.g., as illustrated in <FIG>) or a UEAssistanceInformation delivery procedure (e.g., as illustrated in <FIG>).

In some implementations, the UE may or may not support the SRB-SDT procedures associated with the NTN cells. In some implementations, the UE may automatically support the SRB-SDT procedures associated with the NTN cells if the UE has transmitted its capability regarding the SDT procedures to the network.

In some implementations, the UE's capability may be changed temporally at the UE side due to one or more reasons (e.g., manual operation, overheating problem, co-existence problem in hardware modules, etc.). In some implementations, the UE may change its capability/support about the SDT/CG-SDT/RA-SDT/SRB-SDT procedures and report to the serving NTN cell (or serving TN cell) whether the UE currently supports the SDT/CG-SDT/RA-SDT/SRB-SDT procedures or not. Under such a condition, in some implementations, the UE's capability may change temporarily at the UE side due to various reasons, such as manual operation, overheating, co-existence issues in hardware modules, etc. In some implementations, the UE may change its capability/support regarding the SDT/CG-SDT/RA-SDT/SRB-SDT procedures and report to the serving NTN cell (or serving TN cell) whether the UE supports the SDT/CG-SDT/RA-SDT/SRB-SDT procedures or not. Under such a condition, the UE may present at least one of the following behaviors (<NUM>) and (<NUM>):.

In some implementations, the UE may not release the stored SDT-Config if/after/at the time the UE transitions from the capability status of "SRB-SDT procedures are supported" to "SRB-SDT procedures are not supported. " In some implementations, the UE may release the stored SDT-Config if/at the time /after the UE transitions from the capability status of "SRB-SDT procedures are supported" to "SRB-SDT procedures are not supported.

In some implementations, the UE may transition from the (NR/E-UTRA) RRC INACTIVE state to the (NR/E-UTRA) RRC IDLE state if/at the time /after the UE transitions from the capability status of "SRB-SDT procedures are supported" to "SRB-SDT procedures are not supported. " In some implementations, the UE may stay in the RRC INACTIVE state if/at the time/after the UE transitions from the capability status of "SRB-SDT procedures are supported" to "SRB-SDT procedures are not supported.

In some implementations, an NTN cell may not configure or transmit an SDT/CG-SDT/RA-SDT/SRB-SDT configuration to a UE via an RRC Release (or "RRCRelease") message if the UE does not support the SRB-SDT procedures associated with the NTN cells. For example, if the UE does not support the SRB-SDT procedures associated with the NTN cells, the UE may not expect to receive an SDT-config, which may include parameters/configurations for CG-SDT/RA-SDT/SRB-SDT procedures, from a serving NTN cell during the stage when the UE is receiving/monitoring an RRC (Connection) Release message.

In some implementations, the NTN cell may transmit the SDT configuration to the UE via UE-specific DL control signaling (e.g., an RRC Release message), regardless of whether the UE supports the SDT/CG-SDT/RA-SDT/SRB-SDT procedures associated with the NTN cells. For example, the UE may apply the received SRB-SDT configuration to initiate or perform an SRB-SDT procedure if the UE becomes supporting the SRB-SDT procedures. In some implementations, the SDT/CG-SDT/RA-SDT/SRB-SDT configuration provided by the serving NTN cell may be associated with a TN cell (or TN access). In such cases, the UE may store this SDT/CG-SDT/RA-SDT/SRB-SDT configuration associated with the TN cell. Subsequently, when the UE moves to or selects a TN cell that supports the SDT/CG-SDT/RA-SDT/SRB-SDT procedures, the UE may initiate a corresponding SDT/CG-SDT/RA-SDT/SRB-SDT procedure based on the stored SDT/CG-SDT/RA-SDT/SRB-SDT configuration, which was transmitted by the previously serving NTN cell. Additionally, in some implementations, the UE may (re)select a TN cell to camp on in response to the instruction from the UE's serving NTN cell. The instruction may be included in redirected carrier information (or "re-directedcarrierinformation"), UE-specific control signaling, or broadcast system information. In some implementations, the SDT/CG-SDT/RA-SDT/SRB-SDT configuration may be further associated with a validity period. In such cases, the UE may store/keep the SDT/CG-SDT/RA-SDT/SRB-SDT configuration (only) for the duration of the valid period.

In some implementations, the UE may be configured with a high priority value for the NTN cells/NTN access during the cell (re)selection procedure. This configuration may be set through various means, such as pre-configuration, pre-installation in the USIM, broadcast system information, and/or UE-specific downlink control signaling. Despite this, the UE may also be configured with an SDT-config for an SDT procedure. Under such a condition, the UE may present at least one of the following behaviors (<NUM>) to (<NUM>):.

In some implementations, the cell/gNB/BS (e.g., a TN cell/TN BS) may not transmit an SDT-related configuration associated with a specific UE (e.g., the SDT-config as per 3GPP specifications) to an NTN cell/NTN BS if the UE is not capable of implementing an SDT procedure on the NTN cell/NTN BS. In some implementations, the cell/gNB/BS (e.g., a TN cell/TN BS) may transmit an SDT-related configuration associated with a specific UE (e.g., the SDT-config as per 3GPP specs) to an NTN cell/NTN BS, even if the UE is not capable of implementing an SDT procedure associated with the NTN cell/NTN BS.

An example of the conditions for initiating an SDT procedure is shown in Table <NUM> below, which presents an example implementation in which the UE's capability is taken into account when the UE is requested to resume an RRC connection for an SDT procedure initiation.

According to various implementations of the present disclosure, the mutual impacts of SDT procedures and the NTN cells are analyzed, considering whether the UE supports an SDT procedure associated with a serving NTN cell. Additionally, a serving RAN of the UE may include one or more NR/E-UTRA cells, making the mechanisms proposed in the present disclosure potentially applicable to, but not limited to, <NUM>/<NUM> E-UTRA protocols/systems and/or <NUM> NR protocols/systems. For example, the proposed mechanisms may also be applicable to eMTC and/or NB-IoT over the TN and/or the NTN. Furthermore, the proposed mechanisms may be applicable to the UEs or network nodes that are operating on various types of bands, including licensed bands, shared bands, unlicensed bands, ITS bands, and satellite bands.

NR supports the RRC INACTIVE state and UEs with infrequent (e.g., periodic and/or non-periodic) data transmission are generally maintained by the network in the RRC INACTIVE state. Until Rel-<NUM>, the UE was not allowed to perform data transmission in the RRC INACTIVE state. Hence, the UE had to resume the connection (e.g., move to an RRC CONNECTED state) for any DL reception and/or any UL data transmission. A connection setup and a subsequently release to the INACTIVE state had to occur for each data transmission regardless of how small and infrequent the data packets are. This may result in an unnecessary power consumption and signal overhead.

Signaling overhead from the RRC Inactive state UEs due to transmission of small data is a general problem and may become a critical issue as the number of UEs increases in a network, not only for the network performance and efficiency, but also for the UE battery performance. In general, any device that has intermittent small data packet transmission and/or receptions in the RRC Inactive state may benefit from enabling the SDT procedure in the RRC Inactive state.

<FIG> is a diagram illustrating an overview of a UE's RRC states transitions, according to an example implementation of the present disclosure. The RRC states include NR RRC CONNECTED state <NUM>, NR RRC INACTIVE state <NUM> and NR RRC IDLE state <NUM>. As illustrated in <FIG>, the UE has only one RRC state in NR at a time.

The RRC INACTIVE state (e.g., NR RRC INACTIVE state <NUM>) is a state where a UE remains in a CM (Connection Management)-CONNECTED state and may move within an area configured by the NG-RAN (e.g., the RNA) without notifying the NG-RAN. In the RRC INACTIVE state, the last serving gNB node keeps the UE context and the UE-associated NG connection with the serving Access and Mobility management Function (AMF) and User Plane Function (UPF).

The RRC INACTIVE state may support at least the following functions: a Public Land Mobile Network (PLMN) selection, a broadcast of system information, a cell re-selection mobility, a paging initiated by the NG-RAN (e.g., RAN paging), a RAN-based notification area (RNA) managed by the NG- RAN, a DRX for RAN paging configured by the NG-RAN, a SGC-NG-RAN connection (e.g., both C/U-planes) established for the UE, the UE (e.g., in an Inactive state) AS context stored in the NG-RAN, and the UE, the NG-RAN knows the RNA to which the UE belongs.

For an NR connected to the 5GC, the UE identity, Inactive-RNTI (I-RNTI), may be used to identify the UE context in an RRC INACTIVE state. The I-RNTI provides the new NG-RAN node a reference to the UE context in the old NG-RAN node. How the new NG-RAN node is able to resolve the old NG-RAN ID from the I-RNTI is a matter of proper configuration in the old and new NG-RAN nodes. Some typical partitioning of a 40bit I-RNTI assumes the following contents:.

UE Inactive AS Context: UE Inactive AS Context is stored when the connection is suspended (when the UE is in RRC INACTIVE state) and restored when the connection is resumed (e.g., when the UE is transited from RRC INACTIVE to RRC CONNECTED state).

The suspension of the RRC connection is initiated by the network. When the RRC connection is suspended, the UE stores the UE Inactive AS context and any configuration received from the network, and transitions to an RRC INACTIVE state. If the UE is configured with SCG, the UE releases the SCG configuration upon initiating an RRC Connection Resume procedure. The RRC message to suspend the RRC connection is integrity protected and ciphered. The resumption of a suspended RRC connection is initiated by the upper layers (e.g., when the UE needs to transit from RRC INACTIVE state to RRC CONNECTED state) or by the RRC layer (e.g., to perform an RNA update or by RAN paging from NG-RAN). When the RRC connection is resumed, the network configures the UE according to the RRC connection resume procedure based on the stored UE Inactive AS context and any RRC configuration received from the network. The RRC connection resume procedure re-activates AS security and re-establishes the SRB(s) and DRB(s).

In response to a request to resume the RRC connection, the network may resume the suspended RRC connection and send the UE to an RRC CONNECTED state, or reject the request to resume and send the UE to an RRC INACTIVE (with a wait timer) state, or may directly re-suspend the RRC connection and send the UE to an RRC INACTIVE state, or may directly release the RRC connection and send the UE to an RRC IDLE state, or may instruct the UE to initiate a NAS level recovery (e.g., in a case that the network sends an RRC setup message).

In addition, in the RRC INACTIVE state, a UE specific discontinuous reception (DRX) may be configured by the upper layers or by the RRC layer, a UE controlled mobility may be based on a network configuration, the UE may store the UE Inactive AS context, and a RAN-based notification area may be configured by the RRC layer. Furthermore, the UE may perform at least one of the following behaviors in the RRC INACTIVE state:.

<FIG> is a diagram illustrating a procedure of establishing an SDT session, according to an example implementation of the present disclosure.

In action <NUM>, the UE may receive an SDT configuration from the serving RAN via DL UE-specific signaling (e.g., through an RRC Reconfiguration (or "RRCReconfiguration") message and/or an RRCRelease message). The SDT configuration may be from a first serving cell of the serving RAN associated with the UE. The first serving cell may configure the UE with UL-CG configurations (e.g., CG-PUSCH resource configurations) and/or UE-specific/common RA resources. This enables the UE to implement SDT (e.g., an SDT procedure) after transitioning to the RRC INACTIVE state.

In action <NUM>, the UE may transition to the RRC INACTIVE state (e.g., after receiving an RRCRelease message from the first serving cell, where the RRCRelease message instructs the UE to transition to the RRC INACTIVE state). In some implementations, the CG-PUSCH resource and/or the RA resource configuration may locate on a (normal) UL carrier (e.g., a UL carrier or an NUL carrier) or an SUL carrier. After receiving the SDT configuration and while in the RRC CONNECTED state, the UE may store the SDT configuration to use after transitioning to the RRC INACTIVE state. The UE may still keep or retain the SDT configuration after transitioning to the RRC INACTIVE state.

In action <NUM>, when one or more packets (belonging to the SDT radio bearers, which may also be configured in the SDT configuration) arrive, the UE may initiate an SDT session with a second serving cell of the serving RAN accordingly. The initiation of the SDT session may be done, for example, by transmitting the encoded packets on the configured UL-CG directly, with or without transmitting an RRCResume Request message. Alternatively, a preamble may be transmitted first, with or without attaching encoded packets, during a <NUM>-step RA procedure that is triggered as part of the SDT session. An alternative may be transmitting a preamble as MSG1 followed by an RRCResumeRequest message/an encoded packet in a <NUM>-step RA procedure. It should be noted that the second serving cell may be the same as the first serving cell in some scenarios, or different from the first serving cell in other scenarios. After the UE initiates the SDT session, the serving cell (e.g., the first or the second serving cell) may continue the SDT (procedure) by transmitting DL packets to the UE or by providing dynamic UL grants to the UE for subsequent DL/UL packet exchanges. In some implementations, HARQ protocols may be configured as part of the SDT configuration and may be implemented during the DL/UL packet exchanges in the SDT session.

In action <NUM>, to finish the active SDT session, the second serving cell may transmit another RRCRelease message to instruct the UE to terminate the SDT session. The UE may keep or retain the stored SDT configuration and remain in the RRC INACTIVE state after receiving the RRCRelease message.

In the uplink, a base station (e.g., a gNB) may dynamically allocate resources to the UEs via the C-RNTI on PDCCH(s). A UE always monitors the PDCCH(s) in order to find possible (dynamic) grants for uplink transmission when its downlink reception is enabled (e.g., the activity governed by a DRX when configured). When Carrier Aggregation (CA) is configured, the same C-RNTI applies to all serving cells.

In addition, with Configured Grants, the gNB may allocate uplink resources for the initial HARQ transmissions to the UEs. Two types of configured uplink grants are defined:.

Type <NUM> and Type <NUM> are configured by RRC per Serving Cell and per BWP. Multiple configurations can be activated simultaneously only on different Serving Cells. For Type <NUM>, activation and deactivation are independent among the Serving Cells. For the same Serving Cell, the MAC entity is configured with either Type <NUM> or Type <NUM>.

RRC configures the following parameters when the configured grant Type <NUM> is configured:.

Upon configuration of a configured grant Type <NUM> for a serving cell by upper layers, the MAC entity may:.

Based on the 3GPP technical specifications, two types of random access procedures are supported:
<NUM>-step RA type (with MSG1), such as contention-free random access (CFRA) and/or <NUM>-step contention-based random access (CBRA).

<NUM>-step RA type (with MSGA), such as, <NUM>-step CFRA and/or <NUM>-step CBRA.

Two types of RA procedure are supported: <NUM>-step RA type with MSG1 and <NUM>-step RA type with MSGA. Both types of RA procedure support CBRA and CFRA.

The UE selects the type of random access at initiation of the RA procedure based on the network configuration:.

The network does not configure CFRA resources for <NUM>-step and <NUM>-step RA types at the same time for a BWP. CFRA with <NUM>-step RA type is only supported for handover.

The MSGA of the <NUM>-step RA type includes a preamble on PRACH and a payload on PUSCH. After MSGA transmission, the UE monitors for a response from the network within a configured window. For CFRA, upon receiving the network response, the UE ends the RA procedure. For CBRA, if contention resolution is successful upon receiving the network response, the UE ends the RA procedure; while if fallback indication is received in MSGB, the UE performs MSG3 transmission and monitors contention resolution. If contention resolution is not successful after MSG3 (re)transmission(s), the UE goes back to MSGA transmission.

If the RA procedure with <NUM>-step RA type is not completed after a number of MSGA transmissions, the UE can be configured to switch to CBRA with <NUM>-step RA type.

For random access in a cell configured with supplementary uplink (SUL), the network can explicitly signal which carrier to use (UL or SUL). Otherwise, the UE selects the SUL carrier if and only if the measured quality of the DL is lower than a broadcast threshold. UE performs carrier selection before selecting between <NUM>-step and <NUM>-step RA type. The RSRP threshold for selecting between <NUM>-step and <NUM>-step RA type can be configured separately for UL and SUL. Once started, all uplink transmissions of the RA procedure remain on the selected carrier.

When CA is configured to the UE, the UE may perform the RA procedure with <NUM>-step RA type only on the PCell while contention resolution can be cross-scheduled by the PCell.

When CA is configured to the UE, for the RA procedure with <NUM>-step RA type, the first three steps of CBRA procedure always occur on the PCell while contention resolution (step <NUM>: MSG4) can be cross-scheduled by the PCell. The three steps of a CFRA procedure started on the PCell remain on the PCell. The CFRA procedure on SCell can only be initiated by the gNB to establish timing advance for a secondary TAG. The CFRA procedure is initiated by the gNB with a PDCCH order (step <NUM>) that is sent on a scheduling cell of an activated SCell of the secondary TAG, preamble transmission (step <NUM>: MSG1) takes place on the indicated SCell, and RA Response (step <NUM>: MSG2) takes place on the PCell.

During an RA-SDT procedure involving a <NUM>-step RA procedure, the UE may transmit pending data in MSG1/MSG3 and the subsequent successive UL packets during the <NUM>-step RA procedure. The <NUM>-step RA procedure may end after the UE receives an RRCRelease message from the serving RAN, thereby ending the active SDT procedure. During an RA-SDT procedure involving a <NUM>-step RA procedure, the UE may transmit the pending data in MSGA and the subsequent UL packets during the <NUM>-step RA procedure. The <NUM>-step RA procedure may end when the UE receives an RRCRelease message from the serving RAN, thereby ending the active SDT procedure.

A quasi-earth-fixed case refers to a geographic area for one period and a different geographic period for another period. A platform such as a LEO satellite can create such quasi-earth-fixed beams if satellite beam steering is supported. Handovers typically occur in bursts for all UEs in each coverage area, e.g., every few minutes, in the quasi-earth-fixed case.

An earth-moving case refers to a different geographic area from one instant to the next. The overall coverage area of the beam keeps changing continuously. A platform such as a LEO satellite may use such Earth-moving beams and hence covers different geographic areas as the platform keeps orbiting the Earth. When an NTN cell uses an earth-moving beam, even stationary UEs experience a change in the cell frequently, e.g., every few seconds. Handovers typically occur continuously in the Earth-moving case.

In a feeder link switch case, the timing information on when a cell is going to star or stop serving the area for earth fixed scenario is broadcast to UE via system information. The feeder link switch refers to a link change between a satellite and a gateway (GW), where a GW may be collocated with a gNB. The duration of the feeder link switch is predictable based on satellite ephemeris and GW's location. The network may broadcast the feeder link switch period for UE to stop or start measurement, transmission, or reception.

An NTN refer to a network or at least one network segment that uses a spaceborne vehicle for transmission, e.g., LEO or GEO satellites. <FIG> is a diagram illustrating an NTN with an LEO satellite of transparent payload architecture, according to an example implementation of the present disclosure. As illustrated in <FIG>, the NTN is with LEO satellite <NUM> of transparent payload architecture at orbit <NUM> kilometers (km).

An NTN typically includes at least one of the following elements: <NUM>) a GW <NUM>) a gNB <NUM>) a satellite, and <NUM>) a UE. An NTN may also include a ground or earth station including a Sat-gateway and a Telemetry, Tracking, Command, and Monitoring unit (TTC).

One or several Sat-gateways are attached to a Base Station Base Band Unit (BBU) or a gNB (e.g., gNB <NUM>) that connects the NTN to a Core Network/Application Server. Node BBUs are close to Sat-gateways either co-located or at a few kilometers. Antenna diversity may be required depending on geographical location and feeder-link frequency band.

A satellite may be GEO or Non-GEO and may be part of a Satellite Constellation to ensure service continuity. A satellite may be served successively by one or more Sat-gateways. A Satellite Constellation Controller may provide each BS with satellite system data (ephemeris, satellite position, and velocity, etc.).

A feeder link (e.g., feeder link <NUM>), which is a radio link conveying information for a satellite mobile service between the Sat-gateway and the satellite. The UE (e.g., UE <NUM>) and the satellite (e.g., LEO satellite <NUM>) may be connected via a service link (e.g., service link <NUM>) or a radio link.

Additionally, the satellite may implement a transparent payload architecture. This transparent payload architecture performs radio frequency filtering, frequency conversion, and amplification. As a result, the waveform signal that the payload repeats may remain unchanged, except for frequency translation and transmit power. The satellite may generate multiple spot-beams that cover a given service area, which is bounded by its Field of View (FoV) or footprint. The footprints of these spot-beams usually have an elliptical shape. However, please also note the proposed mechanism would not be limited by the transparent payload architecture and can be applicable to the NTN satellites of regenerative payload architecture.

UE is GNSS capable. Support of UE Types can be handheld devices (NR and LTE smartphones), IoT devices (NB-IoT and eMTC), VSAT, moving platforms (aircraft, vessels, and building-mounted devices). The UE (e.g., UE <NUM>) may support GNSS functionality. The supported types of UEs may include handheld devices such as NR and LTE smartphones, IoT devices like NB-IoT and eMTC, VSATs, and moving platforms like aircraft, vessels, and building-mounted devices.

<FIG> is a flowchart of a method <NUM> for mobility enhancement, according to the present invention. It should be noted that although actions <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> are illustrated as separate actions represented as independent blocks in <FIG>, these separately illustrated actions should not be construed as necessarily order-dependent. The order in which the actions are performed in <FIG> is not intended to be construed as a limitation, and any number of the disclosed blocks may be combined in any order to implement the method, or an alternate method. Moreover, each of actions <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be performed independently of other actions and may be omitted in some implementations of the present disclosure.

In action <NUM>, a UE, that is configured with a first SDT configuration (e.g., SDT-config) by a first cell, receives an RRC release message including a suspend configuration (e.g., an RRCRelease message with a suspendConfig) from the first cell.

In action <NUM>, the UE transitions to an RRC INACTIVE state in response to receiving the RRC release message.

In action <NUM>, the UE receives, in the RRC INACTIVE state, a SIB1 including a second SDT configuration (e.g., SDT-ConfigCommon) from a second cell.

In action <NUM>, the UE camps on the second cell in response to receiving the SIB <NUM> from the second cell.

In action <NUM>, while the UE is camping on the second cell (e.g., the second cell being the current serving cell of the UE), the UE refrains from using the first SDT configuration to initiate an SDT procedure associated with the second cell in a case that the UE does not support performing the SDT procedure associated with the second cell.

In some implementations, the SDT procedure may include at least one of an RA-based SDT (RA-SDT) procedure, an SRB-based SDT (SRB-SDT) procedure, or a CG-based SDT (CG-SDT) procedure.

In some implementations, the first cell may include a TN cell (e.g., TN cell <NUM> illustrated in <FIG>) and the second cell may include an NTN cell (e.g., NTN cell <NUM> illustrated in <FIG>).

In some implementations, refraining from using the first SDT configuration (action <NUM>) may include maintaining, but not using, the first SDT configuration while the UE is camping on the second cell. For example, in a case that the UE does not support the SDT procedures associated with the second cell, the UE may still retain the first SDT configuration while the UE is camping on the second cell, but the UE does not use the first SDT configuration to initiate or perform an SDT procedure associated with the second cell.

In some implementations, refraining from using the first SDT configuration (action <NUM>) may include releasing the first SDT configuration while the UE is camping on the second cell. For example, in a case that the UE does not support the SDT procedure associated with the second cell, the UE may release the first SDT configuration once/after the second cell becomes the current serving cell of the UE.

In some implementations, the UE may transition to an RRC IDLE state while the UE is camping on the second cell. In the RRC IDLE state, the UE may also refrain from using the first SDT configuration to initiate an SDT procedure associated with the second cell, especially if the UE does not support the SDT procedures associated with the second cell.

In some implementations, the UE may initiate an RRC resume procedure associated with the second cell for uplink packet transmissions or UE capability reporting after camping on the second cell. For example, after the UE camps on the second cell, the UE may initiate an RRC Resume procedure to report its current capability regarding the SDT procedures and/or capability changes in the support for the SDT procedures to the second cell.

In some implementations, the UE may switch to camp on a third cell after camping on the second cell and initiate the SDT procedure associated with the third cell based on the first SDT configuration in a case that the UE supports performing the SDT procedure associated with the third cell, where the third cell may be the first cell or a cell other than the first cell.

In some implementations, while the UE is camping on the second cell, the UE may initiate the SDT procedure associated with the second cell based on the first SDT configuration and the second SDT configuration in a case that the UE supports performing the SDT procedure associated with the second cell.

In some implementations, the first cell and the second cell may be identical and may be either a TN cell or an NTN cell.

Leveraging method <NUM> offers technical advantages for improving <NUM> communications, not just for integrating NTNs but also for other types of networks. Method <NUM> ensures smooth transitions between cells, making the user experience and system performance better. Additionally, method <NUM> effectively handles SDT configurations, thereby addressing the co-existence challenges that can happen in various networking scenarios. Therefore, method <NUM> provides a flexible and resource-efficient way to solve challenges in network co-existence and mobility across different networks.

In some implementations, the UE may identify whether the serving cell supports one specific functionality by receiving the system information (e.g., SIB1 transmission or other SI transmission). For example, the UE may monitor whether the serving cell support small data transmission by monitoring if the serving cell broadcast SDT-ConfigCommon via SIB1 reception (e.g., SIB1 may be transmitted via broadcasting approach or UE-specific RRC signaling, such as RRCReconfiguration message). So, in some conditions, the UE may check whether the UE supports one specific target function (e.g., the SDT/CG-SDT/RA-SDT/SRB-SDT procedure initiation) (only) while/after the UE has identified that the target functionality is supported by the serving cell. In contrast, the UE may need not to further check whether the UE support the target functionality if the serving cell does not support the target functionality (e.g., SDT-ConfigCommon is absent in the SIB1 transmitted by the serving cell).

In some implementations, the serving RAN may implement connected mode mobility event by transmitting the system information (e.g., MIB/SIB1/SIB2/SIB3/SIB4/SIB5 or other SI) of one or more neighbor cell(s) via UE-specific (RRC) control signaling to the UE. For example, the serving cell (or the serving BS, which is also known as the source cell/source BS in the connected mode mobility event) may transmit the system information blocks (SIBs) of one or more candidate cells/target cells to the UE. Then, after the UE decides to select one of the candidate cells/target cells as the next serving cell of the UE, the UE may refer to/access the SIBs transmitted by the source cell. In some implementations, the next serving cell of the UE may be configured/instructed by the serving RAN (e.g., the source cell/source BS) via UE-specific (RRC) control signaling or broadcasting system information and the UE may refer to/access the SIBs transmitted by the source cell after receiving the instructions to reselect to one of the candidate/target cells as the next serving cell of the UE. In some implementations, the source cell/BS may obtain the system information blocks of neighbor cells via inter-node signaling protocols defined in 3GPP technical specifications.

<FIG> is a block diagram illustrating a node for wireless communication in accordance with various aspects of the present disclosure. As illustrated in <FIG>, node <NUM> may include transceiver <NUM>, processor <NUM>, memory <NUM>, one or more presentation components <NUM>, and at least one antenna <NUM>. Node <NUM> may also include a radio frequency (RF) spectrum band module, a BS communications module, a network communications module, and a system communications management module, Input / Output (I/O) ports, I/O components, and a power supply (not illustrated in <FIG>).

Node <NUM> may be a UE or a BS that performs various functions disclosed with reference to <FIG>.

Transceiver <NUM> has transmitter <NUM> (e.g., transmitting/transmission circuitry) and receiver <NUM> (e.g., receiving/reception circuitry) and may be configured to transmit and/or receive time and/or frequency resource partitioning information. Transceiver <NUM> may be configured to transmit in different types of subframes and slots including, but not limited to, usable, non-usable, and flexibly usable subframes and slot formats. Transceiver <NUM> may be configured to receive data and control channels.

Node <NUM> may include a variety of computer-readable media. Computer-readable media may be any available media that may be accessed by node <NUM> and include volatile (and/or non-volatile) media and removable (and/or non-removable) media.

The computer-readable media may include computer-storage media and communication media. Computer-storage media may include both volatile (and/or non-volatile media), and removable (and/or non-removable) media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or data.

Computer-storage media may include RAM, ROM, EPROM, EEPROM, flash memory (or other memory technology), CD-ROM, Digital Versatile Disks (DVD) (or other optical disk storage), magnetic cassettes, magnetic tape, magnetic disk storage (or other magnetic storage devices), etc. Computer-storage media may not include a propagated data signal. Communication media may typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanisms and include any information delivery media.

The term "modulated data signal" may mean a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Communication media may include wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media. Combinations of any of the previously listed components should also be included within the scope of computer-readable media.

Memory <NUM> may include computer-storage media in the form of volatile and/or non-volatile memory. Memory <NUM> may be removable, non-removable, or a combination thereof. Example memory may include solid-state memory, hard drives, optical-disc drives, etc. As illustrated in <FIG>, memory <NUM> may store a computer-readable and/or computer-executable instructions <NUM> (e.g., software codes) that are configured to, when executed, cause processor <NUM> to perform various functions disclosed herein, for example, with reference to <FIG>. Alternatively, instructions <NUM> may not be directly executable by processor <NUM> but may be configured to cause node <NUM> (e.g., when compiled and executed) to perform various functions disclosed herein.

Processor <NUM> (e.g., having processing circuitry) may include an intelligent hardware device, e.g., a Central Processing Unit (CPU), a microcontroller, an ASIC, etc. Processor <NUM> may include memory. Processor <NUM> may process data <NUM> and instructions <NUM> received from memory <NUM>, and information transmitted and received via transceiver <NUM>, the baseband communications module, and/or the network communications module. Processor <NUM> may also process information to send to transceiver <NUM> for transmission via antenna <NUM> to the network communications module for transmission to a CN.

One or more presentation components <NUM> may present data indications to a person or another device. Examples of presentation components <NUM> may include a display device, a speaker, a printing component, a vibrating component, etc..

Claim 1:
A method performed by a User Equipment, UE (<NUM>), for mobility enhancement, the UE (<NUM>) configured with a first Small Data Transmission, SDT, configuration by a first cell, the method comprising:
receiving (<NUM>) a Radio Resource Control, RRC, release message comprising a suspend configuration from the first cell;
transitioning (<NUM>) to an RRC INACTIVE state in response to receiving the RRC release message;
receiving (<NUM>), in the RRC INACTIVE state, a System Information Block Type <NUM>, SIB1, comprising a second SDT configuration from a second cell;
camping (<NUM>) on the second cell in response to receiving the SIB1 from the second cell; and
while the UE (<NUM>) is camping on the second cell, refraining (<NUM>) from using the first SDT configuration to initiate an SDT procedure associated with the second cell in a case that the UE (<NUM>) does not support performing the SDT procedure associated with the second cell.