Patent Description:
The present disclosure related to on-demand system information in a cellular communications system.

Small data solutions have previously been introduced in Long Term Evolution (LTE) with the focus on Machine Type Communication (MTC). For example, Release <NUM> Early Data Transmission (EDT) and Release <NUM> Preconfigured Uplink Resources (PUR) have been standardized for LTE for MTC (LTE-M) and Narrowband Internet of Things (NB-IoT). Unlike these features, the Release <NUM> Small Data Transmission (SDT) for New Radio (NR) is not directly targeting MTC use cases, and the Work Item Description (WID) includes smartphone background traffic as the justification.

The Work Item (WI) objectives outline two main objectives: Random Access Channel (RACH)-based schemes and pre-configured Physical Uplink Shared Channel (PUSCH) resources. Comparing to LTE-M and NB-IoT, the <NUM>-step RACH-based scheme is similar to Release <NUM> User Plane Early Data Transmission (UP-EDT), and pre-configured PUSCH resources is similar to Release <NUM> User Plane Preconfigured Uplink Resources (UP-PUR). Further, the Release <NUM> Small Data is only concerning data transmission in INACTIVE state and hence Control Plane (CP) optimizations of EDT and PUR are so far not relevant. <NUM>-step RACH has not been specified for LTE, and hence there is no LTE counterpart for <NUM>-step RACH-based SDT.

The <NUM>-step RA type has been used in Fourth Generation (<NUM>) LTE and is also the baseline for Fifth Generation (<NUM>) NR. The principle of this procedure in NR is shown in <FIG>. The steps of the <NUM>-step RACH procedure are as follows. Step <NUM> - Preamble transmission: The User Equipment (UE) randomly selects a RA preamble (PREAMBLE_INDEX) corresponding to a selected Synchronization Signal (SS) / Physical Broadcast Channel (PBCH) block and transmits the preamble on the Physical Random Access Channel (PRACH) occasion mapped to the selected SS/PBCH block. When the next generation Node B (gNB) detects the preamble, it estimates the Timing Advance (TA) the UE should use in order to obtain uplink (UL) synchronization at the gNB.

Step <NUM> - RA response (RAR): The gNB sends a RA response (RAR) including the TA, the Temporary Cell Radio Network Temporary Identifier (TC-RNTI) (temporary identifier) to be used by the UE, a Random Access Preamble identifier that matches the transmitted PREAMBLE_INDEX, and a grant for Msg3. The UE expects the RAR and, thus, monitors Physical Downlink Control Channel (PDCCH) addressed to Random Access Radio Network Temporary Identifier (RA-RNTI) to receive the RAR message from the gNB until the configured RAR window (ra-ResponseWindow) has expired or until the RAR has been successfully received.

From Third Generation Partnership Project (3GPP) Technical Specification (TS) <NUM>: "The MAC entity may stop ra-ResponseWindow (and hence monitoring for Random Access Response(s)) after successful reception of a Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX.

Step <NUM> - "Msg3" (UE ID or UE-specific C-RNTI): In Msg3, the UE transmits its identifier (UE ID, or more exactly the initial part of the <NUM> Temporary Mobile Subscriber Identity (<NUM>-TMSI)) for initial access or, if it is already in RRC_CONNECTED or RRC_INACTIVE mode and needs to, e.g., re-synchronize, its UE-specific Radio Network Temporary Identifier (RNTI).

If the gNB cannot decode Msg3 at the granted UL resources, it may send a Downlink Control Information (DCI) addressed to TC-RNTI for retransmission of Msg3. Hybrid Automatic Repeat Request (HARQ) retransmission is requested until the UEs restart the random access procedure from step <NUM> after reaching the maximum number of HARQ retransmissions or until Msg3 can be successfully received by the gNB.

Step <NUM> - "Msg4" (contention resolution): In Msg4, the gNB responds by acknowledging the UE ID or C-RNTI. The Msg4 gives contention resolution, i.e. only one UE ID or C-RNTI will be sent even if several UEs have used the same preamble (and the same grant for Msg3 transmission) simultaneously.

For Msg4 reception, the UE monitors TC-RNTI (if it transmitted its UE ID in Msg3) or C-RNTI (if it transmitted its C-RNTI in Msg3).

The <NUM>-step RA type gives much shorter latency than the ordinary <NUM>-step RA. In the <NUM>-step RA, the preamble and a message corresponding to Msg3 (msgA PUSCH) in the <NUM>-step RA can, depending on configuration, be transmitted in two subsequent slots. The msgA PUSCH is sent on a resource dedicated to the specific preamble. This means that both the preamble and the Msg3 face contention but contention resolution in this case means that either both preamble and Msg <NUM> are sent without collision or both collide. The <NUM>-step RA procedure is depicted in <FIG>.

Upon successful reception of msgA, the gNB responds with a msgB. The msgB may be either a "successRAR", "fallbackRAR", or "Back off". The content of msgB has been agreed as seen below. It is noted in particular that fallbackRAR provides a grant for a Msg3 PUSCH that identifies resources in which the UE should transmit the PUSCH, as well as other information.

Note: The notations "msgA" and "MsgA" are used interchangeably herein to denote message A. Similarly, the notations "msgB" and "MsgB" are used interchangeably herein to denote message B.

The possibility to replace the <NUM>-step message exchange by a <NUM>-step message exchange would lead to reduced RA latency. On the other hand, the <NUM>-step RA will consume more resources since it uses contention-based transmission of the data. This means that the resources that are configured for the data transmission may often be unused. Another difference is that <NUM>-step RA operates without a timing advance (TA) since there is no feedback from gNB on how to adjust the uplink synchronization before the data payload is transmitted in MsgA PUSCH.

If both the <NUM>-step and <NUM>-step RA are configured in a cell on shared PRACH resources (and for the UE), the UE will choose its preamble from one specific set if it wants to do a <NUM>-step RA, and from another set if it wants to do a <NUM>-step RA. Hence, a preamble partition is done to distinguish between <NUM>-step and <NUM>-step RA when shared PRACH resources are used. Alternatively, the PRACH configurations are different for the <NUM>-step and <NUM>-step RA procedure, in which case it can be deduced from where the preamble transmission is done if the UE is doing a <NUM>-step or <NUM>-step procedure.

In the 3GPP Release <NUM><NUM>-step RA type procedure, UEs are informed of the potential time-frequency resources where they may transmit MsgA PRACH and MsgA PUSCH via higher layer signaling from the network. PRACH is transmitted in periodically recurring RACH occasions ('ROs'), while PUSCH is transmitted in periodically recurring PUSCH occasions ('POs'). PUSCH occasions are described in MsgA PUSCH configurations provided by higher layer signaling. Each MsgA PUSCH configuration defines a starting time of the PUSCH occasions which is measured from the start of a corresponding RACH occasion. Multiple PUSCH occasions may be multiplexed in time and frequency in a MsgA PUSCH configuration, where POs in an Orthogonal Frequency Division Multiplexing (OFDM) symbol occupy a given number of Physical Resource Blocks (PRBs) and are adjacent in frequency, and where POs occupy 'L' contiguous OFDM symbols. POs multiplexed in time in a MsgA PUSCH configuration may be separated by a configured gap that is 'G' symbols long. The start of the first occupied OFDM symbol in a PUSCH slot is indicated via a start and length indicator value ('SLIV'). The MsgA PUSCH configuration may comprise multiple contiguous PUSCH slots, each slot containing the same number of POs. The start of the first PRB relative to the first PRB in a bandwidth part (BWP) is also given by the MsgA PUSCH configuration. Moreover, the modulation and coding scheme (MCS) for MsgA PUSCH is also given by the MsgA PUSCH configuration.

Each PRACH preamble maps to a PUSCH occasion and a Demodulation Reference Signal (DMRS) port and/or a DMRS port-scrambling sequence combination according to a procedure given in 3GPP TS <NUM>. This mapping allows a gNB to uniquely determine the location of the associated PUSCH in time and frequency as well as the DMRS port and/or scrambling from the preamble selected by the UE.

In regard to SDT procedures, NR supports RRC_INACTIVE state, and UEs with infrequent (periodic and/or aperiodic) data transmission (interchangeably referred to herein as small data transmission, or SDT) are generally maintained by the network not in RRC_IDLE but in the RRC_INACTIVE state. Until Release <NUM>, the RRC_INACTIVE state does not support data transmission. Hence, the UE has to resume the connection (i.e., move to RRC_CONNECTED state) for any downlink (DL) data reception and any UL data transmission. Connection setup and subsequently release to RRC_INACTIVE state happens for each data transmission. This results in unnecessary power consumption and signaling overhead. For this reason, support for UE transmission in RRC_INACTIVE state using the random access procedure is introduced in Release <NUM>. SDT is a procedure to transmit UL data from a UE in RRC_INACTIVE state. SDT is performed with either random access or configured grant (CG). The case in which the UE transmits UL data with random access can use both <NUM>-step RA type and <NUM>-step RA type (see description above). If the UE uses <NUM>-step RA type for a SDT procedure, then the UE transmits the UL data in the Msg3. If the UE uses <NUM>-step RA type for a SDT procedure, then the UE transmits UL data in the MsgA.

Two types of Configured Grant (CG) UL transmission schemes have been supported in NR since Release <NUM>, referred as CG Type1 and CG Type2 in the standard. The major difference between these two types of CG transmission is that, for CG Type1, an uplink grant is provided by Radio Resource Control (RRC) configuration and activated automatically, while, in the case of CG Type2, the uplink grant is provided and activated via L1 signaling, i.e., by an UL DCI with Cyclic Redundancy Check (CRC) scrambled by Configured Scheduling Radio Network Temporary Identifier (CS-RNTI). In both cases, the spatial relation used for PUSCH transmission with Configured Grant is indicated by the uplink grant, either provided by the RRC configuration or by an UL DCI.

The CG periodicity is RRC configured, and this is specified in the ConfiguredGrantConfig Information Element (IE). Different periodicity values are supported in NR depending on the subcarrier spacing.

For use in SDT, the gNB may configure the UE with CG Type1 and may also configure Reference Signal Received Power (RSRP) threshold(s) for selection of an UL carrier. The configuration is given in the RRCRelease message sent to the UE while in connected state (to move the UE into Inactive state), or alternatively in another dedicated RRC message, for example while the UE is in RRC_CONNECTED. Alternatively, the configuration is given in RRCRelease message after a SDT procedure where the UE has started the procedure in RRC_INACTIVE and where the UE stays in RRC_INACTIVE after procedure completion. The use of Configured Grant type of resource requires the UE to remain in a synchronous state in that the time alignment is maintained. Should the UE be out of time alignment, a RA type of procedure can be initiated instead (above).

In regard to NR positioning, since Release <NUM> and the introduction in NR, the LTE Positioning Protocol (LPP) protocol, which is a point-to-point communication protocol between a Location Management Function (LMF) and a target device, has been agreed to be reused for UE positioning in both NR and LTE (3GPP TS <NUM>).

At the core network, a new logical node called the LMF is the main server responsible for computing the UE position, based on the NR, Evolved Universal Terrestrial Radio Access (E-UTRA), or both Radio Access Technologies (RATs) specific positioning methods. NR Positioning Protocol A (NRPPA) is the communication protocol between a Next Generation Radio Access Network (NG-RAN) and the LMF.

The NR Positioning architecture is defined as illustrated in <FIG> (see also 3GPP TS <NUM>).

New and enhanced positioning methods have been defined in NR (see TS <NUM>) such as:.

Recent enhancements in Global Navigation Satellite System (GNSS) technology include Real Time Kinematic (RTK) GNSS, which is a differential GNSS positioning technology which enables positioning accuracy improvement from meter level to decimeter or even centimeter level in the right conditions in real-time by exploiting the carrier phase of the GNSS signal rather than only the code phase. Support for RTK GNSS in NR networks should therefore be provided and are under standardization in the Release <NUM> work item. Several positioning System Information Blocks (posSIBs) have been defined in LTE and NR for delivering RTK Assistance data. Further, there has been agreement to deliver Assistance data for Observed Time Difference of Arrival (OTDOA) and Sensor (barometric pressure sensor) for broadcast.

Below is the list of some of the posSIBs from 3GPP TS <NUM> v <NUM>.

The supported posSibType's are specified in Table <NUM>-<NUM>. The GNSS Common and Generic Assistance Data IEs are defined in clause <NUM>. The OTDOA Assistance Data IEs are defined in clause <NUM>.

On-demand System information request is a feature in NR that allows the network to only broadcast some of the system information messages when there is a UE that needs to acquire it. The UE requests such System Information messages using either msg1 or msg3 based procedures. The procedure allows a UE to request the needed information on-demand, and it allows the network to minimize the overhead in constantly broadcasting information that no UE is currently acquiring.

Further, in Release <NUM>, System Information messages can be requested by UE and provided by the network also in dedicated state using the RRC Connection Reconfiguration message.

For the RRC on-demand system information (SI) framework, the parameter si-BroadcastStatus is used to indicate if an SI message is currently being broadcasted or not. This parameter is defined as:
si-BroadcastStatus ENUMERATED {broadcasting, notBroadcasting}.

From the UE perspective, independent of whether an SI message is indicated as broadcasting or notBroadcasting, the UE obtains the SI scheduling information for the SI message from SIB1. If the SI message is indicated as broadcasting, the UE can then directly acquire the SI message based on the SI scheduling information. However, if the SI message is indicated as notBroadcasting, the UE first needs to perform the on-demand SI request procedure to the base station in order to initiate the transmission of the SI message (according to the SI scheduling information).

Currently, the on-demand broadcast is based upon the following msg1 and msg3 solutions:.

Further in 3GPP Release <NUM>, the UE can request on-demand SIB (including positioning SIBs) using a dedicated procedure as described in the following excerpt from 3GPP TS <NUM> v <NUM>.

The DedicatedSIBRequest message is used to request SIB(s) required by the UE in RRC_CONNECTED as specified in clause <NUM>.

Document <CIT> may be construed to disclose a method and apparatus from the perspective of a UE (User Equipment). The method includes the UE generating a system information request message. The method further includes the UE transmitting the system information request message to a base station through DCCH (Dedicated Control Channel) if the UE is in RRC_CONNECTED state. The method also includes the UE transmitting the system information request message to the base station through CCCH (Common Control Channel) if the UE is not in RRC_CONNECTED state.

Document "<NPL> may be construed to disclose an evaluation of agreements made in RAN1 on IDLE/INACTIVE positioning during the SI phase and its impacts on RAN2. Inter alia, the following proposals were made. Proposal <NUM>: RecquestCapabilities/ProvideCapbilities for PRS cannot be sent in RRC_IDLE/INACTIVE (<NUM>/<NUM>, <NUM>/<NUM>, <NUM>/<NUM>, <NUM>/<NUM>). Proposal <NUM>: RequestAssistanceData for DL-PRS cannot be sent for UE in RRC_IDLE/INACTIVE. (<NUM>/<NUM>, <NUM>/<NUM>). Proposal <NUM>: Current stage3 spec has already supported assistance data delivery for DL positioning during RRC_CONNECTED and on-demand SI request in RRC_IDLE/ INACITVE for IDLE/INACTIVE positioning. (<NUM>/<NUM>). Proposal <NUM>: DL-PRS configuration delivery to the UE in RRC_IDLE/INACTIVE is not supported. (<NUM>/<NUM>, <NUM>/<NUM>). Proposal <NUM>: Current stage3 spec already supports the transfer of RequestLocationInformation in RRC_CONNECTED for PRS measurement in IDLE/INACTIVE. (<NUM>/<NUM>). Proposal <NUM>: Transfer of RequestLocationInformation when the UE is in RRC_IDLE/INACTIVE is not supported (<NUM>/<NUM>, <NUM>/<NUM>). Proposal <NUM>: The report of PRS measurement performed in RRC_IDLE/INACTIVE when the UE is in RRC_INACTIVE is supported, not supported when the UE is in IDLE. (<NUM>/<NUM>, <NUM>/<NUM>). Proposal <NUM>: The report of PRS measurement performed in RRC_IDLE/INACTIVE when the UE is in RRC_CONNECTED is supported. (<NUM>/<NUM>).

Systems and methods are disclosed related to on-demand system information using Small Data Transmission (SDT) procedures.

According to the present disclosure, there are provided methods, a wireless communication device and a network node according to the independent claims. Further developments are set forth in the dependent claims.

According to a first aspect of the present disclosure, there is provided a method performed by a wireless communication device. The method comprises, while in inactive state, transmitting a message to a network node, wherein the message comprises: an identity, ID, of the wireless communication device; information that indicates one or more System Information Blocks, SIBs, and/or one or more position SIBs, posSIBs, being requested by the wireless communication device; and an indication that the wireless communication device supports a Small Data Transmission, SDT, functionality for requesting the one or more SIBs and/or the one or more posSIBs and/or an indication of a capability of the wireless communication device to obtain SIBs and/or posSIBs via downlink SDT transmission.

According to a second aspect of the present disclosure, there is provided a method performed by a network node. The method comprises, while a wireless communication device is in an inactive state, receiving a message from the wireless communication device, wherein the message comprises: an identity, ID, of the wireless communication device; information that indicates one or more System Information Blocks, SIBs, and/or one or more position SIBs, posSIBs, being requested by the wireless communication device; and an indication that the wireless communication device supports a Small Data Transmission, SDT, functionality for requesting the one or more SIBs and/or the one or more posSIBs and/or an indication of a capability of the wireless communication device to obtain SIBs and/or posSIBs via downlink SDT transmission.

According to a third aspect of the present disclosure, there is provided a wireless communication device adapted to perform the method of the first aspect.

According to a fourth aspect of the present disclosure, there is provided a network node adapted to perform the method of the second aspect.

Whenever in the following disclosure any of the above-stated aspects (independent claims) is disclosed as "optional" (e.g. due to usage of conjunctive terms, such as "can", "may", "should" etc.), it is nevertheless to be read as "mandatory".

Hereinabove and in the following, "examples" pertain to principles underlying the claimed subject-matter and/or being useful for understanding the claimed subject-matter, while "embodiments" pertain to the claimed subject-matter within the claim scope.

Whenever in the following disclosure the term "embodiment" occurs, reference is to be made to the figure description above to clarify whether an embodiment or an example is meant.

Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

Transmission/Reception Point (TRP): In some embodiments, a TRP may be either a network node, a radio head, a spatial relation, or a Transmission Configuration Indicator (TCI) state. A TRP may be represented by a spatial relation or a TCI state in some embodiments. In some embodiments, a TRP may be using multiple TCI states. In some embodiments, a TRP may a part of the gNB transmitting and receiving radio signals to/from UE according to physical layer properties and parameters inherent to that element. In some embodiments, in Multiple TRP (multi-TRP) operation, a serving cell can schedule UE from two TRPs, providing better Physical Downlink Shared Channel (PDSCH) coverage, reliability and/or data rates. There are two different operation modes for multi-TRP: single Downlink Control Information (DCI) and multi-DCI. For both modes, control of uplink and downlink operation is done by both physical layer and Medium Access Control (MAC). In single-DCI mode, UE is scheduled by the same DCI for both TRPs and in multi-DCI mode, UE is scheduled by independent DCIs from each TRP.

There currently exist certain challenge(s). With the current solution for on-demand system information, the network cannot deliver UEs System Information Block (SIB) requested via Inactive mode procedures. A UE may request on-demand system information using msg1 or msg3 (in the inactive state), but the network cannot deliver via point to point (unicast) message.

Further, the UE cannot transition to connected mode just for requesting SIBs that are currently not being broadcasted; i.e., the network cannot deliver requested on-demand system information via a connected mode procedure if the request was not made by a UE in connected mode. This is a constraint from the network perspective as it would consume large broadcast resources especially when the on-demand request originates from one UE (or very few) or even large number of UEs but in separate time occasions; in such case, the network cannot deliver point to point and is forced to deliver using broadcast.

Thus, there is a need for systems and methods in this direction for on-demand SIB delivery.

Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. In the present disclosure, embodiments of a system and method for on-demand system information (SI) request and delivery using a Small Data Transmission (SDT) framework are provided.

In one embodiment, a Medium Access Control (MAC) based procedure for on-demand SI request and delivery using the SDT framework is provided. In one embodiment, the MAC based procedure includes one or more of the following:.

In another embodiment, a Radio Resource Control (RRC) based procedure for on-demand SI request and delivery using the SDT framework is provided. In one embodiment, the RRC based procedure includes one or more of the following:.

Certain embodiments may provide one or more of the following technical advantage(s). Embodiments of present disclosure may provide one or more of the following advantages:.

<FIG> illustrates one example of a cellular communications system <NUM> in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system <NUM> is a <NUM> system (5GS) including a Next Generation RAN (NG-RAN) and a <NUM> Core (5GC); however, the present disclosure is not limited thereto. The embodiments described herein can be implemented in other types of cellular communications systems (e.g., an Evolved Packet System (EPS)) in which Small Data Transmission (SDTs) are desired. In this example, the RAN includes base stations <NUM>-<NUM> and <NUM>-<NUM>, which in the NG-RAN include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells <NUM>-<NUM> and <NUM>-<NUM>. The base stations <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as base stations <NUM> and individually as base station <NUM>. Likewise, the (macro) cells <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as (macro) cells <NUM> and individually as (macro) cell <NUM>. The RAN may also include a number of low power nodes <NUM>-<NUM> through <NUM>-<NUM> controlling corresponding small cells <NUM>-<NUM> through <NUM>-<NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells <NUM>-<NUM> through <NUM>-<NUM> may alternatively be provided by the base stations <NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as low power nodes <NUM> and individually as low power node <NUM>. Likewise, the small cells <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as small cells <NUM> and individually as small cell <NUM>. The cellular communications system <NUM> also includes a core network <NUM>, which in the <NUM> System (5GS) is referred to as the 5GC. The base stations <NUM> (and optionally the low power nodes <NUM>) are connected to the core network <NUM>.

In the following description, the wireless communication devices <NUM> are oftentimes UEs and as such sometimes referred to as UEs <NUM>, but the present disclosure is not limited thereto.

In the following, embodiments are described in the context of NR but can be applied without any loss of meaning also to LTE or any other Radio Access Technology (RAT). Further, the terms "posSIB", "positioning SIB", and "positioning information" refer to system information related to positioning that can be generally acquired by the UE via broadcast or via dedicated RRC signaling. Also, the terms "SIB" and "normal SIB" refer to the system information not related to position and that also can be acquired via broadcast or via dedicated RRC signaling.

In the following, the terms posSIB or SIB can be exchanged without loss of meaning since the same embodiments, methods, and solution can be applied to both posSIB or SIB.

As used herein, the term "Inactive mode Radio Network Temporary Identifier (I-RNTI) or "I-RNTI-Value" is used to identify the suspended UE context of a UE in RRC_INACTIVE. In one embodiment, the I-RNTI-Value is an information element defined as:
I-RNTI- Value information element.

As used herein, the term "ShortI-RNTI-Value" is used to identify the suspended UE context of a UE in RRC_INACTIVE using fewer bits compared to I-RNTI-Value. In one embodiment, the ShortI-RNTI-Value is an information element defines as:
ShortI-RNTI-Value information element.

In one embodiment, if the UE <NUM> is in RRC_INACTIVE and has the need to (re)acquire a SIB(s) or posSIB(s), the UE <NUM> sends a new uplink MAC Control Element (CE) to the network (e.g., to a network node such as, e.g., the base station <NUM> or a network node that implements at least part of the functionality of the base station <NUM>) in order to indicate which SIB(s) or posSIB(s) is needed (i.e., without transitioning completely to RRC_CONNECTED).

Also, the use case can be such that the UE <NUM> is in RRC_INACTIVE and has the need to (re)acquire a SIB or posSIB that is indicated by the network (e.g., by a network node) to only be provided by point-to-point delivery (i.e., without broadcast), and then the UE <NUM> sends this request through MAC CE. For example, via unicast tag.

The need to (re)acquire a SIB(s) or posSIB(s) may be due to the following reasons:.

Further, in another embodiment, when the sending the uplink MAC CE to the network (e.g., to the network node), the UE <NUM> may also indicate to the network (e.g., to the network node) (e.g., via the MAC CE) that this particular UE <NUM> supports the SDT functionality for requesting the SIB(s) or posSIB(s) and wants to use it. Alternatively, the network may understand whether a particular UE <NUM> support SDT functionality for requesting the SIB(s) or posSIB(s) via the UE capability or the use of LCID/eLCID in MAC CE or use of certain preamble resource group.

In one embodiment, upon receiving the request of the UE <NUM> via the uplink MAC CE that one (or more) SIBs or posSIBs are requested, the network node (e.g., the base station <NUM> such as, e.g., the gNB) may decide to perform the following actions:.

In another embodiment, a possible implementation of what is described above may include that a new eLCID is defined and the payload would contain <NUM> bits (maxSI message), as illustrated in <FIG>. Further, in one embodiment, the payload is as shown in <FIG>. The R-bit from <FIG> or new flag S shown in <FIG> can also be used to distinguish whether the request is for SIB or posSIB in the MAC payload. Further, the MAC payload may also contain the UE ID (e.g., I-RNTI) which may be, e.g., either <NUM> bits or <NUM> bits. In one embodiment, there can be a flag to distinguish also that (an example; I) as shown in <FIG>; hence, the MAC CE payload can be, for example, <NUM> bytes or <NUM> bytes. The network (e.g., network node) may deduce the I-RNTI type (e.g., short or long) based upon the MAC payload size (e.g., difference of <NUM> bytes).

<FIG> illustrates the operation of a UE <NUM> and a network node <NUM> (e.g., a base station <NUM> or a network node that implements at least some of the functionality of a base station <NUM>) in accordance with an embodiment of the MAC based solution described above. As illustrated, the UE <NUM>, when in inactive state, sends a MAC CE to the network node <NUM>, where the MAC CE indicates one or more SIBs and/or one or more posSIBs requested by the UE <NUM> (step <NUM>). In addition, in one embodiment, the MAC CE further includes an indication that the UE <NUM> supports SDT functionality for requesting the SIB(s) and/or posSIB(s) and wants to use this functionality. In another embodiment, the network node <NUM> determines whether the UE <NUM> supports SDT functionality for requesting the SIB(s) and/or posSIB(s) via UE capabilities (e.g., UE capabilities previously reported by the UE <NUM>), the use of a LCID or eLCID in the MAC CE that indicates that the UE <NUM> supports the SDT functionality, or the use of a certain RA preamble resource group by the UE <NUM> when transmitting an associated RA preamble. Responsive to receiving the MAC CE, the network node <NUM> performs one or more actions (step <NUM>). The one or more actions performed by the network node <NUM> may include sending a new downlink MAC CE to the UE <NUM> to disable the SIB or posSIB request, sending at least one of the requested SIB(s) and/or pos(SIBs) to the UE <NUM> via SDT, e.g., as part of an associated Msg4 or RRCRelease, and/or broadcasting at least one of the requested SIB(s) and/or posSIB(s) (e.g., by changing the broadcasting status flag from notBroadcasting to broadcasting).

In one embodiment, if the UE <NUM> is in RRC_INACTIVE and has the need to (re)acquire a SIB(s) or posSIB(s), the UE <NUM> sends an uplink RRC message to the network in order to request the needed SIB(s) or posSIB(s) (i.e., without transitioning completely to RRC_CONNECTED). In one embodiment, the uplink RRC request is sent according to the following:.

Further, if the UE <NUM> uses <NUM>-step RA type for SDT procedure, then the UE <NUM> transmits the UL messages in the Msg3. If the UE <NUM> uses <NUM>-step RA type for SDT procedure, then the UE <NUM> transmits UL messages in the MsgA.

In another embodiment, when sending the uplink RRC request to the network, the UE <NUM> may also indicate (e.g., in the RRC message) to the network that this particular UE <NUM> supports the SDT functionality for requesting the SIB(s) or posSIB(s) and wants to use it. Alternatively, the network may understand whether the particular UE <NUM> support SDT functionality for requesting the SIB(s) or posSIB(s) via the UE capability.

In one embodiment, the network (e.g., network node) may also enable/disable the SDT functionality for requesting the SIB(s) or posSIB(s) via adding an indication in SIB (if the network wants to disable this functionality to all UE under its coverage) or via adding an indication in a dedicated RRC message (if the network wants to disable this functionality to only a particular UE under its coverage).

In another embodiment, a possible implementation of what is described above is as follows. A bitmap or an explicit indication is added in an existing RRC message or new RRC message in order to indicate to the network with SIB/posSIB are needed. <FIG> illustrates an example in which the bitmap or explicit indication is added in an RRCSystemInfoRequest message.

Further, as the above RRC message does not have UE ID, this RRCSystemInfo message is appended after a specific MAC CE as shown in <FIG> containing the UE ID (e.g., I-RNTI) or after the RRC Resume request message of <FIG>. In such case, the MAC payload may not contain the SI request octets and would instead be provided via the RRC message.

In an embodiment, a separate Preamble group is reserved for transmitting SIB or PosSIB request for UEs supporting SDT functionality. Upon receiving such Preamble, the network would allocate an UL grant that would fit: <MAT>.

It is also possible to create a new RRC Msg which includes the UE ID + BITMAP of requested SIBs or posSIBs or to append the required attributes (BITMAP of requested SIBs/posSIBs) in any SDT specific RRC message.

<FIG> illustrates the operation of a UE <NUM> and a network node <NUM> (e.g., a base station <NUM> or a network node that implements at least some of the functionality of a base station <NUM>) in accordance with an embodiment of the RRC based solution described above. As illustrated, the UE <NUM>, when in inactive state, sends a RRC message to the network node <NUM>, where the RRC message indicates one or more SIBs and/or one or more posSIBs requested by the UE <NUM> (step <NUM>). The RRC message may be in accordance with any of the embodiments described above. Thus, the details described above are equally applicable here. Note that, in one embodiment, the RRC message is a (new) RRC message for SDT request and includes an indication of the capability of the UE <NUM> to obtain SIBs and/or posSIBs via downlink SDT transmission (e.g., a flag bit that indicates the capability of the UE <NUM> to obtain SIBs and/or posSIBs via downlink SDT transmission).

Responsive to receiving the RRC message, the network node <NUM> performs one or more actions (step <NUM>). The one or more actions performed by the network node <NUM> may include disable the SIB or posSIB request, sending at least one of the requested SIB(s) and/or pos(SIBs) to the UE <NUM> via SDT, e.g., as part of an associated Msg4 or RRCRelease, and/or broadcasting at least one of the requested SIB(s) and/or posSIB(s) (e.g., by changing the broadcasting status flag from notBroadcasting to broadcasting).

Example procedures are illustrated in <FIG> and <FIG>. The procedure of <FIG> is illustrated with respect to <NUM>-step RA. The procedure of <FIG> is illustrated with respect to <NUM>-step RA. As illustrated in <FIG>, in MsgA, the UE <NUM> transmits, to a network node <NUM>, a RRCResumeRequest + SmallData (possibly segmented) + SIB request indication (step <NUM>). In MsgB, the network node <NUM> sends (step <NUM>):.

As illustrated in <FIG>, after the UE <NUM> transmits the RA preamble to a network node <NUM> (step <NUM>) and receives a RAR from the network node <NUM> (step <NUM>), in Msg3, the UE <NUM> transmits, to the network node <NUM>, a RRCResumeRequest + SmallData (possibly segmented) + SIB request indication (step <NUM>). In Msg4, the network node <NUM> sends (step <NUM>):.

In one embodiment, the network node <NUM> or <NUM> receives a first SDT message through MsgA or Msg3, or alternatively in a configured grant allocation. The network node <NUM> or <NUM> detects that subsequent SDT transmissions are pending through either:.

The network node <NUM> or <NUM> then may provide a SIB RRC message to the UE <NUM> (step <NUM> or step <NUM>). The network node <NUM> or <NUM> may provide the SIB RRC message to the UE <NUM> by the following means:.

The below contains an example of 3GPP TS <NUM> procedural changes that implement at least some aspects of the embodiments described above. The example shows how existing procedure needs to be updated to accommodate SDT based procedure. Further, it is possible to have a separate on-demand SI procedure for SDT based Inactive mode mechanism.

<FIG> is a schematic block diagram of a network node <NUM> according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node <NUM> may be, for example, a base station <NUM> or <NUM>, a network node that implements all or part of the functionality of the base station <NUM> or gNB, the network node <NUM>, <NUM>, <NUM>, or <NUM> as described herein. As illustrated, the network node <NUM> includes a control system <NUM> that includes one or more processors <NUM> (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory <NUM>, and a network interface <NUM>. The one or more processors <NUM> are also referred to herein as processing circuitry. In addition, the network node <NUM> may include one or more radio units <NUM> that each includes one or more transmitters <NUM> and one or more receivers <NUM> coupled to one or more antennas <NUM>. The radio units <NUM> may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) <NUM> is external to the control system <NUM> and connected to the control system <NUM> via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) <NUM> and potentially the antenna(s) <NUM> are integrated together with the control system <NUM>. The one or more processors <NUM> operate to provide one or more functions of the network node <NUM> as described herein (e.g., one or more functions of a base station <NUM> or <NUM>, a network node that implements all or part of the functionality of the base station <NUM> or gNB, the network node <NUM>, <NUM>, <NUM>, or <NUM>, as described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory <NUM> and executed by the one or more processors <NUM>.

<FIG> is a schematic block diagram that illustrates a virtualized embodiment of the network node <NUM> according to some embodiments of the present disclosure. As used herein, a "virtualized" network node is an implementation of the network node <NUM> in which at least a portion of the functionality of the network node <NUM> is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node <NUM> may include the control system <NUM> and/or the one or more radio units <NUM>, as described above. The control system <NUM> may be connected to the radio unit(s) <NUM> via, for example, an optical cable or the like. The network node <NUM> includes one or more processing nodes <NUM> coupled to or included as part of a network(s) <NUM>. If present, the control system <NUM> or the radio unit(s) are connected to the processing node(s) <NUM> via the network <NUM>. Each processing node <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and a network interface <NUM>.

In this example, functions <NUM> of the network node <NUM> described herein (e.g., one or more functions of a base station <NUM> or <NUM>, a network node that implements all or part of the functionality of the base station <NUM> or gNB, the network node <NUM>, <NUM>, <NUM>, or <NUM>, as described herein) are implemented at the one or more processing nodes <NUM> or distributed across the one or more processing nodes <NUM> and the control system <NUM> and/or the radio unit(s) <NUM> in any desired manner. In some particular embodiments, some or all of the functions <NUM> of the network node <NUM> described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) <NUM>. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) <NUM> and the control system <NUM> is used in order to carry out at least some of the desired functions <NUM>. Notably, in some embodiments, the control system <NUM> may not be included, in which case the radio unit(s) <NUM> communicate directly with the processing node(s) <NUM> via an appropriate network interface(s).

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node <NUM> or a node (e.g., a processing node <NUM>) implementing one or more of the functions <NUM> of the network node <NUM> in a virtual environment according to any of the embodiments described herein is provided.

<FIG> is a schematic block diagram of the network node <NUM> according to some other embodiments of the present disclosure. The network node <NUM> includes one or more modules <NUM>, each of which is implemented in software. The module(s) <NUM> provide the functionality of the network node <NUM> described herein.

<FIG> is a schematic block diagram of a wireless communication device <NUM> (e.g., a wireless communication device <NUM> or UE <NUM>) according to some embodiments of the present disclosure. As illustrated, the wireless communication device <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and one or more transceivers <NUM> each including one or more transmitters <NUM> and one or more receivers <NUM> coupled to one or more antennas <NUM>. The transceiver(s) <NUM> includes radio-front end circuitry connected to the antenna(s) <NUM> that is configured to condition signals communicated between the antenna(s) <NUM> and the processor(s) <NUM>, as will be appreciated by on of ordinary skill in the art. The processors <NUM> are also referred to herein as processing circuitry. The transceivers <NUM> are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device <NUM> described above may be fully or partially implemented in software that is, e.g., stored in the memory <NUM> and executed by the processor(s) <NUM>. Note that the wireless communication device <NUM> may include additional components not illustrated in <FIG> such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the wireless communication device <NUM> and/or allowing output of information from the wireless communication device <NUM>), a power supply (e.g., a battery and associated power circuitry), etc..

With reference to <FIG>, in accordance with an embodiment, a communication system includes a telecommunication network <NUM>, such as a 3GPP-type cellular network, which comprises an access network <NUM>, such as a RAN, and a core network <NUM>. The access network <NUM> comprises a plurality of base stations 1606A, 1606B, 1606C, such as Node Bs, eNBs, gNBs, or other types of wireless Access Points (APs), each defining a corresponding coverage area 1608A, 1608B, 1608C. Each base station 1606A, 1606B, 1606C is connectable to the core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM> located in coverage area 1608C is configured to wirelessly connect to, or be paged by, the corresponding base station 1606C. A second UE <NUM> in coverage area 1608A is wirelessly connectable to the corresponding base station 1606A.

It is noted that the host computer <NUM>, the base station <NUM>, and the UE <NUM> illustrated in <FIG> may be similar or identical to the host computer <NUM>, one of the base stations 1606A, 1606B, 1606C, and one of the UEs <NUM>, <NUM> of <FIG>, respectively.

The wireless connection <NUM> between the UE <NUM> and the base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE <NUM> using the OTT connection <NUM>, in which the wireless connection <NUM> forms the last segment.

Claim 1:
A method performed by a wireless communication device (<NUM>) comprising:
while in inactive state, transmitting (<NUM>; <NUM>) a message to a network node, wherein the message comprises:
an identity, ID, of the wireless communication device (<NUM>);
information that indicates one or more System Information Blocks, SIBs, and/or one or more position SIBs, posSIBs, being requested by the wireless communication device (<NUM>); and
an indication that the wireless communication device (<NUM>) supports a Small Data Transmission, SDT, functionality for requesting the one or more SIBs and/or the one or more posSIBs and/or an indication of a capability of the wireless communication device (<NUM>) to obtain SIBs and/or posSIBs via downlink SDT transmission.