Requesting on-demand sib

Abstract

Methods, communications device, infrastructure equipment and circuitry for defining UE behaviour when requesting on-demand SIB1, in particular when the on-demand SIB1 cannot be acquired by the UE. Based on determining that the UE is unable to acquire the on-demand SIB1, the UE performs one or more remedial actions, which may include retransmission of a RACH preamble, performing a new RACH procedure, performing cell reselection, and / or performing an essential system information missing procedure.

Description

[0001] REQUESTING ON-DEMAND SIB

[0002] The present application claims the Paris Convention priority of European patent application EP24175055.3, filed 9 May 2024, the contents of which are hereby incorporated by reference.

[0003] BACKGROUND

[0004] Field of Disclosure

[0005] The present disclosure relates to communications devices and infrastructure equipment of wireless communications networks and methods of operating such communications devices and infrastructure equipment.

[0006] Description of Related Art

[0007] The “background” description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly or impliedly admitted as prior art against the present invention.

[0008] Previous generation mobile telecommunication systems, such as those based on the 3GPP defined UMTS and Long Term Evolution (LTE) architecture, are able to support a wider range of services than simple voice and messaging services offered by previous generations of mobile telecommunication systems. For example, with the improved radio interface and enhanced data rates provided by LTE systems, a user is able to enjoy high data rate applications such as mobile video streaming and mobile video conferencing that would previously only have been available via a fixed line data connection. The demand to deploy such networks is therefore strong and the coverage area of these networks, i.e. geographic locations where access to the networks is possible, is expected to continue to increase rapidly.

[0009] Current and future wireless communications networks are expected to routinely and efficiently support communications with an ever-increasing range of devices associated with a wider range of data traffic profiles and types than existing systems are optimised to support. For example, it is expected future wireless communications networks will be expected to efficiently support communications with devices including reduced complexity devices, machine type communication (MTC) devices, high resolution video displays, virtual reality headsets, extended Reality (XR) and so on. Some of these different types of devices may be deployed in very large numbers, for example low complexity devices for supporting the “The Internet of Things”, and may typically be associated with the transmissions of relatively small amounts of data with relatively high latency tolerance. Other types of device, for example supporting high-definition video streaming, may be associated with transmissions of relatively large amounts of data with relatively low latency tolerance. Other types of device, for example used for autonomous vehicle communications and for other critical applications, may be characterised by data that should be transmitted through the network with low latency and high reliability. A single device type might also be associated with different traffic profiles I characteristics depending on the application(s) it is running. For example, different consideration may apply for efficiently supporting data exchange with a smartphone when it is running a video streaming application (high downlink data) as compared to when it is running an Internet browsing application (sporadic uplink and downlink data) or being used for voice communications by an emergency responder in an emergency scenario (data subject to stringent reliability and latency requirements).

[0010] In view of this there is expected to be a desire for current wireless communications networks, for example those which may be referred to as 5G or new radio (NR) systems I new radio access technology (RAT) systems, or indeed future 6G wireless communications, as well as future iterations I releases of existing systems, to efficiently support connectivity for a wide range of devices associated with different applications and different characteristic data traffic profiles and requirements. The desire to support these new use-cases and scenarios gives rise to new challenges for efficiently handling communications in wireless communications systems that need to be addressed.

[0011] SUMMARY OF THE DISCLOSURE

[0012] The present disclosure can help address or mitigate at least some of the issues discussed above.

[0013] Respective aspects and features of the present disclosure are defined in the appended claims.

[0014] It is to be understood that both the foregoing general description and the following detailed description are exemplary, but are not restrictive, of the present technology. The described embodiments, together with further advantages, will be best understood by reference to the following detailed description taken in conjunction with the accompanying drawings.

[0015] BRIEF DESCRIPTION OF THE DRAWINGS

[0016] A more complete appreciation of the disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings wherein like reference numerals designate identical or corresponding parts throughout the several views, and wherein:

[0017] Figure 1 schematically represents some aspects of an LTE-type wireless telecommunication system which may be configured to operate in accordance with certain embodiments of the present disclosure;

[0018] Figure 2 schematically represents some aspects of an NR-type wireless telecommunications system which may be configured to operate in accordance with certain embodiments of the present disclosure;

[0019] Figure 3 is a schematic block diagram of an example infrastructure equipment and communications device which may be configured to operate in accordance with certain embodiments of the present disclosure;

[0020] Figure 4 is a message flow diagram showing a typical four-step random access (RACH) procedure;

[0021] Figure 5 is a message flow diagram showing a typical two-step RACH procedure;

[0022] Figures 6A-C are example scenarios in which a UE may determine that it is unable to acquire an on-demand SIB1 ,

[0023] Figure 7 is a flowchart of an example method for operating a communications device according to the present disclosure. Figure 8 is a flowchart of an example method for operating an infrastructure equipment according to the present disclosure.

[0024] DETAILED DESCRIPTION OF THE EMBODIMENTS

[0025] Long Term Evolution Advanced Radio Access Technology (4G)

[0026] Figure 1 provides a schematic diagram illustrating some basic functionality of a mobile telecommunications network I system 6 operating generally in accordance with LTE principles, but which may also support other radio access technologies, and which may be adapted to implement embodiments of the disclosure as described herein. Various elements of Figure 1 and certain aspects of their respective modes of operation are well-known and defined in the relevant standards administered by the 3GPP (RTM) body, and also described in many books on the subject, for example, Holma H. and Toskala A [1], It will be appreciated that operational aspects of the telecommunications networks discussed herein which are not specifically described (for example in relation to specific communication protocols and physical channels for communicating between different elements) may be implemented in accordance with any known techniques, for example according to the relevant standards and known proposed modifications and additions to the relevant standards.

[0027] The network 6 includes a plurality of base stations 1 connected to a core network 2, which may be for example an Evolved Packet Core (EPC). Each base station provides a coverage area 3 (i.e., a cell) within which data can be communicated to and from communications devices 4. Although each base station 1 is shown in Figure 1 as a single entity, the skilled person will appreciate that some of the functions of the base station may be carried out by disparate, interconnected elements, such as antennas (or antennae), remote radio heads, amplifiers, etc. Collectively, one or more base stations may form a radio access network.

[0028] Data is transmitted from base stations 1 to communications devices 4 within their respective coverage areas 3 via a radio downlink (DL). Data is transmitted from communications devices 4 to the base stations 1 via a radio uplink (UL). The core network 2 routes data to and from the communications devices 4 via the respective base stations 1 and provides functions such as authentication, mobility management, charging and so on. Communications devices may also be referred to as mobile stations, user equipment (UE), user terminal, mobile radio, communications device, and so forth. Services provided by the core network 2 may include connectivity to the internet or to external telephony services. The core network 2 may further track the location of the communications devices 4 so that it can efficiently contact (i.e., page) the communications devices 4 for transmitting downlink data towards the communications devices 4.

[0029] Base stations, which are an example of network infrastructure equipment, may also be referred to as transceiver stations, nodeBs, eNodeBs, eNB, gNodeBs, gNB and so forth. In this regard different terminology is often associated with different generations of wireless telecommunications systems for elements providing broadly comparable functionality. However, certain embodiments of the disclosure may be equally implemented in different generations of wireless telecommunications systems, and for simplicity certain terminology may be used regardless of the underlying network architecture. That is to say, the use of a specific term in relation to certain example implementations is not intended to indicate these implementations are limited to a certain generation of network that may be most associated with that particular terminology.

[0030] New Radio Access Technology (5G) Systems incorporating NR technology are expected to support different services (or types of services), which may be characterised by different requirements for latency, data rate and / or reliability. For example, Enhanced Mobile Broadband (eMBB) services are characterised by high capacity with a requirement to support up to 20 Gb / s. The requirements for Ultra Reliable and Low Latency Communications (URLLC) services are for one transmission of a 32 byte packet to be transmitted from the radio protocol layer 2 / 3 SDU ingress point to the radio protocol layer 2 / 3 SDU egress point of the radio interface within 1 ms with a reliability of 1 - 10-5 (99.999 %) or higher (99.9999%) [2],

[0031] An example configuration of a wireless communications network which uses some of the terminology proposed for and used in NR and 5G is shown in Figure 2. In Figure 2 a plurality of transmission and reception points (TRPs) 10 are connected to distributed control units (DUs) 41 , 42 by a connection interface represented as a line 16. Each of the TRPs 10 is arranged to transmit and receive signals via a wireless access interface within a radio frequency bandwidth available to the wireless communications network. Thus, within a range for performing radio communications via the wireless access interface, each of the TRPs 10 provides an individual coverage area 12, where these coverage areas 12 collectively form a cell of the wireless communications network that is provided by DU 41. As such, wireless communications devices 14 which are within a radio communications range provided by the coverage areas 12 can transmit and receive signals to and from the TRPs 10 via the wireless access interface. Each of the distributed units 41 , 42 are connected to a central unit (CU) 40 (which may be referred to as a controlling node) via an interface 46. The central unit 40 is then connected to the core network 20 (which may be for example referred to as 5GC) which may contain all other functions required to transmit data for communicating to and from the wireless communications devices and the core network 20 may be connected to other networks 30.

[0032] The elements of the wireless access network shown in Figure 2 may operate in a similar way to corresponding elements of an LTE network as described with regard to the example of Figure 1. It will be appreciated that operational aspects of the telecommunications network represented in Figure 2, and of other networks discussed herein in accordance with embodiments of the disclosure, which are not specifically described (for example in relation to specific communication protocols and physical channels for communicating between different elements) may be implemented in accordance with any known techniques, for example according to currently used approaches for implementing such operational aspects of wireless telecommunications systems, e.g. in accordance with the relevant standards.

[0033] The TRPs 10 of Figure 2 may in part have a corresponding functionality to a base station or eNodeB of an LTE network. Similarly, the communications devices 14 may have a functionality corresponding to the UE devices 4 known for operation with an LTE network. It will be appreciated therefore that operational aspects of a new RAT network (for example in relation to specific communication protocols and physical channels for communicating between different elements) may be different to those known from LTE or other known mobile telecommunications standards. However, it will also be appreciated that each of the core network component, base stations and communications devices of a new RAT network will be functionally similar to, respectively, the core network component, base stations and communications devices of an LTE wireless communications network.

[0034] In terms of broad top-level functionality, the core network 20 connected to the new RAT telecommunications system represented in Figure 2 may be broadly considered to correspond with the core network 2 represented in Figure 1 , and the respective central units 40 and their associated distributed units I TRPs 10 may be broadly considered to provide functionality corresponding to the base stations 1 of Figure 1. The term network infrastructure equipment I access node may be used to encompass these elements and more conventional base station type elements of wireless telecommunications systems. Depending on the application at hand the responsibility for scheduling transmissions which are scheduled on the radio interface between the respective distributed units and the communications devices may lie with the controlling node I central unit and I or the distributed units I TRPs. A communications device 14 is represented in Figure 2 within the coverage area of the first communication cell 12. This communications device 14 may thus exchange signalling with the first central unit 40 in the first communication cell 12 via one of the distributed units I TRPs 10 associated with the first communication cell 12.

[0035] It will further be appreciated that Figure 2 represents merely one example of a proposed architecture for a new RAT based telecommunications system in which approaches in accordance with the principles described herein may be adopted, and the functionality disclosed herein may also be applied in respect of wireless telecommunications systems having different architectures.

[0036] Thus, certain embodiments of the disclosure as discussed herein may be implemented in wireless telecommunication systems I networks according to various different architectures, such as the example architectures shown in Figures 1 and 2. It will thus be appreciated the specific wireless telecommunications architecture in any given implementation is not of primary significance to the principles described herein. In this regard, certain embodiments of the disclosure may be described generally in the context of communications between network infrastructure equipment I access nodes and a communications device, wherein the specific nature of the network infrastructure equipment I access node and the communications device will depend on the network infrastructure for the implementation at hand. For example, in some scenarios the network infrastructure equipment I access node may comprise a base station, such as an LTE- type base station 1 as shown in Figure 1 which is adapted to provide functionality in accordance with the principles described herein, and in other examples the network infrastructure equipment may comprise a control unit I controlling node 40 and / or a TRP 10 of the kind shown in Figure 2 which is adapted to provide functionality in accordance with the principles described herein.

[0037] A more detailed diagram of some of the components of the network shown in Figure 2 is provided by Figure 3. In Figure 3, a TRP 10 as shown in Figure 2 comprises, as a simplified representation, a wireless transmitter 30, a wireless receiver 32 and a controller or controlling processor 34 which may operate to control the transmitter 30 and the wireless receiver 32 to transmit and receive radio signals to one or more UEs 14 within a cell 12 formed by the TRP 10. As shown in Figure 3, an example UE 14 is shown to include a corresponding transmitter 49, a receiver 48 and a controller 44 which is configured to control the transmitter 49 and the receiver 48 to transmit signals representing uplink data to the wireless communications network via the wireless access interface formed by the TRP 10 and to receive downlink data as signals transmitted by the transmitter 30 and received by the receiver 48 in accordance with the conventional operation.

[0038] The transmitters 30, 49 and the receivers 32, 48 (as well as other transmitters, receivers and transceivers described in relation to examples and embodiments of the present disclosure) may include radio frequency filters and amplifiers as well as signal processing components and devices in order to transmit and receive radio signals in accordance for example with the 5G / NR standard. The controllers 34, 44 (as well as other controllers described in relation to examples and embodiments of the present disclosure) may be, for example, a microprocessor, a CPU, or a dedicated chipset, etc., configured to carry out instructions which are stored on a computer readable medium, such as a non-volatile memory. The processing steps described herein may be carried out by, for example, a microprocessor in conjunction with a random access memory, operating according to instructions stored on a computer readable medium. The transmitters, the receivers and the controllers are schematically shown in Figure 3 as separate elements for ease of representation. However, it will be appreciated that the functionality of these elements can be provided in various different ways, for example using one or more suitably programmed programmable computer(s), or one or more suitably configured application-specific integrated circuit(s) I circuitry I chip(s) I chipset(s). As will be appreciated the infrastructure equipment I TRP I base station as well as the UE I communications device will in general comprise various other elements associated with its operating functionality.

[0039] As shown in Figure 3, the TRP 10 also includes a network interface 50 which connects to the DU 42 via a physical interface 16. The network interface 50 therefore provides a communication link for data and signalling traffic from the TRP 10 via the DU 42 and the CU 40 to the core network 20.

[0040] The interface 46 between the DU 42 and the CU 40 is known as the F1 interface which can be a physical or a logical interface. The F1 interface 46 between CU and DU may operate in accordance with 3GPP technical specifications [3] and [4], and may be formed from a fibre optic or other wired or wireless high bandwidth connection. In one example the connection 16 from the TRP 10 to the DU 42 is via fibre optic. The connection between a TRP 10 and the core network 20 can be generally referred to as a backhaul, which comprises the interface 16 from the network interface 50 of the TRP 10 to the DU 42 and the F1 interface 46 from the DU 42 to the CU 40.

[0041] As will be appreciated by those acquainted with 5G architecture, the CU 40 may be a logical node which hosts Radio Resource Control (RRC) protocols, Service Data Adaptation Protocols (SDAP), and Packet Data Convergence Protocols (PDCP) of a gNB. Alternatively, the CU 40 may be a logical node which hosts RRC and PDCP protocols of an en-gNB (which is a gNB that is able to connect with both EPC and eNBs and can be understood as being, for example, a secondary node (SgNB) used in dual connectivity scenarios). The CU 40 partly controls the operation of one or more DUs 40 and terminates the F1 interfaces 46 for the DUs that it controls. The DU 42 may be a logical node which hosts Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) layers of a gNB or en-gNB. The operation of the DU 42 is partly controlled by the CU 40 for which the DU 42 terminates the F1 interface 46.

[0042] Although not shown in Figures 2 or 3, it will be familiar to those acquainted with 5G architecture that the CU 40 may be further split into a CU-CP which performs the control plane functions of the CU 40 and a CU-UP which performs the user plane functions of the CU 40 (see for example, [5]). In more detail, the CU-CP may be a logical node hosting an RRC protocol and a control plane part of a PDCP protocol of the CU 40 for the gNB or en-gNB. The CU-CP terminates an E1 interface connected with the CU-UP and an F1-C interface connected with the DU 42. As will be appreciated, the F1-C interface carries control plane signalling of the F1 interface 46. The CU-UP may be a logical node which hosts a user plane part of a PDCP protocol of the CU 40 for an en-gNB. Alternatively, the CU-UP may be a logical node which hosts a user plane part of the PDCP protocol and an SDAP protocol of the CU 40 for a gNB. The CU-UP terminates an E1 interface connected with the CU-CP and an F1-U interface connected with the DU 42. As will be appreciated, the F1-U interface carries user plane signalling of the F1 interface 46.

[0043] Random Access (RACH) Procedures In wireless communications networks, such as LTE and NR / 5G type networks, a random access procedure may be used by communications devices to perform initial access with the wireless communications network. The random access procedure involves the communications device transmitting a preamble on a physical random access channel (PRACH), and so the procedure is commonly referred to as a RACH or PRACH procedure I process. The RACH procedure may be a two-step RACH procedure or a four-step RACH procedure as described in more detail below.

[0044] In addition, there exists Radio Resource Control (RRC) modes for communications devices. For example, it is common to support an RRC idle mode (RRCJDLE) and an RRC connected mode (RRC_CONNECTED). A communications device in the RRCJDLE mode may transition to RRC_CONNECTED mode, for example because it needs to transmit uplink data or respond to a paging request, by undertaking a random access procedure.

[0045] In addition to a communications device deciding itself to initiate a random access procedure to connect to the wireless communications network, it is also possible for the wireless communications network, e.g. a base station, to instruct a communications device in an RRC_CONNECTED mode to initiate a random access procedure by transmitting to the communications device an instruction to do so. Such an instruction is sometimes referred to as a PDCCH (Physical Downlink Control Channel) order to RACH. There are various scenarios in which a network-triggered RACH procedure (PDCCH order) may arise.

[0046] Figure 4 shows a typical four-step RACH procedure used in LTE systems such as that described by reference to Figure 1 which is also applied to an NR wireless communications system such as that described by reference to Figure 2. A communications device (or UE), which may be in an RRCJDLE mode for example, may have some data which it needs to send to the network. To do so, the UE sends a random access preamble 51 (message 1) to a gNB. This random access preamble 51 is associated with a RACH preamble ID (RAPID) which may allow the gNB to address the communications device during later stages of the RACH procedure. Assuming the random access preamble 51 is successfully received by the gNB, the gNB will transmit a random access response 52 message (message 2) to the communications device(s) which includes the RAPID. As such the UE reading the response 52 is able to determine that the response 52 is intended for itself by comparing the RAPID included in the response to the RAPID associated with the RACH preamble 51 it previously transmitted. The random access response 52 message carries a further identity which is assigned by the gNB to identify the communications device, as well as a timing advance value such that the communications device can change its timing to compensate for the round trip delay caused by its distance from the gNB and grant uplink resources for the communications device to transmit the data in.

[0047] Following the reception of the random access response message 52, the communications device transmits the scheduled transmission of data 53 to the gNB (message 3), using the identity assigned to it in the random access response message 52. Assuming there were no collisions with other UEs during the transmission of message 1 , which may occur if another UE and the communications device send the same random access preamble 51 to the gNB at the same time and using the same frequency resources, the scheduled transmission of data 53 is successfully received by the gNB. The gNB will respond to the scheduled transmission 53 with a contention resolution message 54 (message 4).

[0048] In 5G / NR systems, an “inactive” RRC mode (RRCJNACTIVE) may be used, where a UE is able to start data transfer with a low delay in the RRCJNACTIVE mode without transition to the RRC_CONNECTED mode. Various possible solutions have been proposed to permit this, one of which is a two-step RACH procedure. As will be appreciated, compared with the four-step RACH process, the two-step RACH process can provide a facility for transmitting data more quickly. Accordingly, general MAC procedures covering both physical layer and higher layer aspects for the two-step RACH process have been standardised. In general, the benefit of the two-step RACH procedure compared with the four-step RACH procedure is to reduce the time it takes for connection setup / resume procedure. For example, in an ideal situation, the two-step RACH will reduce the latency by halving the number of steps from four to two for initial access UEs. In addition, it is considered that a two-step RACH procedure has potential benefits for channel access in NR unlicensed spectrum (NR-ll).

[0049] Broadly, the two-step RACH allows the combination of the transmission of the random access preamble 51 with the transmission of data 53 of Figure 4 as an initial transmission (“Message A” or “MsgA”), and similarly the combination of the transmission of the random access response 52 and contention resolution message 54 as a response (“Message B”, or “MsgB”). A fallback procedure may be provided to allow a RACH procedure which is started according to the specifications for a two-step RACH to instead proceed according to the four-step RACH procedure if, for example the preamble in MsgA is received but not the data. Two-step RACH may be performed by communications devices in the RRCJDLE, RRCJNACTIVE or RRC_CONNECTED modes.

[0050] A message flow diagram illustrating the two-step RACH process is shown in Figure 5. As its name suggests, in the two-step RACH process, there are only two-steps as noted above. In the first step, the UE transmits a Message A 55 which comprises a RACH preamble 56 and data 57. The data 57 is transmitted on a shared uplink channel, such as a physical uplink shared channel, PLISCH that in a four-step RACH procedure would be transmitted in Message 3. More specifically, the choice of a particular preamble 56 may pre-configure the communications device to transmit the data 57 in pre-configured resources of the uplink shared channel. In the second step, the base station, having successfully received the Message A 55, responds with a Message B 58 which incorporates both a RAR, as would be carried by message 2 of the four-step RACH procedure described above, and the corresponding contention resolution and / or data (PDSCH) that in a four-step RACH procedure would be transmitted in Message 4.

[0051] Network Energy Saving (NES)

[0052] 3GPP is currently discussing network energy saving (NES). By reducing energy consumption in wireless communications networks, the impact of wireless communications on the environment can be reduced. For example, if less energy is consumed in wireless communications networks, fewer fossil fuels are burned, there are fewer greenhouse gas emissions and therefore environmental sustainability is improved. Furthermore, the reduction of energy consumption in wireless communications networks can reduce costs incurred by network operators.

[0053] 5G / NR can handle advanced services and applications requiring very high data rates (for example, XR). Additionally, 5G I NR networks are becoming denser, using more antennas, and utilising larger bandwidths and an increasing number of frequency bands. Therefore, in at least some cases, energy consumption in 5G I NR is increasing. Since 5G I NR is becoming increasingly pervasive across various industries and geographical areas, it is becoming increasingly important to reduce the environmental impact of 5G / NR networks. NES solutions are therefore required.

[0054] In addition, energy consumption has become a key part of the operating expenses (OPEX) for network operators. According to a report from the Global System for Mobile Communications (GSMA) [6], the energy cost of mobile networks accounts for approximately 23% of total operator cost. Most of the energy consumption comes from the radio access network and in particular from the Active Antenna Unit (AAU), with data centres and fibre transport accounting for a smaller share of the energy consumption. The energy consumption of a radio access network can be split into two parts: (1) a dynamic part which is only consumed when data transmission / reception is ongoing, and (2) a static part which is consumed all the time to maintain the necessary operation of the radio access network equipment, even when data transmission / reception is not on-going. Further details on NES can be found in [7],

[0055] In Release 19 of the 3GPP standards, an NES work item has been approved ([8]). The objectives of the work item are the following:

[0056] 1. Specify procedures and signaling method(s) to support on-demand SSB SCell operation for UEs in connected mode configured with CA, for both intra- / inter-band CA.

[0057] 2. Study procedures and signaling method(s) to support on-demand SIB1 for UEs in idle / inactive mode, including:

[0058] 3. Specify adaptation of common signal / channel transmissions.

[0059] NES and System Information (SI)

[0060] As will be understood by a person skilled in the art, system information is transmitted by infrastructure equipment of a wireless communications network to communications devices in a cell provided by the infrastructure equipment. The system information informs the communications devices on how to access services provided by the wireless communications network. The system information comprises a master information block (MIB), system information block type 1 (SIB1) and a plurality of other system information blocks (SIBs). The MIB is broadcast in the PBCH in each SSB. The MIB comprises information required to acquire / decode SIB1 . SIB1 comprises information required for performing initial access (for example, random access parameters such as time / frequency resources for PRACH (e.g an RO configuration), preambles, and barring parameters. Therefore, MIB and SIB1 together provide all the information which is required for initial access. Accordingly, SIB1 is defined as the “remaining minimum SI”. SIB1 may comprise scheduling information of the other SIBs (for example, mapping of SIBs to SI message, periodicity of other SIBs and Sl-window size). SIB1 is broadcast periodically over a downlink shared channel (DL-SCH), but may be provided on-demand as explained below. Periodically broadcast SIB1 is typically an “always-on” signal. The information comprised in the other SIBs is not required for initial access and SIB1 may comprise an indication of whether the other SIBs are provided on-demand, in which case, SIB1 may also comprise an indication of a PRACH configuration for use by the UE to request the other SIBs. SIB1 may also comprise radio resource configuration information common to all communications devices in the cell in which the SIB1 is transmitted. SIB1 may also comprise cell barring information.

[0061] The other SIBs may comprise one or more of: SIB2-SIB18 and SIBpos.

[0062] — SIB2 comprises cell re-selection information, mainly related to the serving cell;

[0063] — SIB3 comprises information about the serving frequency and intra-frequency neighbouring cells relevant for cell re-selection (including cell re-selection parameters common for a frequency as well as cell specific re-selection parameters);

[0064] — SIB4 comprises information about other NR frequencies and inter-frequency neighbouring cells relevant for cell re-selection (including cell re-selection parameters common for a frequency as well as cell specific re-selection parameters), which can also be used for NR idle / inactive measurements;

[0065] — SIB5 comprises information about E-LITRA frequencies and E-LITRA neighbouring cells relevant for cell re-selection (including cell re-selection parameters common for a frequency as well as cell specific re-selection parameters);

[0066] — SIB6 comprises an ETWS primary notification;

[0067] — SIB7 comprises an ETWS secondary notification;

[0068] — SIB8 comprises a CMAS warning notification;

[0069] — SIB9 comprises information related to GPS time and Coordinated Universal Time (UTC);

[0070] — SIB10 comprises the Human-Readable Network Names (HRNN) of the NPNs listed in SIB1 ;

[0071] — SIB11 comprises information related to idle / inactive measurements;

[0072] — SIB15 comprises information related to disaster roaming;

[0073] — SIB16 comprises slice-based cell reselection information;

[0074] — SIB17 comprises information related to TRS configuration for UEs in RRC J DLE / RRCJN ACTIVE;

[0075] — SIBpos comprises positioning assistance data as defined in TS 37.355 and TS 38.331 ;

[0076] — SIB18 comprises information related to the Group IDs for Network selection (GINs) associated with SNPNs listed in SIB1.

[0077] Further information regarding existing SI can be found in TS38.300 v18.0.0, the contents of which are hereby incorporated by reference in their entirety.

[0078] In the NES study phase of Release-18 of the 3GPP standards, it has been suggested to introduce an on-demand SIB1. In other words, instead of infrastructure equipment of the wireless communications network periodically broadcasting SIB1 , it has been proposed for infrastructure equipment (i.e. NES infrastructure equipment) to broadcast SIB1 in response to a request (or trigger such as a wake-up signal) from a UE. Since the SIB1 would be transmitted less often, network energy savings would be increased. However, the details of such an on-demand SIB1 have not yet been discussed.

[0079] There is therefore a need to define UE behaviour when requesting on-demand SIB1 , in particular in cases where the acquisition of on-demand SIB1 may be unsuccessful.

[0080] For example, in some cases a UE’s request for on-demand SIB1 may be unsuccessful. In such cases, the UE’s behaviour is currently unspecified and may be subject to individual UE implementation. However, as SIB1 includes information that is highly important for UEs for initial access and scheduling, general UE behaviour should be specified for cases where obtaining on- demand SIB1 is unsuccessful, in order to maximise a UE’s ability to obtain the information included within the SIB1 and not unduly affect quality of service to the network users.

[0081] According to the present disclosure, a communications device, such as a UE, may transmit, to an infrastructure equipment of the wireless communications network a request for an on-demand system information block (SIB) using for example, part of a random access (PRACH) procedure, wherein the on-demand SIB includes information for initial access procedures for the infrastructure equipment (i.e. the on-demand SIB is an on-demand SIB1). The communications device may then determine that the request failed either because it does not receive a response from the infrastructure equipment of the wireless communications network or because it is unable to acquire / decode the on-demand SIB, and, in response to determining that the request has failed, perform one or more predetermined remedial actions.

[0082] In this way, a UE may be able to request on-demand SIB1 using part of a RACH procedure, and may be able to perform appropriate predefined actions in order to obtain the on-demand SIB1 or otherwise connect to the network. Therefore, in contrast to legacy implementations, if the UE is unable to decode / acquire SIB1 , the UE does not immediately consider the cell provided by the infrastructure equipment to be barred, but rather takes an appropriate predetermined action in order to obtain the on-demand SIB1 or otherwise connect to the network. Furthermore, UEs are able to quickly and reliably obtain the on-demand SIB1 , for example when the UE has uplink data to transmit, in a manner which does not appreciably degrade network performance, even if network energy saving is enabled.

[0083] The UE may transmit the request for on-demand SIB1 in multiple different ways. For example, the UE may use a Msg1 based procedure to request on-demand SIB1 , where the request for on- demand SIB1 is included in Msg 1 of the RACH procedure (i.e. the on-demand SIB1 request is transmitted via a random access preamble 51 as shown in Figure 4). This may be done in various different ways. For example, the particular random access preamble 51 may be a preamble which indicates to the gNB / network that the UE is requesting on-demand SIB1. In such cases, the gNB may transmit a random access response (RAR) 52 message to the UE, which may indicate a random access preamble identity (RAPID) it received, and may include information related to the on-demand SIB1 such as a time window in which the on-demand SIB1 requested by the UE will be transmitted. In other cases, after the UE receives a normal RAR in Msg2, the UE may then use Msg3 in a Msg3-based procedure to request on-demand SIB1 , where the request for on- demand SIB1 is included in Msg3 of the RACH procedure (i.e. the actual request for on-demand SIB1 is included in Msg3 53 (i.e. with the scheduled transmission) of the RACH procedure shown in Figure 4. Moreover, while the UE may request the on-demand SIB1 in one or more of Msg1 and / or Msg3 of the four-step RACH procedure shown in Figure 4, it should be appreciated that the UE may also request the on-demand SIB1 in Message A 55 of the two-step RACH procedure shown in Figure 5.

[0084] As discussed above, the UE may take remedial actions based on determining that the UE is unable to acquire the on-demand SIB1. This determination may be made in a number of different ways. An example is shown in Figure 6A, illustrating a communications device / UE 62 comprising a transceiver 62.1 and a controller 62.2, and an infrastructure equipment / gNB 64 comprising a transceiver 64.1 and a controller 64.2. In the example of Figure 6A, the UE 62 determines that it is unable to acquire an on-demand SIB1 from the infrastructure equipment 64 based on determining that the RACH procedure has failed. As shown in Figure 6A, a UE 62 may transmit to the infrastructure equipment 64 a request 65 for on-demand SIB1. The request 65 is transmitted as part of a RACH procedure, for example as part of Msg1 or Msg3 of a four-step RACH procedure, or as part of Message A of a two-step RACH procedure. However, in the example of Figure 6A the UE 62 determines that the RACH procedure has failed. For example, as shown in Figure 6A, the UE 62 may not receive a RAR 66 from the infrastructure equipment 64 within a pre-configured time period. This may occur for various reasons. For example, the infrastructure equipment 64 may not have dictated or decoded the request successfully and so does not transmit the RAR 66, or the UE 62 may be out of coverage when the RAR 66 is transmitted, or there may be a network delay (e.g. due to congestion) in the transmission of the RAR 66, or any other reason may mean that the UE 62 does not receive a RAR 66 from the infrastructure equipment 64 within a pre-configured time period. Accordingly, the UE 62 may determine that the request for SIB1 has failed. Alternatively, the UE 62 may receive a RAR 66, however the random access preamble (RAPID) indicated in the RAR 66 may not match the RAPID of the preamble the UE 62 originally transmitted in the request in the RACH procedure Msg1. In response to determining that the RACH procedure has failed, the UE 62 may determine that it is unable to acquire an on-demand SIB1 from the infrastructure equipment 64.

[0085] A further example is shown in Figure 6B. The UE 62 transmits to the infrastructure equipment 64 a request 65 for on-demand SIB1 in the same manner as discussed above in relation to Figure 6A. In this example, the UE 62 determines whether it is able to acquire an on-demand SIB1 67 from the infrastructure equipment 64 without reference to whether the RACH procedure has completed successfully. That is, the UE 62 determines whether it has been able to acquire an on- demand SIB1 67 within a pre-configured time period 68 from transmission of the request 65 for the on-demand SIB1 (or from the transmission of a random access preamble). As such, the UE’s 62 determination as to whether it is able to acquire an on-demand SIB1 67 is agnostic as to whether the RACH procedure has been successfully completed. This scenario may occur if, for example, the network is not configured to send a RAR on detection of a request 65 of on-demand SIB1.

[0086] An additional example is shown in Figure 6C. In this example, the UE 62 transmits to the infrastructure equipment 64 a request 65 for on-demand SIB1 in the same manner as discussed above in relation to Figure 6A. In this example, the infrastructure equipment 64 transmits a RAR 66, which is received by the UE 62, and the UE 62 may determine that the RACH procedure has completed successfully. However, the UE 62 may nevertheless be unable to acquire the on- demand SIB1 67 within a preconfigured time period 69 (e.g. from receipt of the RAR 66, or from the UE 62 determining that the RACH procedure has successfully completed). This may occur for various reasons. For example, network congestion may prevent the transmission of the on- demand SIB1 67, or may delay the transmission of the on-demand SIB1 until after the preconfigured time period 69, or the UE 62 may move out of coverage when the on-demand SIB1 is transmitted by the infrastructure equipment 64. Based on not acquiring the on-demand SIB1 within the preconfigured time period 69, the UE 62 may determine that it is unable to acquire the on-demand SIB1 68.

[0087] While the examples discussed above in relation to Figures 6A-C have been described separately for ease of explanation, it should be appreciated that in some cases two or more of these examples discussed above in relation to Figures 6A-C may be implemented in combination with one another.

[0088] In response to determining that the UE is unable to acquire the on-demand SIB1 , the UE takes one or more remedial actions in order to attempt to obtain the on-demand SIB1 or otherwise connect to the network. The remedial action(s) taken by the UE may be based on the manner in which the UE is unable to acquire the on-demand SIB1. For example, if the UE determines that the RACH procedure has failed (e.g. as in Figure 6A) the UE may take different remedial action(s) than if the RACH procedure has successfully completed. The one or more remedial actions may be preconfigured for the UE, and may in some cases be preconfigured for the different scenarios in which the UE is unable to acquire the on-demand SIB1. An example of a remedial action may include the UE re-transmitting the request for the on- demand SIB1. In other words, the UE may re-transmit the RACH preamble which indicates that the on-demand SIB1 is requested. Therefore, the retransmission of the request for the on-demand SIB1 is part of a same RACH procedure as the initial request for the on-demand SIB1. In some cases, the UE may continue to re-transmit the request for the on-demand SIB1 until a maximum number of retransmissions is reached, where the maximum number of retransmissions may be preconfigured for the UE. If the maximum number of retransmissions is reached and the UE has still not acquired the on-demand SIB1 or has not received a RAR from the gNB, the UE may in some cases conclude that the RACH procedure has failed.

[0089] Another example of a remedial action may include the UE initiating one or more new RACH procedures. In some cases, the UE may continue to initiate new RACH procedures until a maximum number of RACH attempts is reached, where the maximum number of RACH procedures may be preconfigured for the UE. The UE may initiate a new RACH procedure, for example in response to determining that the UE’s initial RACH procedure (in which the on- demand SIB1 was request) has failed. The new RACH procedure may also include, if necessary, one or more retransmissions of the RACH preamble selected for the new RACH procedure until a preconfigured number of retransmissions is reached. If the new RACH procedure also fails, the UE may in some cases repeat this process of initiating further RACH procedures until the maximum number of RACH procedures is reached. However, the one or more new RACH procedures may additionally or alternatively be initiated in response to any other failure mode (i.e. cases where the UE has not been able to acquire the on-demand SIB1 , but the UE has not determined that a RACH procedure has failed).

[0090] The initiation of one or more new RACH procedures may be implemented in various different ways. For example, the UE may immediately initiate a new RACH procedure after determining that its previous RACH procedure requesting the on-demand SIB1 has failed. Alternatively, the UE may initiate a new RACH procedure within a preconfigured period of time after determining that its previous RACH procedure requesting the on-demand SIB1 has failed. Alternatively, the UE may initiate a new RACH procedure after expiry of a preconfigured timer after determining that its previous RACH procedure requesting the on-demand SIB1 has failed.

[0091] In addition or as an alternative to initiating one or more new RACH procedures, the UE may perform a cell reselection procedure. As such, the UE may identify and select a new cell (operated by a second infrastructure equipment or the same infrastructure equipment), and attempt to connect to the new cell. The selection may be based on a signal strength (e.g. received signal reference power (RSRP)) of one or more synchronisation signals (e.g. synchronization signal block (SSB)) broadcast by the second / same infrastructure equipment. A threshold signal strength (for the synchronisation signal broadcast by the second / same infrastructure equipment) for the UE to connect to the second / same infrastructure equipment may be preconfigured for the UE. It should be noted that cell reselection may be performed by the UE in response to a single RACH procedure failure, or in response to multiple RACH procedure failures. Cell reselection may alternatively be performed without determining that a RACH procedure has failed, for example in response to determining that a UE has been unable to acquire an on-demand SIB1 (e.g. within a predetermined time period).

[0092] In some cases, if the UE determines that it is unable to acquire the on-demand SIB1 (for example due to one or more failed RACH procedures or an inability to acquire the on-demand SIB1 within a preconfigured time period) the UE may determine that the cell provided by the infrastructure equipment is missing essential system information. Accordingly, the UE may initiate a pre-defined missing essential system information procedure. An example of such a process is defined in Section 5.2.2.5 of [9], As briefly mentioned above, the remedial actions discussed above may be executed individually or any combination of two or more of these remedial actions may be executed sequentially.

[0093] As discussed above, after sending a request of on-demand SIB1 to the infrastructure equipment, a UE may monitor for the requested on-demand SIB1 at a particular time. The time at which the UE monitors for the on-demand SIB1 may be determined in a number of different ways. For example, if the UE transmits the request for the on-demand SIB1 as a transmission of a random access preamble (i.e. in Msg 1 of a RACH procedure), then the RAR transmitted by the infrastructure equipment may indicate a start time for the UE to begin monitoring for the on- demand SIB1. The start time may be indicated in the form of an absolute time, and / or may also indicate a timer, or time window, or a particular slot, and optionally a slot offset. In cases where the request for the on-demand SIB1 is included in Msg3 of the RACH procedure, the timing information for the on-demand SIB1 may be indicated in Msg 4 of the RACH procedure.

[0094] In some cases, the time at which the UE should monitor for the requested on-demand SIB1 may not necessarily be indicated in a transmission from the infrastructure equipment. Instead, the UE may be configured to monitor for the on-demand SIB1 in a predetermined time period after receiving a reply (e.g. a RAR) from the infrastructure equipment. The predetermined time period may indicate a start and end time after receiving the RAR for monitoring for the on-demand SIB1. After expiry of the predetermined time period, if the UE has not been able to acquire the on- demand SIB1 , the UE may determine that the UE is unable to acquire the on-demand SIB1. The monitoring for the on-demand SIB1 entails the UE monitoring PDCCH for a DCI with SI-RNTI scheduling a PDSCH in which the on-demand SIB1 will be delivered.

[0095] In particular examples, the preconfigured time window (i.e. start time, end time, and / or duration) may be different depending on a required latency between the RAR transmission and SIB1 transmission by the network. For example, if the cell which on-demand SIB1 is requested and the cell that the on-demand SI B1 is transmitted from are the same, it may be assumed that the latency from the RAR reception to the on-demand SIB1 transmission may be comparatively short. Conversely, if the cell on which on-demand SIB1 is requested and the cell that the on-demand SIB1 is transmitted from are different, it may be assumed that the latency from the RAR reception to on-demand SIB1 transmission may be comparatively large. Therefore, the preconfigured time window may be adjusted according to this assumed latency.

[0096] In certain cases, the UE may begin monitoring for the on-demand SIB1 after a predetermined time period has expired after transmission of the request for the on-demand SIB1. Furthermore, it should be noted that some or all of the above examples for determining when to monitor for the requested on-demand SIB1 may be combined with one another.

[0097] Figure 7 is a flowchart of an example method 700 for operating a communications device according to the present disclosure. Step 710 includes transmitting, to an infrastructure equipment and using a random access (RACH) procedure, a request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access procedures for the infrastructure equipment. Step 720 includes determining that the communications device is unable to acquire the on-demand SIB. Step 730 includes, in response to determining that the communications device is unable to acquire the on-demand SIB, performing one or more predetermined remedial actions. Figure 8 is a flowchart of an example method for operating an infrastructure equipment according to the present disclosure. Step 810 includes receiving, from a communications device, a first request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access to the infrastructure equipment, and wherein the first request uses a random access (RACH) procedure. Step 820 includes transmitting, to the communications device, a response to the request for the on-demand SIB. Step 830 includes after transmitting the response to the request for the on-demand SIB, transmitting the on-demand SIB for receipt by the communications device. Step 840 includes receiving, from the communications device, one or more retransmissions of the request for the on-demand SIB.

[0098] Accordingly, from one perspective there has been described: methods, communications device, infrastructure equipment and circuitry for defining UE behaviour when requesting on-demand SIB1 , in particular when the on-demand SIB1 cannot be acquired by the UE. Based on determining that the UE is unable to acquire the on-demand SIB1 , the UE performs one or more remedial actions, which may include retransmission of a RACH preamble, performing a new RACH procedure, performing cell reselection, and / or performing an essential system information missing procedure.

[0099] The following numbered clauses provide further example aspects and features of the present technique:

[0100] 1. A method of operating a communications device to communicate with infrastructure of a wireless communications network via a wireless access interface provided by the infrastructure equipment, the method comprising: transmitting, to the infrastructure equipment and using a random access (RACH) procedure, a request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access procedures for the infrastructure equipment; determining that the communications device is unable to acquire the on-demand SIB and; in response to determining that the communications device is unable to acquire the on- demand SIB, performing one or more predetermined remedial actions.

[0101] 2. The method according to clause 1 , wherein the on-demand SIB is an on-demand SIB1 .

[0102] 3. The method according to clause 1 or clause 2, wherein the one or more predetermined remedial actions include retransmitting, to the infrastructure equipment, the request for the on- demand SIB.

[0103] 4. The method according to clause 3, comprising retransmitting the request for the on- demand SIB until a predetermined number of retransmissions is reached.

[0104] 5. The method according to clause 3 or 4, wherein the retransmission of the request for the on-demand SIB is transmitted with increased transmission power.

[0105] 6. The method according to any of clauses 1-5, further comprising determining that the RACH procedure has failed.

[0106] 7. The method of clause 6, wherein the one or more predetermined remedial actions include: initiating one or more further RACH procedures with the infrastructure equipment to request the on-demand SIB. 8. The method of clause 7, comprising initiating the one or more further RACH procedures until a predetermined maximum number of RACH procedure attempts is reached.

[0107] 9. The method of any of clauses 7-8, comprising: initiating the one or more further RACH procedures immediately upon determining that the RACH procedure has failed.

[0108] 10. The method of any of clauses 7-9, comprising: initiating the one or more further RACH procedures within a predetermined time period from determining that the RACH procedure has failed.

[0109] 11. The method of any of clauses 7-10, comprising: initiating the one or more further RACH procedures after at least a minimum time period from the determining that the RACH procedure has failed.

[0110] 12. The method of any of clauses 7-11 , further comprising: initiating one or more further RACH procedures with a different cell provided by the wireless communications network.

[0111] 13. The method of clause 12, further comprising: selecting the different cell based on a measured signal strength of synchronisation signal broadcast by the different cell.

[0112] 14. The method of any preceding clause, wherein determining that the communications device is unable to acquire the on-demand SIB is based on the communications device not receiving, within a predetermined time period, a random access response (RAR) from the wireless communications network.

[0113] 15. The method of any of clauses 1-13, wherein determining that communications device is unable to acquire the on-demand SIB is based on the communications device determining that a random access preamble included in a random access response (RAR) received from the wireless communications network does not match a random access preamble included in a random access request transmitted by the communications device.

[0114] 16. The method of any preceding clause, wherein determining that the communications device is unable to acquire the on-demand SIB is based on determining that the communications device has been unable to acquire the on-demand SIB within a predetermined period of time from transmitting the request for the on-demand SIB.

[0115] 17 The method of any preceding clause, wherein the one or more remedial actions comprise: initiating an essential system information missing procedure.

[0116] 18. The method of any of clauses 1-17, further comprising: determining that the RACH procedure has successfully completed, and wherein determining that the communications device is unable to acquire the on-demand SIB is based on determining that the communications device has been unable to acquire the on-demand SIB within a predetermined period of time.

[0117] 19. The method of any preceding clause, wherein the request for the on-demand SIB is transmitted as a random access preamble, as part of an initial message of the RACH procedure.

[0118] 20. The method of any preceding clause, wherein the request for the on-demand SIB is transmitted as part of a message of the RACH procedure, wherein the message of the RACH procedure is transmitted after receiving a random access response message from the wireless communications network.

[0119] 21. The method according to any preceding clause, further comprising: determining a monitoring time period in which to monitor for the on-demand SIB; and monitoring for the on-demand SIB in the determined monitoring time period.

[0120] 22. The method according to clause 21 , wherein the monitoring time period is indicated in a random access response received from the wireless communications network as part of the RACH procedure.

[0121] 23. The method according to clause 21 or clause 22, wherein the monitoring time period is a predetermined period of time after a time at which a random access response is received from the wireless communications network as part of the RACH procedure.

[0122] 24. The method according to any of clauses 21-23, wherein the monitoring time period is determined based on whether: the random access response is received from the infrastructure equipment to which the request for the on-demand SIB is transmitted, or the random access response is received from an entity of the wireless communications network other than the infrastructure equipment to which the request for the on-demand SIB is transmitted.

[0123] 25. The method according to clause 24, wherein a start time of the monitoring time period is set to be later, and / or a length of the monitoring time period is set to be longer, based on determining that the random access response is received from an entity of the wireless communications network other than the infrastructure equipment to which the request for the on- demand SIB is transmitted.

[0124] 26. The method according to any of clauses 21-25, wherein the monitoring time period is a predetermined time period after transmitting the request for the on-demand SIB.

[0125] 27. A communications device configured to transmit signals to and / or to receive signals from an infrastructure equipment of a wireless communications network via a wireless radio interface provided by the wireless communications network, the communications device comprising: a transmitter configured to transmit signals, a receiver configured to receive signals, and a controller configured in combination with the transmitter and the receiver to: transmit, to the infrastructure equipment and using a random access (RACH) procedure, a request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access procedures for the infrastructure equipment; determine that the communications device is unable to acquire the on-demand SIB and; in response to determining that the communications device is unable to acquire the on- demand SIB, perform one or more predetermined remedial actions.

[0126] 28. Circuitry for a communications device configured to transmit signals to and / or to receive signals from an infrastructure equipment of a wireless communications network via a wireless radio interface provided by the wireless communications network, the circuitry comprising: transmitter circuitry configured to transmit signals, receiver circuitry configured to receive signals, and controller circuitry configured in combination with the transmitter circuitry and the receiver circuitry to: transmit, to the infrastructure equipment and using a random access (RACH) procedure, a request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access procedures for the infrastructure equipment; determine that the communications device is unable to acquire the on-demand SIB and; in response to determining that the communications device is unable to acquire the on- demand SIB, perform one or more predetermined remedial actions.

[0127] 29. A method of operating an infrastructure equipment of a wireless communications network to communicate with a communications device via a wireless access interface provided by the infrastructure equipment, the method comprising: receiving, from a communications device, a first request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access to the infrastructure equipment, and wherein the first request uses a random access (RACH) procedure; transmitting, to the communications device, a response to the request for the on-demand SIB; after transmitting the response to the request for the on-demand SIB, transmitting the on-demand SIB for receipt by the communications device; and receiving, from the communications device, one or more retransmissions of the request for the on-demand SIB.

[0128] 30. The method according to clause 29, further comprising: retransmitting, in response to the one or more retransmissions of the request for the on- demand SIB, the response to the request for the on-demand SIB; and retransmitting the on-demand SIB for receipt by the communications device.

[0129] 31. The method according to clause 30, further comprising: receiving, from the communications device, a further request for the on-demand SIB using a new RACH procedure.

[0130] 32. The method according to any of clauses 29-31 , wherein the infrastructure equipment transmits the on-demand SIB during a preconfigured time period.

[0131] 33. The method according to clause 32, wherein the preconfigured time period is indicated in the response to the request for the on-demand SIB.

[0132] 34. The method according to clause 32 or clause 33, wherein the preconfigured time period is a predetermined period of time after a time at which the response to the request for the on- demand SIB is transmitted by the infrastructure equipment.

[0133] 35. The method according to any of clauses 29-34, wherein the request for the on-demand SIB is received via another entity of the wireless communications network. 36. The method according to any of clauses 29-35, wherein the response to the request for the on-demand SIB is transmitted via another entity of the wireless communications network.

[0134] 37. The method according to any of clauses 29-36, wherein the request for the on-demand SIB is received as a random access preamble, as part of an initial message of the RACH procedure.

[0135] 38. The method according to any of clauses 29-36, wherein the request for the on-demand SIB is received as part of a message of the RACH procedure, wherein the message of the RACH procedure is received after transmission of a random access response message to the communications device.

[0136] 39. An infrastructure equipment for a wireless communications network, the infrastructure equipment configured to transmit signals to and / or to receive signals from one or more communications devices via a wireless radio interface provided by the wireless communications network, the infrastructure equipment comprising: a transmitter configured to transmit signals, a receiver configured to receive signals, and a controller configured in combination with the transmitter and the receiver to: receive, from a communications device, a first request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access to the infrastructure equipment, and wherein the first request uses a random access (RACH) procedure; transmit, to the communications device, a response to the request for the on-demand SIB; after transmitting the response to the request for the on-demand SIB, transmit the on-demand SIB for receipt by the communications device; and receive, from the communications device, one or more retransmissions of the request for the on- demand SIB.

[0137] 40. Circuitry for infrastructure equipment for a wireless communications network, the circuitry configured to transmit signals to and / or to receive signals from one or more communications devices via a wireless radio interface provided by the wireless communications network, the circuitry comprising: transmitter circuitry configured to transmit signals, receiver circuitry configured to receive signals, and controller circuitry configured in combination with the transmitter circuitry and the receiver circuitry to: receive, from a communications device, a first request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access to the infrastructure equipment, and wherein the first request uses a random access (RACH) procedure; transmit, to the communications device, a response to the request for the on-demand SIB; after transmitting the response to the request for the on-demand SIB, transmit the on-demand SIB for receipt by the communications device; and receive, from the communications device, one or more retransmissions of the request for the on- demand SIB.

[0138] It will be appreciated that the above description for clarity has described embodiments with reference to different functional units, circuitry and / or processors. However, it will be apparent that any suitable distribution of functionality between different functional units, circuitry and / or processors may be used without detracting from the embodiments.

[0139] Described embodiments may be implemented in any suitable form including hardware, software, firmware or any combination of these. Described embodiments may optionally be implemented at least partly as computer software running on one or more data processors and / or digital signal processors. The elements and components of any embodiment may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. As such, the disclosed embodiments may be implemented in a single unit or may be physically and functionally distributed between different units, circuitry and / or processors.

[0140] Although the present disclosure has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognise that various features of the described embodiments may be combined in any manner suitable to implement the technique.

[0141] References

[0142] [1] Holma H. and Toskala A, “LTE for UMTS OFDMA and SC-FDMA based radio access”, John Wiley and Sons, 2009.

[0143] [2] TR 38.913, “Study on Scenarios and Requirements for Next Generation Access Technologies (Release 14)”, 3rd Generation Partnership Project, v14.3.0, August 2017.

[0144] [3] TS 38.470, “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; F1 general aspects and principles (Release 17)”, 3GPP, V17.4.0, March 2023.

[0145] [4] TS 38.473, “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; F1 application protocol (F1AP) (Release 17)”, 3GPP, V17.4.1 , April 2023.

[0146] [5] TS 38.401 , “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; Architecture description (Release 17)”, 3GPP, V17.4.0, March 2023.

[0147] [6] RP-234065, “New WID: Enhancements of network energy savings for NR,” 3GPP TSG RAN Meeting#102, Edinburgh, Scotland, December 11 th-15th, 2023

[0148] [7] GSMA, 5G energy efficiencies: Green is the new black, https: / / data.gsmaintelligence.com / api-web / v2 / research-file- download?id=54165956&file=241120-5G-energy.pdf

[0149] [8] 3GPP TR 38.864 V18.1.0 Study on network energy savings for NR

[0150] [9] TS 38.331 “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 18), 3GPP, V18.1.0, March 2024

Claims

CLAIMS1. A method of operating a communications device to communicate with infrastructure of a wireless communications network via a wireless access interface provided by the infrastructure equipment, the method comprising: transmitting, to the infrastructure equipment and using a random access (RACH) procedure, a request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access procedures for the infrastructure equipment; determining that the communications device is unable to acquire the on-demand SIB; and in response to determining that the communications device is unable to acquire the on- demand SIB, performing one or more predetermined remedial actions.

2. The method according to claim 1 , wherein the on-demand SIB is an on-demand SIB1.

3. The method according to claim 1 , wherein the one or more predetermined remedial actions include retransmitting, to the infrastructure equipment, the request for the on-demand SIB.

4. The method according to claim 3, comprising retransmitting the request for the on-demand SIB until a predetermined number of retransmissions is reached.

5. The method according to claim 3, wherein the retransmission of the request for the on- demand SIB is transmitted with increased transmission power.

6. The method according to claim 1 , further comprising determining that the RACH procedure has failed.

7. The method of claim 6, wherein the one or more predetermined remedial actions include: initiating one or more further RACH procedures with the infrastructure equipment to request the on-demand SIB.

8. The method of claim 7, comprising initiating the one or more further RACH procedures until a predetermined maximum number of RACH procedure attempts is reached.

9. The method of claim 7, comprising: initiating the one or more further RACH procedures immediately upon determining that the RACH procedure has failed.

10. The method of claim 7, comprising: initiating the one or more further RACH procedures within a predetermined time period from determining that the RACH procedure has failed.

11. The method of claim 7, comprising: initiating the one or more further RACH procedures after at least a minimum time period from the determining that the RACH procedure has failed.

12. The method of claim 7, further comprising: initiating one or more further RACH procedures with a different cell provided by the wireless communications network.

13. The method of claim 12, further comprising: selecting the different cell based on a measured signal strength of synchronisation signal broadcast by the different cell.

14. The method of claim 1 , wherein determining that the communications device is unable to acquire the on-demand SIB is based on the communications device not receiving, within a predetermined time period, a random access response (RAR) from the wireless communications network.

15. The method of claim 1 , wherein determining that communications device is unable to acquire the on-demand SIB is based on the communications device determining that a random access preamble included in a random access response (RAR) received from the wireless communications network does not match a random access preamble included in a random access request transmitted by the communications device.

16. The method of claim 1 , wherein determining that the communications device is unable to acquire the on-demand SIB is based on determining that the communications device has been unable to acquire the on-demand SIB within a predetermined period of time from transmitting the request for the on-demand SIB.17 The method of claim 1 , wherein the one or more remedial actions comprise: initiating an essential system information missing procedure.

18. The method of claim 1 , further comprising: determining that the RACH procedure has successfully completed, and wherein determining that the communications device is unable to acquire the on-demand SIB is based on determining that the communications device has been unable to acquire the on- demand SIB within a predetermined period of time.

19. The method of claim 1 , wherein the request for the on-demand SIB is transmitted as a random access preamble, as part of an initial message of the RACH procedure.

20. The method of claim 1, wherein the request for the on-demand SIB is transmitted as part of a message of the RACH procedure, wherein the message of the RACH procedure is transmitted after receiving a random access response message from the wireless communications network.

21. The method according to claim 1, further comprising: determining a monitoring time period in which to monitor for the on-demand SIB; and monitoring for the on-demand SIB in the determined monitoring time period.

22. The method according to claim 21, wherein the monitoring time period is indicated in a random access response received from the wireless communications network as part of the RACH procedure.

23. The method according to claim 21 , wherein the monitoring time period is a predetermined period of time after a time at which a random access response is received from the wireless communications network as part of the RACH procedure.

24. The method according to claim 21, wherein the monitoring time period is determined based on whether: the random access response is received from the infrastructure equipment to which the request for the on-demand SIB is transmitted, or the random access response is received from an entity of the wireless communications network other than the infrastructure equipment to which the request for the on-demand SIB is transmitted.

25. The method according to claim 24, wherein a start time of the monitoring time period is set to be later, and / or a length of the monitoring time period is set to be longer, based on determining that the random access response is received from an entity of the wireless communications network other than the infrastructure equipment to which the request for the on- demand SIB is transmitted.

26. The method according to claim 21 , wherein the monitoring time period is a predetermined time period after transmitting the request for the on-demand SIB.l. K communications device configured to transmit signals to and / or to receive signals from an infrastructure equipment of a wireless communications network via a wireless radio interface provided by the wireless communications network, the communications device comprising: a transmitter configured to transmit signals, a receiver configured to receive signals, and a controller configured in combination with the transmitter and the receiver to: transmit, to the infrastructure equipment and using a random access (RACH) procedure, a request for an on-demand system information block (SIB), wherein the on- demand SIB includes information for initial access procedures for the infrastructure equipment; determine that the communications device is unable to acquire the on-demand SIB and; in response to determining that the communications device is unable to acquire the on-demand SIB, perform one or more predetermined remedial actions.

28. Circuitry for a communications device configured to transmit signals to and / or to receive signals from an infrastructure equipment of a wireless communications network via a wireless radio interface provided by the wireless communications network, the circuitry comprising: transmitter circuitry configured to transmit signals, receiver circuitry configured to receive signals, and controller circuitry configured in combination with the transmitter circuitry and the receiver circuitry to: transmit, to the infrastructure equipment and using a random access (RACH) procedure, a request for an on-demand system information block (SIB), wherein the on- demand SIB includes information for initial access procedures for the infrastructure equipment; determine that the communications device is unable to acquire the on-demand SIB and; in response to determining that the communications device is unable to acquire the on-demand SIB, perform one or more predetermined remedial actions.

29. A method of operating an infrastructure equipment of a wireless communications network to communicate with a communications device via a wireless access interface provided by the infrastructure equipment, the method comprising: receiving, from a communications device, a first request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access to the infrastructure equipment, and wherein the first request uses a random access (RACH) procedure; transmitting, to the communications device, a response to the request for the on-demand SIB;after transmitting the response to the request for the on-demand SIB, transmitting the on- demand SIB for receipt by the communications device; and receiving, from the communications device, one or more retransmissions of the request for the on-demand SIB.

30. The method according to claim 29, further comprising: retransmitting, in response to the one or more retransmissions of the request for the on- demand SIB, the response to the request for the on-demand SIB; and retransmitting the on-demand SIB for receipt by the communications device.

31. The method according to claim 30, further comprising: receiving, from the communications device, a further request for the on-demand SIB using a new RACH procedure.

32. The method according to claim 29, wherein the infrastructure equipment transmits the on- demand SIB during a preconfigured time period.

33. The method according to claim 32, wherein the preconfigured time period is indicated in the response to the request for the on-demand SIB.

34. The method according to claim 32, wherein the preconfigured time period is a predetermined period of time after a time at which the response to the request for the on-demand SIB is transmitted by the infrastructure equipment.

35. The method according to claim 29, wherein the request for the on-demand SIB is received via another entity of the wireless communications network.

36. The method according to claim 29, wherein the response to the request for the on-demand SIB is transmitted via another entity of the wireless communications network.

37. The method according to claim 29, wherein the request for the on-demand SIB is received as a random access preamble, as part of an initial message of the RACH procedure.

38. The method according to claim 29, wherein the request for the on-demand SIB is received as part of a message of the RACH procedure, wherein the message of the RACH procedure isreceived after transmission of a random access response message to the communications device.

39. An infrastructure equipment for a wireless communications network, the infrastructure equipment configured to transmit signals to and / or to receive signals from one or more communications devices via a wireless radio interface provided by the wireless communications network, the infrastructure equipment comprising: a transmitter configured to transmit signals, a receiver configured to receive signals, and a controller configured in combination with the transmitter and the receiver to: receive, from a communications device, a first request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access to the infrastructure equipment, and wherein the first request uses a random access (RACH) procedure; transmit, to the communications device, a response to the request for the on- demand SIB; after transmitting the response to the request for the on-demand SIB, transmit the on-demand SIB for receipt by the communications device; and receive, from the communications device, one or more retransmissions of the request for the on-demand SIB.

40. Circuitry for infrastructure equipment for a wireless communications network, the circuitry configured to transmit signals to and / or to receive signals from one or more communications devices via a wireless radio interface provided by the wireless communications network, the circuitry comprising: transmitter circuitry configured to transmit signals, receiver circuitry configured to receive signals, and controller circuitry configured in combination with the transmitter circuitry and the receiver circuitry to: receive, from a communications device, a first request for an on-demand system information block (SIB), wherein the on-demand SIB includes information for initial access to the infrastructure equipment, and wherein the first request uses a random access (RACH) procedure; transmit, to the communications device, a response to the request for the on- demand SIB; after transmitting the response to the request for the on-demand SIB, transmit the on-demand SIB for receipt by the communications device; and receive, from the communications device, one or more retransmissions of the request for the on-demand SIB.

Images