DELIVERY OF ON-DEMAND SIB USING SDT

Systems and methods are disclosed related to on-demand system information using Small Data Transmission (SDT) procedures. In one embodiment, a method performed by a wireless communication device comprises, while in inactive state, transmitting a message to a network node, wherein the message comprises an identity (ID) of the wireless communication device and 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. Corresponding embodiments of a wireless communication device are also disclosed. Embodiments of a network node and a method of operation thereof are also disclosed.

TECHNICAL FIELD

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

BACKGROUND

Small data solutions have previously been introduced in Long Term Evolution (LTE) with the focus on Machine Type Communication (MTC). For example, Release 15 Early Data Transmission (EDT) and Release 16 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 17 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 4-step RACH-based scheme is similar to Release 15 User Plane Early Data Transmission (UP-EDT), and pre-configured PUSCH resources is similar to Release 16 User Plane Preconfigured Uplink Resources (UP-PUR). Further, the Release 17 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. 2-step RACH has not been specified for LTE, and hence there is no LTE counterpart for 2-step RACH-based SDT.

The 4-step RA type has been used in Fourth Generation (4G) LTE and is also the baseline for Fifth Generation (5G) NR. The principle of this procedure in NR is shown inFIG.1. The steps of the 4-step RACH procedure are as follows.

Step 1—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 2—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) 38.321: “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 3—“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 5G Temporary Mobile Subscriber Identity (5G-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 1 after reaching the maximum number of HARQ retransmissions or until Msg3 can be successfully received by the gNB.

Step 4—“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 2-step RA type gives much shorter latency than the ordinary 4-step RA. In the 2-step RA, the preamble and a message corresponding to Msg3 (msgA PUSCH) in the 4-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 3 are sent without collision or both collide. The 2-step RA procedure is depicted inFIG.2.

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 4-step message exchange by a 2-step message exchange would lead to reduced RA latency. On the other hand, the 2-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 2-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 4-step and 2-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 4-step RA, and from another set if it wants to do a 2-step RA. Hence, a preamble partition is done to distinguish between 4-step and 2-step RA when shared PRACH resources are used. Alternatively, the PRACH configurations are different for the 2-step and 4-step RA procedure, in which case it can be deduced from where the preamble transmission is done if the UE is doing a 2-step or 4-step procedure.

In the 3GPP Release 16 2-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 38.213. 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 16, 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 17. 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 4-step RA type and 2-step RA type (see description above). If the UE uses 4-step RA type for a SDT procedure, then the UE transmits the UL data in the Msg3. If the UE uses 2-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 15, 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 15 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 37.355).

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 inFIG.3(see also 3GPP TS 38.305)

New and enhanced positioning methods have been defined in NR (see TS 38.305) such as:NR E-CID;Multi-Round Trip Time (RTT) Positioning;Downlink Angle-of-Departure (DL-AoD);Downlink Time Difference of Arrival (DL-TDOA);Uplink Time Difference of Arrival (UL-TDOA);Uplink Angle of Arrival (UL-AoA), including the Azimuth of Arrival (A-AoA) and the Zenith of Arrival (Z-AoA).

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 16 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 37.355 v 16.3.0

Mapping of posSibType to Assistance Data Element
The supported posSibType's are specified in Table 7.2-1. The GNSS Common and Generic Assistance Data IEs are defined in clause 6.5.2.2. The OTDOA Assistance Data IEs are defined in clause 7.4.2.

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 16, System Information messages can be requested by UE and provided by the network also in dedicated state using the RRC Connection Reconfiguration message.

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).

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

DedicatedSIBRequest
The DedicatedSIBRequest message is used to request SIB(s) required by the UE in RRC_CONNECTED as specified in clause 5.2.2.3.5.
Signalling radio bearer: SRB1

RLC-SAP: AM

Direction: UE to Network

Summary

Systems and methods are disclosed related to on-demand system information using Small Data Transmission (SDT) procedures. In one embodiment, a method performed by a wireless communication device comprises, while in inactive state, transmitting a message to a network node, wherein the message comprises an identity (ID) of the wireless communication device and 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. In this manner, the wireless communication device is enabled to request on-demand system information without transitioning to connected mode.

In one embodiment, the message comprises a Medium Access Control (MAC) Control Element (CE) that comprises the information that indicates the one or more SIBs and/or the one or more posSIBs being requested by the wireless communication device. In one embodiment, the MAC CE further comprises an indication that the wireless communication device supports SDT functionality for requesting the one or more SIBs and/or the one or more posSIBs. In another embodiment, the wireless communication device indicates, to the network node, that the wireless communication device supports SDT functionality for requesting the one or more SIBs and/or the one or more posSIBs via: capability information reported to the network node, use of a Logical Channel Identity (LCID) or enhanced Logical Channel Identity (eLCID) in the MAC CE, or use of a certain random access preamble resource group for transmission of an associated random access preamble.

In one embodiment, the MAC CE further comprises the identity of the wireless communication device. In one embodiment, the identity of the wireless communication device is either an Inactive mode Radio Network Temporary Identifier (I-RNTI) or Short I-RNTI of the wireless communication device. In one embodiment, the MAC CE further comprises an indicator that indicates whether the identity of the wireless communication device comprised in the MAC CE is an I-RNTI or a Short I-RNTI.

In one embodiment, the MAC CE further comprises information that indicates whether the one or more SIBs and/or the one or more posSIBs being requested by the wireless communication device are one or more SIBs or one or more posSIBs.

In one embodiment, the MAC CE comprises a subheader that comprises eLCID, wherein the eLCID comprises a plurality of bits that that indicate which of a plurality of SIBs and/or posSIBs are being requested by the wireless communication device. In one embodiment, the MAC CE comprises a flag in the subheader or in the eLCID that indicates whether the one or more SIBs and/or the one or more posSIBs being requested by the wireless communication device are one or more SIBs or one or more posSIBs. In one embodiment, the eLCID further comprises the identity of the wireless communication device. In one embodiment, the identity of the wireless communication device is either an I-RNTI or Short I-RNTI of the wireless communication device. In one embodiment, the eLCID further comprises an indicator that indicates whether the identity of the wireless communication device comprised in the eLCID is an I-RNTI or a Short I-RNTI.

In one embodiment, the message comprises a Radio Resource Control (RRC) message that comprises the information that indicates the one or more SIBs and/or the one or more posSIBs being requested by the wireless communication device. In one embodiment, the RRC message further comprises an indication that the wireless communication device supports a 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. In one embodiment, the information that indicates the one or more SIBs and/or the one or more posSIBs being requested by the wireless communication device comprises a bitmap or explicit indication that indicates one or more SIBs and/or one or more posSIBs being requested by the wireless communication device.

In one embodiment, transmitting the message comprises transmitting the RRC message to be used for communication of SDT framework instead of a legacy RRC message that is normally used when transitioning from an idle/inactive state or in a connected state. In one embodiment, transmitting the message comprises embedding the RRC message comprising information that indicates a capability of receiving SIBs and/or posSIBs using SDT framework within a legacy RRC message that is normally used when transitioning from an idle/inactive state or in a connected state. In one embodiment, transmitting the message comprises transmitting the RRC message in either a Msg3 of a 4-step random access for a SDT procedure or MsgA of a 2-step random access for a SDT procedure.

In one embodiment, the identity of the wireless communication device is not included in the RRC message, but is included in a MAC CE transmitted by the wireless communication device to the network node either before or after the RRC message.

In one embodiment, the method further comprises receiving at least one of the one or more SIBs and/or at least one of the one or more posSIBs as part of a Msg 4 of an associated random access or as part of an RRC Release message.

In one embodiment, the method further comprises receiving at least one of the one or more SIBs and/or at least one of the one or more posSIBs via broadcast. In one embodiment, receiving the at least one of the one or more SIBs and/or the at least one of the one or more posSIBs via broadcast comprises receiving a broadcast status flag(s) associated to the at least one of the one or more SIBs and/or the at least one of the one or more posSIBs where the broadcast status flag(s) is(are) changed to indicate that the at least one of the one or more SIBs and/or the at least one of the one or more posSIBs are broadcasted.

In one embodiment, the method further comprises receiving a message that disables the request for the one or more SIBs and/or the one or more posSIBs.

In one embodiment, transmitting the message comprises transmitting a MsgA in a 2-step random access, where the MsgA comprises a random access preamble, a RRC Resume Request, data, and the message.

In one embodiment, transmitting the message comprises transmitting (1002) a Msg3 in a 4-step random access, where the Msg3 comprises a RRC Resume Request, data, and the message.

Corresponding embodiments of a wireless communication device are also disclosed. In one embodiment, a wireless communication device is adapted to, while in inactive state, transmit a message to a network node, wherein the message comprise an ID of the wireless communication device and information that indicates one or more SIBs and/or one or more posSIBs being requested by the wireless communication device.

In another embodiment, a wireless communication device comprises one or more transmitters, one or more receivers, and processing circuitry associated with the one or more transmitters and the one or more receivers. The processing circuitry is configured to cause the wireless communication device to, while in inactive state, transmit a message to a network node, wherein the message comprise an ID of the wireless communication device and information that indicates one or more SIBs and/or one or more posSIBs being requested by the wireless communication device.

Embodiments of a method performed by a network node are also disclosed. In one embodiment, a method performed by a network node comprises, while a wireless communication device is in an inactive state, receiving a message from the wireless communication device, wherein the message comprises an ID of the wireless communication device and information that indicates one or SIBs and/or one or more posSIBs being requested by the wireless communication device.

Corresponding embodiments of a network node are also disclosed. In one embodiment, a network node is adapted to, while a wireless communication device is in an inactive state, receive a message from the wireless communication device, wherein the message comprises an ID of the wireless communication device and information that indicates one or SIBs and/or one or more posSIBs being requested by the wireless communication device.

In another embodiment, a network node comprises processing circuitry configured to cause the network node to, while a wireless communication device is in an inactive state, receive a message from the wireless communication device, wherein the message comprises an ID of the wireless communication device and information that indicates one or SIBs and/or one or more posSIBs being requested by the wireless communication device.

DETAILED DESCRIPTION

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:An existing Logical Channel Identity (LCID)/enhanced LCID (eLCID) for SDT or a new LCID/eLCID is defined where the UE includes or uses this as part of MsgA/Msg3 Transmission.The MAC CE including this LCID/eLCID has payloads with the SIBs request (e.g., Bit indicating which SIB is requested).Upon receiving such a request, the network (e.g., a network node) provides downlink (DL) Data using SDT framework (e.g., as part of Msg4/RRCRelease) message or subsequent DL transmission in Inactive state.

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:The network provides information via SIB broadcast that SDT based delivery is supported or enabled/disabled. This can also be provided by dedicated signaling.A spare bit from the RRCSystemInfoRequest-IEs of the RRCSystemInfoRequest illustrated inFIG.22is used to indicate that UE supports SDT, and the network may choose to deliver by means of point-to-point delivery.Instead of the below RRCSystemInfoRequest message, it is possible that the UE sends a new RRC message for SDT request and includes the capability of obtaining SIBs (posSIBs) via DL SDT transmission with a flag bit.Alternatively, the network may also determine that the UE is supporting SDT based upon the use of new LCID/eLCID in MAC CE.

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:Power saving mechanisms are essential for RAN based procedures. According to embodiments described herein, the UE is able to transmit and receive data while keeping the RRC status to RRC_INACTIVE and thus avoiding transitioning to RRC_CONNECTED. This means that higher signaling overhead and power consumption to achieve the RRC transition is avoided.Embodiments of the present disclosure may provide network resource savings as the network does not have to deliver the SIB using broadcast.Embodiments of the present disclosure may be especially useful where the UE can use this mechanism to retrieve positioning SIBs (posSIBs) such as Global Navigation Satellite System (GNSS) Almanac or reference stations which are slow varying or static and can also be large data not suitable for broadcast.

FIG.4illustrates one example of a cellular communications system400in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system400is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G 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 stations402-1and402-2, 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) cells404-1and404-2. The base stations402-1and402-2are generally referred to herein collectively as base stations402and individually as base station402. Likewise, the (macro) cells404-1and404-2are generally referred to herein collectively as (macro) cells404and individually as (macro) cell404. The RAN may also include a number of low power nodes406-1through406-4controlling corresponding small cells408-1through408-4. The low power nodes406-1through406-4can 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 cells408-1through408-4may alternatively be provided by the base stations402. The low power nodes406-1through406-4are generally referred to herein collectively as low power nodes406and individually as low power node406. Likewise, the small cells408-1through408-4are generally referred to herein collectively as small cells408and individually as small cell408. The cellular communications system400also includes a core network410, which in the 5G System (5GS) is referred to as the 5GC. The base stations402(and optionally the low power nodes406) are connected to the core network410.

The base stations402and the low power nodes406provide service to wireless communication devices412-1through412-5in the corresponding cells404and408. The wireless communication devices412-1through412-5are generally referred to herein collectively as wireless communication devices412and individually as wireless communication device412. In the following description, the wireless communication devices412are oftentimes UEs and as such sometimes referred to as UEs412, 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:

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:

MAC Based Solution

In one embodiment, if the UE412is in RRC_INACTIVE and has the need to (re)acquire a SIB(s) or posSIB(s), the UE412sends a new uplink MAC Control Element (CE) to the network (e.g., to a network node such as, e.g., the base station402or a network node that implements at least part of the functionality of the base station402) 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 UE412is 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 UE412sends 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:a request from an upper layer at the UE412,a stored SIB(s) or posSIB(s) at the UE412is outdated or not valid anymore, ora particular SIB(s) or posSIB(s) is requested to be acquired to configure or perform a certain functionality (e.g., Sidelink or Non-private network).

Further, in another embodiment, when the sending the uplink MAC CE to the network (e.g., to the network node), the UE412may also indicate to the network (e.g., to the network node) (e.g., via the MAC CE) that this particular UE412supports the SDT functionality for requesting the SIB(s) or posSIB(s) and wants to use it. Alternatively, the network may understand whether a particular UE412support 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 UE412via the uplink MAC CE that one (or more) SIBs or posSIBs are requested, the network node (e.g., the base station402such as, e.g., the gNB) may decide to perform the following actions:1. the network node sends a new downlink MAC CE to the UE412to disable the SIB(s) or posSIB(s) request via the SDT framework, or2. the network node sends the requested SIB(s) or posSIB(s) as part of Msg4 or RRCRelease according to the SDT framework, or3. the network node broadcasts the requested SIB(s) or posSIB(s) (e.g., by changing the broadcasting status flag from notBroadcasting to broadcasting).

In another embodiment, a possible implementation of what is described above may include that a new eLCID is defined and the payload would contain 32 bits (maxSI message), as illustrated inFIG.5. Further, in one embodiment, the payload is as shown inFIG.6. The R-bit fromFIG.5or new flag S shown inFIG.6can 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 24 bits or 40 bits. In one embodiment, there can be a flag to distinguish also that (an example; I) as shown inFIG.6; hence, the MAC CE payload can be, for example, 10 bytes or 8 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 2 bytes).

FIG.7illustrates the operation of a UE412and a network node700(e.g., a base station402or a network node that implements at least some of the functionality of a base station402) in accordance with an embodiment of the MAC based solution described above. As illustrated, the UE412, when in inactive state, sends a MAC CE to the network node700, where the MAC CE indicates one or more SIBs and/or one or more posSIBs requested by the UE412(step702). In addition, in one embodiment, the MAC CE further includes an indication that the UE412supports SDT functionality for requesting the SIB(s) and/or posSIB(s) and wants to use this functionality. In another embodiment, the network node700determines whether the UE412supports SDT functionality for requesting the SIB(s) and/or posSIB(s) via UE capabilities (e.g., UE capabilities previously reported by the UE412), the use of a LCID or eLCID in the MAC CE that indicates that the UE412supports the SDT functionality, or the use of a certain RA preamble resource group by the UE412when transmitting an associated RA preamble. Responsive to receiving the MAC CE, the network node700performs one or more actions (step704). The one or more actions performed by the network node700may include sending a new downlink MAC CE to the UE412to disable the SIB or posSIB request, sending at least one of the requested SIB(s) and/or pos(SIBs) to the UE412via 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).

RRC Based Solution

In one embodiment, if the UE412is in RRC_INACTIVE and has the need to (re)acquire a SIB(s) or posSIB(s), the UE412sends 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:A bitmap or an explicit indication is added in an existing RRC message in order to indicate to the network which SIB(s) or posSIB(s) is(are) needed.This new bitmap or explicit indication is conveyed to the network (e.g., to a network node) according to either of the following options:1. A new or an existing RRC message is sent to the network in order to indicate to the network which SIB(s) or posSIB(s) is (are) needed, and this new RRC message will be used instead of one of the legacy RRC messages normally used when performing the transition from RRC_IDLE to RRC_CONNECTED (e.g., instead of the RRCResumeRequest).2. A new or an existing RRC message is sent to the network embedded (i.e., in a container—OCTET STRING) in one of the legacy RRC messages normally used when performing the transition from RRC_IDLE to RRC_CONNECTED (e.g., instead of the RRCResumeRequest).

Further, if the UE412uses 4-step RA type for SDT procedure, then the UE412transmits the UL messages in the Msg3. If the UE412uses 2-step RA type for SDT procedure, then the UE412transmits UL messages in the MsgA.

In another embodiment, when sending the uplink RRC request to the network, the UE412may also indicate (e.g., in the RRC message) to the network that this particular UE412supports the SDT functionality for requesting the SIB(s) or posSIB(s) and wants to use it. Alternatively, the network may understand whether the particular UE412support 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.23illustrates 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 inFIG.6containing the UE ID (e.g., I-RNTI) or after the RRC Resume request message ofFIG.24. 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:MAC CE+RRC Resume Request+RRC System Info Request Msg

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.8illustrates the operation of a UE412and a network node700(e.g., a base station402or a network node that implements at least some of the functionality of a base station402) in accordance with an embodiment of the RRC based solution described above. As illustrated, the UE412, when in inactive state, sends a RRC message to the network node700, where the RRC message indicates one or more SIBs and/or one or more posSIBs requested by the UE412(step802). 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 UE412to obtain SIBs and/or posSIBs via downlink SDT transmission (e.g., a flag bit that indicates the capability of the UE412to obtain SIBs and/or posSIBs via downlink SDT transmission).

Responsive to receiving the RRC message, the network node700performs one or more actions (step804). The one or more actions performed by the network node800may include disable the SIB or posSIB request, sending at least one of the requested SIB(s) and/or pos(SIBs) to the UE412via 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).

SDT Procedure and Network Delivery of SIB Via SDT

Example procedures are illustrated inFIGS.9and10. The procedure ofFIG.9is illustrated with respect to 2-step RA. The procedure ofFIG.10is illustrated with respect to 4-step RA. As illustrated inFIG.9, in MsgA, the UE412transmits, to a network node900, a RRCResumeRequest+SmallData (possibly segmented)+SIB request indication (step902). In MsgB, the network node900sends (step904):RRCrelease if no other data expected, no config update pursued, orRRC connection request+possibly a dynamic grant to move UE to connected, orRRCrelease+Downlink assignment+possibly a configured grant configuration/single UL configured grant.

As illustrated inFIG.10, after the UE412transmits the RA preamble to a network node1000(step1002) and receives a RAR from the network node1000(step1004), in Msg3, the UE412transmits, to the network node1000, a RRCResumeRequest+SmallData (possibly segmented)+SIB request indication (step1006). In Msg4, the network node1000sends (step1008):RRCrelease if no other data expected, no config update pursued, orRRC connection request+possibly a dynamic grant to move UE to connected, orRRCrelease+Downlink assignment+possibly a configured grant configuration/single UL configured grant.

In one embodiment, the network node900or1000receives a first SDT message through MsgA or Msg3, or alternatively in a configured grant allocation. The network node900or1000detects that subsequent SDT transmissions are pending through either:that the user data in the MAC Sub Protocol Data Unit (PDU) is a segmented Radio Link Control (RLC) payload,or by an explicit indication, e.g. SIB request, or both in addition,or alternatively by receiving the SIB RRC configuration request using a method as described in this document in previous sections

The network node900or1000then may provide a SIB RRC message to the UE412(step906or step1010). The network node900or1000may provide the SIB RRC message to the UE412by the following means:RRCRelease is accompanied with a subsequent downlink assignment for which the UE412stays in RRC INACTIVE until successfully decoded.The DL assignment (c.f. SPS, Semi Persistent Scheduling) contains the SIB RRC configurationA DL assignment (grant) scheduled by the network node900, for which after successful decoding follows with a RRC release message.

The below contains an example of 3GPP TS 38.331 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.

5.2.2.3.3 Request for On-Demand System Information

The UE shall:1> if SIB1 includes si-Schedulinglnfo containing si-RequestConfigSUL and criteria to select supplementary uplink as defined in TS 38.321[13], clause 5.1.1 is met:2> If SIB1 includes si-Schedulinalnfocontaininq sdtSupported, triqqcer the lower layer to initiate the Small Data Transmission procedure on supplementary uplink in accordance with TS MAC specification using the PRACH preamble(s) and PRACH resource(s) in si-RequestConfigSUL corresponding to the SI message(s) that the UE requires to operate within the cell, and for which si-BroadcastStatus is set to notBroadcastinc;3> retrieve/receive the requested SI message(s) via downlink small data transmission:2> else trigger the lower layer to initiate the Random Access procedure on supplementary uplink in accordance with [3] using the PRACH preamble(s) and PRACH resource(s) in si-RequestConfigSUL corresponding to the SI message(s) that the UE requires to operate within the cell, and for which si-BroadcastStatus is set to notBroadcasting;3> if acknowledgement for SI request is received from lower layers:4> acquire the requested SI message(s) as defined in sub-clause 5.2.2.3.2, immediately;

Additional Aspects

FIG.11is a schematic block diagram of a network node1100according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node1100may be, for example, a base station402or406, a network node that implements all or part of the functionality of the base station402or gNB, the network node700,800,900, or1000as described herein. As illustrated, the network node1100includes a control system1102that includes one or more processors1104(e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory1106, and a network interface1108. The one or more processors1104are also referred to herein as processing circuitry. In addition, the network node1100may include one or more radio units1110that each includes one or more transmitters1112and one or more receivers1114coupled to one or more antennas1116. The radio units1110may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s)1110is external to the control system1102and connected to the control system1102via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s)1110and potentially the antenna(s)1116are integrated together with the control system1102. The one or more processors1104operate to provide one or more functions of the network node1100as described herein (e.g., one or more functions of a base station402or406, a network node that implements all or part of the functionality of the base station402or gNB, the network node700,800,900, or1000, as described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory1106and executed by the one or more processors1104.

FIG.12is a schematic block diagram that illustrates a virtualized embodiment of the network node1100according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a “virtualized” network node is an implementation of the network node1100in which at least a portion of the functionality of the network node1100is 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 node1100may include the control system1102and/or the one or more radio units1110, as described above. The control system1102may be connected to the radio unit(s)1110via, for example, an optical cable or the like. The network node1100includes one or more processing nodes1200coupled to or included as part of a network(s)1202. If present, the control system1102or the radio unit(s) are connected to the processing node(s)1200via the network1202. Each processing node1200includes one or more processors1204(e.g., CPUs, ASICs, FPGAs, and/or the like), memory1206, and a network interface1208.

In this example, functions1210of the network node1100described herein (e.g., one or more functions of a base station402or406, a network node that implements all or part of the functionality of the base station402or gNB, the network node700,800,900, or1000, as described herein) are implemented at the one or more processing nodes1200or distributed across the one or more processing nodes1200and the control system1102and/or the radio unit(s)1110in any desired manner. In some particular embodiments, some or all of the functions1210of the network node1100described 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)1200. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s)1200and the control system1102is used in order to carry out at least some of the desired functions1210. Notably, in some embodiments, the control system1102may not be included, in which case the radio unit(s)1110communicate directly with the processing node(s)1200via an appropriate network interface(s).

FIG.13is a schematic block diagram of the network node1100according to some other embodiments of the present disclosure. The network node1100includes one or more modules1300, each of which is implemented in software. The module(s)1300provide the functionality of the network node1100described herein. This discussion is equally applicable to the processing node1200ofFIG.12where the modules1300may be implemented at one of the processing nodes1200or distributed across multiple processing nodes1200and/or distributed across the processing node(s)1200and the control system1102.

FIG.14is a schematic block diagram of a wireless communication device1400(e.g., a wireless communication device412or UE412) according to some embodiments of the present disclosure. As illustrated, the wireless communication device1400includes one or more processors1402(e.g., CPUs, ASICs, FPGAs, and/or the like), memory1404, and one or more transceivers1406each including one or more transmitters1408and one or more receivers1410coupled to one or more antennas1412. The transceiver(s)1406includes radio-front end circuitry connected to the antenna(s)1412that is configured to condition signals communicated between the antenna(s)1412and the processor(s)1402, as will be appreciated by on of ordinary skill in the art. The processors1402are also referred to herein as processing circuitry. The transceivers1406are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device1400described above may be fully or partially implemented in software that is, e.g., stored in the memory1404and executed by the processor(s)1402. Note that the wireless communication device1400may include additional components not illustrated inFIG.14such 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 device1400and/or allowing output of information from the wireless communication device1400), a power supply (e.g., a battery and associated power circuitry), etc.

FIG.15is a schematic block diagram of the wireless communication device1400according to some other embodiments of the present disclosure. The wireless communication device1400includes one or more modules1500, each of which is implemented in software. The module(s)1500provide the functionality of the wireless communication device1400described herein.

With reference toFIG.16, in accordance with an embodiment, a communication system includes a telecommunication network1600, such as a 3GPP-type cellular network, which comprises an access network1602, such as a RAN, and a core network1604. The access network1602comprises a plurality of base stations1606A,1606B,1606C, such as Node Bs, eNBs, gNBs, or other types of wireless Access Points (APs), each defining a corresponding coverage area1608A,1608B,1608C. Each base station1606A,1606B,1606C is connectable to the core network1604over a wired or wireless connection1610. A first UE1612located in coverage area1608C is configured to wirelessly connect to, or be paged by, the corresponding base station1606C. A second UE1614in coverage area1608A is wirelessly connectable to the corresponding base station1606A. While a plurality of UEs1612,1614are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station1606.

The telecommunication network1600is itself connected to a host computer1616, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server, or as processing resources in a server farm. The host computer1616may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections1618and1620between the telecommunication network1600and the host computer1616may extend directly from the core network1604to the host computer1616or may go via an optional intermediate network1622. The intermediate network1622may be one of, or a combination of more than one of, a public, private, or hosted network; the intermediate network1622, if any, may be a backbone network or the Internet; in particular, the intermediate network1622may comprise two or more sub-networks (not shown).

The communication system ofFIG.16as a whole enables connectivity between the connected UEs1612,1614and the host computer1616. The connectivity may be described as an Over-the-Top (OTT) connection1624. The host computer1616and the connected UEs1612,1614are configured to communicate data and/or signaling via the OTT connection1624, using the access network1602, the core network1604, any intermediate network1622, and possible further infrastructure (not shown) as intermediaries. The OTT connection1624may be transparent in the sense that the participating communication devices through which the OTT connection1624passes are unaware of routing of uplink and downlink communications. For example, the base station1606may not or need not be informed about the past routing of an incoming downlink communication with data originating from the host computer1616to be forwarded (e.g., handed over) to a connected UE1612. Similarly, the base station1606need not be aware of the future routing of an outgoing uplink communication originating from the UE1612towards the host computer1616.

Example implementations, in accordance with an embodiment, of the UE, base station, and host computer discussed in the preceding paragraphs will now be described with reference toFIG.17. In a communication system1700, a host computer1702comprises hardware1704including a communication interface1706configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system1700. The host computer1702further comprises processing circuitry1708, which may have storage and/or processing capabilities. In particular, the processing circuitry1708may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The host computer1702further comprises software1710, which is stored in or accessible by the host computer1702and executable by the processing circuitry1708. The software1710includes a host application1712. The host application1712may be operable to provide a service to a remote user, such as a UE1714connecting via an OTT connection1716terminating at the UE1714and the host computer1702. In providing the service to the remote user, the host application1712may provide user data which is transmitted using the OTT connection1716.

The communication system1700further includes a base station1718provided in a telecommunication system and comprising hardware1720enabling it to communicate with the host computer1702and with the UE1714. The hardware1720may include a communication interface1722for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system1700, as well as a radio interface1724for setting up and maintaining at least a wireless connection1726with the UE1714located in a coverage area (not shown inFIG.17) served by the base station1718. The communication interface1722may be configured to facilitate a connection1728to the host computer1702. The connection1728may be direct or it may pass through a core network (not shown inFIG.17) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware1720of the base station1718further includes processing circuitry1730, which may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The base station1718further has software1732stored internally or accessible via an external connection.

The communication system1700further includes the UE1714already referred to. The UE's1714hardware1734may include a radio interface1736configured to set up and maintain a wireless connection1726with a base station serving a coverage area in which the UE1714is currently located. The hardware1734of the UE1714further includes processing circuitry1738, which may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The UE1714further comprises software1740, which is stored in or accessible by the UE1714and executable by the processing circuitry1738. The software1740includes a client application1742. The client application1742may be operable to provide a service to a human or non-human user via the UE1714, with the support of the host computer1702. In the host computer1702, the executing host application1712may communicate with the executing client application1742via the OTT connection1716terminating at the UE1714and the host computer1702. In providing the service to the user, the client application1742may receive request data from the host application1712and provide user data in response to the request data. The OTT connection1716may transfer both the request data and the user data. The client application1742may interact with the user to generate the user data that it provides.

It is noted that the host computer1702, the base station1718, and the UE1714illustrated inFIG.17may be similar or identical to the host computer1616, one of the base stations1606A,1606B,1606C, and one of the UEs1612,1614ofFIG.16, respectively. This is to say, the inner workings of these entities may be as shown inFIG.17and independently, the surrounding network topology may be that ofFIG.16.

InFIG.17, the OTT connection1716has been drawn abstractly to illustrate the communication between the host computer1702and the UE1714via the base station1718without explicit reference to any intermediary devices and the precise routing of messages via these devices. The network infrastructure may determine the routing, which may be configured to hide from the UE1714or from the service provider operating the host computer1702, or both. While the OTT connection1716is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

The wireless connection1726between the UE1714and the base station1718is 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 UE1714using the OTT connection1716, in which the wireless connection1726forms the last segment.

A measurement procedure may be provided for the purpose of monitoring data rate, latency, and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection1716between the host computer1702and the UE1714, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection1716may be implemented in the software1710and the hardware1704of the host computer1702or in the software1740and the hardware1734of the UE1714, or both. In some embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection1716passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which the software1710,1740may compute or estimate the monitored quantities. The reconfiguring of the OTT connection1716may include message format, retransmission settings, preferred routing, etc.; the reconfiguring need not affect the base station1718, and it may be unknown or imperceptible to the base station1718. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer1702's measurements of throughput, propagation times, latency, and the like. The measurements may be implemented in that the software1710and1740causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection1716while it monitors propagation times, errors, etc.

Some example embodiments of the present disclosure are as follows:

GROUP A EMBODIMENTS

Embodiment 1: A method performed by a wireless communication device (412) comprising:while in inactive state, transmitting (702;802) a message to a network node, wherein the message comprises either:a Medium Access Control, MAC, Control Element, CE, that comprises 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 (412); ora Radio Resource Control, RRC, message that comprises information that indicates one or more SIBs and/or one or more posSIBs being requested by the wireless communication device (412).

Embodiment 2: The method of embodiment 1 wherein the messages comprises a MAC CE that comprises information that indicates one or more SIBs and/or one or more posSIBs being requested by the wireless communication device (412).

Embodiment 3: The method of embodiment 2 wherein the MAC CE further comprises an indication that the wireless communication device (412) supports SmallData Transmission, SDT, functionality for requesting the one or more SIBs and/or the one or more posSIBs.

Embodiment 4: The method of embodiment 2 wherein the wireless communication device (412) indicates, to the network node, that the wireless communication device (412) supports SmallData Transmission, SDT, functionality for requesting the one or more SIBs and/or the one or more posSIBs via:capability information reported to the network node, oruse of a Logical Channel Identity, LCID, or enhanced Logical Channel Identity, eLCID, in the MAC CE, oruse of a certain random access preamble resource group for transmission of an associated random access preamble.

Embodiment 5: The method of any of embodiments 2 to 4 wherein the MAC CE further comprises an identity of the wireless communication device (412).

Embodiment 6: The method of embodiment 5 wherein the identity of the wireless communication device (412) is either an I-RNTI or Short I-RNTI of the wireless communication device (412).

Embodiment 7: The method of embodiment 6 wherein the MAC CE further comprises an indicator that indicates whether the identity of the wireless communication device (412) comprised in the MAC CE is an I-RNTI or a Short I-RNTI.

Embodiment 8: The method of any of embodiments 2 to 7 wherein the MAC CE further comprises information that indicates whether the one or more SIBs and/or the one or more posSIBs being requested by the wireless communication device (412) are one or more SIBs or one or more posSIBs.

Embodiment 9: The method of any of embodiments 2 to 8 wherein the MAC CE comprises a subheader that comprises an enhanced, eLCID, wherein the eLCID comprises a plurality of bits that that indicate which of a plurality of SIBs and/or posSIBs are being requested by the wireless communication device (412).

Embodiment 10: The method of embodiment 9 wherein the MAC CE comprises a flag in the subheader or in the eLCID that indicates whether the one or more SIBs and/or the one or more posSIBs being requested by the wireless communication device (412) are one or more SIBs or one or more posSIBs.

Embodiment 11: The method of embodiment 9 or 10 wherein the eLCID further comprises an identity of the wireless communication device (412).

Embodiment 12: The method of embodiment 11 wherein the identity of the wireless communication device (412) is either an I-RNTI or Short I-RNTI of the wireless communication device (412).

Embodiment 13: The method of embodiment 12 wherein the eLCID further comprises an indicator that indicates whether the identity of the wireless communication device (412) comprised in the eLCID is an I-RNTI or a Short I-RNTI.

Embodiment 14: The method of embodiment 1 wherein the messages comprises a RRC message that comprises:information that indicates one or more SIBs and/or one or more posSIBs being requested by the wireless communication device (412); andan identity of the wireless communication device (412) and/or an indication that the wireless communication device (412) 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 (412) to obtain SIBs and/or posSIBs via downlink SDT transmission.

Embodiment 15: The method of embodiment 14 wherein the RRC message comprises a bitmap or explicit indication that indicates one or more SIBs and/or one or more posSIBs being requested by the wireless communication device (412).

Embodiment 16: The method of embodiment 14 or 15 wherein transmitting (802) the message comprises transmitting (802) the RRC message to be used for communication of small data transmission (SDT) framework instead of a legacy RRC message that is normally used when transitioning from an idle/inactive state or in a connected state.

Embodiment 17: The method of embodiment 14 or 15 wherein transmitting (802) the message comprises embedding (802) the RRC message comprising capability of receiving SIBs/posSIBs using small data transmission framework (SDT) within a legacy RRC message that is normally used when transitioning from an idle/inactive state or in a connected state.

Embodiment 18: The method of any of embodiments 14 to 17 wherein transmitting (802) the message comprises transmitting (802) the RRC message in either a Msg3 of a 4-step random access for SDT procedure or MsgA of a 2-step random access for SDT procedure.

Embodiment 19: The method of any of embodiments 14 to 18 wherein the RRC message further comprises information that indicates that the wireless communication device (412) supports a Small Data Transmission, SDT, functionality for requesting the one or more SIBs and/or the one or more posSIBs.

Embodiment 20: The method of any of embodiments 14 to 19 wherein an identity of the wireless communication device (412) is not included in the RRC message, but is included in a MAC CE transmitted by the wireless communication device (412) to the network node either before or after the RRC message.

Embodiment 21: The method of any of embodiments 1 to 20 further comprising receiving (704) at least one of the one or more SIBs and/or at least one of the one or more posSIBs (e.g., via SDT) as part of a Msg 4 of an associated random access or as part of an RRC Release message.

Embodiment 22: The method of any of embodiments 1 to 20 further comprising receiving (704;804) at least one of the one or more SIBs and/or at least one of the one or more posSIBs via broadcast.

Embodiment 23: The method of embodiment 22 wherein receiving (704;804) the at least one of the one or more SIBs and/or the at least one of the one or more posSIBs via broadcast comprises receiving a broadcast status flag(s) associated to the at least one of the one or more SIBs and/or the at least one of the one or more posSIBs where the broadcast status flag(s) is(are) changed to indicate that the at least one of the one or more SIBs and/or the at least one of the one or more posSIBs are broadcasted.

Embodiment 24: The method of any of embodiments 1 to 20 further comprising receiving (704;804) a message that disables the request for the one or more SIBs and/or the one or more posSIBs.

Embodiment 25: The method of any of embodiments 1 to 24 wherein transmitting the message (702;802) comprises transmitting (902) a MsgA in a 2-step random access, where the MsgA comprises a random access preamble, a RRC Resume Request, data, and the message.

Embodiment 26: The method of any of embodiments 1 to 24 wherein transmitting the message (702;802) comprises transmitting (1002) a Msg3 in a 4-step random access, where the Msg3 comprises a RRC Resume Request, data, and the message.

Embodiment 27: The method of any of the previous embodiments, further comprising: providing user data; and forwarding the user data to a host computer via the transmission to the base station.

GROUP B EMBODIMENTS

Embodiment 28: A method performed by a network node (700;800;900;1000), the method comprising:while a wireless communication device (412) is in an inactive state, receiving (702;802) a message from the wireless communication device (412), wherein the message comprises either:a Medium Access Control, MAC, Control Element, CE, that comprises 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 (412); ora Radio Resource Control, RRC, message that comprises information that indicates one or more SIBs and/or one or more posSIBs being requested by the wireless communication device (412).

Embodiment 29: The method of embodiment 28 wherein the messages comprises a MAC CE that comprises information that indicates one or more SIBs and/or one or more posSIBs being requested by the wireless communication device (412).

Embodiment 30: The method of embodiment 29 wherein the MAC CE further comprises an indication that the wireless communication device (412) supports Small Data Transmission, SDT, functionality for requesting the one or more SIBs and/or the one or more posSIBs.

Embodiment 31: The method of embodiment 29 wherein the network node determines that the wireless communication device (412) supports Small Data Transmission, SDT, functionality for requesting the one or more SIBs and/or the one or more posSIBs via:capability information reported from the wireless communication device (412) to the network node, oruse of a Logical Channel Identity, LCID, or enhanced Logical Channel Identity, eLCID, in the MAC CE, oruse of a certain random access preamble resource group for transmission of an associated random access preamble.

Embodiment 32: The method of any of embodiments 29 to 31 wherein the MAC CE further comprises an identity of the wireless communication device (412).

Embodiment 33: The method of embodiment 32 wherein the identity of the wireless communication device (412) is either an I-RNTI or Short I-RNTI of the wireless communication device (412).

Embodiment 34: The method of embodiment 33 wherein the MAC CE further comprises an indicator that indicates whether the identity of the wireless communication device (412) comprised in the MAC CE is an I-RNTI or a Short I-RNTI.

Embodiment 35: The method of any of embodiments 29 to 34 wherein the MAC CE further comprises information that indicates whether the one or more SIBs and/or the one or more posSIBs being requested by the wireless communication device (412) are one or more SIBs or one or more posSIBs.

Embodiment 36: The method of any of embodiments 29 to 35 wherein the MAC CE comprises a subheader that comprises an enhanced, eLCID, wherein the eLCID comprises a plurality of bits that that indicate which of a plurality of SIBs and/or posSIBs are being requested by the wireless communication device (412).

Embodiment 37: The method of embodiment 36 wherein the MAC CE comprises a flag in the subheader or in the eLCID that indicates whether the one or more SIBs and/or the one or more posSIBs being requested by the wireless communication device (412) are one or more SIBs or one or more posSIBs.

Embodiment 38: The method of embodiment 36 or 37 wherein the eLCID further comprises an identity of the wireless communication device (412).

Embodiment 39: The method of embodiment 38 wherein the identity of the wireless communication device (412) is either an I-RNTI or Short I-RNTI of the wireless communication device (412).

Embodiment 40: The method of embodiment 39 wherein the eLCID further comprises an indicator that indicates whether the identity of the wireless communication device (412) comprised in the eLCID is an I-RNTI or a Short I-RNTI.

Embodiment 41: The method of embodiment 28 wherein the messages comprises a RRC message that comprises information that indicates one or more SIBs and/or one or more posSIBs being requested by the wireless communication device (412).

Embodiment 42: The method of embodiment 41 wherein the RRC message comprises a bitmap or explicit indication that indicates one or more SIBs and/or one or more posSIBs being requested by the wireless communication device (412).

Embodiment 43: The method of embodiment 41 or 42 wherein receiving (802) the message comprises receiving (802) the RRC message instead of a legacy RRC message that is normally used when transitioning from an idle state or a connected state.

Embodiment 44: The method of embodiment 41 or 42 wherein receiving (802) the message comprises receiving (802) the RRC message embedded within a legacy RRC message that is normally used when transitioning from an idle state or a connected state.

Embodiment 45: The method of any of embodiments 41 to 44 wherein receiving (802) the message comprises receiving (802) the RRC message in either a Msg3 of a 4-step random access for SDT procedure or MsgA of a 2-step random access for SDT procedure.

Embodiment 46: The method of any of embodiments 41 to 45 wherein the RRC message further comprises information that indicates that the wireless communication device (412) supports a Small Data Transmission, SDT, functionality for requesting the one or more SIBs and/or the one or more posSIBs.

Embodiment 47: The method of any of embodiments 41 to 46 wherein an identity of the wireless communication device (412) is not included in the RRC message, but is included in a MAC CE received from the wireless communication device (412) either before or after the RRC message.

Embodiment 48: The method of any of embodiments 28 to 47 further comprising transmitting (704) at least one of the one or more SIBs and/or at least one of the one or more posSIBs to the wireless communication device (412) (e.g., via SDT) as part of a Msg 4 of an associated random access or as part of an RRC Release message.

Embodiment 49: The method of any of embodiments 28 to 47 further comprising broadcasting (704;804) at least one of the one or more SIBs and/or at least one of the one or more posSIBs.

Embodiment 50: The method of embodiment 49 wherein broadcasting (704;804) the at least one of the one or more SIBs and/or the at least one of the one or more posSIBs comprises sending a broadcast status flag(s) associated to the at least one of the one or more SIBs and/or the at least one of the one or more posSIBs where the broadcast status flag(s) is(are) changed to indicate that the at least one of the one or more SIBs and/or the at least one of the one or more posSIBs are broadcasted.

Embodiment 51: The method of any of embodiments 28 to 47 further comprising transmitting (704;804) a message that disables the request for the one or more SIBs and/or the one or more posSIBs.

Embodiment 52: The method of any of embodiments 28 to 51 wherein receiving the message (702;802) comprises receiving (902) a MsgA in a 2-step random access, where the MsgA comprises a random access preamble, a RRC Resume Request, data, and the message.

Embodiment 53: The method of any of embodiments 28 to 51 wherein receiving the message (702;802) comprises receiving (1002) a Msg3 in a 4-step random access, where the Msg3 comprises a RRC Resume Request, data, and the message.

Embodiment 54: The method of any of the previous embodiments, further comprising: obtaining user data; and forwarding the user data to a host computer or a wireless communication device.

GROUP C EMBODIMENTS

Embodiment 55: A wireless communication device comprising: processing circuitry configured to perform any of the steps of any of the Group A embodiments; and power supply circuitry configured to supply power to the wireless communication device.

Embodiment 56: A base station comprising: processing circuitry configured to perform any of the steps of any of the Group B embodiments; and power supply circuitry configured to supply power to the base station.

Embodiment 57: A User Equipment, UE, comprising:an antenna configured to send and receive wireless signals;radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry;the processing circuitry being configured to perform any of the steps of any of the Group A embodiments;an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry;an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; anda battery connected to the processing circuitry and configured to supply power to the UE.

Embodiment 58: A communication system including a host computer comprising:processing circuitry configured to provide user data; anda communication interface configured to forward the user data to a cellular network for transmission to a User Equipment, UE;wherein the cellular network comprises a base station having a radio interface and processing circuitry, the base station's processing circuitry configured to perform any of the steps of any of the Group B embodiments.

Embodiment 59: The communication system of the previous embodiment further including the base station.

Embodiment 60: The communication system of the previous 2 embodiments, further including the UE, wherein the UE is configured to communicate with the base station.

Embodiment 61: The communication system of the previous 3 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application, thereby providing the user data; and the UE comprises processing circuitry configured to execute a client application associated with the host application.

Embodiment 63: The method of the previous embodiment, further comprising, at the base station, transmitting the user data.

Embodiment 64: The method of the previous 2 embodiments, wherein the user data is provided at the host computer by executing a host application, the method further comprising, at the UE, executing a client application associated with the host application.

Embodiment 65: A User Equipment, UE, configured to communicate with a base station, the UE comprising a radio interface and processing circuitry configured to perform the method of the previous 3 embodiments.

Embodiment 66: A communication system including a host computer comprising: processing circuitry configured to provide user data; and a communication interface configured to forward user data to a cellular network for transmission to a User Equipment, UE; wherein the UE comprises a radio interface and processing circuitry, the UE's components configured to perform any of the steps of any of the Group A embodiments.

Embodiment 67: The communication system of the previous embodiment, wherein the cellular network further includes a base station configured to communicate with the UE.

Embodiment 68: The communication system of the previous 2 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application, thereby providing the user data; and the UE's processing circuitry is configured to execute a client application associated with the host application.

Embodiment 70: The method of the previous embodiment, further comprising at the UE, receiving the user data from the base station.

Embodiment 71: A communication system including a host computer comprising: communication interface configured to receive user data originating from a transmission from a User Equipment, UE, to a base station; wherein the UE comprises a radio interface and processing circuitry, the UE's processing circuitry configured to perform any of the steps of any of the Group A embodiments.

Embodiment 72: The communication system of the previous embodiment, further including the UE.

Embodiment 73: The communication system of the previous 2 embodiments, further including the base station, wherein the base station comprises a radio interface configured to communicate with the UE and a communication interface configured to forward to the host computer the user data carried by a transmission from the UE to the base station.

Embodiment 76: A method implemented in a communication system including a host computer, a base station, and a User Equipment, UE, the method comprising: at the host computer, receiving user data transmitted to the base station from the UE, wherein the UE performs any of the steps of any of the Group A embodiments.

Embodiment 77: The method of the previous embodiment, further comprising, at the UE, providing the user data to the base station.

Embodiment 78: The method of the previous 2 embodiments, further comprising: at the UE, executing a client application, thereby providing the user data to be transmitted; and at the host computer, executing a host application associated with the client application.

Embodiment 81: The communication system of the previous embodiment further including the base station.

Embodiment 82: The communication system of the previous 2 embodiments, further including the UE, wherein the UE is configured to communicate with the base station.

Embodiment 83: The communication system of the previous 3 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application; and the UE is configured to execute a client application associated with the host application, thereby providing the user data to be received by the host computer.

Embodiment 84: A method implemented in a communication system including a host computer, a base station, and a User Equipment, UE, the method comprising: at the host computer, receiving, from the base station, user data originating from a transmission which the base station has received from the UE, wherein the UE performs any of the steps of any of the Group A embodiments.

Embodiment 85: The method of the previous embodiment, further comprising at the base station, receiving the user data from the UE.

Embodiment 86: The method of the previous 2 embodiments, further comprising at the base station, initiating a transmission of the received user data to the host computer.