On-demand SIB delivery using SDT

Abstract

Systems and methods relating to on-demand system information using small data transmission (SDT) procedures are disclosed. In one embodiment, the method performed by a wireless communication device includes sending a message to a network node while in an inactive state, the message including an identity (ID) of the wireless communication device and information indicating one or more system information blocks (SIBs) and / or one or more positioning SIBs (posSIBs) that have been requested by the wireless communication device. Corresponding embodiments of the wireless communication device are also disclosed. Embodiments of a network node and a method of operation thereof are also disclosed.

Description

[Technical field]

[0001] Related Applications This application claims the benefit of Provisional Patent Application Serial No. 63 / 159,173, filed on March 10, 2021, the disclosure of which is incorporated herein in its entirety.

[0002] FIELD This disclosure relates to on-demand system information in cellular communication systems. [Background technology]

[0003] Small data solutions have been introduced so far in Long Term Evolution (LTE) with a focus on Machine Type Communication (MTC). For example, Early Data Transmission (EDT) in Release 15 and Preconfigured Uplink Resource (PUR) in Release 16 have been standardized for LTE for MTC (LTE-M) and Narrowband Internet of Things (NB-IoT). Unlike these features, Small Data Transmission (SDT) for New Radio (NR) in Release 17 does not directly target MTC use cases and the Work Item Description (WID) includes smartphone background traffic as a justification.

[0004] The objective of the Work Item (WI) states two main objectives: a Random Access Channel (RACH) based scheme and pre-configured Physical Uplink Shared Channel (PUSCH) resources. Compared to LTE-M and NB-IoT, the 4-step RACH based scheme is similar to the User Plane Early Data Transmission (UP-EDT) in Release 15, and the pre-configured PUSCH resources are similar to the User Plane Preconfigured Uplink Resource (UP-PUR) in Release 16. Furthermore, small data in Release 17 only concerns data transmission in the INACTIVE state, and therefore control plane (CP) optimization of EDT and PUR is not relevant for now. A 2-step RACH is not specified for LTE, and therefore there is no LTE counterpart for 2-step RACH based SDT.

[0005] The 4-step RA type is used in 4G LTE and is also the baseline for 5G NR. The principle of this procedure in NR is shown in Figure 1. The steps of the 4-step RACH procedure are as follows:

[0006] Step 1 - Preamble transmission: A User Equipment (UE) randomly selects an RA preamble (PREAMBLE_INDEX) corresponding to a selected Synchronization Signal (SS) / Physical Broadcast Channel (PBCH) block and transmits the preamble on a Physical Random Access Channel (PRACH) opportunity mapped to the selected SS / PBCH block. When a Next Generation Node B (gNB) detects the preamble, it estimates the Timing Advance (TA) that the UE should use to obtain Uplink (UL) synchronization at the gNB.

[0007] Step 2 - RA Response (RAR):The gNB sends an RA response (RAR) containing the TA, the Temporary Cell Radio Network Temporary Identifier (TC-RNTI) (temporary identifier) ​​to be used by the UE, the random access preamble identifier matching the transmitted PREAMBLE_INDEX, and a grant for Msg3. The UE expects the RAR and thus receives the RAR message from the gNB by monitoring the Physical Downlink Control Channel (PDCCH) addressed to the Random Access Radio Network Temporary Identifier (RA-RNTI) until the configured RAR window (ra-ResponseWindow) expires or until the RAR is successfully received.

[0008] From the 3rd Generation Partnership Project (3GPP®) Technical Specification (TS) 38.321: "A MAC entity may stop the ra-ResponseWindow (and therefore stop monitoring for random access responses) after successfully receiving a random access response that contains a random access preamble identifier that matches the transmitted PREAMBLE_INDEX."

[0009] Step 3 - "Msg3" (UE ID or UE specific C-RNTI): In Msg3, the UE sends its identifier (UE ID, or more precisely 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 resynchronize its UE specific Radio Network Temporary Identifier (RNTI).

[0010] If the gNB is unable to decode Msg3 in the granted UL resources, it may send Downlink Control Information (DCI) addressed to the TC-RNTI for retransmission of Msg3. Hybrid Automatic Repeat Request (HARQ) is requested until the UE restarts the random access procedure from step 1 after the maximum number of HARQ retransmissions is reached, and until Msg3 may be successfully received by the gNB.

[0011] Step 4 - "Msg4" (Conflict Resolution): In Msg4, the gNB responds by acknowledging the UE ID or C-RNTI. Msg4 provides contention resolution, i.e. only one UE ID or C-RNTI is transmitted even if several UEs are simultaneously using the same preamble (and the same grant for Msg3 transmission).

[0012] When Msg4 is received, the UE monitors the TC-RNTI (if the UE ID of the UE is transmitted in Msg3) or the C-RNTI (if the C-RNTI of the UE is transmitted in Msg3).

[0013] The 2-step RA type provides a much shorter latency than the normal 4-step RA. In 2-step RA, the preamble and message corresponding to Msg3 (msgA PUSCH) in 4-step RA can be transmitted in the following two slots depending on the configuration. The msgA PUSCH is transmitted on a resource dedicated to the specific preamble. This means that both the preamble and Msg3 face contention, but the contention resolution in this case means that both the preamble and Msg3 are transmitted without collision or both collide. The 2-step RA procedure is shown in Figure 2.

[0014] Upon successful reception of msgA, the gNB responds with msgB, which can be either "successRAR", "fallbackRAR" or "Back off". The content of msgB is agreed upon as follows: Note in particular that fallbackRAR provides a grant for Msg3 PUSCH, identifying the resources on which the UE should transmit PUSCH, as well as other information.

[0015] 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.

[0016] The possibility of replacing the 4-step message exchange with a 2-step message exchange leads to a reduction in RA latency. On the other hand, 2-step RA consumes more resources since it uses contention-based data transmission. This means that resources configured for data communication may often go unused. Another difference is that 2-step RA works without Timing Advance (TA), since there is no feedback from the gNB on how to adjust the uplink synchronization before the data payload is transmitted on the MsgA PUSCH.

[0017] If both 4-step RA and 2-step RA are configured in a cell (and for a UE) on shared PRACH resources, the UE selects its preamble from one particular set if it wants to do 4-step RA and from the other set if it wants to do 2-step RA. Thus, a preamble partition is done to distinguish between 4-step RA and 2-step RA when shared PRACH resources are used. Alternatively, the PRACH configuration is different for 2-step and 4-step RA procedures, in which case it can be deduced from where the preamble transmission is made if the UE is doing a 2-step or 4-step procedure.

[0018] In the 3GPP Release 16 two-step RA type procedure, the UE is informed of potential time-frequency resources on which it may transmit MsgA PRACH and MsgA PUSCH via higher layer signaling from the network. PRACH is transmitted in periodically recurring RACH opportunities ("RO"), while PUSCH is transmitted in periodically recurring PUSCH opportunities ("PO"). PUSCH opportunities are represented in MsgA PUSCH configurations provided by higher layer signaling. Each MsgA PUSCH configuration defines the start time of the PUSCH opportunity, measured from the start of the corresponding RACH opportunity. Multiple PUSCH opportunities may be multiplexed in time and frequency in a MsgA PUSCH configuration, where a PO within an Orthogonal Frequency Division Multiplexing (OFDM) symbol occupies a given number of Physical Resource Blocks (PRBs) and is contiguous in frequency, with the PO occupying "L" consecutive OFDM symbols. The POs multiplexed in time in the MsgA PUSCH configuration may be separated by a configured gap, which 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 include multiple consecutive PUSCH slots, each slot including the same number of POs. The start of the first PRB relative to the first PRB in the bandwidth portion (BWP) is also given by the MsgA PUSCH configuration. Furthermore, the modulation and coding scheme (MCS) for the MsgA PUSCH is also given by the MsgA PUSCH configuration.

[0019] Each PRACH preamble is mapped to a PUSCH opportunity and a Demodulation Reference Signal (DMRS) port and / or a DMRS port-scrambling sequence combination according to the procedures given in 3GPP TS 38.213. This mapping is determined by the location of the associated PUSCH in time and frequency, This allows the gNB to uniquely determine the DMRS port and / or scrambling from the preamble selected by the UE.

[0020] For the SDT procedure, NR supports the RRC_INACTIVE state, and UEs with infrequent (periodic and / or aperiodic) data transmissions (herein synonymously referred to as small data transmission, or SDT) are generally maintained by the network in the RRC_INACTIVE state, rather than RRC_IDLE. Until Release 16, the RRC_INACTIVE state does not support data transmission. Thus, the UE needs to resume the connection (i.e., move to the RRC_CONNECTED state) for any downlink (DL) data reception and any UL data transmission. The connection setup to the RRC_INACTIVE state and subsequent release is done for every data transmission. This results in unnecessary power consumption and signaling overhead. For this reason, Release 17 introduces support for UE transmission in the RRC_INACTIVE state using a random access procedure. SDT is a procedure for transmitting UL data from a UE in the RRC_INACTIVE state. SDT is performed using either random access or configured grant (CG). In the case where the UE transmits UL data using random access, both 4-step and 2-step RA types can be used (see explanation above). If the UE uses the 4-step RA type for the SDT procedure, the UE transmits UL data in Msg3. If the UE uses the 2-step RA type for the SDT procedure, the UE transmits UL data in MsgA.

[0021] In NR, since Release 15, two types of configuration grant (CG) UL transmission schemes are supported, called CG type 1 and CG type 2. The main difference between these two types of CG transmission is that in the case of CG type 1, the uplink grant is provided by the Radio Resource Control (RRC) configuration and is activated automatically, while in the case of CG type 2, the uplink grant is provided and activated by L1 signaling (i.e., by a UL DCI with a cyclic redundancy check (CRC) scrambled by the Configured Scheduling Radio Network Temporary Identifier (CS-RNTI)). In both cases, the spatial relationship used for PUSCH transmission with configuration grant is indicated by the uplink grant provided by either the RRC configuration or the UL DCI.

[0022] The CG periodicity is RRC configured and is specified in the ConfiguredGrantConfig information element (IE). In NR, different periodicity values ​​are supported depending on the subcarrier spacing.

[0023] For use in SDT, the gNB may configure the UE with CG type 1 and may further configure the Reference Signal Received Power (RSRP) threshold(s) for UL carrier selection. The configuration may be given in an RRCRelease message sent to the UE while in connected state (to move the UE to inactive state) or in another dedicated RRC message, for example while the UE is in RRC_CONNECTED. Alternatively, the configuration may be given in an RRCRelease message after the SDT procedure, in which case the UE initiates the procedure in RRC_INACTIVE, and the UE remains in RRC_INACTIVE after the procedure is completed. The use of configuration grant type resources requires that the UE remains synchronized, in that time alignment is maintained. If the UE is out of time alignment, an RA type procedure may be initiated instead (see above).

[0024] Regarding NR positioning, since its introduction in Release 15 and NR, It has been agreed that the LTE Positioning Protocol (LPP) protocol, which is a point-to-point communication protocol between the Location Management Function (LMF) and the target device, will be reused for UE positioning in both NR and LTE (3GPP TS 37.355).

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

[0026] The NR positioning architecture is defined as illustrated in FIG. 3 (see also 3GPP TS 38.305).

[0027] New extended positioning methods are defined in NR (see TS 38.305): ● NR E-CID; ●Multiple 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 Azimuth Angle of Arrival (A-AoA) and Zenith Angle of Arrival (Z-AoA).

[0028] Recent enhancements in Global Navigation Satellite System (GNSS) technology include Real Time Kinematic (RTK) GNSS, a differential GNSS positioning technique that allows for improved positioning accuracy in real time, from meter level to decimeter or centimeter level in the right conditions, by utilizing the carrier phase of the GNSS signal rather than only the code phase. Therefore, support for RTK GNSS in NR networks should be provided and is being standardized in a Release 16 work item. Several positioning system information blocks (posSIBs) have been defined in LTE and NR to deliver RTK assistance data. In addition, it has been agreed to deliver Observed Time Difference of Arrival (OTDOA) and sensor (barometric pressure sensor) assistance data for broadcast.

[0029] Below is a partial listing of posSIB from 3GPP TS 37.355 v 16.3.0. TIFF0007641395000001.tif156145

[0030] On-demand system information request is a feature in NR that allows the network to broadcast only parts of system information messages if there are UEs that need to obtain them. UEs request such system information messages using either msg1 or msg3 based procedures. These procedures allow UEs to request required information on demand, allowing the network to minimize the overhead of constantly broadcasting information that the UE does not currently have.

[0031] Furthermore, in Release 16, system information messages can be requested by the UE and provided by the network in a dedicated state as well, using RRC connection reconfiguration messages.

[0032] For the RRC on-demand System Information (SI) framework, the parameter si-BroadcastStatus is used to indicate whether an SI message is currently being broadcast or not. This parameter is defined as follows: si-BroadcastStatus ENUMERATED {broadcasting, notBroadcasting}

[0033] From the UE's perspective, regardless of whether the 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 directly obtain the SI message based on the SI scheduling information. However, if the SI message is indicated as notBroadcasting, the UE needs to first perform an on-demand SI request procedure to the base station to start transmitting the SI message (according to the SI scheduling information).

[0034] Currently, on-demand broadcasting is based on the following msg1 and msg3 solutions: ● Broadcast (Msg1 option): Msg1 SI Request RACH Procedure (PRACH, "RAR") Broadcast SI messages (for a while) ● Broadcast (Msg3 option): 〇 Msg3 SI request RACH procedure (PRACH, RAR, RRCSystemInfoRequest, "Msg4") Broadcast SI messages (for a while)

[0035] Furthermore, in 3GPP Release 16, the UE may request on-demand SIBs (including positioning SIBs) using a dedicated procedure as described in the following excerpt from 3GPP TS 38.331 v 16.3.0: TIFF0007641395000002.tif188143 Summary of the Invention

[0036] A system and method relating to on-demand system information using a small data transmission (SDT) procedure is disclosed. In one embodiment, the method performed by a wireless communication device includes sending a message to a network node while in an inactive state, the message including an identity (ID) of the wireless communication device and information indicating one or more system information blocks (SIBs) and / or one or more position SIBs (posSIBs) that have been requested by the wireless communication device. In this manner, the wireless communication device is able to request on-demand system information without transitioning to a connected mode.

[0037] In one embodiment, the message includes a Media Access Control (MAC) CE (Control Element) including the information indicating 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 includes 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 one embodiment, the wireless communication device informs 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 an Extended Logical Channel Identity (eLCID) in the MAC CE, or use of a specific random access preamble resource group for transmission of an associated random access preamble.

[0038] In one embodiment, the MAC CE further includes 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 a short I-RNTI of the wireless communication device. In one embodiment, the MAC CE further includes an indicator indicating whether the identity of the wireless communication device included in the MAC CE is an I-RNTI or a short I-RNTI.

[0039] In one embodiment, the MAC CE further includes information indicating whether the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device are one or more SIBs or one or more posSIBs.

[0040] In one embodiment, the MAC CE includes a sub-header including an eLCID, the eLCID including a number of bits indicating which of a number of SIBs and / or posSIBs are requested by the wireless communication device. In one embodiment, the MAC CE includes a flag in the sub-header or the eLCID indicating whether the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device are one or more SIBs or one or more posSIBs. In one embodiment, the eLCID further includes the identity of the wireless communication device. In one embodiment, the identity of the wireless communication device is either an I-RNTI or a short I-RNTI of the wireless communication device. In one embodiment, the eLCID further includes an indicator indicating whether the identity of the wireless communication device included in the eLCID is an I-RNTI or a short I-RNTI.

[0041] In one embodiment, the message comprises a radio resource control (RRC) message including the information indicating the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device. In one embodiment, the RRC message further includes an indication that the wireless communication device supports an SDT capability to request the one or more SIBs and / or the one or more posSIBs and / or an indication of the capability of the wireless communication device to obtain SIBs and / or posSIBs via a downlink SDT transmission. In one embodiment, the information indicating the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device comprises a bitmap or an explicit indication indicating the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device.

[0042] In one embodiment, transmitting the message includes transmitting the RRC message to be used for SDT framework communication instead of a legacy RRC message normally used in a connected state or when transitioning from an idle / inactive state. In one embodiment, transmitting the message includes embedding the RRC message including information indicating an ability to receive SIBs and / or posSIBs using an SDT (Small Data Transmission) framework in a legacy RRC message normally used in a connected state or when transitioning from an idle / inactive state. In one embodiment, transmitting the message includes transmitting the RRC message in either Msg3 of a 4-step random access for SDT procedure or MsgA of a 2-step random access for SDT procedure.

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

[0044] In one embodiment, the method further includes receiving at least one of the one or more SIBs and / or at least one of the one or more posSIBs as part of an associated random access Msg4 or as part of an RRC release message.

[0045] In one embodiment, the method further includes 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 at least one of the one or more SIBs and / or at least one of the one or more posSIBs via broadcast includes receiving a broadcast status flag associated with the at least one of the one or more SIBs and / or the at least one of the one or more posSIBs, wherein the broadcast status flag is modified 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 is broadcast.

[0046] In one embodiment, the method further includes receiving a message invalidating the request for the one or more SIBs and / or the one or more posSIBs.

[0047] In one embodiment, transmitting the message includes transmitting MsgA in two-step random access, the MsgA including a random access preamble, an RRC resume request, data, and the message.

[0048] In one embodiment, transmitting the message includes transmitting Msg3 in a four-step random access, the Msg3 including an RRC resume request, data, and the message.

[0049] Corresponding embodiments of a wireless communication device are also disclosed. In one embodiment, the wireless communication device is adapted to send a message to a network node while in an inactive state, the message comprising an ID of the wireless communication device and information indicative of one or more SIBs and / or one or more posSIBs requested by the wireless communication device. The wireless communication device is configured to send a message to a network node while in an inactive state, the message comprising an ID of the wireless communication device and information indicative of one or more SIBs and / or one or more posSIBs requested by the wireless communication device.

[0050] In another embodiment, a wireless communication device comprises one or more transmitters, one or more receivers, and a processing circuit associated with the one or more transmitters and the one or more receivers, the processing circuit configured to cause the wireless communication device to transmit a message to a network node while in an inactive state, the message including an identity of the wireless communication device and information indicating one or more SIBs and / or one or more posSIBs that have been requested by the wireless communication device.

[0051] Also disclosed are embodiments of a method performed by a network node. In one embodiment, the method performed by a network node comprises receiving a message from a wireless communication device while the wireless communication device is in an inactive state, the message comprising an identity of the wireless communication device and information indicating one or more SIBs and / or one or more posSIBs that have been requested by the wireless communication device.

[0052] Corresponding embodiments of a network node are also disclosed. In one embodiment, the network node is configured to receive a message from a wireless communication device while the wireless communication device is in an inactive state, the message including an ID of the wireless communication device and information indicating one or more SIBs and / or one or more posSIBs that have been requested by the wireless communication device.

[0053] In another embodiment, a network node comprises processing circuitry configured to cause the network node to receive a message from a wireless communication device while the wireless communication device is in an inactive state, the message including an ID of the wireless communication device and information indicating one or more SIBs and / or one or more posSIBs requested by the wireless communication device. [Brief description of the drawings]

[0054] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate several aspects of the present disclosure and, together with the description, serve to explain the principles of the disclosure.

[0055] [Figure 1] FIG. 1 shows a four-step random access (RA) procedure used in 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) and New Radio (NR).

[0056] [Diagram 2] FIG. 2 shows the two-step RA procedure defined in 3GPP.

[0057] [Diagram 3] FIG. 3 shows the NR positioning architecture defined in 3GPP.

[0058] [Figure 4] FIG. 4 illustrates an example of a cellular communication system in which embodiments of the present disclosure may be implemented.

[0059] [Diagram 5] FIG. 5 illustrates one example implementation of a media access control (MAC) control element (CE) according to an embodiment of the present disclosure.

[0060] [Figure 6] FIG. 6 illustrates one exemplary embodiment of the payload of the MAC CE of FIG.

[0061] [Figure 7] FIG. 7 illustrates the operation of a user equipment (UE) and a network node according to an embodiment of the present disclosure.

[0062] [Figure 8] FIG. 8 illustrates the operation of a UE and a network node according to another embodiment of the present disclosure.

[0063] [Figure 9] FIG. 9 illustrates an example small data transmission (SDT) procedure using a four-step RA process to request and obtain on-demand system information, according to one embodiment of the present disclosure.

[0064] [Figure 10] FIG. 10 illustrates an example SDT procedure using a four-step RA process to request and obtain on-demand system information in accordance with another embodiment of the present disclosure.

[0065] [Figure 11] , [Figure 12] , [Figure 13] 11, 12 and 13 are schematic block diagrams of example embodiments of network nodes in which aspects of the present disclosure may be implemented.

[0066] [Figure 14] , [Figure 15]14 and 15 are schematic block diagrams of example embodiments of wireless communication devices (specifically as UEs) in which aspects of the embodiments of the present disclosure may be implemented.

[0067] [Figure 16] FIG. 16 illustrates an exemplary embodiment of a communication system in which embodiments of the present disclosure may be implemented.

[0068] [Figure 17] FIG. 17 illustrates an exemplary embodiment of the host computer, base station, and UE of FIG.

[0069] [Figure 18] , [Figure 19] , [Figure 20] , [Figure 21] 18-21 are flow charts illustrating exemplary embodiments of methods that may be performed in a communications system such as that of FIG.

[0070] [Figure 22] FIG. 22 illustrates an example RRC System Info Request message according to an embodiment of the present disclosure.

[0071] [Diagram 23] FIG. 23 shows an example in which a bitmap or explicit indication of requested system information blocks (SIBs) or positioning SIBs (posSIBs) is added in the RRC System Info Request message.

[0072] [Figure 24] FIG. 24 illustrates a RRCResumeRequest that may be used in an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0073] The embodiments described below represent information to enable those skilled in the art to practice the embodiments and to illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawings, those skilled in the art will understand the concepts of the present disclosure and will recognize applications of these concepts not specifically addressed herein. It is understood that these concepts and applications are within the scope of the present disclosure.

[0074] Some of the embodiments discussed herein are more fully described below with reference to the accompanying drawings, in which: However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as being limited to only the embodiments described herein, but rather, these embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

[0075] In general, all terms used herein should be interpreted according to their ordinary meaning in the relevant technical field unless a different meaning is expressly given and / or implied from the context in which it is used. Any reference to an element, apparatus, component, means, step, etc. should be openly interpreted as referring to at least one instance of the element, apparatus, component, means, step, etc., unless otherwise specified. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless a step is explicitly described as after or before another step and / or it is implicit that a step must be after or before another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, where appropriate. Similarly, any advantage of any embodiment may be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the embodiments of the present specification will become apparent from the following description.

[0076] Wireless Node: As used herein, a "wireless node" is either a wireless access node or a wireless communication device.

[0077] Radio Access Node: As used herein, a "radio access node" or "radio network node" or "radio access network node" is any node in a radio access network (RAN) of a cellular communication network that operates to transmit and / or receive signals wirelessly. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a 3rd Generation Partnership Project (3GPP) 5th Generation (5G) NR network, an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high power or macro base station, a low power base station (e.g., a micro base station, a pico base station, a home eNB, etc.), a relay node, a network node that implements some of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)), or a network node that implements some of the functionality of some other type of radio access node.

[0078] 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 core network nodes include, for example, a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), etc. Other examples of core network nodes include nodes implementing an Access and Mobility 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), etc.

[0079] Communication Device: As used herein, a "communication device" is any type of device that has access to an access network. Some examples of communication devices include, but are not limited to, mobile phones, smartphones, sensor devices, meters, vehicles, home appliances, medical equipment, media players, cameras, or any type of consumer electronics, such as, for example, televisions, radios, lighting devices, tablet computers, laptops, or personal computers (PCs). A communication device can be a portable, handheld, computer-embedded, or vehicle-mounted mobile device capable of communicating voice and / or data over a wireless or wired connection.

[0080] Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of wireless devices include, but are not limited to, user equipment devices (UE) in a 3GPP network, machine type communication (MTC) devices, and Internet of Things (IoT) devices. Some examples of such wireless communication devices may be or may be embedded in a mobile phone, a smartphone, a sensor device, a meter, a vehicle, a home appliance, a medical device, a media player, a camera, or any type of consumer electronic device, such as, for example, a television, a radio, a lighting device, a tablet computer, a laptop, or a PC. A wireless communication device may be a portable, handheld, computer-embedded, or vehicle-mounted mobile device capable of communicating voice and / or data over a wireless connection.

[0081] Network Node: As used herein, a "network node" is any node that is part of the RAN or part of the core network of a cellular communications network / system.

[0082] Transmission / Reception Point (TRP): In some embodiments, a TRP can be either a network node, a radio head, a spatial relationship, or a Transmission Configuration Indicator (TCI) state. In some embodiments, a TRP can be represented by a spatial relationship or a TCI state. In some embodiments, a TRP can use multiple TCI states. In some embodiments, a TRP can be part of a gNB that transmits and receives radio signals to and from a UE according to physical layer characteristics and parameters specific to that element. In some embodiments, in multiple TRP (multi-TRP) operation, a serving cell can schedule a UE from two TRPs, providing better physical downlink shared channel (PDSCH) coverage, reliability, and / or data rates. There are two different modes of operation for multi-TRP: single downlink control information (DCI) and multi-DCI. For both modes, control of uplink and downlink operations is done by both the physical layer and the medium access control (MAC). In single DCI mode, the UE is scheduled by the same DCI for both TRPs, and in multi-DCI mode, the UE is scheduled by independent DCI from each TRP.

[0083] It should be noted that the description provided herein focuses on 3GPP cellular communication systems, and as such 3GPP terminology or terminology similar to 3GPP terminology is often used, however, the concepts disclosed herein are not limited to 3GPP systems.

[0084] It should be noted that although in the description herein reference may be made to the term "cell", it is important to note that, particularly with regard to 5G NR concepts, beams may be used instead of cells, and therefore the concepts described herein are equally applicable to both cells and beams.

[0085] Currently, there is one or more challenges: In the current solution for on-demand system information, the network cannot deliver the requested UE System Information Block (SIB) via an inactive mode procedure. Although the UE can request on-demand system information using msg1 or msg3 (in the inactive state), the network cannot deliver it via point-to-point (unicast) messages.

[0086] Furthermore, a UE cannot transition to connected mode just to request a SIB that is not currently broadcast, i.e. the network cannot deliver requested on-demand system information via connected mode procedures unless the request is made by a UE in connected mode. This is a constraint from the network's point of view, since it consumes a lot of broadcast resources, especially when on-demand requests come from one UE (or a very small number of them), or even from many UEs at different time occasions, in which case the network cannot deliver point-to-point and is forced to deliver using broadcast.

[0087] Therefore, there is a need for a system and method in this direction for on-demand SIB delivery.

[0088] Certain aspects of the present disclosure and their embodiments may provide solutions to the above or other problems. 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.

[0089] In one embodiment, a Media 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) / extended LCID (eLCID) for the SDT or a new LCID / eLCID is defined if the UE will include or use this as part of the MsgA / Msg3 transmission. ● The MAC CE containing this LCID / eLCID has a payload with the SIB request (eg, bits indicating which SIB is requested). ● Upon receiving such a request, the network (e.g., a network node) provides downlink (DL) data using a message in the SDT framework (e.g., as part of Msg4 / RRCRelease) or provides a subsequent DL transmission in an inactive state.

[0090] 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 the information via SIB broadcast that SDT-based delivery is supported or enabled / disabled, this can also be provided by dedicated signaling. ● The spare bit from the RRCSystemInfoRequest-IE of the RRCSystemInfoRequest shown in FIG. 22 may be used to indicate that the UE supports SDT and the network may select delivery via point-to-point delivery. ● Instead of the following RRCSystemInfoRequest message, the UE may be capable of sending a new RRC message for SDT request and obtaining the SIB (posSIB) via DL SDT transmission using a flag bit. ● Alternatively, the network may further determine that the UE supports SDT based on the use of a new LCID / eLCID in the MAC CE.

[0091] Certain embodiments may provide one or more of the following technical advantages: Embodiments of the present disclosure may provide one or more of the following advantages: ● Power saving mechanisms are essential for RAN-based procedures. According to the embodiments described herein, the UE is able to transmit and receive data while keeping the RRC status in RRC_INACTIVE and thereby avoiding the transition to RRC_CONNECTED. This means that the higher signaling overhead and power consumption to achieve the RRC transition is avoided. ● Embodiments of the present disclosure may provide savings in network resources since the network does not need to distribute SIBs using broadcast. ● Embodiments of the present disclosure may be particularly useful where the UE can use this mechanism to retrieve positioning SIBs (posSIBs), such as Global Navigation Satellite System (GNSS) almanacs or reference stations, which may be slow-changing or static and large-scale data that is not suitable for broadcast.

[0092] FIG. 4 illustrates an example of a cellular communication system 400 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communication system 400 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC), although the present disclosure is not limited thereto. The embodiments described herein may be implemented in other types of cellular communication systems (e.g., Evolved Packet Systems (EPS)) in which small data transmission (SDT) is desired. In this example, the RAN includes base stations 402-1 and 402-2, which in the NG-RAN include NR base stations (gNBs) and optionally Next Generation eNBs (ng-eNBs) (e.g., LTE RAN connected to 5GC), which control corresponding (macro) cells 404-1 and 404-2. The base stations 402?1 and 402?2 are generally referred to herein collectively as base stations 402 and individually as base stations 402. Similarly, the (macro) cells 404-1 and 404-2 are generally referred to herein collectively as the (macro) cells 404 and individually as the macro cells 404. The RAN may also include several low power nodes 406-1 to 406-4 that control corresponding small cells 408-1 to 408-4. The low power nodes 406-1 to 406-4 may be small base stations (such as pico or femto base stations) or remote radio heads (RRHs), etc. Notably, although not shown, one or more of the small cells 408-1 to 408-4 may alternatively be provided by the base station 402. The low power nodes 406-1 to 406-4 are generally referred to herein collectively as the low power nodes 406 and individually as the low power nodes 406. Similarly, small cells 408-1 through 408-4 are generally referred to herein collectively as small cells 408 and individually as small cells 408. The cellular communication system 400 further includes a core network 410, which is referred to as 5GC in a 5G system (5GS). The base station 402 (and optionally the low power node 406) are connected to the core network 410.

[0093] Base station 402 and low power node 406 serve wireless communication devices 412-1 through 412-5 in corresponding cells 404 and 408. Wireless communication devices 412-1 through 412-5 are generally referred to herein collectively as wireless communication devices 412 and individually as wireless communication devices 412. In the following description, wireless communication devices 412 are often UEs and therefore sometimes referred to as UEs 412, although the disclosure is not limited thereto.

[0094] In the following, the embodiments are described in the context of NR, but are also applicable to LTE or any other radio access technology (RAT) without loss of meaning. Furthermore, the terms "posSIB", "positioning SIB", and "positioning information" refer to system information related to positioning that may be generally obtained by a UE via broadcast or via dedicated RRC signaling. Furthermore, the terms "SIB" and "normal SIB" refer to system information that is not related to positioning that may be obtained via broadcast or dedicated RRC signaling.

[0095] In the following, the terms posSIB or SIB may be interchanged without loss of meaning, since the same embodiments, methods and solutions are applicable to both posSIB or SIB.

[0096] 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 follows: TIFF0007641395000003.tif41145

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

[0098] <MACベースのソリューション> In one embodiment, when the UE 412 is in RRC_INACTIVE and has a need to obtain SIB(s) or posSIB(s), the UE 412 sends a new uplink MAC control element (CE) to the network (e.g., to a network node, such as the base station 402 or a network node implementing at least a portion of the functionality of the base station 402) to indicate which SIB(s) or posSIB(s) are needed (i.e., without transitioning completely to RRC_CONNECTED).

[0099] A use case may also be such that the UE 412 is RRC_INACTIVE and has a need to (re)acquire a SIB or posSIB that is informed by the network (e.g. by a network node) to be provided only by point-to-point delivery (i.e. without broadcast), so that the UE 412 sends this request through the MAC CE, e.g. using a unicast tag.

[0100] The need to (re)acquire a SIB(s) or a posSIB(s) may be due to the following reasons: - Requirements from higher layers in UE412, ● The SIB(s) or posSIB(s) stored in the UE 412 are out of date or are no longer valid, or ● A specific SIB(s) or posSIB(s) is / are required to be obtained in order to configure or perform a certain function (e.g., sidelink or non-private network).

[0101] Furthermore, in another embodiment, when sending an uplink MAC CE to the network (e.g., to a network node), the UE 412 may further inform the network (e.g., to a network node) (e.g., via the MAC CE) that this particular UE 412 supports and wishes to use the SDT functionality for requesting SIB(s) or posSIB(s). Alternatively, the network may understand whether the particular UE 412 supports the SDT functionality for requesting SIB(s) or posSIB(s) via UE capabilities, or the use of LCID / eLCID in MAC CE, or the use of a particular preamble resource group.

[0102] In one embodiment, upon receiving a UE 412 request via an uplink MAC CE that one (or more) SIBs or posSIBs are requested, the network node (e.g., a base station 402, such as a gNB) may decide to perform the following actions: 1. The network node invalidates the SIB(s) or posSIB(s) request via the SDT framework by sending a new downlink MAC CE to the UE 412, or 2. The network node sends the requested SIB(s) or posSIB(s) as part of a Msg4 or RRCRelease in accordance with the SDT framework, or 3. The network node broadcasts the requested SIB(s) or posSIB(s) (e.g., by changing the broadcast status flag from notBroadcasting to broadcasting).

[0103] In another embodiment, a possible implementation of the above may include that a new eLCID is defined and the payload contains 32 bits (maxSI message) as shown in Figure 5. Furthermore, in one embodiment, the payload is as shown in Figure 6. The R bit from Figure 5 or the new flag S shown in Figure 6 may also be used to distinguish whether the request is for a SIB or a posSIB in the MAC payload. Furthermore, the MAC payload may also contain a UE ID (e.g., I-RNTI), which may be, for example, either 24 or 40 bits. In one embodiment, as shown in Figure 6, there may be a flag to distinguish it as well, and therefore the MAC CE payload may be, for example, 10 or 8 bytes. The network (e.g., network node) may infer the I-RNTI type (e.g., short or long) based on the MAC payload size (e.g., 2 bytes difference).

[0104] 7 illustrates the operation of a UE 412 and a network node 700 (e.g., a base station 402 or a network node implementing at least a part of the functionality of a base station 402) according to one embodiment of the MAC-based solution described above. As shown, when the UE 412 is in an inactive state, it sends a MAC CE to the network node 700, the MAC CE indicating one or more SIBs and / or one or more posSIBs requested by the UE 412 (step 702). Furthermore, in one embodiment, the MAC CE further includes an indication that the UE 412 supports the SDT functionality for requesting the SIB(s) and / or the posSIB(s) and wishes to use this functionality. In another embodiment, the network node 700 determines whether the UE 412 supports the SDT functionality for requesting SIB(s) and / or posSIB(s) via UE capabilities (e.g., UE capabilities previously reported by the UE 412), via use of an LCID or eLCID in the MAC CE indicating that the UE 412 supports the SDT functionality, or via use of a specific RA preamble resource group by the UE 412 when transmitting an associated RA preamble. In response to receiving the MAC CE, the network node 700 performs one or more actions (step 704). The one or more actions performed by the network node 700 may include sending a new downlink MAC CE to the UE 412 to invalidate the SIB or posSIB request, sending at least one of the requested SIB and / or pos(SIB) to the UE 412 via the SDT, e.g., as part of an associated Msg4 or RRCRelease, and / or broadcasting at least one of the requested SIB and / or posSIB (e.g., by changing a broadcast status flag from notBroadcasting to broadcasting).

[0105] <RRCベースのソリューション> In one embodiment, when the UE 412 is in RRC_INACTIVE and needs to (re)acquire SIB(s) or posSIB(s), the UE 412 sends an uplink RRC message to the network (i.e., without transitioning to RRC_CONNECTED entirely) to request the needed SIB(s) or posSIB(s). In one embodiment, the uplink RRC request is sent according to the following: ● A bitmap or explicit indication is added to existing RRC messages to inform the network which SIB(s) or posSIB(s) are required. This new bitmap or explicit indication is communicated to the network (e.g., to network nodes) according to one of the following options: 1. A new or existing RRC message is sent to the network to inform the network which SIB(s) or posSIB(s) are needed, and this new RRC message is 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 RRCResumeRequest). 2. The new or existing RRC message is embedded (i.e., within a container - OCTET STRING) in one of the legacy RRC messages normally used to perform the transition from RRC_IDLE to RRC_CONNECTED (e.g., instead of RRCResumeRequest) and sent to the network.

[0106] Furthermore, if the UE 412 uses a 4-step RA type for the SDT procedure, the UE 412 sends a UL message in Msg3. If the UE 412 uses a 2-step RA type for the SDT procedure, the UE 412 sends a UL message in MsgA.

[0107] In another embodiment, when sending the uplink RRC request to the network, the UE 412 may further inform the network (e.g., in an RRC message) that this particular UE 412 supports and would like to use the SDT capability for requesting SIB(s) or posSIB(s). Alternatively, the network may understand if the particular UE 412 supports the SDT capability for requesting SIB(s) or posSIB(s) via the UE capabilities.

[0108] In one embodiment, the network (e.g., a network node) may further enable / disable the SDT feature for requesting SIB(s) or posSIB(s) by adding an indication to the SIB (if the network wants to disable this feature for all UEs under its coverage) or by adding an indication to a separate RRC message (if the network wants to disable this feature only for a specific UE under its coverage).

[0109] In another embodiment, a possible implementation of the above is as follows: A bitmap or explicit indication is added to an existing or new RRC message to inform the network that a SIB / posSIB is required. Figure 23 shows an example where a bitmap or explicit is added to the RRC System Info Request message.

[0110] Furthermore, since the above RRC message does not have a UE ID, this RRC System Info message is appended after a specific MAC CE as shown in Figure 6, which includes the UE ID (e.g., I-RNTI), or after the RRC Resume Request message of Figure 24. In such a case, the MAC payload does not include the SI request octet, which is instead provided via the RRC message.

[0111] In one embodiment, a separate preamble group is reserved for transmitting SIB or PosSIB requests for UEs supporting SDT functionality. Upon receiving such a preamble, the network will allocate a UL grant that will fit the following: MAC CE + RRC Resume Request + RRC System Info Request Msg

[0112] It is also possible to create a new RRC message containing the UE ID+BITMAP of the requested SIB or posSIB or to add the requested attribute (BITMAP of the requested SIB / posSIB) to any SDT specific RRC message.

[0113] FIG. 8 illustrates the operation of the UE 412 and the network node 700 (e.g., the base station 402, or a network node implementing at least part of the functionality of the base station 402) according to one embodiment of the RRC-based solution described above. As shown, the UE 412, when in an inactive state, transmits an RRC message to the network node 700, the RRC message indicating one or more SIBs and / or one or more posSIBs requested by the UE 412 (step 802). The RRC message may be according to any of the embodiments described above. Thus, the details described above are equally applicable here. It should be noted that in one embodiment, the RRC message is a (new) RRC message for an SDT request and includes an indication of the UE 412's capability to obtain SIBs and / or posSIBs via downlink SDT transmissions (e.g., a flag bit indicating the UE 412's capability to obtain SIBs and / or posSIBs via downlink SDT transmissions).

[0114] In response to receiving the RRC message, network node 700 performs one or more actions (step 804). The one or more actions performed by network node 800 may include invalidating the SIB or posSIB request, sending at least one of the requested SIB and / or pos(SIB) to UE412 via SDT, for example, as part of the associated Msg4 or RRCRelease, and / or broadcasting at least one of the requested SIB and / or posSIB (for example, by changing the broadcast status flag from notBroadcasting to broadcasting).

[0115] <SDT Procedures and Network Delivery of SIB via SDT> Exemplary procedures are shown in FIGS. 9 and 10. The procedure in FIG. 9 is shown for 2-step RA. The procedure in FIG. 10 is shown for 4-step RA. As shown in FIG. 9, in MsgA, UE412 sends an RRCResumeRequest+ (optionally segmented) small data+SIB request indication to network node 900 (step 902). In MsgB, network node 900 sends the following (step 904): ● If no other data is expected and no configuration update is performed, an RRC release (RRCrelease), or ● An RRC connection request + optionally a dynamic grant to transition the UE to the connected state, or ● An RRC release (RRCrelease) + a downlink assignment + optionally a setup grant configuration / single UL setup grant.

[0116] As shown in Figure 10, the UE 412 transmits an RA preamble to the network node 1000 (step 1002) and, after receiving an RAR from the network node 1000 (step 1004), in Msg3 the UE 412 transmits an RRCResumeRequest+small data (possibly segmented)+SIB request indication to the network node 1000 (step 1006). In Msg4 the network node 1000 transmits (step 1008): - RRCrelease, if no other data is expected and no configuration updates are to be performed; or ● An RRC connection request + possibly a dynamic grant to move the UE to connected, or ● RRC release + Downlink assignment + possibly configuration grant configuration / single UL configuration grant.

[0117] In one embodiment, the network node 900 or 1000 receives the first SDT message through MsgA or Msg3, or in a configured grant allocation. The network node 900 or 1000 detects that a subsequent SDT transmission is pending through either: ● The user data in the MAC sub-Protocol Data Unit (PDU) is a segmented Radio Link Control (RLC) payload; or by explicit indication, e.g., SIB request, or both; ● Or alternatively, by receiving a SIB RRC request using the methods described in the previous sections herein.

[0118] Thereafter, network node 900 or 1000 may provide the SIB RRC message to UE412 (step 906 or step 1010). Network node 900 or 1000 may provide the SIB RRC message to UE412 by the following means: ● RRC Release is accompanied by a subsequent downlink allocation, for which UE412 remains in RRC INACTIVE until successfully decoded. 〇 DL allocation (refer to SPS (Semi Persistent Scheduling)) includes SIB RRC configuration ● DL allocation (grant) scheduled by network node 900, for which an RRC release message is accompanied after successful decoding.

[0119] <Description of RRC procedure (impact on Chapter 5 of 3GPP TS 38.331)> The following includes examples of changes to the 3GPP TS 38.331 procedure to implement at least some aspects of the above embodiments. This example shows how existing procedures need to be updated to conform to SDT-based procedures. Furthermore, it is possible to have a separate on-demand SI procedure for the SDT-based inactive mode mechanism. TIFF0007641395000005.tif138144TIFF0007641395000006.tif154146

[0120] <Further aspects> FIG. 11 is a schematic block diagram of a network node 1100 according to some embodiments of the present disclosure. Optional functionality is represented by dashed boxes. The network node 1100 may be, for example, a base station 402 or 406, or a network node implementing all or a portion of the functionality of a base station 402 or gNB, network node 700, 800, 900, or 1000 as described herein. As shown, the network node 1100 includes a control system 1102 including one or more processors 1104 (e.g., a central processing unit (CPU), an application specific integrated circuit (ASIC), and / or a field programmable gate array (FPGA), etc.), memory 1106, and a network interface 1108. The one or more processors 1104 are also referred to herein as processing circuits. The network node 1100 may also include one or more radio units 1110 including one or more transmitters 1112 and one or more receivers 1114 each coupled to one or more antennas 1116. The radio unit 1110 may be referred to as or may be part of a radio interface circuit. In some embodiments, the radio unit(s) 1110 are external to the control system 1102 and are connected to the control system 1102, for example, via a wired connection (e.g., optical cable). However, in some other embodiments, the radio unit(s) 1110 and potentially the antenna(s) 1116 are integrated together with the control system 1102. The one or more processors 1104 operate to provide one or more functions of the network node 1100 as described herein (e.g., one or more functions of a base station 402 or 406, or a network node implementing all or part of the functions of a base station 402 or gNB, network node 700, 800, 900, or 1000 as described herein). In some embodiments, the function(s) are implemented in software, for example stored in the memory 1106 and executed by the one or more processors 1104.

[0121] FIG. 12 is a schematic block diagram illustrating a virtualized embodiment of a network node 1100 according to some embodiments of the present disclosure. Again, optional functionality is represented by dashed boxes. As used herein, a "virtualized" network node is an implementation of a network node 1100 in which at least some of the functionality of the network node 1100 is implemented as virtual component(s) (e.g., via virtual machine(s) running on physical processing node(s) in network(s)). As shown, in this example, the network node 1100 may include a control system 1102 and / or one or more radio units 1110, as described above. The control system 1102 may be connected to the radio unit(s) 1110 via, for example, optical cables or the like. The network node 1100 includes one or more processing nodes 1200 coupled to or included as part of the network(s) 1202. If present, the control system 1102 or wireless unit(s) are connected to processing node(s) 1200 via a network 1202. Each processing node 1200 includes one or more processors 1204 (e.g., a CPU, an ASIC, and / or an FPGA, etc.), memory 1206, and a network interface 1208.

[0122] In this example, the network node 1100 functions 1210 described herein (e.g., one or more functions of a base station 402 or 406, or a network node implementing all or a portion of the functionality of a base station 402 or gNB, network node 700, 800, 900, or 1000 as described herein) are implemented in one or more processing nodes 1200 or distributed in any desired manner across one or more processing nodes 1200 and the control system 1102 and / or radio unit 1110. In some particular embodiments, some or all of the network node 1100 functions 1210 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) 1200. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 1200 and the control system 1102 is used to perform at least some of the desired functions 1210. Notably, in some embodiments, the control system 1102 may not be included, in which case the wireless unit(s) 1110 communicate directly with the processing node(s) 1200 via an appropriate network interface(s).

[0123] In some embodiments, a computer program is provided that includes instructions that, when executed by at least one processor, cause the at least one processor to perform functions of the network node 1100 or a node (e.g., processing node 1200) implementing functions of one or more functions 1210 of the network node 1100 in a virtual environment according to any of the embodiments described herein. In some embodiments, a carrier is provided that includes the aforementioned computer program product. The carrier is either an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (a non-transitory computer readable medium such as a memory).

[0124] 13 is a schematic block diagram of a network node 1100 according to some other embodiments of the present disclosure. Network node 1100 includes one or more modules 1300, each implemented in software. The module(s) 1300 provide the functionality of network node 1100 described herein. This description is equally applicable to processing node 1200 of FIG. 12 where module 1300 is implemented on one of processing nodes 1200 or distributed across multiple processing nodes 1200 and / or distributed across processing node(s) 1200 and control system 1102.

[0125] 14 is a schematic block diagram of a wireless communication device 1400 (e.g., a wireless communication device 412 or a UE 412) according to some embodiments of the present disclosure. As shown, the wireless communication device 1400 includes one or more processors 1402 (e.g., a CPU, an ASIC, and / or an FPGA, etc.), a memory 1404, and one or more transceivers 1406 each including one or more transmitters 1408 and one or more receivers 1410 coupled to one or more antennas 1412. As will be appreciated by those skilled in the art, the transceiver(s) 1406 comprises a radio front-end circuit connected to the antenna(s) 1412 and configured to condition signals exchanged between the antenna(s) 1412 and the processor(s) 1402. The processor 1402 is also referred to herein as a processing circuit. The transceiver 1406 is also referred to herein as a radio circuit. In some embodiments, the functionality of the wireless communication device 1400 described above may be implemented fully or partially in software, e.g., stored in memory 1404 and executed by processor(s) 1402. It is noted that the wireless communication device 1400 may include additional components not shown in FIG. 14 , such as, for example, one or more user interface components (e.g., input / output interfaces including a display, buttons, a touch screen, a microphone, speaker(s), and / or the like, and / or any other components for enabling input of information into and / or output of information from the wireless communication device 1400), a power source (e.g., a battery and associated power circuitry), etc.

[0126] In some embodiments, a computer program is provided that includes instructions that, when executed by at least one processor, cause the at least one processor to perform the functions of the wireless communication device 1400 in accordance with any of the embodiments described herein. In some embodiments, a carrier is provided that includes the aforementioned computer program product. The carrier is either an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium (a non-transitory computer-readable medium such as a memory).

[0127] 15 is a schematic block diagram of a wireless communication device 1400 according to some other embodiments of the present disclosure. The wireless communication device 1400 includes one or more modules 1500, each implemented in software. The module(s) 1500 provide the functionality of the wireless communication device 1400 described herein.

[0128] Referring to Fig. 16, according to an embodiment, a communication system includes a communication network 1600, such as a 3GPP type cellular network, including an access network 1602, such as a wireless access network, and a core network 1604. The access network 1602 comprises a number of base stations 1606A, 1606B, 1606C, such as NBs, 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 can be connected to the core network 1604 via a wired or wireless connection 1610. A first UE 1612 located in the coverage area 1608C is configured to wirelessly connect to or be paged by the corresponding base station 1606C. A second UE 1614 in the coverage area 1608A can be wirelessly connected to the corresponding base station 1606A. In this example, multiple UEs 1612, 1614 are shown, however, the disclosed embodiments are equally applicable to situations where a single UE is within the coverage area or where a single UE is connected to a corresponding base station 1606.

[0129] The communication network 1600 itself is connected to a host computer 1616, which may be implemented in hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as a processing resource in a server farm. The host computer 1616 may be owned or controlled by a service provider, or may be operated by or on behalf of the service provider. The connections 1618 and 1620 between the communication network 1600 and the host computer 1616 may extend directly from the core network 1604 to the host computer 1616, or may extend through an optional intermediate network 1622. The intermediate network 1622 may be a combination of one or more of a public network, a private network, or a host network, if any, the intermediate network 1622 may be a backbone network or the Internet, and in particular the intermediate network 1622 may include two or more sub-networks (not shown).

[0130] The communication system of FIG. 16 generally provides connectivity between one of the connected UEs 1612, 1614 and a host computer 1616. Such connectivity may be described as an over-the-top (OTT) connection 1624. The host computer 1616 and the connected UEs 1612, 1614 are configured to communicate data and / or signaling via the OTT connection 1624 using the access network 1602, the core network 1604, any intermediate networks 1622, and possibly further infrastructure (not shown) as intermediaries. The OTT connection 1624 may be transparent in the sense that participating communication devices through which the OTT connection 1624 passes are unaware of the routing of the uplink and downlink communications. For example, the base station 1606 may not be or need not be informed about the past routing of an incoming downlink communication having data originating from a host computer 1616 that is forwarded (e.g., handed over) to an attached UE 1612. Similarly, the base station 1606 does not need to know the future routing of an outgoing uplink communication from the UE 1612 to the host computer 1616.

[0131] With reference to Fig. 17, an implementation example according to the embodiment of the UE, base station and host computer described in the previous paragraph is described below. In the communication system 1700, the host computer 1702 comprises hardware 1704 including a communication interface 1706 configured to set up and maintain wired or wireless connections with interfaces of different communication devices of the communication system 1700. The host computer 1702 further comprises a processing circuit 1708 that may have storage and / or processing capabilities. In particular, the processing circuit 1708 may include one or more programmable processors, ASICs, FPGAs, or combinations thereof (not shown) adapted to execute instructions. The host computer 1702 further comprises software 1710 stored in the host computer 1702 or accessible by the host computer 2802 and executable by the processing circuit 1708. The software 1710 includes a host application 1712. The host application 1712 may be operable to provide services to a remote user, such as a UE 1714, connecting via an OTT connection 1716 that terminates at the UE 1714 and the host computer 1702. In providing services to the remote user, the host application 1712 may provide user data that is transmitted using the OTT connection 1716.

[0132] The communication system 1700 further includes a base station 1718 provided within the communication system and comprising hardware 1720 enabling communication with the host computer 1702 and the UE 1714. The hardware 1720 may include a communication interface 1722 for setting up and maintaining wired or wireless connections with interfaces of different communication devices of the communication system 1700, and a wireless interface 1724 for setting up and maintaining at least a wireless connection 1726 with a UE 1714 located within a coverage area (not shown in FIG. 17) served by the base station 1718. The communication interface 1722 may be configured to facilitate a connection 1728 to the host computer 1702. The connection 1728 may be direct or may pass through a core network (not shown in FIG. 17) of the communication system and / or one or more intermediate networks external to the communication system. In the embodiment shown, the hardware 1720 of the base station 1718 further includes processing circuitry 1730, which may include one or more programmable processors, ASICs, FPGAs, or combinations thereof (not shown) adapted to execute instructions. The base station 1718 also includes software 1732 stored internally or accessible via an external connection.

[0133] The communication system 1700 further includes the UE 1714, as already mentioned. The hardware 1734 of the UE 1714 may include a wireless interface 1736 configured to set up and maintain a wireless connection 1726 with a base station serving the coverage area in which the UE 1714 is currently located. The hardware 1734 of the UE 1714 further includes a processing circuit 1738, which may include one or more programmable processors, ASICs, FPGAs, or combinations thereof (not shown) adapted to execute instructions. The UE 1714 further includes software 1740 stored within or accessible to the UE 1714 and executable by the processing circuit 1738. The software 1740 includes a client application 1742. The client application 1742 may be operable to provide services to a human or non-human user via the UE 1714 with the support of the host computer 1702. At the host computer 1702, an executing host application 1712 may communicate with an executing client application 1742 via a UE 1714 and an OTT connection 1716 that terminates at the host computer 1702. In providing a service to a user, the client application 1742 may receive request data from the host application 1712 and provide user data in response to the request data. The OTT connection 1716 may transport both the request data and the user data. The client application 1742 may interact with the user to generate the user data to provide.

[0134] It should be noted that the host computer 1702, base station 1718, and UE 1714 shown in Figure 17 may be similar to or identical to the host computer 1616, one of the base stations 1606A, 1606B, and 1606C, and one of the UEs 1612 and 1614, respectively, of Figure 16. That is, the internal operation of these entities may be as shown in Figure 17, and independently, the surrounding network topology may be that of Figure 16.

[0135] 17, an OTT connection 1716 is depicted abstractly to show communication between a host computer 1702 and a UE 1714 via a base station 1718, without explicitly referring to any intermediate devices and the exact routing of messages through those devices. The network infrastructure may determine the routing, which may be configured to be hidden from the UE 1714, or from the service provider operating the host computer 1702, or both. The network infrastructure may further determine to dynamically change the routing while the OTT connection 1716 is active (e.g., based on load considerations or network reconfiguration).

[0136] The wireless connection 1726 between the UE 1714 and the base station 1718 follows the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments may improve performance of the OTT service provided to the UE 1714 using the OTT connection 1716 of which the wireless connection 1726 forms the final segment.

[0137] In some embodiments, a measurement procedure may be provided for the purpose of monitoring data rates, latency, and other factors that one or more embodiments improve upon. Additionally, there may be an optional network function for reconfiguring the OTT connection 1716 between the host computer 1702 and the UE 1714 in response to variations in the measurement results. The measurement procedure and / or the network function for reconfiguring the OTT connection 1716 may be implemented in the software 1710 and hardware 1704 of the host computer 1702, or in the software 1740 and hardware 1734 of the UE 1714, or both. In some embodiments, a sensor (not shown) may be located at or associated with a communication device through which the OTT connection 1716 passes. The sensor may participate in the measurement procedure by providing values ​​of monitored quantities, as exemplified above, or by providing values ​​of other physical quantities from which the software 1710, 1740 may calculate or estimate the monitored quantities. The reconfiguration of the OTT connection 1716 may include message formats, retransmission configurations, preferred routing, etc., and such reconfiguration need not impact the base station 1718 and may be unknown or imperceptible to the base station 1718. Such procedures and functions are known and may be implemented in the art. In certain embodiments, the measurements may involve proprietary UE signaling that facilitates the host computer 1702 measuring throughput, propagation time, latency, etc. The measurements may be performed by having the software 1710 and 1740 send messages (particularly empty or "dummy" messages) using the OTT connection 1716 while monitoring propagation times, errors, etc.

[0138] FIG. 18 is a flow chart illustrating a method performed in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be described with reference to FIG. 16 and FIG. 17. To simplify this disclosure, only drawing references to FIG. 18 are included in this section. In step 1800, the host computer provides user data. In sub-step 1802 (which may be optional) of step 1800, the host computer provides the user data by executing a host application. In step 1804, the host computer initiates a transmission carrying the user data to the UE. In step 1806 (which may be optional), the base station transmits the user data carried in the host computer initiated transmission to the UE, according to the teachings of the embodiments described throughout this disclosure. In step 1808 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0139] FIG. 19 is a flow chart illustrating a method performed in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be described with reference to FIG. 16 and FIG. 17. To simplify the disclosure, only drawing references to FIG. 19 are included in this section. In step 1900 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides the user data by executing a host application. In step 1902, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass through a base station in accordance with the teachings of the embodiments described throughout this disclosure. In step 1904 (which may be optional), the UE receives the user data carried in the transmission.

[0140] FIG. 20 is a flow chart illustrating a method performed in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be described with reference to FIG. 16 and FIG. 17. To simplify the disclosure, only drawing references to FIG. 20 are included in this section. In step 2000 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 2002, the UE provides user data. In sub-step 2004 (which may be optional) of step 2000, the host computer provides the user data by executing a host application. In sub-step 2006 (which may be optional) of step 2002, the UE executes a client application that provides the user data in response to the received input data provided by the host computer. In providing the user data, the executed client application may further take into account user input received from a user. Regardless of the particular manner in which the user data was provided, the UE initiates transmission of the user data to the host computer in sub-step 2008 (which may be optional). In step 2010 of the method, the host computer receives user data transmitted from the UE according to the teachings of the embodiments described throughout this disclosure.

[0141] FIG. 21 is a flow chart illustrating a method performed in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be described with reference to FIG. 16 and FIG. 17. To simplify this disclosure, only drawing references to FIG. 21 are included in this section. In step 2100 (which may be optional), the base station receives user data from the UE, according to the teachings of the embodiments described throughout this disclosure. In step 2102 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 2104 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0142] Any suitable steps, methods, features, functions, or advantages disclosed herein may be performed through one or more functional units or modules of one or more virtual devices. Each virtual device may comprise several of these functional units. These functional units may be implemented using processing circuitry, which may include one or more microprocessors or microcontrollers, and other digital hardware, which may include digital signal processors (DSPs), dedicated digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, and the like. The program code stored in memory includes program instructions for implementing one or more telecommunications and / or data communication protocols and instructions for implementing one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause each functional unit to perform a corresponding function according to one or more embodiments of the present disclosure.

[0143] Although the processes within the figures may indicate a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such orders are exemplary (e.g., alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc.).

[0144] Some exemplary embodiments of the present disclosure are as follows:

[0145] <Embodiment of Group A> Embodiment 1: A method performed by a wireless communication device (412), comprising: While in an inactive state, sending a message to the network node (702; 802), said message comprising: a Medium Access Control (MAC) CE (Control Element) containing information indicating one or more System Information Blocks (SIBs) and / or one or more Positioning SIBs (posSIBs) that are required by the wireless communication device (412); or a RRC (Radio Resource Control) message including information indicating one or more SIBs (System Information Blocks) and / or one or more posSIBs (Positioning SIBs) that are requested by the wireless communication device (412); A method comprising any one of the steps of:

[0146]

[0023] Embodiment 2: The method of embodiment 1, wherein the message includes a MAC CE including information indicating one or more SIBs and / or one or more posSIBs requested by the wireless communication device (412).

[0147] Embodiment 3: The method of embodiment 2, wherein the MAC CE further includes an indication that the wireless communication device (412) supports SDT (small data transmission) functionality to request the one or more SIBs and / or the one or more posSIBs.

[0148]

[0023] Embodiment 4: The method of embodiment 2, wherein the wireless communication device (412) is configured to: determine that the wireless communication device (412) supports a small data transmission (SDT) function to request the one or more SIBs and / or the one or more posSIBs; Capability information reported to the network node, or Use of an LCID (Logical Channel Identity) or eLCID (Extended Logical Channel Identity) within said MAC CE, or ● Use of a specific random access preamble resource group for the transmission of the associated random access preamble; and informing the network node via

[0149]

[0023] Embodiment 5: The method of any one of embodiments 2 to 4, wherein the MAC CE further includes an identity of the wireless communication device (412).

[0150]

[0023] Embodiment 6: The method of embodiment 5, wherein the identity of the wireless communication device (412) is either an I-RNTI or a short I-RNTI of the wireless communication device (412).

[0151] Embodiment 7: The method of embodiment 6, wherein the MAC CE further includes an indicator indicating whether the identity of the wireless communication device (412) included in the MAC CE is an I-RNTI or a short I-RNTI.

[0152] Embodiment 8: A method according to any one of embodiments 2 to 7, wherein the MAC CE further includes information indicating whether the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device (412) are one or more SIBs or one or more posSIBs.

[0153] Embodiment 9: A method according to any of embodiments 2 to 8, wherein the MAC CE includes a subheader including an eLCID, the eLCID including a number of bits indicating which of a number of SIBs and / or posSIBs is being requested by the wireless communication device.

[0154] Embodiment 10: The method of embodiment 9, wherein the MAC CE includes a flag in the subheader or the eLCID indicating whether the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device (412) are one or more SIBs or one or more posSIBs.

[0155] Embodiment 11: The method of embodiment 9 or 10, wherein the eLCID further includes an identity of the wireless communication device (412).

[0156]

[0036] Embodiment 12: The method of embodiment 11, wherein the identity of the wireless communication device (412) is either an I-RNTI or a short I-RNTI of the wireless communication device (412).

[0157] Embodiment 13: The method of embodiment 12, wherein the eLCID further includes an indicator indicating whether the identity of the wireless communication device (412) included in the eLCID is an I-RNTI or a short I-RNTI.

[0158]

[0036] Embodiment 14: The method of embodiment 1, wherein the message comprises a radio resource control (RRC) message, the RRC message comprising: information indicating one or more SIBs and / or one or more posSIBs requested by the wireless communication device (412); and ● an identity of the wireless communication device (412) and / or an indication that the wireless communication device (412) supports a SDT (Small Data Transmission) function to request the one or more SIBs and / or the one or more posSIBs and / or an indication of the capability of the wireless communication device (412) to obtain SIBs and / or posSIBs via a downlink SDT transmission; A method comprising:

[0159] Embodiment 15: The method of embodiment 14, wherein the RRC message includes a bitmap or explicit indication of one or more SIBs and / or one or more posSIBs requested by the wireless communication device (412).

[0160] Embodiment 16: The method of embodiment 14 or 15, wherein transmitting the message (802) includes transmitting the RRC message to be used for SDT (Small Data Transmission) framework communication instead of a legacy RRC message normally used when transitioning from an idle / inactive state or in a connected state (802).

[0161] Embodiment 17: A method according to embodiment 14 or 15, wherein transmitting the message (802) includes embedding the RRC message including the capability to receive SIB / posSIB using an SDT (Small Data Transmission) framework within a legacy RRC message typically used when transitioning from an idle / inactive state or in a connected state (802).

[0162] Embodiment 18: A method according to any one of embodiments 14 to 17, wherein transmitting the message (802) includes transmitting the RRC message in either Msg3 of a four-step random access for an SDT procedure or MsgA of a two-step random access for an SDT procedure (802).

[0163] Embodiment 19: A method according to any of embodiments 14 to 18, wherein the RRC message further includes information indicating that the wireless communication device (412) supports an SDT (small data transmission) function to request the one or more SIBs and / or the one or more posSIBs.

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

[0165] Embodiment 21: A method according to any one 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 as part of an associated random access Msg4 (e.g., via an SDT) or as part of an RRC release message.

[0166] Embodiment 22: A method according to any one 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.

[0167] Embodiment 23: The method of embodiment 22, wherein receiving at least one of the one or more SIBs and / or at least one of the one or more posSIBs via broadcast (704; 804) includes receiving a broadcast status flag associated with the at least one of the one or more SIBs and / or the at least one of the one or more posSIBs, and the broadcast status flag is modified 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 is broadcast.

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

[0169] Embodiment 25: A method according to any one of embodiments 1 to 24, wherein the sending of the message (702; 802) includes sending (902) MsgA in two-step random access, the MsgA including a random access preamble, an RRC resumption request, data, and the message.

[0170] Embodiment 26: A method according to any one of embodiments 1 to 24, wherein the sending of the message (702; 802) includes sending (1002) Msg3 in four-step random access, the Msg3 including an RRC resumption request, data, and the message.

[0171] Embodiment 27: The method of any of the above embodiments, further comprising providing user data and transferring the user data to the host computer via transmission to a base station.

[0172] <Embodiments of Group B> Embodiment 28: A method performed by a network node (700; 800; 900; 1000), the method comprising: receiving (702; 802) a message from a wireless communication device (412) while the wireless communication device (412) is in an inactive state, the message comprising: a Medium Access Control (MAC) CE (Control Element) containing information indicating one or more System Information Blocks (SIBs) and / or one or more Positioning SIBs (posSIBs) that are required by the wireless communication device (412); or a RRC (Radio Resource Control) message including information indicating one or more SIBs (System Information Blocks) and / or one or more posSIBs (Positioning SIBs) that are requested by the wireless communication device (412); A method comprising any one of the steps of:

[0173]

[0046] Embodiment 29: The method of embodiment 28, wherein the message includes a MAC CE including information indicating one or more SIBs and / or one or more posSIBs requested by the wireless communication device (412).

[0174] Embodiment 30: The method of embodiment 29, wherein the MAC CE further includes an indication that the wireless communication device (412) supports SDT (small data transmission) functionality to request the one or more SIBs and / or the one or more posSIBs.

[0175]

[0046] Embodiment 31: The method of embodiment 29, wherein the network node detects that the wireless communication device (412) supports a small data transmission (SDT) function to request the one or more SIBs and / or the one or more posSIBs. Capability information reported from the wireless communication device (412) to the network node; or Use of an LCID (Logical Channel Identity) or eLCID (Extended Logical Channel Identity) within said MAC CE, or ● Use of a specific random access preamble resource group for the transmission of the associated random access preamble; A method for determining via.

[0176]

[0046] Embodiment 32: The method of any one of embodiments 29 to 31, wherein the MAC CE further includes an identity of the wireless communication device (412).

[0177]

[0081] Embodiment 33: The method of embodiment 32, wherein the identity of the wireless communication device (412) is either an I-RNTI or a short I-RNTI of the wireless communication device (412).

[0178] Embodiment 34: The method of embodiment 33, wherein the MAC CE further includes an indicator indicating whether the identity of the wireless communication device (412) included in the MAC CE is an I-RNTI or a short I-RNTI.

[0179] Embodiment 35: A method of any of embodiments 29 to 34, wherein the MAC CE further includes information indicating whether the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device (412) are one or more SIBs or one or more posSIBs.

[0180] Embodiment 36: A method of any of embodiments 29 to 35, wherein the MAC CE includes a subheader including an eLCID, the eLCID including a number of bits indicating which of a number of SIBs and / or posSIBs is being requested by the wireless communication device.

[0181] Embodiment 37: The method of embodiment 36, wherein the MAC CE includes a flag in the subheader or the eLCID indicating whether the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device (412) are one or more SIBs or one or more posSIBs.

[0182] Embodiment 38: The method of embodiment 36 or 37, wherein the eLCID further includes the identity of the wireless communication device (412).

[0183]

[0081] Embodiment 39: The method of embodiment 38, wherein the identity of the wireless communication device (412) is either an I-RNTI or a short I-RNTI of the wireless communication device (412).

[0184] Embodiment 40: The method of embodiment 39, wherein the eLCID further includes an indicator indicating whether the identity of the wireless communication device (412) included in the eLCID is an I-RNTI or a short I-RNTI.

[0185] Embodiment 41: The method of embodiment 28, wherein the message includes an RRC message including information indicating one or more SIBs and / or one or more posSIBs requested by the wireless communication device (412).

[0186] Embodiment 42: The method of embodiment 41, wherein the RRC message includes a bitmap or explicit indication of one or more SIBs and / or one or more posSIBs requested by the wireless communication device (412).

[0187] Embodiment 43: The method of embodiment 41 or 42, wherein receiving the message (802) includes receiving the RRC message in place of a legacy RRC message normally used when transitioning from an idle state or a connected state (802).

[0188] Embodiment 44: The method of embodiment 41 or 42, wherein receiving the message (802) includes receiving the RRC message embedded within a legacy RRC message typically used when transitioning from an idle state or a connected state (802).

[0189] Embodiment 45: A method according to any one of embodiments 41 to 44, wherein receiving the message (802) includes receiving the RRC message in either Msg3 of a four-step random access for an SDT procedure or MsgA of a two-step random access for an SDT procedure (802).

[0190] Embodiment 46: A method according to any of embodiments 41 to 45, wherein the RRC message further includes information indicating that the wireless communication device (412) supports an SDT (small data transmission) function to request the one or more SIBs and / or the one or more posSIBs.

[0191] Embodiment 47: A method of any of embodiments 41 to 46, wherein the 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.

[0192] Embodiment 48: A 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) as part of an associated random access Msg4 (e.g., via an SDT) or as part of an RRC release message.

[0193] Embodiment 49: A method according to 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.

[0194] Embodiment 50: The method of embodiment 49, wherein broadcasting (704; 804) at least one of the one or more SIBs and / or at least one of the one or more posSIBs includes transmitting a broadcast status flag associated with the at least one of the one or more SIBs and / or the at least one of the one or more posSIBs, and the broadcast status flag is modified 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 is broadcast.

[0195] Embodiment 51: A method according to any of embodiments 28 to 47, further comprising sending (704; 804) a message invalidating the request for the one or more SIBs and / or the one or more posSIBs.

[0196] Embodiment 52: A method according to any one of embodiments 28 to 51, wherein receiving the message (702; 802) includes receiving (902) an MsgA in two-step random access, the MsgA including a random access preamble, an RRC resumption request, data, and the message.

[0197] Embodiment 53: A method according to any one of embodiments 28 to 51, wherein receiving the message (702; 802) includes receiving (1002) Msg3 in a four-step random access, the Msg3 including an RRC resumption request, data, and the message.

[0198] Embodiment 54: The method of any of the above embodiments, further comprising obtaining user data and transferring the user data to a host computer or wireless communication device.

[0199] <Embodiments of Group C> Embodiment 55: A wireless communication device comprising: a processing circuit configured to perform any of the steps included in any of the embodiments of group A; and a power supply circuit configured to supply power to the wireless communication device.

[0200] Embodiment 56: A base station comprising a processing circuit configured to perform any of the steps included in any of the embodiments of Group B, and a power supply circuit configured to supply power to the base station.

[0201] Embodiment 57: A UE (user equipment), an antenna configured to transmit and receive wireless signals; a radio front-end circuit coupled to the antenna and to a processing circuit and configured to condition a signal communicated between the antenna and the processing circuit; the processing circuitry configured to perform any of the steps included in any of the embodiments of group A; an input interface connected to the processing circuitry and configured to enable input of information to be processed by the processing circuitry into the UE; an output interface connected to the processing circuit and configured to output information processed by the processing circuit from the UE; A UE comprising: a battery connected to the processing circuit and configured to supply power to the UE.

[0202] Embodiment 58: A communication system including a host computer, processing circuitry configured to provide user data; a communication interface configured to transfer the user data to a cellular network for transmission to a user equipment (UE); ●A communications system, wherein the cellular network includes a base station having a radio interface and processing circuitry, the processing circuitry of the base station being configured to perform any of the steps included in any of the Group B embodiments.

[0203] Embodiment 59: A communication system according to any of the above embodiments, further comprising the base station.

[0204] Embodiment 60: The communication system of the above two embodiments, further comprising the UE, the UE configured to communicate with the base station.

[0205] Embodiment 61: A communications system according to any of the three embodiments above, 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.

[0206] Embodiment 62: A method performed in a communication system including a host computer, a base station, and a UE (user equipment), comprising: providing user data at the host computer; and initiating a transmission at the host computer conveying the user data to the UE via a cellular network including the base station, the base station performing steps included in any of the embodiments of Group B.

[0207] Embodiment 63: The method of any of the above embodiments, further comprising transmitting user data at the base station.

[0208] Embodiment 64: The method of the two above embodiments, wherein the user data is provided at the host computer by executing a host application, and the method further includes executing at the UE a client application associated with the host application.

[0209] Embodiment 65: A UE (User Equipment) configured to communicate with a base station, the UE comprising a radio interface and a processing circuit configured to perform the methods of the above three embodiments.

[0210] Embodiment 66: A communications system including a host computer, the host computer comprising a processing circuit configured to provide user data and a communications interface configured to transfer the user data to a cellular network for transmission to a UE (User Equipment), the UE comprising a base station having a wireless interface and processing circuitry, the processing circuitry of the UE being configured to perform the steps included in any of the embodiments of Group A.

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

[0212] Embodiment 68: A communications system according to the two preceding embodiments, wherein the processing circuitry of the host computer is configured to execute a host application thereby providing the user data, and the processing circuitry of the UE is configured to execute a client application associated with the host application.

[0213] Embodiment 69: A method performed in a communication system including a host computer, a base station, and a UE (user equipment), comprising: providing user data at the host computer; and initiating a transmission at the host computer conveying the user data to the UE via a cellular network including the base station, wherein the UE performs the steps included in any of the embodiments of Group A.

[0214] Embodiment 70: The method of any preceding embodiment, further comprising receiving, at the UE, the user data from the base station.

[0215] Embodiment 71: A communications system including a host computer having a communications interface configured to receive user data resulting from a transmission from a UE (user equipment) to a base station, the UE having a radio interface and processing circuitry, the processing circuitry of the UE being configured to perform the steps included in any of the embodiments of Group A.

[0216] Embodiment 72: The communication system of the above embodiment, further comprising the UE.

[0217] Embodiment 73: The communication system of the above two embodiments, further comprising the base station, the base station having a radio interface configured to communicate with the UE and a communication interface configured to transfer the user data carried by transmissions from the UE to the base station to the host computer.

[0218] Embodiment 74: A communications system according to any of the three preceding embodiments, wherein the processing circuitry of the host computer is configured to execute a host application, and the processing circuitry of the UE is configured to provide the user data by executing a client application associated with the host computer.

[0219] Embodiment 75: A communications system according to any of the four preceding embodiments, wherein the processing circuitry of the host computer is configured to execute a host application thereby providing requested data, and the processing circuitry of the UE is configured to execute a client application associated with the host application thereby providing the user data in response to the requested data.

[0220] Embodiment 76: A method performed in a communication system including a host computer, a base station, and a UE (user equipment), the method including receiving, at the host computer, user data transmitted from the UE to the base station, the UE performing a step included in any of the embodiments of Group A.

[0221]

[0071] Embodiment 77: The method of any preceding embodiment, further comprising, in the UE, providing the user data to the base station.

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

[0223] Embodiment 79: The method of the above three embodiments, further comprising: executing a client application in the UE; and receiving in the UE input data for the client application, the input data being provided at the host computer by executing a host application associated with the client application, wherein the user data to be transmitted is provided by the client application in response to the input data.

[0224] Embodiment 80: A communications system including a host computer having a communications interface configured to receive user data resulting from a transmission from a UE (user equipment) to a base station, the base station having a radio interface and processing circuitry, the processing circuitry of the base station being configured to perform any of the steps included in any of the embodiments of Group B.

[0225] Embodiment 81: The communication system of the above embodiment, further comprising the base station.

[0226] Embodiment 82: The communication system of the above two embodiments, further comprising the UE, the UE configured to communicate with the base station.

[0227] Embodiment 83: A communication system according to any of the three embodiments above, wherein the processing circuitry of the host computer is configured to execute a host application, and the UE is configured to provide the user data by executing a client application associated with the host computer.

[0228] Embodiment 84: A method performed in a communication system including a host computer, a base station, and a UE (user equipment), the method including receiving, at the host computer, user data from the base station resulting from a transmission received by the base station from the UE, the UE performing a step included in any of the embodiments of Group A.

[0229]

[0046] Embodiment 85: The method of any preceding embodiment, further comprising receiving, at the base station, the user data from the base station.

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

[0231] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure, and all such improvements and modifications are deemed to be within the scope of the concepts disclosed herein.

Claims

1. A method performed by a wireless communication device (412), comprising: While in an inactive state, sending a message to the network node (702; 802), said message comprising: The identity of the wireless communication device (412); information indicating one or more system information blocks (SIBs) and / or one or more positioning SIBs (posSIBs) that are requested by the wireless communication device (412); an indication that the wireless communication device (412) supports a small data transmission (SDT) function to request the one or more SIBs and / or the one or more posSIBs, and / or an indication of the wireless communication device (412)'s capability to obtain SIBs and / or posSIBs via a downlink SDT transmission; and A method comprising:

2. 2. The method of claim 1, wherein the message includes a Medium Access Control (MAC) Control Element (CE) that includes the information indicating the one or more SIBs and / or the one or more posSIBs that are requested by the wireless communication device (412).

3. 3. The method of claim 2, wherein the indication that the wireless communication device (412) supports the SDT capability to request the one or more SIBs and / or the one or more posSIBs comprises: Capability information reported to the network node; or Use of an LCID (Logical Channel Identity) or an eLCID (Extended Logical Channel Identity) in the MAC CE, or Use of a specific random access preamble resource group for the transmission of the associated random access preamble; The method of claim 1, wherein the message is transmitted via

4. The method of claim 2 or 3, wherein the MAC CE further comprises the identity of the wireless communication device (412).

5. The method according to any one of claims 2 to 4, wherein the identity of the wireless communication device (412) is either an Inactive Mode Radio Network Temporary Identifier (I-RNTI) or a short I-RNTI of the wireless communication device (412).

6. 6. The method of claim 5, wherein the MAC CE further includes an indicator indicating whether the identity of the wireless communication device (412) included in the MAC CE is an I-RNTI or a short I-RNTI.

7. 7. The method of claim 2, wherein the MAC CE further includes information indicating whether the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device (412) are one or more SIBs or one or more posSIBs.

8. 8. The method of claim 2, wherein the MAC CE includes a sub-header including an extended logical channel identity (eLCID), the eLCID including a number of bits indicating which of a number of SIBs and / or posSIBs are requested by the wireless communication device.

9. 9. The method of claim 8, wherein the MAC CE includes a flag in the subheader or the eLCID indicating 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.

10. The method of claim 8 or 9, wherein the eLCID further comprises the identity of the wireless communication device (412).

11. The method of claim 10, wherein the identity of the wireless communication device (412) is either an I-RNTI or a short I-RNTI of the wireless communication device (412).

12. 12. The method of claim 11, wherein the eLCID further includes an indicator indicating whether the identity of the wireless communication device (412) included in the eLCID is an I-RNTI or a short I-RNTI.

13. 2. The method of claim 1, wherein the message comprises a radio resource control (RRC) message including the information indicating the one or more SIBs and / or the one or more posSIBs that are requested by the wireless communication device (412).

14. 14. The method of claim 13, wherein the information indicating the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device (412) comprises a bitmap or an explicit indication indicating the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device (412).

15. 15. The method of claim 13 or 14, wherein transmitting (802) the message comprises transmitting (802) the RRC message to be used for SDT (Small Data Transmission) framework communication instead of a legacy RRC message normally used when transitioning from an idle / inactive state or in a connected state.

16. The method according to claim 13 or 14, wherein the transmitting (802) of the message comprises embedding (802) the RRC message including information indicating an ability to receive SIBs and / or posSIBs using a SDT (Small Data Transmission) framework within a legacy RRC message normally used when transitioning from an idle / inactive state or in a connected state.

17. 17. The method according to claim 13, wherein transmitting the message (802) comprises transmitting the RRC message in either Msg3 for a four-step random access for SDT procedure or MsgA for a two-step random access for SDT procedure.

18. 18. The method of claim 13, wherein the identity of the wireless communication device (412) is not included in the RRC message, but in a MAC (Medium Access Control) CE (Control Element) sent by the wireless communication device (412) to the network node either before or after the RRC message.

19. 19. The method of claim 1, further comprising receiving (704) at least one of the one or more SIBs and / or at least one of the one or more posSIBs as part of an associated random access Msg4 or as part of an RRC release message.

20. 19. The method according to claim 1, 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.

21. 21. The method of claim 20, wherein 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 comprises receiving a broadcast status flag associated with the at least one of the one or more SIBs and / or the at least one of the one or more posSIBs, wherein the broadcast status flag is modified 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 is broadcast.

22. 19. The method according to any one of claims 1 to 18, further comprising receiving (704; 804) a message invalidating the request for the one or more SIBs and / or the one or more posSIBs.

23. 23. The method according to claim 1, wherein the sending (702; 802) of the message comprises sending (902) an MsgA in two-step random access, the MsgA including a random access preamble, an RRC resumption request, data, and the message.

24. 23. The method according to claim 1, wherein the sending (702; 802) of the message comprises sending (1002) Msg3 in a four-step random access, the Msg3 including an RRC resumption request, data and the message.

25. A wireless communication device (412), While in an inactive state, the method is configured to send (702; 802) a message to a network node, the message comprising: The identity of the wireless communication device (412); information indicating one or more system information blocks (SIBs) and / or one or more positioning SIBs (posSIBs) that are requested by the wireless communication device (412); an indication that the wireless communication device (412) supports a small data transmission (SDT) function to request the one or more SIBs and / or the one or more posSIBs, and / or an indication of the wireless communication device (412)'s capability to obtain SIBs and / or posSIBs via a downlink SDT transmission; and 23. A wireless communication device comprising:

26. A wireless communication device (412) according to claim 25, further configured to perform the method according to any one of claims 2 to 24.

27. A wireless communication device (412; 1400), one or more transmitters (1408); One or more receivers (1410); a processing circuit (1402) associated with the one or more transmitters (1408) and the one or more receivers (1410), the processing circuit (1402) configured to cause the wireless communication device (412; 1400) to transmit (702; 802) a message to a network node while in an inactive state, the message comprising: The identity of the wireless communication device (412); information indicating one or more system information blocks (SIBs) and / or one or more positioning SIBs (posSIBs) that are requested by the wireless communication device (412); an indication that the wireless communication device (412) supports a small data transmission (SDT) function to request the one or more SIBs and / or the one or more posSIBs, and / or an indication of the wireless communication device (412)'s capability to obtain SIBs and / or posSIBs via a downlink SDT transmission; and 23. A wireless communication device comprising:

28. 28. A wireless communication device (412; 1400) as claimed in claim 27, wherein the processing circuit (1402) is further configured to cause the wireless communication device (412; 1400) to perform a method according to any one of claims 2 to 24.

29. A method performed by a network node (700; 800; 900; 1000), said method comprising the steps of: receiving (702; 802) a message from a wireless communication device (412) while the wireless communication device (412) is in an inactive state, the message comprising: The identity of the wireless communication device (412); information indicating one or more system information blocks (SIBs) and / or one or more positioning SIBs (posSIBs) that are requested by the wireless communication device (412); an indication that the wireless communication device (412) supports a small data transmission (SDT) function to request the one or more SIBs and / or the one or more posSIBs, and / or an indication of the wireless communication device (412)'s capability to obtain SIBs and / or posSIBs via a downlink SDT transmission; and A method comprising:

30. 30. The method of claim 29, wherein the message includes a Medium Access Control (MAC) Control Element (CE) containing the information indicating the one or more SIBs and / or the one or more posSIBs that are requested by the wireless communication device (412).

31. 31. The method of claim 30, wherein the indication that the wireless communication device (412) supports the SDT capability to request the one or more SIBs and / or the one or more posSIBs comprises: Capability information reported from the wireless communication device (412) to the network node; or Use of an LCID (Logical Channel Identity) or an eLCID (Extended Logical Channel Identity) in the MAC CE, or Use of a specific random access preamble resource group for the transmission of the associated random access preamble; The method of claim 1, wherein the message is received via

32. The method of claim 30 or 31, wherein the MAC CE further includes the identity of the wireless communication device (412).

33. 33. The method of claim 32, wherein the identity of the wireless communication device (412) is either an I-RNTI or a short I-RNTI of the wireless communication device (412).

34. 34. The method of claim 33, wherein the MAC CE further includes an indicator indicating whether the identity of the wireless communication device (412) included in the MAC CE is an I-RNTI or a short I-RNTI.

35. 35. The method of claim 30, wherein the MAC CE further includes information indicating whether the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device (412) are one or more SIBs or one or more posSIBs.

36. 36. The method of claim 30, wherein the MAC CE includes a sub-header including an eLCID, the eLCID including a number of bits indicating which of a number of SIBs and / or posSIBs are requested by the wireless communication device.

37. 37. The method of claim 36, wherein the MAC CE includes a flag in the subheader or the eLCID indicating 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.

38. 38. The method of claim 36 or 37, wherein the eLCID further comprises the identity of the wireless communication device (412).

39. 39. The method of claim 38, wherein the identity of the wireless communication device (412) is either an I-RNTI or a short I-RNTI of the wireless communication device (412).

40. 40. The method of claim 39, wherein the eLCID further includes an indicator indicating whether the identity of the wireless communication device (412) included in the eLCID is an I-RNTI or a short I-RNTI.

41. 30. The method of claim 29, wherein the message comprises a radio resource control (RRC) message including the information indicating the one or more SIBs and / or the one or more posSIBs that are requested by the wireless communication device (412).

42. 42. The method of claim 41, wherein the information indicating the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device (412) comprises a bitmap or an explicit indication indicating the one or more SIBs and / or the one or more posSIBs requested by the wireless communication device (412).

43. 43. The method of claim 41 or 42, wherein receiving (802) the message comprises receiving (802) the RRC message in place of a legacy RRC message normally used when transitioning from an idle or connected state.

44. 43. The method of claim 41 or 42, wherein receiving (802) the message comprises receiving (802) the RRC message embedded within a legacy RRC message typically used when transitioning from an idle or connected state.

45. 45. The method according to claim 41, wherein receiving (802) the message comprises receiving (802) the RRC message in either Msg3 for a four-step random access for SDT procedure or MsgA for a two-step random access for SDT procedure.

46. 46. ​​The method of claim 41, wherein the RRC message further includes information indicating that the wireless communication device (412) supports the SDT functionality to request the one or more SIBs and / or the one or more posSIBs as the indication that the wireless communication device (412) supports the SDT functionality to request the one or more SIBs and / or the one or more posSIBs.

47. 47. The method of any one of claims 41 to 46, wherein the 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.

48. 48. The method of claim 29, 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) as part of an associated random access Msg4 or as part of an RRC release message.

49. 48. The method according to any one of claims 29 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.

50. 50. The method of claim 49, wherein broadcasting (704; 804) at least one of the one or more SIBs and / or at least one of the one or more posSIBs comprises transmitting a broadcast status flag associated with the at least one of the one or more SIBs and / or the at least one of the one or more posSIBs, wherein the broadcast status flag is modified 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 is broadcast.

51. 48. The method of any one of claims 29 to 47, further comprising sending (704; 804) a message invalidating the request for the one or more SIBs and / or the one or more posSIBs.

52. 52. The method according to any one of claims 29 to 51, wherein receiving the message (702; 802) includes receiving MsgA in two-step random access, the MsgA including a random access preamble, an RRC resumption request, data, and the message (902).

53. 52. The method according to any one of claims 29 to 51, wherein receiving the message (702; 802) comprises receiving Msg3 in a four-step random access, the Msg3 including an RRC resumption request, data, and the message (1002).

54. A network node (700; 800; 900; 1000), The method is configured to receive (702; 802) a message from a wireless communication device (412) while the wireless communication device (412) is in an inactive state, the message comprising: The identity of the wireless communication device (412); information indicating one or more system information blocks (SIBs) and / or one or more positioning SIBs (posSIBs) that are requested by the wireless communication device (412); an indication that the wireless communication device (412) supports a small data transmission (SDT) function to request the one or more SIBs and / or the one or more posSIBs, and / or an indication of the wireless communication device (412)'s capability to obtain SIBs and / or posSIBs via a downlink SDT transmission; and A network node including:

55. A network node (700; 800; 900; 1000) according to claim 54, further configured to perform a method according to any one of claims 30 to 53.

56. A network node (700; 800; 900; 1000), a processing circuit (1104) for transmitting to said network node (700; 800; 900; 1000) The method is configured to receive (702; 802) a message from a wireless communication device (412) while the wireless communication device (412) is in an inactive state, the message comprising: The identity of the wireless communication device (412); information indicating one or more system information blocks (SIBs) and / or one or more positioning SIBs (posSIBs) that are requested by the wireless communication device (412); an indication that the wireless communication device (412) supports a small data transmission (SDT) function to request the one or more SIBs and / or the one or more posSIBs, and / or an indication of the wireless communication device (412)'s capability to obtain SIBs and / or posSIBs via a downlink SDT transmission; and A network node including:

57. A network node (700; 800; 900; 1000) as claimed in claim 56, wherein the processing circuitry (1104) is further configured to cause the network node (700; 800; 900; 1000) to perform a method as claimed in any one of claims 30 to 53.

Images