EP3928572A1

EP3928572A1 - Communicating between a terminal and a wireless network node

Info

Publication number: EP3928572A1
Application number: EP19915996.3A
Authority: EP
Inventors: Samuli Turtinen; Kari Hooli; Sami Hakola; Chunli Wu
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2019-02-19
Filing date: 2019-02-19
Publication date: 2021-12-29
Also published as: TWI745866B; CN113439467B; TW202041087A; AR118135A1; CN113439467A; EP3928572A4; WO2020168469A1

Abstract

An apparatus comprising means for: sending an uplink message (MsgA) in a two-step random access procedure; receiving a downlink reply message (MsgB) in the two-step random access procedure, the received downlink reply message comprising an identifier for the apparatus; and sending an uplink acknowledgement message using a PUCCH resource determined by a PUCCH resource index wherein the PUCCH resource index is dependent upon, at least, a PUCCH resource indicator (PRI) and the identifier of the apparatus.

Description

COMMUNICATING BETWEEN A TERMINAL AND A WIRELESS NETWORK NODE

TECHNOLOGICAL FIELD
Embodiments of the present disclosure relate to communicating between a terminal and a wireless network node.

BACKGROUND

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.
BRIEF SUMMARY
According to various, but not necessarily all, embodiments there is provided examples as claimed in the appended claims.
BRIEF DESCRIPTION
Some example embodiments will now be described with reference to the accompanying drawings in which:
FIG. 1 shows an example embodiment of the subject matter described herein;
FIG. 2 shows another example embodiment of the subject matter described herein;
FIG. 3 shows another example embodiment of the subject matter described herein;
FIG. 4 shows another example embodiment of the subject matter described herein;
FIG. 5A shows another example embodiment of the subject matter described herein;
FIG. 5B shows another example embodiment of the subject matter described herein;
DEFINITIONS
ACK Acknowledge
BWP Bandwidth Part
CCE Control Channel Element
CS Cyclic Shift
DCI Downlink Control Information
HARQ Hybrid Acknowledge Request
NW Network
PRB Physical Resource Block
PRACH Physical RACH
PRI PUCCH Resource Indicator
PUCCH Physical Uplink Control Channel
RA Random Access
RA-RNTI Random Access Radio Network Temporary Identifier
RACH Random Access Channel
RAR Random Access Response
RO RACH Occasion
UCI Uplink Control Information
UE User Equipment

DETAILED DESCRIPTION

FIG 1 illustrates an example of a network 100 comprising a plurality of network nodes including terminal nodes 110, access nodes 120 and one or more core nodes 1129. The terminal nodes 110 and access nodes 120 communicate with each other. The one or more core nodes 129 communicate with the access nodes 120.
The one or more core nodes 129 may, in some examples, communicate with each other. The one or more access nodes 120 may, in some examples, communicate with each other.
The network 100 may be a cellular network comprising a plurality of cells 122 each served by an access node 120. In this example, the interface between the terminal nodes 110 and an access node 120 defining a cell 122 is a wireless interface 124.
The access node 120 is a cellular radio transceiver. The terminal nodes 110 are cellular radio transceivers.
In the example illustrated the cellular network 100 is a third generation Partnership Project (3GPP) network in which the terminal nodes 110 are user equipment (UE) and the access nodes 120 are base stations.
In the particular example illustrated the network 100 is an Evolved Universal Terrestrial Radio Access network (E-UTRAN) . The E-UTRAN consists of E-UTRAN NodeBs (eNBs) 120, providing the E-UTRA user plane and control plane (RRC) protocol terminations towards the UE 110. The eNBs 120 are interconnected with each other by means of an X2 interface 126. The eNBs are also connected by means of the S1 interface 128 to the Mobility Management Entity (MME) 129.
In other example the network 100 is a Next Generation (or New Radio, NR) Radio Access network (NG-RAN) . The NG-RAN consists of gNodeBs (gNBs) 120, providing the user plane and control plane (RRC) protocol terminations towards the UE 110. The gNBs 120 are interconnected with each other by means of an X2/Xn interface 126. The gNBs are also connected by means of the N2 interface 128 to the Access and Mobility management Function (AMF) .
Current development of radio access networks is focused on supporting large numbers of latency tolerant, low data UEs 110. 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 110 when it is in the idle mode 130.
A UE 110 may transmit to network 100 to enable the network to classify the UE 110 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 1.4MHz. For example, a narrowband internet of things (NB-IoT) protocol uses a reduced bandwidth of 200kHz. The expected mobility of a UE 110 performing the NB-IoT protocol is very low. For NB-IoT protocol there is no handover in the connected mode 132.
UEs 110 can be operating at different coverage enhancement levels. This means, that in the same cell 122, different UEs 110 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 110 operating at different coverage enhancement levels.
FIG 2 illustrates an example of different modes 130, 132 of a UE 110 and transitions 131, 133 between the modes 130, 132.
The connected mode 132 is a mode that enables communication between the UE 110 and the network 100 at higher layers, for example to enable the communication of application data or higher layer signaling.
The Random Access procedure is used for transition 131 from the idle mode (or inactive mode) 130 to the connected mode, as well as in connected mode when the UE 110 is UL out-of-sync or to request UL resource when there is no dedicated scheduling request resource configured, or to recover from beam failure, for instance. A transition 133 from the connected mode 132 to the idle mode 130 may, for example, occur on release of the connection or radio link failure.
In the NG-RAN network 100, the idle or inactive mode 130 corresponds to RRC_IDLE or RRC_INACTIVE, respectively, and the connected mode corresponds to RRC_CONNECTED. The transition 131 corresponds to RRC Connection Establishment, RRC Connection Re-establishment, RRC Connection Resume or Early Data Transmission (EDT) , for instance. The transition 133 corresponds to RRC Connection RELEASE (also Radio Link Failure) , for instance.
In the following a terminal node 110 will be referred to as a terminal 110.
A terminal 110 is a device that terminates the cell side of the radio link. It is a device allowing access to network services. The terminal 110 may be a mobile terminal. The terminal 110 may be user equipment or mobile equipment. User equipment is mobile equipment plus a subscriber identity module (SIM) .
An access node 120 is a network element in radio access network responsible for radio transmission and reception in one or more cells 122 to or from terminals 110. The access node 120 is the network termination of the radio link. The access node 120 operates as a NodeB, eNodeB, gNodeB.
FIG 3 illustrates an example of a 4-step contention based random access procedure 200. An example of a contention based random access procedure is described at section 10.1.5 of 3GPP TS 36.300 (2018, Rel15) .
The contention based random access procedure is a common procedure for frequency division duplex (FDD) and time division duplex (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 4-step contention based random access procedure 200 starts, at the first step, when a terminal node 110 sends to an access node 120 an uplink initiation message (Msg1) 202. This is the Random Access Preamble in 3GPP TS 36.300 section 10.1.5 (2018, Rel 15) . Msg1 202 is sent in the logical Random Access Channel (RACH) and, physically, in the Physical Random Access Channel (PRACH) . The terminal node 110 selects random access resources including e.g. random access occasions (ROs) and preamble group within the selected ROs based on testing at the terminal node 110 of conditions broadcast on system information and randomly selecting one preamble. Such conditions may include a signal level (like RSRP, RSRQ, SINR) of a beam, for instance.
Next, at the second step, the access node 120 responds to receiving an uplink initiation message (Msg1) 202 by sending a downlink response (Msg2) 204 from the access node 120 to the terminal node 110. The downlink response 204 includes an initial uplink grant. The downlink response 204 is the Random Access Response in 3GPP TS 36.300 section 10.1.5 (2018, Rel 15) . 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 within a configured window (Random Access Response window) which time-frequency resource was utilized by the terminal node 110 to transmit the Random Access Preamble 202.
The terminal node 110 uses the timing advance to advance/delay its timings of transmissions to the access node 120 so as to compensate for propagation delay between the terminal node 110 and the access node 120.
Next, at the third step, the terminal node 110 responds to receiving the downlink response (Msg2) 204 from the access node 120 by sending an uplink connection request (Msg3) 206 from the terminal node 110 to the access node 120. The uplink connection request 206 can comprise an identifier of the terminal node 110. The uplink connection request 206 is the Scheduled Transmission in 3GPP TS 36.300 section 10.1.5 (2018, Rel 15) . The identifier of the terminal node 110 is the UE identifier. The Scheduled Transmission 206 is sent according to the initial uplink grant provided in the Random Access Response 204. The Scheduled Transmission can include a RRC Connection Request, a RRC Connection Re-establishment Request, RRC Connection Resume Request or, if early data transmission (EDT) is enabled a RRC EarlyDataRequest, or in one possibility it does not include RRC message but C-RNTI MAC CE (Medium Access Control Control Element) for connected mode terminal nodes.
Next, at the fourth step, the access node 120 responds to receiving the uplink connection request 206 by sending a downlink response (Msg4) 208 from the access node 120 to the terminal node 110. The downlink response 208 to the uplink connection request 206 includes an identifier of the terminal node 110 received in the uplink connection request 206. The downlink response 208 to the uplink connection request 206 is the Contention Resolution in 3GPP TS 36.300 section 10.1.5 (2018, Rel 15) .
If the access node 120 is able to decode an Msg3 206, the contention resolution happens in the fourth step by including either the terminal node’s contention resolution ID into the contention resolution MAC PDU (IDLE/INACTIVE mode terminal nodes) or by scheduling directly with the terminal node’s C-RNTI (CONNECTED mode terminal nodes) .
Concentrating solely on the IDLE/INACTIVE mode terminal nodes, the terminal node 110 that decodes its contention resolution ID from the MAC PDU then sends a HARQ ACK to the access node 120 (NACK is not transmitted as the terminal node 110 does not obviously know if the contention resolution message was for it or not) .
Thus, in the 4-step random access procedure 200, a terminal node 110 transmits HARQ ACK/NACK feedback for the Msg4 208. A PUCCH resource set is provided by pucch-ResourceCommon signalled in RMSI through an index to a row of Table 9.2.1-1 in 3GPP TS 38.213 (2018, Rel 15) for transmission of HARQ-ACK information on PUCCH in an initial uplink BWP of PRBs.
The PUCCH resource set includes sixteen resources (16 index values) , each corresponding to:
a PUCCH format,
a first symbol,
a duration,
a PRB offset and
a cyclic shift index set for a PUCCH transmission.
The terminal node 110 transmits a PUCCH using frequency hopping. An orthogonal cover code with index 0 is used for a PUCCH resource with PUCCH format 1 in Table 9.2.1-1.
The terminal node 110 determines a PUCCH resource with PUCCH resource index r _PUCCH, 0≤r _PUCCH≤15, as where N _CCE is a number of CCEs in a CORESET of a PDCCH reception,
n _CCE, 0 is the index of a first CCE for the PDCCH reception, and
Δ _PRI is a value of the PUCCH resource indicator field in the DCI.
If
- the terminal node 110 determines the PRB index of the PUCCH transmission in the first hop as and the PRB index of the PUCCH transmission in the second hop as
where N _CS is the total number of initial cyclic shift indexes in the set of initial cyclic shift indexes,
- the terminal node 110 determines the initial cyclic shift index in the set of initial cyclic shift indexes as r _PUCCHmodN _CS.
If
- the terminal node 110 determines the PRB index of the PUCCH transmission in the first hop as and the PRB index of the PUCCH transmission in the second hop as
- the terminal node 110 determines the initial cyclic shift index in the set of initial cyclic shift indexes as (r _PUCCH-8) modN _CS.
In addition to the above PUCCH resource determination, PDCCH scheduling of PDSCH provides, in DCI, a time domain allocation (PDSCH-to-HARQ_feedback timing indicator) . This determines a time slot for the determined PUCCH resource. The PDSCH-to-HARQ-timing-indicator field values map to {1, 2, 3, 4, 5, 6, 7, 8} .
In Rel15 of 3GPP, HARQ ACK/NACK feedback for Msg4 208 PDSCH is transmitted after collision resolution, i.e. only one terminal node 110 which decodes its contention resolution ID would be transmitting the HARQ ACK.
FIG 4 illustrates an example of a 2-step contention based random access procedure 300. This can be supported in addition to the 4-step random access procedure 200.
The 2-step contention based random access procedure 300 starts, at the first step, when the terminal node 110 sends to the access node 120 an uplink initiation message (MsgA) 302 of the 2-step random access procedure. The MsgA may comprise of a randomly selected PRACH preamble over PRACH and PUSCH data transmission over PUSCH, ie., it may be 1 or 2 transmissions but is considered as one step.
Next, at the second step, the access node 120 responds to receiving an uplink initiation message (MsgA) 302 of the 2-step random access procedure by sending a downlink reply message (MsgB) 304 from the access node 120 to the terminal node 110.
The 2-step contention based random access procedure 200 differs from the 4-step contention based random access procedure 200 in that the response to the random access request enables contention resolution without further messaging, for example, without first providing an uplink grant for contention resolution.
MsgA 302 is a signal to detect the terminal node 110 and provides a Msg3 payload while MsgB 304 is for contention resolution for contention based random access (CBRA) with a possible payload. MsgA 302 will at least include the equivalent information that is transmitted in Msg3 for the 4-step contention based random access procedure 200. All the triggers for the 4-step contention based random access procedure 200 are also applicable to the 2-step contention based random access procedure 300.
The contention resolution in the 2-step procedure 300 will be performed by including a terminal node identifier 310 (UE identifier) in the first message MsgA 302 which is echoed in the second message MsgB 304. The type of terminal node identifier (s) 310 may be for example the RRC connection setup message/RRC connection resume message/re-establishment request message which contains the UE ID or number of least/most significant bits of the sent RRC message thereto (like 48 MSBs or LSBs) , or C-RNTI MAC CE. The terminal node identifier (s) 310 may be echoed in the second message MsbG 304 by using a UE Contention Resolution MAC CE.
For 2-step contention based random access procedure 300, the MsgB 304 can include responses to multiple terminal nodes 110 (similarly to Msg2 204 in the 4-step procedure 200) . Whenever the preamble part of MsgA 302 is transmitted on the same or different PRACH resources by multiple terminal nodes 110, the payload on PUSCH resource could be different. Hence, MsgB 304 could include contention resolution ID (the echoed terminal node identifier 310) for multiple terminal nodes 110 which succeeded in the MsgA 302 transmission.
As a single MsgB 304 can include contention resolution ID 310 of several terminal nodes 110, the acknowledgement (HARQ ACK acknowledging the reception of the contention resolution message MsgB 304) resources for all the terminal nodes 110 should be unique for each terminal node 110 that sends an acknowledgement so that the access node 120 can determine which terminal nodes 110 received the message MsgB 304. For transmission of acknowledgement, a PUCCH resource set is provided e.g. by pucch-ResourceCommon or some other information element signalled e.g. in RMSI. The terminal node 110 can determine PUCCH resource for acknowledgement from the PUCCH resource set or, in some examples, from PRBs outside the PUCCH resource set but using the PUCCH format, first symbol, duration, PRB offset, and a cyclic shift index set indicated for the PUCCH resource set.
In the following example, the terminal node 110 determines PUCCH resource for the HARQ ACK transmission (acknowledging 306 the PDSCH carrying MsgB 304) in this case the access node 120 does or could transmit in a single MsgB 304 multiple contention resolution IDs 310 for multiple terminal nodes 110.
The terminal node 110 determines PUCCH transmission time and resource for HARQ ACK based on the information provided in DCI scheduling MsgB 304 as well as within the MsgB 304.
The information differentiating the PUCCH resources between terminal nodes 110 is contained in the MsgB 304 and may be explicit and/or implicit, e.g. the index position of the echoed terminal node identifier 310 (contention resolution ID) in the MsgB 304.
In the 2-step procedure 300 the acknowledgement 306 can be transmitted by multiple terminal nodes 110 using orthogonal resources to acknowledge individual contention resolution success.
To achieve this, the method 300, in addition to sending an uplink message (MsgA) 302 in a two-step random access procedure 300 and receiving a downlink reply message (MsgB) 304 in the two-step random access procedure 300 comprises: sending an uplink acknowledgement message 306 using a PUCCH resource determined by a PUCCH resource index wherein the PUCCH resource index is dependent upon, at least, a PUCCH resource indicator (PRI) and an identifier 310 of the apparatus 110 received in the downlink reply message (MsgB) 304.
The PUCCH resource indicator (PRI) is received from downlink control information (DCI) and/or from the downlink reply message (MsgB 304) . Alternatively/additionally, a hybrid method could be supported where first PUCCH resource indicator (PRI) is provided by DCI and if more resources are required, e.g., in resource domain, they’re provided inside MsgB 304.
In some but not necessarily all examples, the terminal node 110 determines its valid PUCCH resource for transmission of the acknowledgement 306 based on the PUCCH resource indicator (PRI) and the index position of the terminal node’s contention resolution ID 310 in the MsgB 304.
The slot for transmission of the acknowledgement 306 is determined based on the PDSCH-to-HARQ_feedback timing indicator in the received scheduling DCI or alternatively provided inside the MsgB 304.
In some but not necessarily all examples, the PUCCH resource index is dependent upon, at least, a PUCCH resource index suitable for the four-step random access procedure 200 and the identifier 310 of the terminal node 110. The PUCCH resource index suitable for the four-step random access procedure 200 is dependent upon the PUCCH resource indicator (PRI) :
In some but not necessarily all examples, the PUCCH resource index is dependent upon the identifier 310 of the terminal node 110 because it is dependent upon an index position of the identifier 310 of the terminal node 110 in the received downlink reply message (MsgB) 304.
In some but not necessarily all examples, the PUCCH resource index is dependent upon the identifier 310 of the terminal node 110 because it is dependent upon an offset associated with the identifier 310 of the terminal node 110. The offset is received from the received downlink reply message (MsgB) 304 or from downlink control information (DCI) .
In some but not necessarily all examples, the PUCCH resources available for the uplink acknowledgement message 306 are reserved via received downlink control information (DCI) .
In some but not necessarily all examples, the PUCCH resource index is dependent upon a first index value dependent upon the PUCCH resource indicator (PRI) that is offset by a second value dependent upon the identifier 310 of the terminal node 110.
In some but not necessarily all examples, when the PUCCH resource index exceeds a maximum permissible value, an additional process is performed to determine a PUCCH resource for sending the uplink acknowledgement message 306.
In some but not necessarily all examples, the determined resource is determined from a seed received within the received downlink reply message (MsgB) 304 or the determined resource is determined by applying a modulo 16 operation to the PUCCH resource index.
In some but not necessarily all examples, the method 300 comprises receiving a further downlink reply message 304 that specifies a new PUCCH resource indicator (PRI) and/or a new slot for the uplink acknowledgement message 306.
In some but not necessarily all examples, when the PUCCH resource index exceeds a maximum permissible value, it is reset to a minimum permissible value.
In some but not necessarily all examples, the uplink acknowledgement message 306 is sent in a time slot determined by an indicator received via downlink control information (DCI) or in the received downlink reply message 304.
The method 300 can be implemented in a variety of different ways, as will be better understood from the following examples.
In some but not necessarily all examples, the PUCCH resource index is dependent upon a first index value dependent upon the PUCCH resource indicator (PRI) that is offset by a second value dependent upon the identifier 310 of the terminal node 110.
The first index value is dependent upon, at least, a PUCCH resource index suitable for the four-step random access procedure 200 and the identifier 310 of the terminal node 110. The PUCCH resource index suitable for the four-step random access procedure 200 is dependent upon the PUCCH resource indicator (PRI) . For example, the index position (e.g., #0, #1, #2 and so on) of the terminal node’s contention resolution ID could be summed to the PUCCH resource index r _PUCCH (determined by PRI and the index of the first CCE) .
When the PUCCH resource index exceeds a maximum permissible value, an additional process is performed to determine a PUCCH resource for sending the uplink acknowledgement message 306, such as for example, receiving a further downlink reply message 304 that specifies a new PUCCH resource indicator and/or a new slot for the uplink acknowledgement message 306. In one example, whenever sum of the PUCCH resource index and the terminal node’s index position reaches the maximum value of PUCCH resource index (15) , the network 100 should schedule another MsgB 304 with PUCCH resource indicator and PDSCH-to-HARQ_feedback timing indicator pointing to different UL slot. This gives the network 100 the possibility to reserve some of the PUCCH resources for other downlink transmissions.
DCI scheduling of MsgB or MsgB itself may include an indication that there will another MsgB transmission for the same RO (e.g., same RA-RNTI within the same RAR window) coming. That would allow terminal nodes 110 to potentially ignore other MsgBs 304 for the same RO in case the first detected MsgB 304 didn’t include terminal node’s contention resolution ID.
In some but not necessarily all examples, the determined resource is determined by applying a modulo 16 operation to the PUCCH resource index. For example, after the PUCCH resource index space is exhausted (reaches 15) , the next terminal node 110 starts from PUCCH resource index r _PUCCH = 0 and this continues until the first PUCCH resource index-1 value is reached.
In some but not necessarily all examples, the PUCCH resource index is dependent upon a first index value dependent upon the PUCCH resource indicator (PRI) that is offset by a second value dependent upon the identifier 310 of the terminal node 110. For example, each index position of contention resolution ID 310 provides its own resource offset value that is then used together with the PUCCH resource indicator (PRI) given in DCI (e.g. summing the resource offset value to PUCCH resource indicator (PRI) in PDCCH and applying modulo operation in base 16) . This approach would provide high flexibility with the cost of increased MsgB 304 payload.
In some but not necessarily all examples, the PUCCH resource index is dependent upon a first index value dependent upon the PUCCH resource indicator (PRI) that is offset by a second value dependent upon the identifier 310 of the terminal node 110. For example, scheduling DCI has a set of bits mapped to each index position of contention resolution ID 310 where the set of bits acts as a relative value to be applied to the common PUCCH resource indicator in the DCI. E. g. there could be up to 3 sets and each set could be allocated 2 bits. Thus, altogether 6 bits would be needed in DCI for providing up to three PUCCH resources (and up to three terminal nodes 110) in addition to the first PUCCH resource indicated by the PRI in the scheduling DCI.
In some but not necessarily all examples, the PUCCH resources available for the uplink acknowledgement message 306 are reserved via received downlink control information (DCI) . For example, the network 100 configures the maximum value of the PUCCH resource index that can be used by the terminal nodes 110 sending HARQ ACK for their contention resolution messages; the lower bound for PUCCH resource index is signaled by the PUCCH resource indicator and the first CCE of the scheduling DCI. This enables reservation of PUCCH resources, e.g. PUCCH resources indicated by indices 3-10 for the contention resolution purpose and other PUCCH resources are available for any other use.
In some but not necessarily all examples, the PUCCH resource index is dependent upon a first index value dependent upon the PUCCH resource indicator (PRI) that is offset by a second value dependent upon the identifier 310 of the terminal node 110. For example, DCI may include also a step size per index position that is summed to the PUCCH resource index r _PUCCH (determined by PRI and the index of the first CCE) E.g. DCI indicates step size equal to two, then terminal node 110 with index position #1 would add two and terminal node 110 with index position #2 would add four. This would require e.g. 2 bits in DCI to provide flexibility for the gNB (step sizes 1, 2, 3, 4. The step size could be signaled as part of MsgB 304 content as well.
In some but not necessarily all examples, the PUCCH resource index is dependent upon a first index value dependent upon the PUCCH resource indicator (PRI) that is offset by a second value dependent upon the identifier 310 of the terminal node 110. When the PUCCH resource index exceeds a maximum permissible value, an additional process is performed to determine a PUCCH resource for sending the uplink acknowledgement message 306. The determined resource is determined from a seed received within the received downlink reply message (MsgB) 304. For example, once the PUCCH resources are exhausted for one uplink slot, the MsgB 304 could indicate a new “seed” for the further contention resolution messages included in the same MsgB 304. This may include providing the first CCE index, first PUCCH resource indicator (PIR) and either new PDSCH-to-HARQ-timing-indicator or PUCCH resource index offset which are used by the next terminal node 110 indexed in the MsgB 304 and the terminal nodes 110 after that use the approaches described above. PUCCH resources offset r _offset would be summed on the PUCCH resource index r _offset determined by the approaches above to obtain actual PUCCH resource index.
In some but not necessarily all examples, the PUCCH resource index is dependent upon a first index value dependent upon the PUCCH resource indicator (PRI) that is offset by a second value dependent upon the identifier of the terminal node 110. When the PUCCH resource index exceeds a maximum permissible value, an additional process is performed to determine a PUCCH resource for sending the uplink acknowledgement message 306. The determined resource is determined by applying a modulo 16 operation to the PUCCH resource index. For example, after the PUCCH resource index space is exhausted for the initial PUCCH resource set (reaches 15) , the next terminal node 110 starts from PUCCH resource index r _PUCCH = 16. The PUCCH resource index is then incremented by one for each following terminal node 110 indexed in the MsgB 304.
When the PUCCH resource index is increased beyond the space of PUCCH resource set, the PRB index determination needs to be modified to ensure non-fragmented use of UL PRBs. The PRB index may e.g. be determined for r _PUCCH ＞ 15 by:
If
- the terminal node 110 determines the PRB index of the PUCCH transmission in the first hop as and the PRB index of the PUCCH transmission in the second hop as where N _CS is the total number of initial cyclic shift indexes in the set of initial cyclic shift indexes
- the terminal node 110 determines the initial cyclic shift index in the set of initial cyclic shift indexes as
If
- the terminal node 110 determines the PRB index of the PUCCH transmission in the first hop as and the PRB index of the PUCCH transmission in the second hop as
- the terminal node 110 determines the initial cyclic shift index in the set of initial cyclic shift indexes as
Fig 5A illustrates an example of a controller 500. Implementation of a controller 500 may be as controller circuitry. The controller 500 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) .
As illustrated in Fig 5A the controller 500 may be implemented using instructions that enable hardware functionality, for example, by using executable instructions of a computer program 506 in a general-purpose or special-purpose processor 502 that may be stored on a computer readable storage medium (disk, memory etc) to be executed by such a processor 502.
The processor 502 is configured to read from and write to the memory 504. The processor 502 may also comprise an output interface via which data and/or commands are output by the processor 502 and an input interface via which data and/or commands are input to the processor 502.
The memory 504 stores a computer program 506 comprising computer program instructions (computer program code) that controls the operation of the apparatus 110, 120 when loaded into the processor 502. The computer program instructions, of the computer program 506, provide the logic and routines that enables the apparatus to perform the methods illustrated in Figs 3 and 4. The processor 502 by reading the memory 504 is able to load and execute the computer program 506.
The apparatus 110 therefore comprises:
at least one processor 502; and
at least one memory 504 including computer program code
the at least one memory 504 and the computer program code configured to, with the at least one processor 502, cause the apparatus 110 at least to perform:
sending an uplink message (MsgA) in a two-step random access procedure; receiving a downlink reply message (MsgB) in the two-step random access procedure, the received downlink reply message comprising an identifier for the apparatus; and
sending an uplink acknowledgement message using a PUCCH resource determined by a PUCCH resource index wherein the PUCCH resource index is dependent upon, at least, a PUCCH resource indicator (PRI) and the identifier of the apparatus.
The apparatus 110 therefore comprises:
at least one processor 502; and
at least one memory 504 including computer program code
the at least one memory 504 and the computer program code configured to, with the at least one processor 502, cause the apparatus 110 at least to perform:
sending an uplink acknowledgement message, following a two-step random access procedure, using a PUCCH resource determined by a PUCCH resource index wherein the PUCCH resource index is dependent upon, at least, a PUCCH resource indicator (PRI) and the identifier of the apparatus.
As illustrated in Fig 5B, the computer program 506 may arrive at the apparatus 110, 120 via any suitable delivery mechanism 510. The delivery mechanism 510 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 506. The delivery mechanism may be a signal configured to reliably transfer the computer program 506. The apparatus 110, 120 may propagate or transmit the computer program 506 as a computer data signal.
Computer program instructions for causing an apparatus 110 to perform at least the following or for performing at least the following:
sending an uplink message (MsgA) in a two-step random access procedure;
receiving a downlink reply message (MsgB) in the two-step random access procedure, the received downlink reply message comprising an identifier for the apparatus; and
sending an uplink acknowledgement message using a PUCCH resource determined by a PUCCH resource index wherein the PUCCH resource index is dependent upon, at least, a PUCCH resource indicator (PRI) and the identifier of the apparatus.
The computer program instructions may be comprised in a computer program, a non-transitory computer readable medium, a computer program product, a machine readable medium. In some but not necessarily all examples, the computer program instructions may be distributed over more than one computer program.
Although the memory 504 is illustrated as a single component/circuitry it may be implemented as one or more separate components/circuitry some or all of which may be integrated/removable and/or may provide permanent/semi-permanent/dynamic/cached storage.
Although the processor 502 is illustrated as a single component/circuitry it may be implemented as one or more separate components/circuitry some or all of which may be integrated/removable. The processor 502 may be a single core or multi-core processor.
References to ‘computer-readable storage medium’ , ‘computer program product’ , ‘tangibly embodied computer program’ etc. or a ‘controller’ , ‘computer’ , ‘processor’ etc. should be understood to encompass not only computers having different architectures such as single/multi-processor architectures and sequential (Von Neumann) /parallel architectures but also specialized circuits such as field-programmable gate arrays (FPGA) , application specific circuits (ASIC) , signal processing devices and other processing circuitry. References to computer program, instructions, code etc. should be understood to encompass software for a programmable processor or firmware such as, for example, the programmable content of a hardware device whether instructions for a processor, or configuration settings for a fixed-function device, gate array or programmable logic device etc.
As used in this application, the term ‘circuitry’ may refer to one or more or all of the following:
(a) hardware-only circuitry implementations (such as implementations in only analog and/or digital circuitry) and
(b) combinations of hardware circuits and software, such as (as applicable) :
(i) a combination of analog and/or digital hardware circuit (s) with software/firmware and
(ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions and
(c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g. firmware) for operation, but the software may not be present when it is not needed for operation.
This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit for a mobile device or a similar integrated circuit in a server, a cellular network device, or other computing or network device.
The stages illustrated in the Figs 4 may represent steps in a method and/or sections of code in the computer program 506. 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.
Where a structural feature has been described, it may be replaced by means for performing one or more of the functions of the structural feature whether that function or those functions are explicitly or implicitly described.
From the foregoing it will be appreciated that in some examples there is provided a system comprising:
an apparatus comprising means for:
sending an uplink message (MsgA) in a two-step random access procedure; receiving a downlink reply message (MsgB) in the two-step random access procedure, the received downlink reply message comprising an identifier for the apparatus; and
sending an uplink acknowledgement message using a PUCCH resource determined by a PUCCH resource index wherein the PUCCH resource index is dependent upon, at least, a PUCCH resource indicator (PRI) and the identifier of the apparatus; and
an access node comprising means for:
receiving the uplink message (MsgA) in the two-step random access procedure;
sending the downlink reply message (MsgB) in the two-step random access procedure, the received downlink reply message comprising the identifier for the apparatus; and
receiving the uplink acknowledgement message.
In some but not necessarily all examples, the apparatus 110 is configured to communicate data from the apparatus 110 with or without local storage of the data in a memory 504 at the apparatus 110 and with or without local processing of the data by circuitry or processors at the apparatus 110.
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 shod 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 110 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 110 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.
The term ‘comprise’ is used in this document with an inclusive not an exclusive meaning. That is any reference to X comprising Y indicates that X may comprise only one Y or may comprise more than one Y. If it is intended to use ‘comprise’ with an exclusive meaning then it will be made clear in the context by referring to “comprising only one. ” or by using “consisting” .
In this description, reference has been made to various examples. The description of features or functions in relation to an example indicates that those features or functions are present in that example. The use of the term ‘example’ or ‘for example’ or ‘can’ or ‘may’ in the text denotes, whether explicitly stated or not, that such features or functions are present in at least the described example, whether described as an example or not, and that they can be, but are not necessarily, present in some of or all other examples. Thus ‘example’ , ‘for example’ , ‘can’ or ‘may’ refers to a particular instance in a class of examples. A property of the instance can be a property of only that instance or a property of the class or a property of a sub-class of the class that includes some but not all of the instances in the class. It is therefore implicitly disclosed that a feature described with reference to one example but not with reference to another example, can where possible be used in that other example as part of a working combination but does not necessarily have to be used in that other example.
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.
Features described in the preceding description may be used in combinations other than the combinations explicitly described above.
Although functions have been described with reference to certain features, those functions may be performable by other features whether described or not.
Although features have been described with reference to certain embodiments, those features may also be present in other embodiments whether described or not.
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.
The presence of a feature (or combination of features) in a claim is a reference to that feature or (combination of features) itself and also to features that achieve substantially the same technical effect (equivalent features) . The equivalent features include, for example, features that are variants and achieve substantially the same result in substantially the same way. The equivalent features include, for example, features that perform substantially the same function, in substantially the same way to achieve substantially the same result.
In this description, reference has been made to various examples using adjectives or adjectival phrases to describe characteristics of the examples. Such a description of a characteristic in relation to an example indicates that the characteristic is present in some examples exactly as described and is present in other examples substantially as described.
Whilst endeavoring in the foregoing specification to draw attention to those features believed to be of importance it should be understood that the Applicant may seek protection via the claims in respect of any patentable feature or combination of features hereinbefore referred to and/or shown in the drawings whether or not emphasis has been placed thereon.

Claims

An apparatus comprising means for:

sending an uplink message in a two-step random access procedure;

receiving a downlink reply message in the two-step random access procedure, the received downlink reply message comprising an identifier for the apparatus; and

sending an uplink acknowledgement message using a PUCCH resource determined by a PUCCH resource index wherein the PUCCH resource index is dependent upon, at least, a PUCCH resource indicator and the identifier of the apparatus.
An apparatus as claimed in claim 1, wherein the PUCCH resource indicator (PRI) is received from downlink control information (DCI) and/or from the downlink reply message (MsgB) .
An apparatus as claimed in claim 1 or 2, wherein the PUCCH resource index is dependent upon, at least, a PUCCH resource index suitable for four-step random access and the identifier of the apparatus, wherein the PUCCH resource index suitable for four-step random access is dependent upon the PUCCH resource indicator.
An apparatus as claimed in any preceding claim, wherein the PUCCH resource index is dependent upon the identifier of the apparatus because it is dependent upon an index position of the identifier of the apparatus in the received downlink reply message.
An apparatus as claimed in any one of claims 1 to 3, wherein the PUCCH resource index is dependent upon the identifier of the apparatus because it is dependent upon an offset associated with the identifier of the apparatus.
An apparatus as claimed in claim 5, wherein the offset is received from the received downlink reply message or from downlink control information (DCI) .
An apparatus as claimed in any preceding claim, wherein the PUCCH resources available for the uplinkacknowledgement message are indicated via received downlink control information (DCI) .
An apparatus as claimed in any preceding claim, wherein the PUCCH resource index is dependent upon a first index value dependent upon the PUCCH resource indicator (PRI) that is offset by a second value dependent upon the identifier of the apparatus.
An apparatus as claimed in claim 8, comprising means for, when the PUCCH resource index exceeds a maximum permissible value, performing an additional process to determine a PUCCH resource for sending the uplink acknowledgement message.
An apparatus as claimed in claim 9, wherein the determined resource is determined from a seed received within the received downlink reply message or wherein the determined resource is determined by applying a modulo operation to the PUCCH resource index.
An apparatus as claimed in any preceding claim, comprising means for receiving a further downlink reply message that specifies a new PUCCH resource indicator and/or a new slot for uplink acknowledgement message.
An apparatus as claimed in any preceding claim, wherein when the PUCCH resource index exceeds a maximum permissible value, it is reset to a minimum permissible value.
An apparatus as claimed in any preceding claim, wherein the uplink acknowledgement message is sent in a time slot determined by an indicator received via downlink control information or in the received downlink reply message.
Computer program instructions for causing an apparatus to perform at least the following or for performing at least the following:

sending an uplink message in a two-step random access procedure;

receiving a downlink reply message in the two-step random access procedure, the received downlink reply message comprising an identifier for the apparatus; and

sending an uplink acknowledgement message using a PUCCH resource determined by a PUCCH resource index wherein the PUCCH resource index is dependent upon, at least, a PUCCH resource indicator and the identifier of the apparatus.
A method comprising:

sending an uplink message in a two-step random access procedure;

receiving a downlink reply message in the two-step random access procedure, the received downlink reply message comprising an identifier for the apparatus; and

sending an uplink acknowledgement message using a PUCCH resource determined by a PUCCH resource index wherein the PUCCH resource index is dependent upon, at least, a PUCCH resource indicator and the identifier of the apparatus.