Patent Description:
Work of the presently named inventors, to the extent it is described in the 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.

Third and fourth generation mobile telecommunication systems, such as those based on the 3GPP (<NUM>rd Generation Partnership Project) defined UMTS and Long Term Evolution (LTE) architecture, are able to support more sophisticated services than simple voice and messaging services offered by previous generations of mobile telecommunication systems.

Future wireless communications networks will be expected to routinely and efficiently support communications with a wider range of devices than current 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 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" (IoT), and may typically be associated with the transmissions of relatively small amounts of data with relatively high latency tolerance. Low complexity devices are also often low power devices, in which it is desirable for such devices to have a low power consumption (and therefore a long battery life).

Future wireless communications networks will be expected to routinely and efficiently support location based services with a wider range of devices / applications than current systems are optimised to support.

For example, it is expected that wireless communications in <NUM> will support geo-fencing services such as child location services, mobile coupons / advertisements which are triggered near a shop and airport automatic check-in at the gate / counter. These applications require continuous tracking of UE position or monitoring the equivalent trigger conditions with low UE power consumption.

In view of this there is expected to be a desire for future wireless communications networks, for example those which may be referred to as <NUM> (<NUM>th Generation) or new radio (NR) system / new radio access technology (RAT) systems, as well as future iterations / releases of existing systems, to efficiently support connectivity for a wide range of devices. In particular, the problem of how to efficiently transmit signals to and receive signals from low complexity devices whilst keeping the power consumption of such devices low needs to be addressed.

<CIT> relates to wireless location/positioning techniques.

<CIT> relates to providing a mobile station with assistance information related to estimating a position for the mobile station, and <CIT> relates to on-demand system information.

The present technique is defined according to the claims.

<FIG> provides a schematic diagram illustrating some basic functionality of a mobile telecommunications network / system operating in accordance with LTE principles and which may be adapted to implement embodiments of the disclosure as described further below. It will be appreciated, however, that the use of LTE is only an example, and that the principles of the present disclosure may be applied to other types of wireless communications systems such as UMTS or NR (<NUM>). Various elements of <FIG> and their respective modes of operation are well-known and defined in the relevant standards administered by the 3GPP (RTM) body, , for example, 3GPP TS36 series [<NUM>] for LTE and 3GPP TS38 series for NR [<NUM>]. It will be appreciated that operational aspects of the telecommunications network which are not specifically described below may be implemented in accordance with any known techniques, for example according to the relevant standards.

The network <NUM> includes a plurality of base stations <NUM> connected to a core network <NUM>. Each base station provides a coverage area <NUM> (i.e. a cell) within which data can be communicated to and from communications devices <NUM>. Data is transmitted from base stations <NUM> to communications devices <NUM> within their respective coverage areas <NUM> via a radio downlink. Data is transmitted from communications devices <NUM> to the base stations <NUM> via a radio uplink. The uplink and downlink communications are made using radio resources that are licenced for exclusive use by the operator of the network <NUM>. The core network <NUM> routes data to and from the communications devices <NUM> via the respective base stations <NUM> and provides functions such as authentication, mobility management, charging and so on. A communications device may also be referred to as a mobile station, user equipment (UE), user device, mobile radio, terminal device, terminal and so forth. A base stations may also be referred to as a transceiver station, infrastructure equipment, NodeB (which is a UMTS base station), eNodeB (which is a LTE base station (eNB for short)), gNodeB (which is a NR base station (gNB for short)), and so forth.

Wireless communications systems such as those arranged in accordance with the 3GPP defined Long Term Evolution (LTE) architecture use an orthogonal frequency division modulation (OFDM) based interface for the radio downlink (so-called OFDMA) and a single carrier frequency division multiple access scheme (SC-FDMA) on the radio uplink.

<FIG> schematically shows some components of a UE <NUM>, a base station <NUM> and a data processing apparatus <NUM> (e.g. a location server) according to an example embodiment.

The UE <NUM> comprises a first receiver <NUM>, a second receiver <NUM>, a transmitter <NUM> and a controller <NUM>. The first receiver <NUM> is for receiving wireless signals from each of one or more signal emitting devices located at respective spatial locations. Such signal emitting devices may be GNSS (Global Navigation Satellite System) satellites, for example. The second receiver <NUM> is for reception of wireless signals (e.g. radio signals). The transmitter <NUM> is for transmission of wireless signals (e.g. radio signals). The controller <NUM> is configured to control the first receiver <NUM>, second receiver <NUM> and transmitter <NUM> and to control the UE <NUM> to operate in accordance with embodiments of the present disclosure. The controller <NUM> may comprise various sub-units for providing functionality in accordance with embodiments of the present disclosure as explained further below. These sub-units may be implemented as discrete hardware elements or as appropriately configured functions of the controller <NUM>. The controller <NUM> may be suitably configured / programmed to provide the desired functionality described herein using conventional programming / configuration techniques for equipment in telecommunications systems. The first receiver <NUM>, second receiver <NUM>, transmitter <NUM> and controller <NUM> are schematically shown in <FIG> 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 a single suitably programmed computer, or suitably configured application-specific integrated circuit(s) / circuitry. It will be appreciated that, although not shown, the UE <NUM> will in general comprise various other elements associated with its operating functionality, such as a user interface, battery, and the like. In the following embodiments, the first receiver <NUM>, second receiver <NUM>, transmitter <NUM> and controller <NUM> are implemented as circuitry.

The base station <NUM> comprises a transmitter <NUM>, a receiver <NUM>, a network interface <NUM> and a controller <NUM>. The transmitter <NUM> is for transmission of wireless signals (e.g. radio signals), the receiver <NUM> is for reception of wireless signals (e.g. radio signals), a network interface <NUM> for transmission and reception of signals (e.g. to and from a location server, as explained below) over a network such as the internet and the controller <NUM> is configured to control the transmitter <NUM>, receiver <NUM> and network interface <NUM> and to control the base station <NUM> to operate in accordance with embodiments of the present disclosure. The controller <NUM> may comprise various sub-units for providing functionality in accordance with embodiments of the present disclosure as explained further below. These sub-units may be implemented as discrete hardware elements or as appropriately configured functions of the controller <NUM>. The controller <NUM> may be suitably configured / programmed to provide the desired functionality described herein using conventional programming / configuration techniques for equipment in telecommunications systems. The transmitter <NUM>, receiver <NUM>, network interface <NUM> and controller <NUM> are schematically shown in <FIG> 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 a single suitably programmed computer, or suitably configured application-specific integrated circuit(s) / circuitry. It will be appreciated that, although not shown, the base station <NUM> will in general comprise various other elements associated with its operating functionality. In the following embodiments, the transmitter <NUM>, receiver <NUM>, network interface <NUM> and controller <NUM> are implemented as circuitry.

The data processing apparatus <NUM> comprises a network interface <NUM>, a storage medium <NUM> and a controller <NUM>. The network interface <NUM> is for transmission and reception of signals (e.g. to and from infrastructure equipment, as explained below) over a network such as the internet. The storage medium <NUM> is for storage of digital data (and may take the form of a hard disk drive, solid state drive, tape drive or the like, for example). The controller <NUM> is configured to control the network interface <NUM> and storage medium <NUM> and to control the data processing apparatus <NUM> to operate in accordance with embodiments of the present disclosure. The controller <NUM> may comprise various sub-units for providing functionality in accordance with embodiments of the present disclosure as explained further below. These sub-units may be implemented as discrete hardware elements or as appropriately configured functions of the controller <NUM>. The controller <NUM> may be suitably configured / programmed to provide the desired functionality described herein using conventional programming / configuration techniques for equipment in telecommunications systems. The network interface <NUM>, storage medium <NUM> and controller <NUM> are schematically shown in <FIG> 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 a single suitably programmed computer, or suitably configured application-specific integrated circuit(s) / circuitry. It will be appreciated that, although not shown, the data processing apparatus <NUM> will in general comprise various other elements associated with its operating functionality. In the following embodiments, the network interface <NUM> and controller <NUM> are implemented as circuitry.

In the UE <NUM>, the first receiver <NUM> is configured to receive a first signal from each of one or more signal emitting devices located at respective spatial positions. The transmitter <NUM> is configured to transmit a second signal to infrastructure equipment (such as the base station <NUM>) of the wireless telecommunications network. The second receiver <NUM> is configured to receive a third signal from the infrastructure equipment, the third signal being transmitted by the infrastructure equipment in response to the infrastructure equipment receiving the second signal, the third signal indicating the respective spatial positions of each of the one or more signal emitting devices, and the third signal being comprised within a predetermined system information block (SIB). The controller <NUM> is configured to determine a spatial position of the terminal device based on the received first and third signals.

In the base station <NUM>, the receiver <NUM> is configured to receive a second signal from a terminal device (such as the UE <NUM>) of the wireless telecommunications network, the second signal being transmitted by the terminal device in response to the terminal device receiving a first signal from each of one or more signal emitting devices located at respective spatial positions. The controller <NUM> is configured, in response to the reception of the second signal, to determine the respective spatial positions of each of the one or more signal emitting devices. The transmitter <NUM> is configured to transmit a third signal to the terminal device, the third signal indicating the respective spatial positions of each of the one or more signal emitting devices and the third signal being comprised within a predetermined system information block (SIB).

In an embodiment, the controller <NUM> of the UE <NUM> is configured to determine the spatial position of the terminal device with respect to each of the one or more signal emitting devices based on a measurement of a characteristic (e.g. signal strength and/or quality) of the first signal transmitted by each of the one or more signal emitting devices. The third signal indicates the respective spatial position of each of the one or more signal emitting devices. The controller <NUM> is then able to calculate the absolute position of the UE <NUM> in a given coordinate system based on the determined spatial position of the terminal device with respect to each of the one or more signal emitting devices and the respective spatial position of each of the one or more signal emitting devices (such calculation techniques are known in the art and will therefore not be discussed here).

In embodiments of the present technique, the base station <NUM> (e.g. an LTE base station (eNodeB) or NR base station (gNodeB)) transmits assistance information of positioning (comprised within the above-mentioned third signal) via on-demand system information (the on-demand system information being provided via the above-mentioned predetermined SIB). The UE <NUM> can receive the assistance information in idle mode or in-active mode (although note that a connected mode UE can also receive the assistance information in this way). In order to support on-demand system information (SI), in an embodiment, UE capability indication/bitmap/implicit signaling is transmitted (as part of the above-mentioned first signal) in a random access procedure (e.g. Msg1 or Msg3 in the Random Access Channel (RACH) procedure) for requesting an on-demand SI. The UE <NUM> can thus avoid transitioning to connected mode to receive the assistance information, thus providing UE power saving. Such an arrangement is particularly suitable for low complexity devices used in, for example, MTC/loT applications.

Compared to existing solutions for positioning (such as those proposed by 3GPP) it is desirable to provide improved positioning arrangements. The term "positioning" should be understood to refer to any process by which a UE determines its position in space (in particular, its geographical position). The desired improvements include:.

The described embodiments relate primarily to <NUM> (NR) positioning enhancements. However, it will be appreciate that the teachings provided may be applicable for LTE systems (e.g. LTE systems which support on-demand SI or similar, as may be available in the near future). The present technique may provide at least some of the above-mentioned improvements for both suitable LTE and NR systems.

An example of on-demand SI which may be used with embodiments of the present technique may be found in European patent application <CIT>, for example.

Furthermore, information regarding existing 3GPP location based service and protocols may be found in the following white paper: <NPL>.

Supported versions of UE positioning methods in LPP are disclosed in 3GPP TS36. <NUM>, for example. Some information from this publication is shown in Table <NUM>.

In 3GPP, when a UE determines its spatial position, the measurement of signals (from GNSS satellites or the like) and the calculation of the UEs position based on those signals are distinguished. "UE-assistance positioning" refers to a situation in which a device external to the UE (such as a location server of a network to which the UE is connected) calculates the position of the UE according to the report of measurement results from the UE. The present technique, on the other hand, allows more "UE-based positioning", in which the UE is provided with sufficient information to calculate its position. In other words (as described in 3GPP TS <NUM> V13. <NUM> (<NUM>-<NUM>)), the suffixes "-based" and "-assisted" refer respectively to the node that is responsible for making the positioning calculation (and which may also provide measurements) and a node that provides measurements (but which does not make the positioning calculation). Thus, an operation in which measurements are provided by the UE to the E-SMLC (Evolved Serving Mobile Location Centre) to be used in the computation of a position estimate is described as "UE-assisted" (and could also be called "E-SMLC-based"), while one in which the UE computes its own position is described as "UE-based". UE-based positioning (as used with the present technique) requires less communication with the network compared to UE-assistance positioning, thus reducing the power consumption at the UE.

An example conventional UE-assistance positioning procedure (in particular, a typical LPP procedure) comprises the following steps:.

It is noted that steps <NUM>, <NUM> and <NUM> are still carried out even if UE-based positioning is used.

With the conventional method, the location server knows the UE positioning capability in advance. Furthermore, the network can provide a large volume of position assistance information to UE because it is able to use a connected mode communication bearer rather than, for example, relying on broadcast system information to provide the assistance information. However, the fact that the UE must enter connected mode in order for the UE positioning to be carried out means increased power consumption at the UE.

As previously mentioned, UE positioning may be carried out based on signals received from GNSS satellites. As discussed in https://www. eu/system/files/reports/anss mr <NUM>. pdf, for example, Global Navigation Satellite System (GNSS) is the infrastructure that allows users with a compatible device (in this case, UE) to determine their position, velocity and time by processing signals from satellites. GNSS signals are provided by a variety of satellite positioning systems, including global and regional constellations and Satellite-Based Augmentation Systems:.

A GNSS may have more than one band or code/signals.

For example, GPS newly supports L2C signal (band L2, civilian GPS signal) in addition to conventional L1 C/A (band L1 and coarse/acquisition code). However, most of GPS terminals still support only L1 C/A.

GNSS assistance information via cellar network provides benefits for positioning. In particular, it allows some of the information required for the UE's position to be determined via GNSS to be provided to the UE via the network rather than directly from a satellite. In an embodiment of the present technique, GNSS assistance information may be transmitted as part of the third signal transmitted from the transmitter <NUM> of the base station <NUM> and received by the second receiver <NUM> of the UE <NUM>. Other GNSS information is received directly from a satellite as part of the first signal by the first receiver <NUM> of the UE <NUM>.

GNSS satellites transmit two type of signals, the codes and messages. The code is orthogonal code such as pseudorandom noise or the like. The messages includes the satellite orbit information such as Ephemeris and Almanac (which are needed for position estimation). Information regarding the Ephemeris and Almanac is provided in <NPL>), for example. Here, it is defined that Ephemeris and Clock Models assistance provides the GNSS receiver (in this case, the UE) with parameters to calculate the GNSS satellite position and clock offsets. The various GNSSs use different model parameters and formats, and all parameter formats as defined by the individual GNSSs are supported by the signaling. It is also defined that Almanac assistance provides the GNSS receiver with parameters to calculate the coarse (long-term) GNSS satellite position and clock offsets. The various GNSSs use different model parameters and formats, and all parameter formats as defined by the individual GNSSs are supported by the signaling.

LPP supports the communication of a portion of the GNSS information (e.g. the messages) from a location server to a UE via an LTE base station as a faster complement to the transmission of this information from GNSS satellites.

Assistance information for positioning from the cellular network (that is, from a base station of the network) helps alleviate various problems associated with GNSS positioning, including those relating to the sensitivity of messages transmitted by GNSS satellites, the time to first fix and the provision of precise positioning.

In particular, the use of a cellular network helps alleviate satellite signal strength issues. A GNSS satellite signal is very weak due to the long distance between the UE and the satellites. The UE may also miss the signal due to having a relatively small GNSS antenna. It is noted that GNSS codes (in particular, GPS codes) require a lower signal to noise ratio (SNR) than GNSS messages (in particular, GPS messages). Thus, a situation may arise in which a UE can receive the GNSS codes, but cannot receive the GNSS messages. Furthermore, even if a UE can receive the message with high SNR, measurement time, which is called the time to first fix (TTFF), may be an issue. For example, GPS transmits the messages with very low bit rate (e.g. <NUM> bits/second). If a UE is to receive all necessary messages from a scratch (both Almanac and Ephemeris), this will take <NUM> minutes. By contrast, the cellular network provides a much higher bitrate and the UE is able to receive all necessary messages over a time period of the order of seconds.

The volume of GNSS assistance information is expected to be increased in the near future because of envisaged requirements for more accurate positioning. For example, JAXA (Japan Aerospace Exploration Agency) provides MADOCA (Multi-GNSS Advanced Demonstration tool for Orbit and Clock Analysis) for QZSS users, which needs precise point position (PPP). The assistance information from MADOCA is not only included in QZSS orbit and clock information, but is also used in other GNSS systems. However, the capacity of QZSS satellite communication (L-band) is limited. Highly common information which many users need may therefore be transmitted from the satellite. However, the remaining assistance information could be transmitted via other communication methods like (such as via the internet - for example, see https://ssl. jp/madoca/public/public index en.

The described embodiments primarily relate to handling GNSS assistance information. However, the present technique may also be applied to positioning using other types of signal emitting devices which emit signals detectable by the UE. Such alternative positioning may be used in indoor public spaces (such as shopping centres, art galleries, museums and the like) in which it is not possible to obtain a satellite signal of sufficient strength and/or quality. In this case, information indicative of the position of one or more signal emitting devices is used in conjunction with a UE's distance from each signal emitting device (as measured based on a first signal from each signal emitting device by the first receiver <NUM> of the UE <NUM>, for example) in order to determine the UE's position within the building. In this case, assistance information (indicative of the position of each of the one or more indoor signal emitting devices) could be transmitted to a UE via the network. More generally, the present technique may be implemented using one or more satellite or non-satellite signal emitting devices located at respective predetermined positions within a predetermined space. Various additional sensors may also be used for UE positioning, as explained later on.

Current 3GPP LTE Positioning Protocol (LPP) requires connected mode communication to request/receive assistance information from a location server. However, NR loT UEs are expected to be able to stay for longer periods in idle mode (or inactive mode) so as to provide UE power saving. With this in mind, with embodiments of the present technique, the UE is able to receive the assistance information via system information in idle mode (or inactive mode) rather than via dedicated data radio bearer (DRB). The UE is therefore less likely to have to enter connected mode in order to receive assistance information, thus providing improved power saving. In addition, embodiments of the present technique also help alleviate problems associated with the limited capacity of system information for transmitting assistance information.

Information regarding NR RRC connection states is provided in <NPL>), an extract of which is provided below. ----------------------------------------- 3GPP TS <NUM> ------------------------------------------.

FFS Whether a RAN-based notification area is always configured or not.

FFS UE behavior if it is decided that a RAN-based notification area is not always configured.

----------------------------------------- 3GPP TS <NUM> ------------------------------------------.

In embodiments, the implementation of the present technique depends on the connection state of the UE.

In RRC_IDLE mode (idle mode), the following characteristics should be taken into account for NR positioning.

The UE does not store the AS context information, where AS refers to access stratum. AS context information includes UE specific information specified by RRC protocols. A base station is not aware of UE capability and UE ID when it receives RACH Msg1 or Msg3 from the UE. The UE is able to acquire system information. However, unicast data communication is not supported. The assistance information must thus be sent via system information.

In RRC_INACTIVE mode (inactive mode), the following characteristics should be taken into account for NR positioning.

UE transitions to RRC_INACTIVE mode and stays in it for a certain time period (e.g. <NUM> hours). RRC_INACTIVE mode is a lower power consumption mode compared to RRC_CONNECTED mode and the UE transitions to RRC_INACTIVE mode after initially entering RRC connected mode. This characteristic is especially suitable for low frequency communication terminals (low frequency meaning that the UE transmits or receives data less frequently that in, for example, RRC connected mode) like IoT (Internet of Things) / M2M (Machine-to-Machine).

The UE stores the AS context information. A base station of the network is aware of UE ID (Resume ID) (this having been allocated during the last connection) and, optionally, UE capability when it receives RACH Msg3 from the UE. Resume ID has not yet been decided. However, for example, Resume ID may be derived using a combination of part of base station ID and UE ID. The Resume ID may indicate relevant assistance information when a location server or a base station selects assistance information.

In RRC_CONNECTED mode (connected mode), the following characteristic should be taken into account for NR positioning.

A base station of the network can transmit unicast data to or receive unicast data from the UE. Assistance information could be exchanged via the normal LPP protocol in connected mode.

However, the UE can also acquire system information also in RCC_CONNECTED mode. There are several benefits of system information-based assistance information in connected mode. In terms of power consumption, RRC connected typically has a higher power consumption. However, a UE may be configured with a UE specific DRX (Discontinuous Reception) mode. In this case, for example, the network may adjust the DRX duration for a specific UE, e.g. making the DRX duration longer (and thus reducing UE power consumption), due to the ability to receive the assistance information as system information rather than through the use of radio resources specifically scheduled for that UE (as occurs for data which is unicast to a UE). In terms of radio resource consumption, when assistance information is transmitted via system information, a UE is able to read on-demand system information which is requested by other UEs and to store any relevant assistance information. The volume of assistance information transmitted via unicast communication is therefore reduced when the present technique is implemented, even in RRC_CONNECTED mode. This helps to save network capacity.

<FIG> schematically shows some further components of the UE <NUM>, according to an embodiment. These components help to reduce power consumption of the UE, as will be explained.

First receiver <NUM> comprises GNSS antenna <NUM>, Acquisition & Tracking circuitry <NUM> (for acquisition and tracking of a received GNSS signal), and a Navigation Message decoder <NUM>. Receiving the assistance information from a cellar network (rather than via the GNSS signal) allows the UE to skip navigation message decoding, thus reducing the UE positioning time from a cold start (that is, from a time at which the UE has no positioning information). If the GNSS function of the UE is implemented using more than one system or band then, for each system or band, Acquisition & Tracking circuitry <NUM> and a Navigation Message decoder <NUM> are provided within the UE <NUM>. The antenna may or may not share GNSS#<NUM> receiver circuitry <NUM> between the different GNSS bands or systems (that is, use a single instance of GNSS#<NUM> receiver circuitry <NUM> for all GNSS bands or systems), depending on the GNSS bands or systems used. In this example, the UE <NUM> is configured for use with two GNSS bands / systems and the GNSS#<NUM> receiver circuitry <NUM> is shared for both bands / systems.

Second receiver <NUM> comprises NR antenna <NUM> and NR receiver circuitry <NUM> (via which the received RF signal is amplified and down converted to base band signal). NR baseband circuitry <NUM> provides channel coding and demodulation. RRC protocol circuitry (or circuitry implementing other protocols such as PDCP, RLC, MAC or the like) interprets the L1 signal to messages. The second receiver <NUM> may have LTE components instead of or in addition to NR components. Corresponding LTE components to NR components <NUM>, <NUM>, <NUM>, <NUM> and <NUM> are labelled <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, respectively. In this example, the UE <NUM> thus supports both NR and LTE. In idle mode and in inactive mode, the UE is required to occasionally activate the receiver circuitry <NUM> for cell reselection and DRX operation (e.g. paging). In connected mode, the receiver circuitry <NUM> should be always active except during an RRC connected mode DRX operation. The UE in RRC connected mode DRX is required to occasionally activate the receiver circuitry <NUM> for control channel reception and mobility management (e.g. measurements). The UE power consumption in RRC connected mode DRX can be reduced since, if assistance information has been received via an on-demand SIB in the way as described, the UE only needs to connect to the network for a time sufficient to receive updates to the assistance information (rather than to obtain the assistance information in its entirety). The DRX "wake" duration may therefore be reduced accordingly, thus reducing UE power consumption. It will thus be appreciated that the present technique allows reduced UE power consumption in idle, inactive and connected modes.

Second transmitter <NUM> comprises NR baseband circuitry for uplink (which, in this case, is the same NR baseband circuitry <NUM> as used for the second receiver <NUM>, although it may, in other embodiments, be separate circuitry) and RRC protocol circuitry for uplink (which, in this case, is the same NR protocol circuitry <NUM> as used for the second receiver <NUM>, although it may, in other embodiments, be separate circuitry). The second transmitter <NUM> comprises NR transmitter circuitry <NUM> (via which a baseband signal is up-converted to RF) and power amplifier circuitry <NUM> to boost the transmission power of the RF signal. The RF signal is then sent via antenna <NUM>. In idle mode and in inactive mode, the UE is not required to activate the transmitter circuitry <NUM> or power amplifier <NUM>. This helps provide reduced UE power consumption.

The controller <NUM> is configured to implement spatial position functions and sensor processing. The controller implements a SUPL protocol <NUM> and LPP protocol <NUM>. Assistance information <NUM> provided by information elements of the protocols <NUM> and <NUM> is decoded and stored. Sensor controller circuitry <NUM> (comprised as part of the controller circuitry <NUM>) uses the assistance information <NUM> to configure various sensors and the one or more GNSS receivers (e.g. GNSS#<NUM> receiver <NUM>) of the UE. The controller <NUM> also implements a PVT estimate function <NUM> (which refers to position (P), velocity (V) and time (T)) and uses the generated P, V and/or T values for calculation positioning information of the UE <NUM>. The Application CPU <NUM> (also comprised as part of the controller circuitry <NUM>) may then use the positioning result (positioning information) for location based services such as e.g. geo-fencing applications.

In the context of <NUM> (NR) positioning, PVT estimation may not only use GNSS positioning (or, more generally, positioning based on one or more signal emitting devices, which may include GNSS satellites or indoor signal emitting devices), but also one or more other sensors of various types. Thus, in addition to or instead of the first receiver <NUM> being configured to receive a signal from one or more signal emitting devices, the first receiver <NUM> may also receive signals from one or more other sensors comprised as part of the UE <NUM>. Such sensors may include accelerometers, gravimeters, barometer sensors, gyroscopic sensors or the like, and may be used in various ways in addition to or instead of GNSS or other emitted signals. The term "sensor" should be interpreted broadly as an element (implemented using circuitry, for example) configured to detect one or more characteristics on the basis of which a position of the UE (or at least one or more services applicable based on the position of the UE) may be determined.

Various different types of sensor may be used in combination in order to carry out UE positioning.

In one example, if a GNSS signal is lost and a barometer sensor detects a pressure drop, the UE (in particular, the controller <NUM>) may conclude that the UE <NUM> has entered a basement in the building. The PVT function <NUM> indirectly estimates the UE position based on specific conditions (e.g. the combination of sensor output, in this case, the loss of the GNSS signal and the drop in pressure being greater than a predetermined threshold) and/or pre-configured data (e.g. a 3D map of the UE's environment, which includes the fact that there is a basement). The assistance information may comprise the data indicative of the 3D map of the UE's environment and/or the specific conditions of combined sensor output and what should be inferred from such conditions (e.g. the assistance information may indicate that a GNSS signal loss combined with drop in pressure by more than a predetermined amount should result in it being determined that the UE has entered a basement when the 3D map of the UE's environment comprises a basement).

In another example, a gyroscopic (gyro) sensor may detect that the UE <NUM> is stationary. In this case, the UE may deactivate the GNSS function (and/or other positioning sensors) because the UE position does not change. In an embodiment, the controller <NUM> may control all sensors to enter a power saving mode except for the gyro sensor, thus reducing power consumption of the UE <NUM>.

In another example, a light sensor detects when the UE <NUM> is in the dark and the controller <NUM> determines that the user has put the UE in a pocket or the like. The controller <NUM> then controls the GNSS function to be deactivated and activate indoor positioning (e.g. Pedestrian Dead Reckoning (PDR)) is activated instead. In this case, the first receiver <NUM> may be controlled to stop receiving a GNSS signal and to start receiving signals from indoor signal emitting devices (together with relevant assistance information from the network) instead.

Thus, in the context of <NUM> positioning, the assistance information may be not only for use with GNSS positioning. That is, it may also include information for use in UE positioning implemented using one or more other sensors. It will be appreciated that assistance information of embodiments of the present technique may therefore comprise information of a range of different types, depending on the sensors comprised within the UE <NUM> requesting the assistance information and, in other embodiments, the position of the UE <NUM> (e.g. if the UE <NUM> is located within the cell of a base station located in a shopping centre, the assistance information may include a map of that shopping centre, the map, in turn, being used to influence the inferences made by the sensor output from the UE <NUM> (as discussed in the above-mentioned example of detecting when a UE enters a basement).

<FIG> schematically shows some details of a location server according to an example embodiment and shows how the location server generates assistance information.

The location server comprises circuitry for implementing 3GPP protocol functionality such as functionality of the SUPL <NUM>, LPP <NUM> and LPPa <NUM> protocols. This circuitry is comprised as part of the network interface <NUM>, for example. In terms of position estimation at the network side, for UE assisted positioning, the location server collects the measurement result <NUM> from the UE using the LPP protocol <NUM> and from the gNodeB(s) (e.g. via Uplink Time Difference of Arrival (UTDOA)) using the LPPa protocol <NUM>. Position estimator circuitry <NUM> (which is comprised as part of the controller <NUM>, for example) calculates the UE position based on the measurement result and information obtained via a UE assistance information server <NUM> (which may be implemented using the same physical hardware as the location server or different physical hardware at a different location). Alternatively, or in addition, the position estimator circuitry <NUM> may refer directly to database and/or satellite information. The database and/or satellite information are stored in storage medium <NUM> of the location server, for example. Alternatively, as in this example, the database may be stored at the UE assistance information server <NUM> and the satellite information may be stored at a satellite information server <NUM> (again, the satellite information server <NUM> may be implemented using the same physical hardware as the location server or different physical hardware at a different location). The position estimator circuitry <NUM> may comprise a storage medium for storing a previous position of the UE. Alternatively, a previous position of the UE may be stored at the UE assistance information server <NUM>. This helps to allow suitable assistance information for the UE to be generated more quickly and using less bandwidth capacity (since assistance information likely to be irrelevant to the UE's location does not need to be obtained and transmitted to the UE).

In terms of generating UE assistance information, in an embodiment, the UE assistance information server <NUM> collects information from the database <NUM> (containing data indicative of e.g. wifi access points, Bluetooth beacon, Cell ID or the like) and from the satellite information server <NUM>. The UE assistance information server <NUM> may store the UE positioning capability based on a previous connection or may retrieve it from MME <NUM>. The data base <NUM> is updated using suitable operation and maintenance (O&M) tools, as is known in the art. The satellite information server <NUM> may be maintained by a space agency or a private company (a global reference network provider, for example). The UE assistance information server <NUM> can select the relevant assistance information for the UE based on UE capability (which may be stored at the UE assistance information server <NUM>) and the current (or at least last known) UE location. The location server then transmits the assistance information to the UE with LPP over SUPL (user plane). Alternatively, the location server sends it to the UE with LPP via MME (control plane). The volume of UE assistance information for UE based positioning may be larger than that for UE assistance based because the calculation of position may requires additional assistance information.

Thus, more generally, in the embodiment of <FIG>, UE assistance information is selected based on UE position and UE capability. The UE position is determined by position estimation circuitry <NUM> using a measurement result <NUM> obtained from the UE and, if available, previous position information of the UE stored at the UE assistance information server <NUM>. The UE assistance information server <NUM> comprises a database <NUM> comprising assistance information and is also able to obtain satellite information from a satellite information server <NUM>. Based on the UE position and capability (which may be received from the UE via the MME <NUM> or may be stored in advance at the UE assistance information server <NUM>), relevant assistance information is determined and transmitted back to the UE via the network. It is noted that the database <NUM> may comprise any suitable assistance information, including location information of signal emitting devices used for indoor UE positioning (as previously explained), information relating to interpreting multiple sensor data (as previously explained) and the like.

In an embodiment, on-demand system information is used to provide positioning assistance information to the UE <NUM>.

Firstly, the UE <NUM> requests on-demand system information of positioning assistance information in line with own UE positioning capability/preferences. This request is transmitted as part of the above-mentioned second signal transmitted from UE <NUM> to base station <NUM>. In an embodiment, the second signal (comprising the SI request) is transmitted as part of a random access channel (RACH) procedure. Secondly, the base station <NUM> (for example, a gNodeB) transmits the requested system information. This is the above-mentioned third signal transmitted from base station <NUM> to UE <NUM>. The system information comprises the positioning assistance information. Thirdly, the UE <NUM> receives the system information (comprising the positioning assistance information) and stores the positioning assistance information. Finally, the UE activates the positioning function(s) in idle mode or inactive mode (or even connected mode) in order to determine its spatial position. The UE <NUM> (in particular, the controller <NUM> determines the spatial position of the UE <NUM> based on information comprised within the first signal (received from a satellite and/or sensor) and the positioning assistance information. The UE may update the assistance information if it expired (e.g. if a certain time period for which the assistance information is valid expires).

In an embodiment ,the second signal comprising the SI request is transmitted as part of a RACH procedure. The SI request comprises the request for on-demand SI and an indication of the UE's capability/preference regarding which positioning technology (e.g. type of GNSS) is to be used for determining the UE's position. The second signal comprising the SI request may be transmitted as part of Msg1 or Msg3 in the RACH procedure.

Although the described embodiments primarily relate to allowing assistance information to be transmitted to UEs <NUM> in idle / inactive mode, it is noted that receiving on-demand system information in the way(s) described may also be useful for connected mode UEs. This is because, if such a UE is able to obtain assistance information via on-demand system information, it does not does not need to again communicate with the network to obtain the assistance information using connected mode resources.

<FIG> schematically shows relevant portions of the network architecture for UE positioning in LTE. In the user plane (U-plane) <NUM>, data is exchanged between the UE <NUM>, base station <NUM>, serving gateway <NUM>, packet gateway <NUM>, SLP <NUM> (comprised within LCS (Location Service) server (LS) <NUM>) and LCS client <NUM> via the SUPL and/or LPP protocols. In the control plane (C-plane) <NUM>, data is exchanged between the base station <NUM>, mobile management entity (MME) <NUM> and E-SMLC <NUM> (comprised within the LS <NUM>) via the LPPa (LTE Positioning Protocol Annexe) protocol. Furthermore, data is exchanged between the UE <NUM>, base station <NUM>, MME <NUM> and E-SMLC <NUM> (comprised within the LS <NUM>) via the LPP protocol. More details regarding the architecture of <FIG> may be found at http://www. rohde-schwarz-wireless. com/documents/LTELBSWhitePaper RohdeSchwarz. pdf, for example. This architecture is also applicable to NR (in which case the base station <NUM> will be gNobeB rather than an eNodeB).

It is noted that, conventionally, the location server (LC) <NUM> was the same as the E-SMLC <NUM> because UE positioning was implemented using a C-plane based solution only. Nowadays, however, a U-plane solution may also be used (as enabled by SUPL <NUM> protocol, for example). In embodiments of the present technique, the term "location server" should be understood to include the use of both the C-plane case and U-plane. More specifically, it is noted that the location server of embodiments may be provided by a suitable proprietary standard / cloud service of a third party company. For example, the location server be a SUPL <NUM> server (e.g. as provided by Google ®) or an Apple ® Cloud server (which is similar to SUPL). Of course, other such location services could be used. The location server of embodiments may be referred to as a "SUPL server". However, this should be understood to mean an SUPL server or suitable equivalent. In general, it is noted that, in 3GPP, the LPP protocol is defined between the UE <NUM> and location server <NUM>. On the other hand, the Radio Resource Control (RRC) protocol is defined between the <NUM> UE and base station <NUM>.

As previously mentioned, the UE <NUM> may be a low complexity device such as an loT / MTC type terminal. Such UEs require very low power consumption. It will be appreciated, however, that the present technique could be applied to more complex UEs such as smartphones and the like.

The UE <NUM> described with reference to <FIG> comprises a first receiver <NUM>, second receiver <NUM>, transmitter <NUM> and controller <NUM>. The first receiver <NUM> may comprise, for example, one or more GNSS sensors or antennas and/or sensors for detecting signals (e.g. radio signals) transmitted by position sensors or the like. The second receiver <NUM> and transmitter <NUM> may be implemented together to form a NR RF (radio frequency) modem and/or LTE RF modem. The controller <NUM> may comprise one or more central processing units (CPUs) for controlling the UE functionality. In addition, the UE <NUM> may comprise RRC protocol functions (on-demand system information support), one or more further sensors (e.g. barometric sensor, Terrestrial Beacon System (TBS) or the like), one or more further communication interfaces which could be used for positioning (e.g. Low power Bluetooth ®, Wi-Fi ® or the like - in this case, the first receiver <NUM> may comprise such technology and the first signal received at the first receiver <NUM> will be a Bluetooth ® or Wi-Fi ® signal on the basis of which the UE <NUM> may determine positioning information), a battery and/or a user interface such as a screen, keyboard or the like (it is noted that UEs such as smart phones will generally have a user interface, whereas low complexity devices such as loT / MTC terminals may not equipped with a user interface).

As previously mentioned, although the described embodiments generally relate to GNSS assistance information, it will be appreciated that, more generally, GNSS support at the UE is not mandatory and that the UE may have one or more other elements to be used for positioning (in combination with suitable assistance information received from the network). The first receiver <NUM> may therefore be configured to receive signals from a GNSS satellite, indoor signal emitting device or other sensor comprised within the UE <NUM>.

As previously mentioned, the UE <NUM> of embodiments is configured to perform UE based positioning. It is thus able to determine its position based on the first signal received at the first receiver <NUM> and the assistance information received as part of the second signal received at the second receiver <NUM>. It does this without the need for further assistance from the network or the need to transition to connected mode, thus reducing UE power consumption.

Some examples of signalling sequences between the UE <NUM> and location server via a base station (in this example, a gNB) are provided below:.

Although embodiments of the present technique allow a UE to receive assistance information in idle mode or inactive mode (thought the use of on-demand system information to transmit the assistance information to the UE), the UE may still enter connected mode to get the assistance information via e.g. a dedicated channel or MBMS channel if the volume of assistance information is too large to accommodate the system information (this may be referred to as "dedicated system information"). After receiving the assistance information, the UE then returns to idle mode (or inactive mode) and performs the UE based positioning in inactive mode (or idle mode).

As previously mentioned, the on-demand SI request may be transmitted as part of the RACH procedure. The on-demand SI request may be transmitted in message <NUM> (Msg1) or message <NUM> (Msg3) of the RACH procedure, for example.

An example in which Msg1 is used for transmitting the on-demand SI request is shown in <FIG>. In this example, the base station <NUM> is a gNB. At step <NUM>, minimum system information (MSI) is transmitted from the base station <NUM> to the UE <NUM>. At step <NUM>, based on the MIS, the UE <NUM> is able to determine an identifier of the on-demand SIB (e.g. that SIB number X is the on-demand SIB) and to determine that the on-demand SI request must be transmitted in RACH Msg1. At step <NUM>, the UE transmits the on-demand SI request to the base station as part of RACH Msg1. For example, the RACH Msg1 may comprise a specific RACH preamble (signature) which indicates to the base station that Msg1 is an on-demand SI request. At step <NUM>, the base station <NUM> transmits a Random Access Response (RAR) to the UE <NUM>. This is message <NUM> (Msg2) of the RACH procedure. At step <NUM>, the UE then monitors the SI window of the on-demand SIB (e.g. SIB number X) in order to receive the assistance information.

In the arrangement of <FIG>, it is necessary for the UE <NUM> to indicate to the base station <NUM> that the request transmitted with Msg1 is for positioning related information. A challenge with using Msg1, however, is that number of available signatures is very small. Thus, only a small number (e.g. one) of the signatures may be allocated for indicating that Msg1 comprises an on-demand SI request. There are several options in relation to this.

With this option, only one RACH resource will be reserved in advance for assistance positioning information. After receiving an SI request using this common RACH resource from the UE:.

In this case, there is a mapping between reserved RACH resources and respective types of assistance positioning information. For example, RACH resource <NUM> may be associated with a particular GNSS type, RACH resource <NUM> may be associated with a particular position sensor type, RACH resource <NUM> may be associated with both the particular GNSS and particular sensor type, and so on.

If the received assistance information is the information required by the UE (or is not sufficient), then the UE sends Msg1 again and request further information. The signature used may be the same as the one previously used. Alternatively, one or more signatures may be repeatedly transmitted one after the other (in a consecutive sequence) so that the signature transmitted with each successive Msg1 is toggled between the available signatures. This allows the network to more easily differentiate between a repeated Msg1 transmitted because the UE has not successfully received the assistance information even though the assistance information is suitable for use with the UE's capability (as may occur if the strength and/or quality of the third signal is low) and a repeated Msg1 transmitted because the assistance information transmitted to the UE is not suitable for use with the UE's capability. Such an arrangement is illustrated below for two signatures which are toggled.

It is noted that L1c is a new GPS code on the same frequency as L1 (thus providing good compatibility with e.g. the Galileo system).

An example in which Msg3 is used for transmitting the on-demand SI request is shown in <FIG>. In this example, the base station <NUM> is a gNB. At step <NUM>, minimum system information (MSI) is transmitted from the base station <NUM> to the UE <NUM>. At step <NUM>, based on the MIS, the UE <NUM> is able to determine an identifier of the on-demand SIB (e.g. that SIB number X is the on-demand SIB) and to determine that the on-demand SI request must be transmitted in RACH Msg3. At step <NUM>, the UE transmits RACH Msg1 to the base station. In this case, a random one of the available RACH preambles (signatures) may be transmitted in the usual way. At step <NUM>, the base station <NUM> transmits a Random Access Response (RAR) to the UE <NUM>. This is message <NUM> (Msg2) of the RACH procedure. The RAR includes information indicating uplink radio resources granted to the UE (e.g. on an uplink shared channel UL-SCH). At step <NUM>, the UE transmits the on-demand SI request to the base station as part of RACH Msg3. The on-demand SI request is transmitted using one or more of the uplink resources granted to the UE, and includes, for example, the request for the on-demand SIB (e.g. SIB number X) and an identifier of the UE. At step <NUM>, a UE Content Resolution Identity is transmitted from the base station to the UE. This is message <NUM> (Msg4) of the RACH procedure. At step <NUM>, the UE then monitors the SI window of the on-demand SIB (e.g. SIB number X) in order to receive the assistance information.

In Msg3, the expected assistance positioning information will be indicated. For example, in the case that there is a predetermined mapping between assistance positioning information type (e.g. GNSS type, sensor type, or the like )and a certain identifier (e.g. numerical value), then this identifier will be included in Msg3.

A challenge associated with the use of Msg3 for transmitting the on-demand SI request is the limited message size (that is, the limited amount of data that can be transmitted using Msg3). In conventional LTE operation, for example, RACH Msg3 includes a UE-identifier (e.g. 40bits S-TMSI (System Architecture Evolution (SEA) Temporary Mobile Subscriber Identity) or Random Value) and establishment causes (<NUM> bits). If the conventional format is used in embodiments of the present technique, then the UE identifier (UE-ID) may be with an SI request bitmap a new establish cause may be defined for allowing the network to determine that the Msg3 comprises a positioning on-demand SI request. It is envisaged that NR may expand the size of Msg3. For example, it may be expanded to between <NUM> bytes (<NUM> bits) and <NUM> bytes (<NUM> bits) (see e.g. 3GPP Tdoc R2-<NUM>). The positioning capability indication (e.g. GNSS type, sensor type, or the like) should also be accommodated within Msg3 of a given size.

Conventional LPP has a large data capacity for communication because it is directed for us in connected mode (rather than idle or inactive mode, as enabled by the present technique). Thus, LPP assumes that the UE sends all the related positioning capability information to the location server (via the base station) in advance. On the other hand, in an embodiment of the present technique in which an on-demand SI request is transmitted within Msg3, there are limits on the amount of data that can be sent. It may therefore not be possible to transmit all the positioning capability information that would normally be sent in connected mode using conventional LPP. Embodiments of the present technique help alleviate this problem.

In an embodiment, the UE's approximate position (based on, for example, the location of the base station(s) with which the UE is able to receive signals) is known by the network. This is possible, for example, when the UE is in an inactive (e.g. RRC_INACTIVE) state. In this case, only assistance information necessary based on the UE's approximate position is transmitted to the UE. For example, for the case of GNSS assistance information, only information for satellites which may serve the UE at the UE's approximate position (e.g. covering a geographical area comprising the approximate position of the UE) is transmitted as assistance information to the UE.

In terms of supported GNSS bands/frequencies, Upper L-band (e.g. L1 C/A in GPS) is most common use for GNSS systems. Lower L-bands are more recently supported, in particular for high end, special terminal devices. The supported GNSS bands / frequencies may form part of the positioning capability information of the UE. Further information on GNSS bands / frequencies may be found at, for example:
http://cdn. rohde-schwarz. com/pws/dl downloads/dl application/application notes/1ma203/1MA203 0e BeiDou SWReceiver.

As previously mentioned, UE positioning capability information may be transmitted with the Msg3 on-demand SI request using suitable bitmap information. Such bitmap information is designed to be of a sufficiently small data size such that it can be transmitted within the limited data size of Msg3. Such bitmap information may be referred to as a "compact" bitmap.

In an embodiment, a bitmap is made compact by omitting certain default values in the signalling (these default values may therefore be implicit instead). Some examples of such default information which may be omitted are given below:.

The used of a compact bitmap (such as those described above) with an omissible default value has been described with reference to Msg3. However, it will be appreciated that such a technique could also be used with Msg1 (to help alleviate the problems associated with signature number limitation, for example). For example, if a UE supports multiple GNSS types, then a default value may be the most common combination of these GNSS types. When the base station receives Msg1 comprising a common signature, the base station provides the assistance information for the combination of the most common GNSS types (e.g. GPS L1 C/A, Gallileo E5 OS, GLONASS G1 and Beidou B1). If the UE supports GNSS types other than this default combination, then the UE may issue further positioning SI requests comprising capability information indicating these further GNSS types (or, more generally, further configurations for use by the UE in determining its spatial position). The further positioning SI requests may be transmitted as part of Msg3, for example.

In embodiments, the contents of assistance information (sent from a location server to a UE via a base station, for example) may comprise existing assistance information such as A-GNSS information in LTE REL-<NUM> (see, for example, <NPL>)). The assistance information sent from a location server to a UE (via a base station) may comprise GNSS information for UE based measurement (see again, for example, <NPL>)). This allows the UE to determine its spatial position based on measurements of first signals transmitted from GNSS satellites and the received GNSS assistance information (which is received as a third signal).

A summary of a number of features of the embodiments of the present technique is provided below:.

<FIG> schematically shows a method of operating a terminal device <NUM> according to an embodiment. The method starts at step <NUM>. At step <NUM>, the first receiver circuitry <NUM> is controlled to receive a first signal. At step <NUM>, the transmitter circuitry <NUM> is controlled to transmit a second signal to infrastructure equipment <NUM> of the wireless telecommunications network. At step <NUM>, the second receiver circuitry <NUM> is controlled to receive a third signal from the infrastructure equipment, the third signal being transmitted by the infrastructure equipment in response to the infrastructure equipment receiving the second signal, the third signal being for determining, in combination with the first signal, the spatial position of the terminal device, and the third signal being comprised within a system information block (SIB). At step <NUM>, a spatial position of the terminal device is determined based on the received first and third signals. The process then ends at step <NUM>.

<FIG> schematically shows a method of operating infrastructure equipment <NUM> according to an embodiment. The method starts at step <NUM>. At step <NUM>, the receiver circuitry <NUM> is controlled to receive a second signal from a terminal device <NUM> of the wireless telecommunications network. At step <NUM>, the transmitter circuitry <NUM> is controlled to transmit a third signal to the terminal device, the third signal being transmitted in response to the reception of the second signal, the third signal being for the terminal device to determine, in combination with a first signal received by the terminal device, the spatial position of the terminal device, and the third signal being comprised within a system information block (SIB). The process then ends at step <NUM>.

<FIG> schematically shows a method of operating a data processing apparatus <NUM> according to an embodiment. The method starts at step <NUM>. At step <NUM>, communication circuitry (in the form of network interface <NUM>, for example) is controlled to receive, from infrastructure equipment <NUM> of a wireless telecommunications network, a request signal for information for determining a spatial position of a terminal device <NUM> of the wireless telecommunications network, the request signal being transmitted by the infrastructure equipment in response to the infrastructure equipment receiving a second signal transmitted by the terminal device. At step <NUM>, the communication circuitry is controlled to transmit to the infrastructure equipment, in response to the received request signal, a response signal comprising information for determining the spatial position of the terminal device, the response signal being for use by the infrastructure equipment to generate a third signal to be transmitted from the infrastructure equipment to the terminal device for the terminal device to determine, in combination with a first signal received by the terminal device, the spatial position of the terminal device, the third signal being comprised within a system information block (SIB).

In so far as embodiments of the disclosure have been described as being implemented, at least in part, by software-controlled data processing apparatus, it will be appreciated that a nontransitory machine-readable medium carrying such software, such as an optical disk, a magnetic disk, semiconductor memory or the like, is also considered to represent an embodiment of the present disclosure.

Claim 1:
A terminal device (<NUM>) for use in a wireless telecommunications network, the terminal device comprising:
first receiver circuitry (<NUM>) comprising a Global Navigation Satellite System, GNSS, antenna, the first receiver circuitry being configured to receive a first signal from each of one or more signal emitting devices located at respective spatial positions, wherein the signal emitting devices are GNSS satellites;
transmitter circuitry (<NUM>) configured to transmit a second signal to infrastructure equipment (<NUM>) of the wireless telecommunications network;
second receiver circuitry (<NUM>) configured to receive a third signal from the infrastructure equipment, the third signal being transmitted by the infrastructure equipment in response to the infrastructure equipment receiving the second signal, the third signal comprising assistance information of positioning, the assistance information of positioning being for determining, in combination with the first signal, the spatial position of the terminal device, and the third signal being comprised within a first system information block, SIB; and
control circuitry (<NUM>) configured to determine a spatial position of the terminal device based on the received first and third signals, wherein
the second receiver circuitry is configured to receive information comprised within a second SIB received from the infrastructure equipment prior to transmission of the first SIB;
the control circuitry is configured to determine whether the information comprised within the second SIB is sufficient to determine, in combination with the first signal, the spatial position of the terminal device;
wherein, when it is determined that the information comprised within the second SIB is not sufficient to determine, in combination with the first signal, the spatial position of the terminal device, the control circuitry is configured to control the transmitter circuitry to transmit the second signal to the infrastructure equipment of the wireless telecommunications network.