REDUCING CONTENTION BY IMPROVING THE IDENTIFICATION OF THE TARGET OF A RESPONSE SIGNAL
20230107781 · 2023-04-06
Assignee
Inventors
Cpc classification
H04W56/0045
ELECTRICITY
International classification
Abstract
An apparatus, method and computer program for aiding identification of a target of a response to a request. The apparatus comprises means for generating the request. Means for determining a timing advance to be applied to a predetermined time of transmission of the request in order for the request to reach a destination at the predetermined time. Means for transmitting the request signal towards the to destination. Means for receiving a response, the response comprising a timing advance indication, the timing advance indication indicating a difference in time between receipt of the request signal and the predetermined time. Means for determining from the timing advance indication and the determined timing advance whether the received response is a response to the request.
Claims
1. An apparatus comprising: circuitry configured to generate a request; circuitry configured to determine a timing advance to be applied to a predetermined time of transmission of said request in order for said request to reach a destination at said predetermined time; circuitry configured to determine an expected time delay for transmission of said request signal to said destination said timing advance being determined in dependence upon said expected time delay; a transmitter configured to transmit said request signal towards said destination; circuitry configured to provide a timing offset; said transmitter being configured to transmit said request signal with said timing offset; and a receiver configured to receive a response from said destination, said response comprising a timing advance indication, said timing advance indication indicating a difference in time between receipt of said request signal and said predetermined time; circuitry configured to determine whether said received response is a response to said request from said timing advance indication, said timing offset and said determined timing advance.
2. (canceled)
3. An apparatus according to claim 1, wherein said circuitry configured to provide said timing offset comprises circuitry configured to selecting one of a plurality of predetermined timing offsets.
4. An apparatus according to claim 1, further comprising circuitry configured to add said timing offset to said timing advance to generate an updated timing advance; said transmitter being configured to transmit said request with said updated timing advance; said circuitry configured to determine whether said received response is said response to said request is configured to determine whether said selected timing offset and said indication of said timing advance differ by less than a predetermined amount.
5. An apparatus according to claim 4, wherein said predetermined amount is an acceptable error in determining said expected time delay.
6. An apparatus according to claim 3, wherein each of said plurality of predetermined timing offsets are less than a time period during which said request can be correctly received at said destination.
7. An apparatus according to claim 3, wherein said plurality of timing offsets includes no offset, that is a timing offset of 0 seconds.
8. An apparatus according to c claim 3, comprising circuitry configured to store said plurality of predetermined timing offsets.
9. An apparatus according to claim 3, comprising a receiver configured to receive said plurality of predetermined timing offsets.
10. An apparatus according to claim 1, wherein said circuitry configured to provide is configured to determine where a collision is unlikely and to select to apply no timing offset to said timing advance.
11. (canceled)
12. An apparatus according to claim 1, wherein said request comprises a connection request and said response comprises a connection response.
13. An apparatus according to claim 1, wherein the circuitry comprise: at least one processor; and at least one memory including computer program code, the at least one memory and computer program code being configured to, with the at least one processor, cause the performance of the apparatus.
14. A method comprising: generating a request; determining an expected time delay for transmission of said request to a destination; determining a timing advance required for said request to reach a destination at a predetermined time, said timing advance being determined in dependence upon said expected time delay; providing a timing offset; outputting said request for transmission towards said destination with said timing offset; in response to receiving a response, said response comprising a timing advance indicator, said timing advance indicator indicating a difference in time between receipt of said request at said destination and said predetermined time, determining whether said received response is a response to said request in dependence upon said timing advance indicator, said timing offset and said determined timing advance.
15. A non-transitory computer readable medium comprising program instructions which when executed by a processor on a user equipment cause said user equipment to perform a method according to claim 14.
16. An apparatus according to claim 1, wherein said apparatus comprises a user equipment.
17. A method according to claim 14, wherein said providing an offset comprises selecting one of a plurality of predetermined timing offsets.
18. A method according to claim 14, the method further comprising adding said timing offset to said timing advance to generate an updated timing advance; said transmitting said request comprises transmitting said request with said updated timing advance to said destination; and said determining whether said received response is said response to said request comprises determining whether said timing offset and said indication of said timing advance differ by less than a predetermined amount.
19. A method according to claim 17, the method further comprising an initial determining whether a collision is unlikely and said selecting comprises selecting to apply no timing offset to said timing advance where it is determined that a collision is unlikely.
20. A method according to claim 14, wherein the determining said timing advance comprises: determining an expected time delay for transmission of said request signal to the destination.
21. An apparatus comprising: at least one processor; and at least one memory storing instructions that when executed by the at least one processor cause the apparatus at least to perform: generating a connection request; determining a timing advance to be applied to a predetermined time of transmission of said connection request in order for said connection request to reach a destination at said predetermined time; determining an expected time delay for transmission of said request signal to said destination, said timing advance being determined in dependence upon said expected time delay; providing a timing offset; transmitting said connection request signal towards said destination with said timing offset; receiving a response from said destination, said response comprising a timing advance indication, said timing advance indication indicating a difference in time between receipt of said connection request and said predetermined time; determining from said timing advance indication, said timing offset and said determined timing advance whether said received response is a response to said connection request.
22. An apparatus according to claim 21, wherein said providing said timing offset comprises selecting one of a plurality of predetermined timing offsets.
Description
BRIEF DESCRIPTION
[0047] Some example embodiments will now be described with reference to the accompanying drawings in which:
[0048]
[0049]
[0050]
[0051]
[0052]
DETAILED DESCRIPTION
[0053] Before discussing the example embodiments in any more detail, first an overview will be provided.
[0054] Example embodiments may be used in cases where UEs are capable of estimating with high precision the delay of their signals to a network node. Examples include industrial settings where the network node is an access point or in the field of Non-Terrestrial Networks (NTN), more specifically, the field of using satellite links to provide cellular communication to UEs in remote areas, in disaster zones or over the sea.
[0055] Looking at the NTN example, there are several types of satellite deployments that can be considered. For the scope of this application the most important definitions are: [0056] Satellite Altitude: [0057] GEO (Geostationary Earth Orbits): Located at approximately 36000 km from Earth, above the equator, the orbit period of this satellite is equivalent to one astronomical day. Therefore, the satellite is static from the point of view of one user on Earth. [0058] LEO (Low Earth Orbits): Located at heights between 300 and 1500 km above Earth. They may be deployed in different orbit inclinations and orientations around Earth, and travel and significant speeds (approximately 7500 m/s at 600 Kms) and have a very high relative speed from an observer on Earth. [0059] Architecture: [0060] Regenerative: In this architecture, at least the lower layers are implemented at the hardware located in the satellite, meaning that some central functions deployed by the gNb are deployed at the satellite (scheduling, retransmissions, random access response). [0061] Transparent: In the transparent architecture, the satellite hardware acts simply as a repeater (or frequency converter) for the gNb located on the ground . In this case the latency of the scheduling algorithms are approximately twice as high as in the case before.
[0062] The GEO satellites have been around for decades are mostly used for low throughput applications. Recent technical developments have made the LEO deployments significantly more attractive for new medium and high throughput applications using satellites. Several private companies are endeavouring to provide communication solutions using LEO systems.
[0063] Compared to legacy 3GPP systems, there are challenges to be addressed in order to provide NTN coverage in a system natively designed to provide terrestrial coverage.
[0064] Namely: [0065] Ultra high speeds: The relative speed between a LEO satellite and a UE on the ground is on the range of .sub.7 km/s, which is much higher than anything previously studied for 3GPP deployments. It affects the frequency synchronization, channel model, handover rate, etc. [0066] Very high latency: the propagation delay of the signal in the case of transparent scenario can be as high 500 ms in case of a GEO satellite (and about 40 ms in case of LEO).
[0067] In current 3GPP release 17 work item on Non Terrestrial Networks (NTN), several agreements were made respective to the long delays experienced by the UE due to the large distances to the satellite (above the limits that can be simply corrected via 5G NR common signalling due to UE-satellite distances being at least 600 km). Other agreements also were made in support of corrective frequency doppler measures, introduced due to high satellite speeds.
[0068] Among Such Agreements:
[0069] Agreement: (RAN1#102e) [0070] In Rel-17 NR NTN, at least support UE which can derive based on its GNSS implementation one or more of: [0071] its position [0072] a reference time and frequency [0073] And, based on one or more of these elements together with additional information (e.g., serving satellite ephemeris or timestamp) signalled by the network, can compute timing and frequency, and apply timing advance and frequency adjustment at least for UE in RRC idle/inactive mode.
[0074] There is growing interest in 3GPP to introduce solutions for reducing latency in NTN communications. The reasons are twofold. First, the RTT delays in NTN are already very large (from dozens of ms in LEO deployments to up to 500 ms in GEO), and each extra step in signalling or radio control exchange represents significant additional latency for the payload transmission. Secondly, NTNs are expected to provide coverage in under-served and/or remote areas, and if UEs require a larger time to execute simple procedures, they will spend extra energy that may be a scarce resource.
[0075] Example embodiments make use of the idea that both a UE and network node may independently determine a timing advance required to compensate for the round trip time delay in transmitting the signals and that this independent determination can be used to help identify whether a response is the expected response to a transmitted request or is a response to a request from another device. In this regard the inventors recognised that where a user equipment has means to accurately determine the expected round trip time delay of signals between it and a network node and the network node provides an indication of the timing advance required for a received signal in its response then a comparison of the two may indicate if the response is directed at that user equipment or at another device. Thus, embodiments compare the UE determined timing advance with the network node indicated timing advance to determine whether the response is a response to the request sent by the user equipment, or whether the timing advance indicated does not correlate with the estimated timing advance and thus, it is likely not to be the expected response and should be disregarded.
[0076] In example embodiments, the UE determines the expected time delay and performs time pre-compensation using the information available (satellite ephemeris, cell broadcast, GNSS, etc). The UE, as agreed in 3GPP, calculates the timing advance to compensate the RTT (round trip time). Ideally this will lead to perfect pre-compensation, meaning that the timing advance command (TAC) in msg 2—the response is zero or at least very close to zero.
[0077] In some cases the user equipment may apply a particular offset in some cases in addition to its determined timing advance to the request signal and then compare the indicated timing advance in a received response with the particular offset applied and the determined timing advance to determine whether the response is a response to its request or not. In some embodiments, the offset that is applied may be selected from a plurality of predetermined offsets perhaps stored on the UE, while in others it may be a value generated by a random number generator that is configured to generate values within a predefined range. Where a set of UEs each select a different particular offset perhaps from a set of offset values, then this may allow an individual UE to more accurately differentiate between the responses using the indicated timing advances.
[0078] Embodiments seek to address the problem of contention resolution, particularly in the initial access (from idle to connected mode). When the UE, initially in idle mode, has detected incoming data on the buffer to be transmitted on UL, or when the UE receives a paging from the eNb, the UE must initiate the connected mode. For that, the UE sends a Random Access Preamble towards the eNb, as depicted in
[0079] After the UE sends the message 1, it will wait for the message 2 (Random Access Response). The RAR contains the synchronization and identity information of the UE to be used towards the eNb, It also contains the scheduling information for the subsequent transmission of message 3, as depicted in
[0080] In this case these UEs may act as destructive interference, causing none of them to succeed in sending Msg 3. Or just one UE will be able to get Msg 3 through, but this will be only clear after the reception of Msg 4. The “failing” UEs will only discover the RACH attempt failed after 4 messages, before a new attempt is made. In the case of a GEO scenario, this may add up to more than 2 seconds.
[0081] In example embodiments, the UE chooses a random value for an offset delay to be added on top of the timing pre-compensation before sending MSG.sub.1 (the request). This may be the expected timing advance “mismatch” between UE and gNB, which will be detected by the gNB and informed back to UE via RAR (random access response). Upon receiving the random access response, with a valid RAPID (random access preamble identifier), the UE reads the TA (timing advance) field (see
[0082] In example embodiments UEs capable of performing very refined TA pre-compensation, will add a “manageable and known” offset to this compensation, in order to check the validity of the gNB TA response. The goal is comparing the TA command provided by the gNB in the RAR with the RAPID associated to the UE with the expected value of timing advance determined by that UE.
[0083] The principle of an example embodiment is presented in the flowchart in
[0084] At step 1 the UE calculates the time advance pre compensation (TAest) at a refined level by estimating the RTT (using ephemeris, broadcast, GNSS, etc).
[0085] At step 2 the UE estimates the potential error e in the timing advance estimation from a difference between TAest and the real timing advance (TAreal). This difference may come from different sources, i.e. from potential inaccuracies and movements between the elapsed time for the exchange of messages in initial access. The difference depends on certain parameters such as how often information like the satellite ephemeris, and GNSS is checked, other error sources and the steps size of the TA may also be factors. In some embodiments the UE may obtain a value for ϵ from a lookup table where a value is retrieved based on the current value of the parameters that affect the value of minimum value of ϵ.
[0086] In some embodiments the network (RAN) may specify a minimum value for this difference ϵ.
[0087] At step 3 the UE chooses an offset delay, κ, to be added to the timing advance information. This offset is better chosen if it falls in a range where the later residual TA provided in the TA command cannot be entirely attributed to the inaccuracy of the initial estimation, therefore the suggested (optional) rule: κ−ϵ≤TAest+κ−TAreal≤: κ+ϵ. The offset delay may be a random value or it may be selected from a set of values that are supplied to the UE by the network.
[0088] Note: The value of κ may be negative and the principle of the idea is still maintained Note: The value of κ is better chosen to ensure the delay does not exceed the cyclic prefix in the gNB, that is the time delay is within a time period during which the request can be correctly received at said destination. In some embodiments, the network, in some cases the RAN, may specify a range of values or a set of predefined values for k that the UE can choose from.
[0089] At step 4 the UE sends a preamble, associated with a RAPID (random access preamble ID), but instead of using the full compensated TAest, the UE uses the offset value TAest+κ as the timing advance.
[0090] At step 5, The UE scans for RAR with the same RAPID.
[0091] At step 6 the UE reads the TA command (TAc) in the RAR associated with the same RAPID. That is the timing advance indicated by the network node.
[0092] At step 7 it is determined if the TAc in the RAR is reasonable as a response for its initial transmission. In the example, if the TA command magnitude satisfies: κ−ϵ≤TAc≤κα+ϵ.
[0093] If the condition is satisfied then the method proceeds to step 8 and the UE completes the RA procedure and sends Message 3. Potential contention is further resolved in Message 4, as per legacy procedure.
[0094] If the UE detects this message is not within the expected timing range, the UE proceeds to step 9 and stops the procedure and goes directly for a new RA attempts (2 message exchanges are saved on top of further interference caused in Message 3 transmission)
[0095] Note: The differential TA associated to the movement of the satellite and the UE in the elapsed time between Msg1 (RA preamble) and Msg 2 (RAR) may be used by the UE algorithm to be discounted from TAc in the formula above
[0096] As the precision of the algorithm is expected to be high, the offset value, κ, may be of the order of microseconds. Even for very strict preamble formats, with very short cyclic prefixes, there may still have the opportunity to add this offset delay to the preamble transmission. [0097] The larger the preamble's cyclic prefix, the more values of κ can be chosen, increasing even more the collision avoidance. [0098] Even in strict scenarios, where only one value of κ (that is not zero) is feasible, the UE will have two choices, “applying or not the delay offset”. And this will increase the collision avoidance significantly.
[0099] For example, in a scenario with 1% probability of collision in RA from different UEs, with 32 preambles, by artificially creating two more options of transmission (with and without delay offset), the collision probability is almost halved, with the additional advantage that most collisions will be more quickly detected by UEs that have the capabilities to use this feature, saving time and energy.
[0100] Although the above example was with respect to NTN example embodiments are not restricted to NTN. In industrial settings (Industry 4.0), there are many scenarios where the UEs are capable of estimating with high precision their delay to the access point, either because of high synchronization of devices, using the access point as a master clock or because the static nature of some industrial settings over time. In this cases, in a context of several RA attempts per second such as an industrial settings, this solution provides one more possibility to reduce contention in the random access.
[0101] Embodiments provide a gain when multiple UEs access the system at the same time with the same preamble the gain depends on the load (number of random access attempts in a cell), the invention can be configured to only be used when the load is high by RAN. In this regard there may be an initial step in the method of
[0102]
[0103] There is also selecting circuitry 20 for selecting one of a plurality of timing offsets that are stored in data store 30. These timing offsets may have been received from the network.
[0104] Where the UE 5 is to transmit a request such as a connection request to the network node 105 and it is determined by the network that the load is high and that contention may arise, the UE 5 may be configured to apply the contention reduction technique of embodiments. In this case UE 5 will estimate a timing advance using circuitry 50 and select a timing offset using selecting circuitry 20 and apply a timing advance based on the estimated timing advance plus the selected offset to the request at the transmitting circuitry 10 when transmitting the request towards the network node 105.
[0105] A response is received at receiving circuitry 12 and if it has an ID corresponding to the UE, determining circuitry 4o that may be in the form of a comparator will compare the timing advance supplied by the network node and indicated in the received response with the timing advance that was applied to the request prior to transmission. If the timing advance indicated is the same or similar to the timing advance applied by the transmitting circuitry 10, then circuitry 40 determines that the response is directed to UE 5 and the UE proceeds to respond to the response. If the timing advance indicated is different to the timing advance that was applied by more than a predetermined amount, then UE 5 determines that the received signal was not a response to its request and discards the signal.
[0106] It should be noted that the circuitry for estimating a timing advance 50, the circuitry for selecting a timing offset 20 and the circuitry for comparing the timing advances 40 may be processing circuitry configured either by hardware or software to perform these functions.
[0107]
[0108] In this embodiment at step S20, the UE generates a request and at step S30 it estimates a timing delay for transmission of the request to the destination node. At step S40 the UE transmits the request with a timing advance based on the calculated timing delay towards the destination. At step S50 a response is received and this response has a timing advance indicator associated with it. If at D5 it is determined that the current network load is high and the contention reduction technique should be employed, then the UE determines at step D15 the difference between the applied timing advance and the indicated timing advance and if it is less than a certain value it determines that the response is directed to this UE and responds at step S70. If it is not less than this value then the UE discards the response at step S60. Where the network has not indicated a high loading then the UE simply proceeds to step S70 and responds to the response.
[0109] A person of skill in the art would readily recognize that steps of various above-described methods can be performed by programmed computers. Herein, some embodiments are also intended to cover program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of said above-described methods. The program storage devices may be, e.g., digital memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media. The embodiments are also intended to cover computers programmed to perform said steps of the above-described methods.
[0110] As used in this application, the term “circuitry” may refer to one or more or all of the following: [0111] (a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and [0112] (b) combinations of hardware circuits and software, such as (as applicable): [0113] (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and [0114] (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 [0115] (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.
[0116] 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 (or multiple processors) or portion of 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 or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
[0117] Although embodiments of the present invention 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 invention as claimed.
[0118] Features described in the preceding description may be used in combinations other than the combinations explicitly described.
[0119] Although functions have been described with reference to certain features, those functions may be performable by other features whether described or not.
[0120] Although features have been described with reference to certain embodiments, those features may also be present in other embodiments whether described or not.
[0121] Whilst endeavouring in the foregoing specification to draw attention to those features of the invention believed to be of particular importance it should be understood that the Applicant claims protection in respect of any patentable feature or combination of features hereinbefore referred to and/or shown in the drawings whether or not particular emphasis has been placed thereon.