Patent Description:
A wireless network comprises a plurality of network nodes including terminal nodes and access nodes.

The terminal nodes and access nodes communicate with each other wirelessly.

In some circumstances it may be desirable to reduce power consumption at the terminal nodes.

<NPL>, discusses transmission in preconfigured uplink resources (PUR). A UE is allowed to use PUR with a valid timing advance. Transmission in preconfigured uplink resources in RRC_IDLE is limited to UEs which can reuse their timing advance (TA) from previous transmission. A UE must fulfil certain requirements to ensure its TA is valid before accessing using PUR resources.

<NPL>, discusses considerations for preconfigured uplink (UL) resources in A-MTC. A TA is used for PUSCH and PUCCH in order to maintain orthogonality among different UEs' uplink transmissions. It is possible that the TA signalled to the UE during its last RACH process is valid for PUR transmission. For such cases, it will be beneficial to indication to a PUR-capable UE that their TA is valid.

<NPL>, discusses signalling aspects for transmission in preconfigured resources. As the uplink transmission over preconfigured resources requires possession of a valid TA at the UE, the UE needs to check whether the last received TA is valid prior to its next opportunity for PUR transmission.

<FIG> illustrates an example of a network <NUM> comprising a plurality of network nodes including terminal nodes <NUM>, access nodes <NUM> and one or more core nodes <NUM>. The terminal nodes <NUM> and access nodes <NUM> communicate with each other. The one or more core nodes <NUM> communicate with the access nodes <NUM>.

The one or more core nodes <NUM> may, in some examples, communicate with each other. The one or more access nodes <NUM> may, in some examples, communicate with each other.

The network <NUM> may be a cellular network comprising a plurality of cells <NUM> each served by an access node <NUM>. In this example, the interface between the terminal nodes <NUM> and an access node <NUM> defining a cell <NUM> is a wireless interface <NUM>. The access node <NUM> is a cellular radio transceiver. The terminal nodes <NUM> are cellular radio transceivers.

In the example illustrated the cellular network <NUM> is a third generation Partnership Project (3GPP) network in which the terminal nodes <NUM> are user equipment (UE) and the access nodes <NUM> are base stations.

In the particular example illustrated the network <NUM> is an Evolved Universal Terrestrial Radio Access network (E-UTRAN). The E-UTRAN consists of E-UTRAN NodeBs (eNBs) <NUM>, providing the E-UTRA user plane and control plane (RRC) protocol terminations towards the UE <NUM>. The eNBs <NUM> are interconnected with each other by means of an X2 interface <NUM>. The eNBs are also connected by means of the S1 interface <NUM> to the Mobility Management Entity (MME) <NUM>.

Current development of E-UTRAN is focused on supporting large numbers of latency tolerant, low data UEs <NUM>. This enables the machine type communications (MTC) and cellular Internet of Things (IoT). MTC & IoT devices may transmit data only sporadically and the network needs to support sporadic data transmission by a UE <NUM> when it is in the idle mode <NUM>.

A UE <NUM> may transmit to network <NUM> to enable the network to classify the UE <NUM> for latency requirements, data bandwidth requirements and mobility requirements. For example, a Physical Layer Enhancements for Machine Type Communications (eMTC) protocol may use a reduced bandwidth of <NUM>. For example, a narrowband internet of things (NB-loT) protocol uses a reduced bandwidth of <NUM>. The expected mobility of a UE <NUM> performing the NB-loT protocol is very low. For NB-loT protocol there is no handover in the connected state <NUM>.

UEs <NUM> can be operating at different coverage enhancement levels. This means, that in the same cell <NUM>, different UEs <NUM> may be using the same logical channels but the characteristics (narrowband resources, repetitions, etc) of the corresponding physical channels can be very different between UEs <NUM> operating at different coverage enhancement levels.

<FIG> illustrates an example of different modes <NUM>, <NUM> of a UE <NUM> and transitions <NUM>, <NUM> between the modes <NUM>, <NUM>.

The connected mode <NUM> is a mode that enables communication between the UE <NUM> and the network <NUM> at higher layers, for example to enable the communication of application data or higher layer signaling.

The Random Access procedure is used to transition <NUM> from the idle mode <NUM> to the connected mode. A transition <NUM> from the connected mode <NUM> to the idle mode <NUM> may, for example, occur on release of the connection or radio link failure.

In the E-UTRAN network <NUM>, the idle mode <NUM> corresponds to RRC_IDLE and the connected mode corresponds to RRC_CONNECTED. The transition <NUM> corresponds to RRC Connection Establishment, RRC Connection Re-establishment or Early Data Transmission (EDT). The transition <NUM> corresponds to RRC Connection RELEASE (also Radio Link Failure).

In the following a terminal node <NUM> will be referred to as a terminal <NUM>.

A terminal <NUM> is a device that terminates the cell side of the radio link. It is a device allowing access to network services. The terminal <NUM> may be a mobile terminal. the terminal may be user equipment or mobile equipment. User equipment is mobile equipment plus a subscriber identity module (SIM).

A base station <NUM> is a network element in radio access network responsible for radio transmission and reception in one or more cells to or from terminals <NUM>. The base station <NUM> is the network termination of the radio link. The base station operates as a NodeB.

<FIG> illustrates an example of a contention based random access procedure <NUM>. An example of a contention based random access procedure is described at section <NUM>. <NUM> of 3GPP TS <NUM> (<NUM>, Rel <NUM>).

The contention based random access procedure is a common procedure for FDD and TDD. The contention based random access procedure can for example be used for initial access from RRC_IDLE. This may be performed for RRC Connection Establishment, RRC Connection Re-establishment or Early data Transmission (EDT) or other reasons.

The contention based random access procedure <NUM> starts when the terminal node <NUM> sends to the access node <NUM> an uplink initiation message (Msg1) <NUM>. This is the Random Access Preamble in 3GPP TS <NUM> (<NUM>, Rel <NUM>). It is sent in the logical Random Access Channel (RACH) and, physically, in the Physical Random Access Channel (PRACH). The terminal node <NUM> selects a preamble based on testing at the terminal node <NUM> of conditions broadcast on system information.

Next, the access node <NUM> responds to receiving an uplink initiation message (Msg1) <NUM> by sending
a downlink response (Msg2) <NUM> from the access node <NUM> to the terminal node <NUM>. The downlink response <NUM> includes an initial uplink grant. The downlink response <NUM> is the Random Access Response in 3GPP TS <NUM> (<NUM>, Rel <NUM>). The Random Access Response additionally includes timing alignment information used to determine timing advance. It is addressed to RA-RNTI on PDCCH. The Random Access RNTI (RA-RNTI) unambiguously identifies which time-frequency resource was utilized by the terminal node <NUM> to transmit the Random Access Preamble <NUM>.

The terminal node <NUM> uses the timing advance to advance/delay its timings of transmissions to the access node <NUM> so as to compensate for propagation delay between the terminal node <NUM> and the access node <NUM>.

Next, the terminal node <NUM> responds to receiving the downlink response (Msg2) <NUM> from the access node <NUM> by sending an uplink connection request (Msg3) <NUM> from the terminal node <NUM> to the access node <NUM>. The uplink connection request <NUM> can comprise an identifier of the terminal node <NUM>. The uplink connection request <NUM> is the Scheduled Transmission in 3GPP TS <NUM> (<NUM>, Rel <NUM>). The identifier of the terminal node <NUM> is the UE identifier. The Scheduled Transmission <NUM> is sent according to the initial uplink grant provided in the Random Access Response <NUM>. The Scheduled Transmission can include a RRC Connection Request, a RRC Connection Re-establishment Request or, if early data transmission (EDT) is enabled a RRC EarlyDataRequest.

Next, the access node <NUM> responds to receiving the uplink connection request <NUM> by sending a downlink response (Msg4) <NUM> from the access node <NUM> to the terminal node <NUM>. The downlink response <NUM> to uplink connection request includes identifier of the terminal node <NUM> received in the uplink connection request <NUM>. The downlink response <NUM> to uplink connection request is the Contention Resolution in 3GPP TS <NUM> (<NUM>, Rel <NUM>).

In 3GPP Rel-<NUM>, e.g. 3GPP TS <NUM> s7. <NUM>, sending of small data during the Random Access Procedure <NUM> without establishing the RRC connection is introduced. This feature is known as early data transmission (EDT). The data transmission happens in the early steps of the Random Access procedure <NUM>. If the terminal node <NUM> wants to send a data packet (up to <NUM> bits) then it sends a special uplink initiation message <NUM> (a special Random Access Preamble). When the access node <NUM> detects this special uplink initiation message <NUM>, it knows that the terminal node <NUM> requests small data transmission. The access node <NUM> sends downlink response <NUM>
(the Random Access Response) with an uplink grant for an uplink connection request <NUM> (Scheduled Transmission) with a bigger size of up to <NUM> bits. The terminal node <NUM> sends the data directly in the uplink connection request <NUM> (Scheduled Transmission). On reception of a downlink response <NUM> to uplink connection request (Contention Resolution) acknowledging the reception of the data, the terminal node <NUM> returns to idle (RRC_IDLE) <NUM>.

In 3GPP TS <NUM> (<NUM>, Rel <NUM>), if the Random Access procedure <NUM> fails after transmission of the Scheduled Transmission <NUM> e.g. due to contention resolution failure, the terminal node (UE) <NUM> needs to restart the Random Access Procedure starting from the Random Access Preamble <NUM> transmission.

In 3GPP TS <NUM> (<NUM>, Rel <NUM>), if a RRC connection needs to be setup, even within a short time interval from release of the last RRC connection, the terminal node <NUM> needs to restart the Random Access Procedure starting from the Random Access Preamble <NUM> transmission.

In 3GPP TS <NUM> (<NUM>, Rel <NUM>), if during EDT the Contention Resolution <NUM>, acknowledging data receipt by the access node <NUM>, fails then the terminal node <NUM> needs to restart the Random Access Procedure starting from the Random Access Preamble <NUM> transmission.

In case of deep coverage for NB-loT/eMTC UE <NUM>, NPDCCH/MPDCCH/PDSCH/PUSCH transmission would usually require a large number of repetitions, therefore restarting RA procedure <NUM> may not always be optimal as this would cause more UE power consumption and control-plane latency.

The procedure is improved by using common preconfigured uplink resources. This use of the common preconfigured uplink resources obviates the need to perform the Random Access procedure from the start (transmitting the uplink initiation message <NUM>), instead it can be performed from the uplink connection request <NUM>. The uplink connection request <NUM> is sent within a preconfigured uplink resource. The preconfigured uplink resource is different to the initial uplink grant normally used to send the uplink connection request (as described above).

The preconfigured uplink resources (PUR) are preconfigured by the access node <NUM>. The access node <NUM> allocates a set of uplink resources for uplink transmission. The preconfigured uplink resources are fixed and pre-allocated by the network. They have a fixed location in time. They have a fixed duration in time. They have a fixed frequency. The preconfigured uplink resources may be defined by uplink subframes and frequency resources.

The multiple available preconfigured uplink resources have distinct allocations of the same bandwidth (frequency) with a common timing schedule.

The preconfigured uplink resources can be allocated to each UE individually as dedicated resources. This is called dedicated PUR. The preconfigured uplink resources can be allocated commonly for multiple terminals <NUM>. In this case it is called shared PUR or common PUR. In this case the resources are shared across multiple users.

The access to the preconfigured uplink resources can be contention based or contention free.

The configuration information is sent via broadcast (system information) signaling to all terminals <NUM>. The preconfigured uplink resources are configured for transmission of small data without connection establishment. The terminal <NUM> using these resources for transmission does not have a RRC connection and any dedicated identifiers. Any terminal <NUM> in idle mode can use the preconfigured uplink resources if the resource configurations are known.

<FIG> illustrates multiple preconfigured uplink resources <NUM> that have a common fixed time schedule <NUM> that is time aligned with a schedule for sending uplink initiation messages <NUM> of a random access procedure <NUM>. Thus the preconfigured uplink resources <NUM> for transmission of an uplink connection request are configured in the same timing and periodicity as RACH Resources used for sending a Random Access Preamble. The set of multiple preconfigured uplink resources <NUM> are allocated to a frequency range <NUM> different to the frequency range <NUM> used for sending uplink initiation messages <NUM> of a random access procedure <NUM>.

The set of multiple preconfigured uplink resources <NUM>, the PUA region, is frequency divided to provide each separate preconfigured uplink resource <NUM>. Each preconfigured uplink resource <NUM> in the set of multiple preconfigured uplink resources <NUM> has the same size <NUM> (e.g. transport block size) corresponding to the uplink connection request <NUM> of the random access procedure <NUM>. The size may be <NUM> bits.

Thus multiple preconfigured uplink resources <NUM> are configured at the same starting time <NUM> of the PRACH window for sending uplink initiation messages <NUM> but are separated in frequency from the uplink initiation messages <NUM>.

During a pre-configuration stage, the access node <NUM> preconfigures the uplink resources by sending broadcast system information defining the preconfigured uplink resources <NUM>. This system information, received at the mobile node <NUM>, is a broadcast network allocation of preconfigured uplink resources for transmission of an uplink connection request. This broadcast system information can be sent as a broadcast information element for preconfiguring multiple uplink resources. The broadcast information element comprises one or more data structures, for example fields, configured to define multiple preconfigured uplink resources <NUM> that have:.

Referring to a method <NUM> illustrated in <FIG>, instead of re-starting the random access procedure <NUM> and sending uplink initiation message <NUM> and downlink response <NUM> in the normal way, the terminal <NUM> sends, at block <NUM>, the uplink connection request <NUM> via a preconfigured uplink access resource <NUM>.

The timing advance will need to be valid. In at least some examples, the terminal <NUM> is configured to check validity of a timing advance before causing the sending of the uplink connection request <NUM> within the preconfigured uplink resource <NUM>. The timing advance becomes invalid if a validity timer expires in idle state. Other criteria can be used to invalidate the timing advance, for example, changes in received signal strength measurement, changes in serving cell id, movement of the terminal <NUM> beyond a threshold distance (e.g. <NUM>).

If the timing advance is determined to be valid, at block <NUM>, the terminal <NUM> sends, at block <NUM>, an uplink connection request <NUM> within a preconfigured uplink resource <NUM>.

The uplink connection request <NUM> can, in at least some examples, comprise an identifier of the terminal <NUM>.

The preconfigured uplink resource <NUM> used to send the uplink connection request <NUM> can, in at least some examples, be different to the initial uplink grant <NUM> provided previously by a downlink response <NUM> of a random access procedure <NUM>. The preconfigured uplink resource <NUM> used for sending the uplink connection request <NUM> is not scheduled by the downlink response <NUM> (although scheduling will depend upon a timing advance supplied). The preconfigured uplink resource <NUM> has a fixed, pre-allocated timing schedule that is independent of the uplink grant and is time aligned with a time schedule for sending uplink initiation messages <NUM>. One of preconfigured uplink resources <NUM> is selected and the selected preconfigured uplink resource <NUM> is used to send the uplink connection request <NUM>. The preconfigured uplink resource <NUM> can be randomly selected by the terminal <NUM> from the set of multiple available preconfigured uplink resources <NUM>.

At block <NUM>, a trigger causes the terminal to start the process for sending an uplink connection request <NUM> within a preconfigured uplink resource <NUM>. The terminal can, for example, send an uplink connection request <NUM> within a preconfigured uplink resource <NUM> in the following scenarios:.

As previously described, in the random access procedure <NUM>, the terminal <NUM> responds to receipt of a downlink response <NUM> comprising an initial uplink grant by sending an uplink connection request <NUM>, comprising an identifier of the terminal <NUM>, using the initial uplink grant. After a delay without receiving a downlink contention resolution response <NUM>, if the timing advance remains valid, the terminal <NUM> sends the uplink connection request <NUM>, comprising the identifier of the terminal <NUM>, within the preconfigured uplink resource <NUM> which is different to the initial uplink grant.

In response to receiving the uplink connection request <NUM> within a preconfigured uplink resource <NUM> the access node <NUM> sends, at block <NUM>, a downlink response <NUM>. The downlink response <NUM> is a response to the uplink connection request <NUM> within the preconfigured uplink resource <NUM>. This continues the random access procedure <NUM>. The uplink connection request <NUM> may be used for connection establishment, connection re-establishment or early data transmission.

As illustrated in <FIG>, the downlink response <NUM> to the uplink initiation message <NUM> and the downlink response <NUM> to the uplink connection request <NUM> within the preconfigured uplink resource <NUM> can occupy a common resource space <NUM> monitored by the terminal <NUM>. The monitored common resource space <NUM> comprises common timing and a common frequency space. The downlink responses <NUM>, <NUM> are both transmitted in a Physical Downlink Control Channel. Thus the terminal <NUM> listens to the same common search space <NUM> configured for Random Access Response <NUM> to get a downlink response <NUM>, in response to the uplink connection request <NUM>.

A one-step process may be used for delivery of the downlink contention resolution response. In this case, the downlink response <NUM> to the uplink connection request <NUM> within the preconfigured uplink resource provides a downlink contention resolution response, for example, comprising the received identifier of the terminal.

Alternatively a multi-step process may be used for delivery of the downlink contention resolution response. In this case, the downlink response <NUM> to the uplink connection request <NUM> within the preconfigured uplink resource <NUM> allocates directly or indirectly a future resource <NUM> for providing a downlink contention resolution response comprising the received identifier of the terminal.

In one example, the downlink response <NUM> to the uplink connection request <NUM> within the preconfigured uplink resource <NUM> provides a time schedule to receive a downlink contention resolution response comprising the received identifier of the terminal. For example, the downlink response <NUM> to the uplink connection request <NUM> within the preconfigured uplink resource can provide a downlink response <NUM> to the uplink initiation message defining a time schedule for receiving a downlink contention resolution response comprising the received identifier of the terminal. At the scheduled time, the mobile node <NUM> receives a downlink contention resolution response comprising the received identifier of the terminal.

In the following examples the common search space (RNTI) <NUM> configured for Random Access Response is used for enabling receipt, directly <NUM> or indirectly <NUM>, the downlink contention response.

Downlink control information (DCI) sent to the terminal <NUM> via the common search space <NUM> schedules two separate transport blocks. A first one is allocated for the downlink Random Access Response <NUM> and the second is used for the downlink response <NUM>. The downlink response <NUM> contains a downlink grant for sending <NUM> the downlink contention response. Thus the downlink control information sent on the common search space <NUM> indicates a separate resource for sending a downlink response <NUM>. The downlink response <NUM> can be the downlink contention response or can be used to schedule the downlink contention response.

Where the common search space <NUM>, corresponds to the search space used for the Random Access Response (RA-RNTI), a downlink response message <NUM> is modified to include information elements as the downlink response <NUM> in addition to the Random Access Response. In one example, the information elements (downlink response <NUM>) include a downlink grant to send a downlink message <NUM> and an uplink grant for an acknowledgement <NUM> in reply. The information element also includes an identifier to identify the predetermined uplink resource <NUM> used to send the uplink connection request <NUM>. The downlink message <NUM> can be the downlink contention response or can be used to schedule the downlink contention response. In another example, the information elements (downlink response <NUM>) includes the downlink contention response.

<FIG> illustrates an example of a controller <NUM>. Implementation of a controller <NUM> may be as controller circuitry. The controller <NUM> may be implemented in hardware alone, have certain aspects in software including firmware alone or can be a combination of hardware and software (including firmware).

The memory <NUM> stores a computer program <NUM> comprising computer program instructions (computer program code) that controls the operation of the apparatus <NUM>, <NUM> when loaded into the processor <NUM>. The computer program instructions, of the computer program <NUM>, provide the logic and routines that enables the apparatus to perform the methods illustrated in <FIG>. The processor <NUM> by reading the memory <NUM> is able to load and execute the computer program <NUM>.

As illustrated in <FIG>, the computer program <NUM> may arrive at the apparatus <NUM>, <NUM> via any suitable delivery mechanism <NUM>. The delivery mechanism <NUM> may be, for example, a machine readable medium, a computer-readable medium, a non-transitory computer-readable storage medium, a computer program product, a memory device, a record medium such as a Compact Disc Read-Only Memory (CD-ROM) or a Digital Versatile Disc (DVD) or a solid state memory, an article of manufacture that comprises or tangibly embodies the computer program <NUM>. The delivery mechanism may be a signal configured to reliably transfer the computer program <NUM>. The apparatus <NUM>, <NUM> may propagate or transmit the computer program <NUM> as a computer data signal.

Computer program instructions for causing an apparatus <NUM> to perform at least the following or for performing at least the following:.

Different computer program instructions for causing an apparatus <NUM> to perform at least the following or for performing at least the following:.

The blocks illustrated in the <FIG> may represent steps in a method and/or sections of code in the computer program <NUM>. The illustration of a particular order to the blocks does not necessarily imply that there is a required or preferred order for the blocks and the order and arrangement of the block may be varied. Furthermore, it may be possible for some blocks to be omitted.

In some but not necessarily all examples, the apparatus <NUM> is configured to communicate data from the apparatus <NUM> with or without local storage of the data in a memory <NUM> at the apparatus <NUM> and with or without local processing of the data by circuitry or processors at the apparatus <NUM>.

The data may be stored in processed or unprocessed format remotely at one or more devices. The data may be stored in the Cloud.

The data may be processed remotely at one or more devices. The data may be partially processed locally and partially processed remotely at one or more devices.

The data may be communicated to the remote devices wirelessly via short range radio communications such as Wi-Fi or Bluetooth, for example, or over long range cellular radio links. The apparatus may comprise a communications interface such as, for example, a radio transceiver for communication of data.

The apparatus <NUM> may be part of the Internet of Things forming part of a larger, distributed network.

The processing of the data, whether local or remote, may be for the purpose of health monitoring, data aggregation, patient monitoring, vital signs monitoring or other purposes.

The processing of the data, whether local or remote, may involve artificial intelligence or machine learning algorithms. The data may, for example, be used as learning input to train a machine learning network or may be used as a query input to a machine learning network, which provides a response. The machine learning network may for example use linear regression, logistic regression, vector support machines or an acyclic machine learning network such as a single or multi hidden layer neural network.

The processing of the data, whether local or remote, may produce an output. The output may be communicated to the apparatus <NUM> where it may produce an output sensible to the subject such as an audio output, visual output or haptic output.

The above described examples find application as enabling components of: automotive systems; telecommunication systems; electronic systems including consumer electronic products; distributed computing systems; media systems for generating or rendering media content including audio, visual and audio visual content and mixed, mediated, virtual and/or augmented reality; personal systems including personal health systems or personal fitness systems; navigation systems; user interfaces also known as human machine interfaces; networks including cellular, non-cellular, and optical networks; ad-hoc networks; the internet; the internet of things; virtualized networks; and related software and services.

A property of the instance can be a property of only that instance or a property of the class or a property of a subclass of the class that includes some but not all of the instances in the class.

Although embodiments have been described in the preceding paragraphs with reference to various examples, it should be appreciated that modifications to the examples given can be made without departing from the scope of the claims.

The term 'a' or 'the' is used in this document with an inclusive not an exclusive meaning. That is any reference to X comprising a/the Y indicates that X may comprise only one Y or may comprise more than one Y unless the context clearly indicates the contrary. If it is intended to use 'a' or 'the' with an exclusive meaning then it will be made clear in the context. In some circumstances the use of `at least one' or 'one or more' may be used to emphasis an inclusive meaning but the absence of these terms should not be taken to infer and exclusive meaning.

Claim 1:
An apparatus in a terminal comprising:
means for checking validity of a timing advance;
means for determining (<NUM>) that the timing advance is valid; and
means for, based on the determination that the timing advance is valid, sending (<NUM>) an uplink connection request (<NUM>) to a wireless network node within a preconfigured uplink resource (<NUM>)
wherein the preconfigured uplink resource (<NUM>) is configured with the same timing and periodicity as random access channel resources used for sending a random access preamble, and
wherein the preconfigured uplink resource (<NUM>) is configured with a frequency that is different to a frequency of random access channel resources used for sending the random access preamble.