WO2023039879A1

WO2023039879A1 - Rach enhancement for ue without gnss in ntn iot

Info

Publication number: WO2023039879A1
Application number: PCT/CN2021/119326
Authority: WO
Inventors: Zhi YAN; Hongmei Liu; Yuantao Zhang; Haiming Wang
Original assignee: Lenovo (Beijing) Limited
Priority date: 2021-09-18
Filing date: 2021-09-18
Publication date: 2023-03-23

Abstract

Methods and apparatuses for RACH procedure for UE without GNSS are disclosed. A method comprises receiving one or more reference position candidates, wherein each reference position candidate includes a position coordinate.

Description

RACH ENHANCEMENT FOR UE WITHOUT GNSS IN NTN IOT

FIELD

The subject matter disclosed herein generally relates to wireless communications, and more particularly relates to methods and apparatuses for RACH procedure for UE without GNSS in NTN IoT.

BACKGROUND

The following abbreviations are herewith defined, at least some of which are referred to within the following description: New Radio (NR) , Very Large Scale Integration (VLSI) , Random Access Memory (RAM) , Read-Only Memory (ROM) , Erasable Programmable Read-Only Memory (EPROM or Flash Memory) , Compact Disc Read-Only Memory (CD-ROM) , Local Area Network (LAN) , Wide Area Network (WAN) , User Equipment (UE) , Evolved Node B (eNB) , Next Generation Node B (gNB) , Uplink (UL) , Downlink (DL) , Central Processing Unit (CPU) , Graphics Processing Unit (GPU) , Field Programmable Gate Array (FPGA) , Orthogonal Frequency Division Multiplexing (OFDM) , Radio Resource Control (RRC) , User Entity/Equipment (Mobile Terminal) (UE) , non-terrestrial networks (NTN) , terrestrial network (TN) , timing advance (TA) , timing offset (TO) , Machine-Type Communication (MTC) , enhanced MTC (eMTC) , Internet-of-Things (IoT) , Narrowband (NB) , Narrowband Internet-of-Things (NB-IoT or NBIoT) , receiver and transmitter distance (RTD) , reference point (RP) , Global Navigation Satellite System (GNSS) , Random Access Channel (RACH) , Physical Random Access Channel (PRACH) , NB-IoT PRACH (NB-PRACH, NPRACH) , Physical Uplink Shared Channel (PUSCH) , NB-IoT PUSCH (NB-PUSCH, NPUSCH) , Downlink control information (DCI) , Low Earth Orbit (LEO) , Cyclic Prefix (CP) , Frequency Division Duplex (FDD) , Earth-Centered, Earth-Fixed (ECEF) , World Geodetic System (WGS) , Reference Signal Receiving Power (RSRP) , light of sight (LOS) .

A non-terrestrial network (NTN) is a network in which a non-terrestrial element (e.g. satellite) is involved. Depending on whether the base station (e.g. eNB that is used in scenario of eMTC or NBIoT, or gNB that is used in scenario of NR) is located on the satellite, the non-terrestrial network (NTN) has two cases: for regenerative payload and for bent-pipe payload. In case of regenerative payload, the base station is located on the satellite. In case of bent-pipe payload, the base station (e.g. eNB or gNB) is located in a terrestrial place while the satellite serves as a relay point between the UE and the base station.

Figures 1 and 2 illustrate two different situations for bent-pipe payload.

It can be seen from Figure 1 that, d0 is a distance (e.g. receiver and transmitter distance (RTD) ) between the satellite (SAT) and the base station (gNB) where a reference point (RP) is located at the base station; d1 is a distance between the satellite and the UE. The propagation delay between the satellite and the base station (gNB) , that is common to all UEs in the range of the satellite, is d0/c = T_0 (which can be referred to as common propagation delay) , in which c is the speed of light. The propagation delay between the satellite and the UE, that is specific to each UE in the range of the satellite, is d1/c = T_1 (which can be referred to as UE-specific propagation delay) . The timing advance (TA) is twice the value of the propagation delay (or the propagation delay is half of the TA) . The timing advance (TA) can be also referred to as timing offset (TO) . In the following description, TA (timing advance) is used. The TA for bent-pipe payload is 2*T_0 + 2*T_1, in which 2*T_0 is common TA (which is common to all UEs) , and 2*T_1 is UE-specific TA (which is specific to each UE) . Therefore, the TA (or whole TA) for bent-pipe payload is equal to the sum of common TA and UE-specific TA. That is, TA (or whole TA) = common TA + UE-specific TA = 2*T_0 + 2*T_1.

Figure 2 illustrates another example of the common TA and the UE-specific TA in NTN for bent-pipe payload. Figure 2 differs from Figure 1 only in that the reference point (RP) is not located at the base station (gNB in Figure 2) , but can be located in a middle place between the base station (gNB) and the satellite. The location of the reference point (RP) is predetermined (which means that it is known to the base station) . According to Figure 2, T_0 is determined according to the distance between the reference point (RP) and the satellite. That is, in Figure 2, d0 is the distance between the satellite and the reference point (RP) , and T_0 is the propagation delay between the satellite and the reference point (RP) .

As illustrated in Figure 2, the common TA is determined by T_0 (i.e. common TA = 2*T_0) , which is determined by the distance (e.g. RTD) between the satellite and the reference point (RP) , which is common to all UEs within the coverage of the satellite. The UE-specific TA is determined by T_1 (i.e. UE-specific TA = 2*T_1) , which is determined by the distance (e.g. RTD) between the satellite and the UE, which is specific to each UE within the coverage of the satellite.

In the example of Figure 1, the TA (= common TA + UE-specific TA) reflects the round trip delay between the base station (gNB) and the UE, in which the common TA reflects the round trip delay between the base station (gNB) and the satellite (one way delay between the base station and the satellite can be referred to as ‘feeder link delay’ ) , and the UE-specific TA reflects the round trip delay between the satellite and the UE (one way delay between the satellite and UE can be referred to as ‘service link delay’ ) .

On the other hand, in the example of Figure 2, the TA (= common TA + UE-specific TA) reflects the round trip delay between the reference point (RP) and the UE, i.e. it does not reflect the round trip delay between the base station and the UE. In particular, the common TA reflects only part of the round trip delay between the base station and the UE. The round trip delay between the reference point and the base station will be handled by the base station.

As a whole, the common TA is determined by the distance between a reference point (such as at the base station (gNB) in Figure 1, or at a predetermined location in Figure 2) and the satellite, which in turn is determined by the position of the reference point and the position of the satellite. The UE-specific TA is determined by the distance between the satellite and the UE, which in turn is determined by the position of the satellite and the position of the UE.

The position of the reference point (such as at the base station (gNB) ) is basically predetermined and known to the base station. The position of the satellite is always changing. However, the position of the satellite at any specific time point is known to (or can be calculated by) the base station, depending on satellite ephemeris information. Therefore, with the position of the satellite and the location of the reference point, the common TA at any time point is known to (or can be calculated by) the base station. The common TA can be broadcasted to all UEs by the base station. For example, the base station may broadcast an initial common TA, and optionally indicate a common TA drift rate. Accordingly, the UE can calculate the common TA at any time based on the initial common TA and the common TA drift rate.

The position of a UE can be known by the UE itself, if the UE assumingly has GNSS capability (e.g. the UE has a GNSS module) . The position of the UE can be acquired based on the GNSS module of the UE.

A random access channel (RACH) procedure in NTN in NR Release 17 includes 4 steps as illustrated in Figure 3. In step 1, when UE has location information (e.g. obtained by its GNSS module) and satellite position and moving information (e.g. satellite ephemeris information) , the UE can estimate distance of the UE and the satellite or UE-specific TA. The common TA is broadcast from the base station (eNB or gNB) . So, the UE can estimate the TA (or whole TA) , which is used to adjust the uplink frame timing relative to the downlink frame timing, according to the UE-specific TA and the common TA (i.e. TA (or whole TA) = common TA + UE-specific TA) . Then, the UE transmits Msg1 (i.e. random access preamble) to gNB by applying the estimated TA. In step 2, the UE monitors Msg2 (i.e. random access response, which is the response to Msg1) transmitted from the gNB. Msg2 includes the message of TA command, which is used for UE to correct the TA. Msg2 is also used to schedule Msg3 transmitted by the UE. According to the receiving of Msg2, the UE can make correction of TA based on the TA command (e.g. correction of the estimated TA) . In step 3, the UE transmits Msg3 by applying the corrected TA. In addition, TA (or only UE-specific TA or differential TA to last TA or differential TA to a reference TA) may be included in Msg3. In step 4, the gNB receives Msg3 and derives TA (or only UE-specific TA or differential TA to last TA or differential TA to a reference TA) information, and then transmits Msg4 (response to Msg3) to the UE.

In NR Release 18, low cost IoT devices without GNSS capability (e.g. without GNSS module) are proposed in order to improve UE energy efficiency and reduce dependency on GNSS service availability. A UE without GNSS capability (e.g. without GNSS module) cannot acquire its own position. Accordingly, the UE without GNSS capability cannot determine UE-specific TA, and cannot apply the estimated TA in step 1 of Figure 3.

This invention targets RACH enhancement for UE without GNSS capability in NTN IoT.

BRIEF SUMMARY

Methods and apparatuses for RACH procedure for UE without GNSS are disclosed.

In one embodiment, a method comprises receiving one or more reference position candidates, wherein each reference position candidate includes a position coordinate. The position coordinate is one of position coordinate in ECEF, position coordinate in WGS, and position coordinate in other systems.

In one embodiment, the method may further comprise determining a reference position from the one or more reference position candidates based on a random selection manner, or based on a last reference position or any physical neighboring reference position of the last reference position before the UE goes to idle mode.

In some embodiment, the method may further comprise receiving a reference position indication. Preferably, the method may further comprise determining a reference position from the one or more reference position candidates based on the reference position indication.

In some embodiment, the method may further comprise receiving one or more measurement thresholds for each reference position candidate. Preferably, the method may further comprise determining a reference position from the one or more reference position candidates based on an estimated RSRP and the measurement thresholds.

The method may further comprise, based on the reference position and satellite ephemeris information, determining a time offset adjustment and a frequency offset adjustment.

In some embodiment, the method may further comprise receiving at least one of a preamble set and a RACH resource set for each reference position candidate; and transmitting a preamble from the preamble set on a RACH resource from the RACH resource set for a reference position candidate determined as reference position.

In some embodiment, the method may further comprise receiving a maximal number of preamble attempts for each reference position candidate. Preferably, the method may further comprise performing preamble transmission up to the maximal number of preamble attempts for a reference position candidate determined as reference position.

In another embodiment, a method comprises transmitting one or more reference position candidates, wherein each reference position candidate includes a position coordinate

In yet another embodiment, a remote unit comprises a receiver that receives one or more reference position candidates, wherein each reference position candidate includes a position coordinate.

In other embodiment, a base unit comprises a transmitter that transmits one or more reference position candidates, wherein each reference position candidate includes a position coordinate.

BRIEF DESCRIPTION OF THE DRAWINGS

A more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only some embodiments, and are not therefore to be considered to be limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

Figures 1 and 2 illustrate the concept of the common TA and the UE-specific TA in NTN;

Figure 3 illustrates a legacy random access procedure;

Figure 4 illustrates an example of uplink transmission gap;

Figure 5 illustrates the preamble set and the RACH resource set shared by four reference position candidates;

Figure 6 illustrates the preamble set and the RACH resource set for each reference position candidate;

Figure 7 is a schematic flow chart diagram illustrating an embodiment of a method;

Figure 8 is a schematic flow chart diagram illustrating an embodiment of a method; and

Figure 9 is a schematic block diagram illustrating apparatuses according to one embodiment.

DETAILED DESCRIPTION

As will be appreciated by one skilled in the art that certain aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc. ) or an embodiment combining software and hardware aspects that may generally all be referred to herein as a “circuit” , “module” or “system” . Furthermore, embodiments may take the form of a program product embodied in one or more computer readable storage devices storing machine-readable code, computer readable code, and/or program code, referred to hereafter as “code” . The storage devices may be tangible, non-transitory, and/or non-transmission. The storage devices may not embody signals. In a certain embodiment, the storage devices only employ signals for accessing code.

Certain functional units described in this specification may be labeled as “modules” , in order to more particularly emphasize their independent implementation. For example, a module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

Modules may also be implemented in code and/or software for execution by various types of processors. An identified module of code may, for instance, include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but, may include disparate instructions stored in different locations which, when joined logically together, include the module and achieve the stated purpose for the module.

Indeed, a module of code may contain a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules and may be embodied in any suitable form and organized within any suitable type of data structure. This operational data may be collected as a single data set, or may be distributed over different locations including over different computer readable storage devices. Where a module or portions of a module are implemented in software, the software portions are stored on one or more computer readable storage devices.

Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing code. The storage device may be, for example, but need not necessarily be, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

A non-exhaustive list of more specific examples of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, random access memory (RAM) , read-only memory (ROM) , erasable programmable read-only memory (EPROM or Flash Memory) , portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

Code for carrying out operations for embodiments may include any number of lines and may be written in any combination of one or more programming languages including an object-oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the "C"programming language, or the like, and/or machine languages such as assembly languages. The code may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the very last scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN) , or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) .

Reference throughout this specification to “one embodiment” , “an embodiment” , or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in one embodiment” , “in an embodiment” , and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment, but mean “one or more but not all embodiments” unless expressly specified otherwise. The terms “including” , “comprising” , “having” , and variations thereof mean “including but are not limited to” , unless otherwise expressly specified. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, otherwise unless expressly specified. The terms “a” , “an” , and “the” also refer to “one or more” unless otherwise expressly specified.

Furthermore, described features, structures, or characteristics of various embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however, that embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid any obscuring of aspects of an embodiment.

Aspects of different embodiments are described below with reference to schematic flowchart diagrams and/or schematic block diagrams of methods, apparatuses, systems, and program products according to embodiments. It will be understood that each block of the schematic flowchart diagrams and/or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which are executed via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the schematic flowchart diagrams and/or schematic block diagrams for the block or blocks.

The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices, to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function specified in the schematic flowchart diagrams and/or schematic block diagrams block or blocks.

The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices, to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the code executed on the computer or other programmable apparatus provides processes for implementing the functions specified in the flowchart and/or block diagram block or blocks.

The schematic flowchart diagrams and/or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods and program products according to various embodiments. In this regard, each block in the schematic flowchart diagrams and/or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function (s) .

It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may substantially be executed concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, to the illustrated Figures.

Although various arrow types and line types may be employed in the flowchart and/or block diagrams, they are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted embodiment. It will also be noted that each block of the block diagrams and/or flowchart diagrams, and combinations of blocks in the block diagrams and/or flowchart diagrams, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and code.

The description of elements in each Figure may refer to elements of proceeding figures. Like numbers refer to like elements in all figures, including alternate embodiments of like elements.

As mentioned in the background part, if a UE (e.g. IoT device) does not have GNSS capability (e.g. not including a GNSS module) , the UE is not able to determine its position, and accordingly is not able to estimate the TA (e.g. UE-specific TA) .

In NB-IoT Release 16, for NPUSCH, when a coded data is transmitted from the remote unit (e.g. UE) to the base unit (e.g. eNB) , it is mapped to one or more resource units (N _RU) , each of which is transmitted by a number of times (i.e. repetitions) (N _Rep) .

Table 1 indicates the number of resource units (N _RU) being determined by the resource assignment (I _RU) for NPUSCH. The resource assignment (I _RU) is indicated with 3 bits by the corresponding control signal (e.g., DCI format N0) . The resource unit for NPUSCH is determined by the subcarrier spacing of the NPUSCH data.

Table 1

Table 2 indicates the repetition number (N _Rep) being determined by repetition number index (I _Rep) for NPUSCH. The repetition number index (I _Rep) for NPUSCH is indicated with 3 bits by the corresponding control signal (e.g., DCI format N0) .

Table 2

The subcarriers to be used for NPUSCH data transmission are different for different subcarrier spacings. For subcarrier spacing of 3.75KHz, only single-tone

is supported. For subcarrier spacing of 15KHz, both single-tone and multiple-tone are supported. One or three or six or twelve of twelve subcarriers (

or 3 or 6 or 12) is used within one NBIoT carrier.

In scenario of converge enhancement for NB-IoT, a total duration of a PUSCH transmission may span tens of seconds. Table 3 indicates the maximum total durations of PUSCH transmissions. It can be seen that a PUSCH transmission can span up to 40s.

Table 3

For NTN network, the satellite (e.g., LEO) is moving with high speed, the propagation delay and frequency between the satellite and UE are always changing.

Suppose that the satellite orbital speed is 7.5 km/sat 600km altitude and that a minimum elevation angle on earth is approximately 10 degrees, the maximum delay drift between the satellite and UE will be on the order of ±20 μs/s.

For one PUSCH transmission spanning up to 40s, the delta propagation delay is changed up to 0.8ms (based on a delay drift of ±20 μs/s) from the beginning to the end of PUSCH transmission. If TA is not updated in a PUSCH transmission (for example, spanning up to 40s) , the TA adopted in the beginning is not suitable in the middle (and at the end) of the PUSCH transmission, because the delta TA exceeding ± T ₀ (e.g., CP/2) will destroy OFDM orthogonality. It means that the UE cannot maintain the original TA (as well as the original frequency) during long NPUSCH transmission.

The TA can be updated during the long NPUSCH transmission by inserting uplink transmission gaps for DL synchronization. During uplink transmission gaps, the UE may switch to the DL and perform time and frequency synchronization. Uplink transmission gap is defined by a period X and a gap length Y. All uplink transmissions of duration greater than or equal to X ms apply transmission gap with gap length Y and periodicity X until the uplink transmission completes. For NPUSCH as shown in Figure 4, X = 256 ms, and Y = 40 ms. The gap is also necessary for the transmission of the preamble in RACH procedure. For example, for NPRACH, X = 64 * (preamble duration (e.g. 5.6ms or 6.4ms) ) , Y = 40 ms.

In NR Release 16, RACH procedure for UE without GNSS has been discussed. In case pre-compensation of timing and frequency offset is not performed at UE side for UL transmission, enhanced PRACH formats and/or preamble sequences should be supported.

However, the enhanced PRACH formats and/or preamble sequences are not suitable to combat timing and frequency offset for UE without GNSS module, at least for the following two reasons:

Firstly, IoT RACH preamble (especially NBIoT preamble) is a simplified design with 3.75kHz subcarrier spacing (e.g., all “1” repetition sequence) . It is hard to enhance the sequence itself.

Secondly, IoT RACH preamble sequence is transmitted with large repetition numbers. In addition, time and/or frequency adjustments should be done during the transmission. It is hard to design a RACH sequence to flexibly combat the time and/or frequency offsets for long transmission duration. In addition, even the enhanced preamble sequence can combat large TA and high Doppler shift, the UE needs to update the TA and frequency offset during the RACH procedure. It is hard to achieve the time and/or frequency drift information during the uplink transmission period due to half duplex FDD.

In view of the above, the enhanced PRACH formats and/or preamble sequences cannot combat timing and frequency offset for UE without GNSS module.

The present invention proposes reference positions for the UE without GNSS capability. According to the present invention, the base station (e.g. eNB or gNB) configures one or multiple UE reference position candidates to the UE. Each UE reference position candidate includes position coordinate, e.g. a pattern of position. The pattern of position may be position coordinates X, Y, Z in Earth-Centered, Earth-Fixed (ECEF) coordinate system. Alternatively, the pattern of position may be position coordinates X, Y, Z in World Geodetic System (i.e. 1984 Coordinate System) . Further alternatively, the pattern of position may be other pattern of position (e.g. latitude, longitude and height coordinates) . The UE reference position candidate (s) may be configured based on cell coverage. It means that for predetermined cell coverage, one or multiple UE reference position candidates are configured.

The UE may determine a reference position from the configured one or multiple UE reference position candidates. It is obvious that when one UE reference position candidate is configured, the configured one UE reference position candidate is determined as the reference position.

When multiple UE reference position candidates are configured in the cell coverage where the UE is located, the UE is necessary to determine a reference position from the configured multiple reference position candidates.

The determination of the reference position from multiple reference position candidates may be made based on different criteria.

Criterion 1: UE determines the reference position based on random selection. In other words, it is up to UE implementation to decide which reference position candidate is determined as the reference position. For example, the UE may randomly determine any one of the reference position candidate as the reference position.

Criterion 2: The eNB may further configure one or more RSRP thresholds (e.g. an RSRP range) associated with each reference position candidate. The UE may determine the reference position based on its estimated or measured RSRP and the one or more RSRP thresholds (e.g. the RSRP range) .

The estimated or measured RSRP can be used as a reference for the UE to determine the reference position due to the LOS (light of sight) between the satellite and UE. For example, the RSRP threshold (s) associated with each reference position candidate may be a RSRP range, while the UE can determine a reference position candidate as the reference position when the UE’s estimated or measured RSRP falls within the RSRP range of the reference position candidate. If the UE’s estimated or measured RSRP falls within the RSRP ranges of two or more reference position candidates, the UE can determine any one of the reference position candidates as the reference position.

For example, suppose there are for reference position candidates A, B, C and D. The RSRP range of reference position candidate A is {A1, A2} e.g., {-105dBm, -95dBm} ; the RSRP range of reference position candidate B is {B1, B2} e.g., {-110dBm, -100dBm} ; the RSRP range of reference position candidate C is {C1, C2} e.g., {-115dBm, -105dBm} ; and the RSRP range of reference position candidate D is {D1, D2} e.g., {-120dBm, -110dBm} . If the UE estimates its RSRP as -102dBm (i.e. falling within the RSRP range of reference position candidate A {-105dBm, -95dBm} , and falling within the RSRP range of reference position candidate B {-110dBm, -100dBm} ) , the UE can determine reference position candidate A or reference position candidate B as the reference position.

Criterion 3: In consideration that an IoT UE is substantially stationary, the UE may determine the reference position based on the lastly determined reference position before the UE goes to idle mode (e.g. the reference position determined for the last RACH procedure) . For example, suppose there are for reference position candidates A, B, C and D, and the lastly determined reference position before the UE goes to idle mode is reference position candidate A. The UE can determine the reference position candidate A as the reference position when the UE needs to start a (new) RACH procedure and resumes from the idle mode. Alternatively, any of the physically neighboring reference positions of the lastly determined reference position before the UE goes to idle mode (i.e. the reference position determined for the last RACH procedure) may be determined as the reference position. For example, if reference position candidates B and C are physically neighboring reference positions of the reference position candidate A, the UE can determine the reference position candidate B or C as the reference position when the UE needs to start a (new) RACH procedure and resumes from the idle mode.

Criterion 4: The eNB may further configure an indication (e.g. an index of one of the multiple reference position candidates) to the UE. That is, the eNB indicates the UE which reference position candidate should be determined as the reference position. The eNB may configure the index based on UE positioning reporting information. The UE positioning reporting information is the TA information reported by the UE, which can be UE-specific TA or UE position information. The UE positioning reporting information was obtained by the UE in the past. For example, the UE positioning reporting information may be the last reference position.

Once a reference position candidate is determined as the reference position, the UE may estimate the distance (d1) or UE-specific TA (T_1) (and accordingly TA or whole TA) as well as the frequency Doppler shift for the service link, based on the determined reference position and the satellite ephemeris information. The TA (or whole TA) can be referred to as time offset adjustment; and the frequency Doppler shift can be referred to as frequency offset adjustment.

Then, the UE performs the RACH procedure similar to the procedure shown in Figure 3. In particular, the UE transmits a random access preamble on RACH resource for the whole TA estimated based on the determined reference position. The random access preamble and the RACH resource can be shared by all reference position candidates. Alternatively, the random access preamble and the RACH resource can be configured for each reference position candidate. This can be implemented by associating a random access preamble set and a RACH resource set with each reference position candidate. When a reference position candidate is determined as the reference position, the UE determines a random access preamble set and a RACH resource set associated with the reference position candidate, and transmits a preamble from the random access preamble set on a RACH resource from the RACH resource set.

For example, as shown in Figure 5, suppose that there are four reference position candidates, indicated as “Reference Position 1” , “Reference Position 2” , “Reference Position 3” and “Reference Position 4” in Figure 5, all four reference position candidates are associated with the same random access preamble set (e.g. random access preamble set 1) and the same RACH resource set (e.g. RACH resource set 1) . That is, the same random access preamble set and the same RACH resource set are shared by all four reference position candidates.

As shown in Figure 6, suppose that there are four reference position candidates, indicated as “Reference Position 1” , “Reference Position 2” , “Reference Position 3” and “Reference Position 4” in Figure 6, each reference position candidate (i.e. each of “Reference Position 1” , “Reference Position 2” , “Reference Position 3” and “Reference Position 4” ) is associated with a different random access preamble set and a different RACH resource set. That is, “Reference Position 1” is associated with random access preamble set 1 and RACH resource set 1; “Reference Position 2” is associated with random access preamble set 2 and RACH resource set 2; “Reference Position 3” is associated with random access preamble set 3 and RACH resource set 3; “Reference Position 4” is associated with random access preamble set 1 and RACH resource set 4.

It is not necessary that both the random access preamble set and the RACH resource set are associated with each reference position candidate. It is feasible that only the random access preamble set or only the RACH resource set is associated with each reference position candidate.

Incidentally, for NBIoT, different UEs are differentiated by transmitting the random access preamble on different subcarriers (i.e. on different tones) . Accordingly, the random access preamble set can be alternatively replaced by tone set.

If each reference position candidate is associated with a different random access preamble set and a different RACH resource set, when a random access preamble from the different random access preamble set is transmitted on a RACH resource from the different RACH resource set from the UE to the base station (e.g. eNB) , the eNB knows which reference position candidate is determined as the reference position. In this situation, the eNB can calculate the UE-specific TA (as well as the whole TA) . This can facilitate the eNB scheduling and save the signaling overhead of TA reporting.

There is a possibility that the determined reference position by the UE may not be suitable, which may lead to that the RACH procedure by applying the TA estimated based on the determined reference position cannot be performed successfully. In view of the above, each reference position candidate may be preferably further associated with a maximal number of preamble attempts. It means that, for a reference position candidate determined as the reference position, the UE may attempt to perform the RACH procedure, if not successful, for at most the maximal number of preamble attempts. That is, if the UE fails to successfully perform the RACH procedure with the determined reference position, the UE may attempt to re-perform the RACH procedure with the determined reference position up to N times, where N is equal to the maximal number of preamble attempts associated with the reference position candidate determined as the reference position.

The maximal number of preamble attempts can be configured by higher layer parameter in TS36.331 as maxNumPreambleAttemptRefPos = ENUMERATED {n3, n4…, n10} .

If the UE fails the RACH procedure with the determined reference position maxNumPreambleAttemptRefPos times, the UE is necessary to determine another reference position candidate as newly determined reference position, and perform the RACH procedure with the newly determined reference position up to N times, where N is equal to the maximal number of preamble attempts for the other reference position candidate newly determined as the reference position.

Figure 7 is a schematic flow chart diagram illustrating an embodiment of a method 700 according to the present application. In some embodiments, the method 700 is performed by an apparatus, such as a remote unit (e.g. UE) . In certain embodiments, the method 700 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method 700 may include 702 receiving one or more reference position candidates, wherein each reference position candidate includes a position coordinate. The position coordinate is one of position coordinate in ECEF, position coordinate in WGS, and position coordinate in other systems.

Figure 8 is a schematic flow chart diagram illustrating an embodiment of a method 800 according to the present application. In some embodiments, the method 800 is performed by an apparatus, such as a base unit. In certain embodiments, the method 800 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method 800 may include 802 transmitting one or more reference position candidates, wherein each reference position candidate includes a position coordinate. The position coordinate is one of position coordinate in ECEF, position coordinate in WGS, and position coordinate in other systems.

In some embodiment, the method may further comprise transmitting a reference position indication.

In some embodiment, the method may further comprise transmitting one or more measurement thresholds for each reference position candidate.

In some embodiment, the method may further comprise transmitting at least one of a preamble set and a RACH resource set for each reference position candidate; and receiving a preamble from the preamble set on a RACH resource from the RACH resource set for a reference position candidate.

In some embodiment, the method may further comprise transmitting a maximal number of preamble attempts for each reference position candidate.

Referring to Figure 9, the UE (i.e. the remote unit) includes a processor, a memory, and a transceiver. The processor implements a function, a process, and/or a method which are proposed in Figure 7.

A remote unit (e.g. UE) comprises a receiver that receives one or more reference position candidates, wherein each reference position candidate includes a position coordinate. The position coordinate is one of position coordinate in ECEF, position coordinate in WGS, and position coordinate in other systems.

In one embodiment, the remote unit may further comprise a processor.

In some embodiment, the processor determines a reference position from the one or more reference position candidates based on a random selection manner, or based on a last reference position or any physical neighboring reference position of the last reference position before the UE goes to idle mode.

In some embodiment, the receiver may further receive a reference position indication. Preferably, the processor may further determine a reference position from the one or more reference position candidates based on the reference position indication.

In some embodiment, the receiver may further receive one or more measurement thresholds for each reference position candidate. Preferably, the processor may further determine a reference position from the one or more reference position candidates based on an estimated RSRP and the measurement thresholds.

The processor may further, based on the reference position and satellite ephemeris information, determine a time offset adjustment and a frequency offset adjustment.

In some embodiment, the receiver may further receive at least one of a preamble set and a RACH resource set for each reference position candidate; and the remote unit further comprises a transmitter that transmits a preamble from the preamble set on a RACH resource from the RACH resource set for a reference position candidate determined as reference position.

In some embodiment, the receiver may further receive a maximal number of preamble attempts for each reference position candidate. Preferably, the processor may further perform preamble transmission up to the maximal number of preamble attempts for a reference position candidate determined as reference position.

The eNB or gNB (i.e. base unit) includes a processor, a memory, and a transceiver. The processor implements a function, a process, and/or a method which are proposed in Figure 8.

A base unit comprises a transmitter that transmits one or more reference position candidates, wherein each reference position candidate includes a position coordinate. The position coordinate is one of position coordinate in ECEF, position coordinate in WGS, and position coordinate in other systems.

In some embodiment, the transmitter may further transmit a reference position indication.

In some embodiment, the transmitter may further transmit one or more measurement thresholds for each reference position candidate.

In some embodiment, the transmitter may further transmit at least one of a preamble set and a RACH resource set for each reference position candidate; and the base unit comprises a receiver that receives a preamble from the preamble set on a RACH resource from the RACH resource set for a reference position candidate.

In some embodiment, the transmitter may further transmit a maximal number of preamble attempts for each reference position candidate.

Layers of a radio interface protocol may be implemented by the processors. The memories are connected with the processors to store various pieces of information for driving the processors. The transceivers are connected with the processors to transmit and/or receive a radio signal. Needless to say, the transceiver may be implemented as a transmitter to transmit the radio signal and a receiver to receive the radio signal.

The memories may be positioned inside or outside the processors and connected with the processors by various well-known means.

In the embodiments described above, the components and the features of the embodiments are combined in a predetermined form. Each component or feature should be considered as an option unless otherwise expressly stated. Each component or feature may be implemented not to be associated with other components or features. Further, the embodiment may be configured by associating some components and/or features. The order of the operations described in the embodiments may be changed. Some components or features of any embodiment may be included in another embodiment or replaced with the component and the feature corresponding to another embodiment. It is apparent that the claims that are not expressly cited in the claims are combined to form an embodiment or be included in a new claim.

The embodiments may be implemented by hardware, firmware, software, or combinations thereof. In the case of implementation by hardware, according to hardware implementation, the exemplary embodiment described herein may be implemented by using one or more application-specific integrated circuits (ASICs) , digital signal processors (DSPs) , digital signal processing devices (DSPDs) , programmable logic devices (PLDs) , field programmable gate arrays (FPGAs) , processors, controllers, micro-controllers, microprocessors, and the like.

Embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects to be only illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

A method at a UE, comprising:

receiving one or more reference position candidates,

wherein each reference position candidate includes a position coordinate.
The method of claim 1, wherein, the position coordinate is one of position coordinate in ECEF, position coordinate in WGS, and position coordinate in other systems.
The method of claim 1, further comprising:

determining a reference position from the one or more reference position candidates based on a random selection manner, or based on a last reference position or any physical neighboring reference position of the last reference position before the UE goes to idle mode.
The method of claim 1, further comprising:

receiving a reference position indication.
The method of claim 4, further comprising:

determining a reference position from the one or more reference position candidates based on the reference position indication.
The method of claim 1, further comprising:

receiving one or more measurement thresholds for each reference position candidate.
The method of claim 6, further comprising:

determining a reference position from the one or more reference position candidates based on an estimated RSRP and the measurement thresholds.
The method of any of claims 3, 5 and 7, further comprising:

determining a time offset adjustment and a frequency offset adjustment based on the reference position and satellite ephemeris information.
The method of claim 1, further comprising:

receiving at least one of a preamble set and a RACH resource set for each reference position candidate; and

transmitting a preamble from the preamble set on a RACH resource from the RACH resource set for a reference position candidate determined as reference position.
The method of claim 1, further comprising:

receiving a maximal number of preamble attempts for each reference position candidate.
The method of claim 10, further comprising:

performing preamble transmission up to the maximal number of preamble attempts for a reference position candidate determined as reference position.
A method at a base unit, comprising:

transmitting one or more reference position candidates,

wherein each reference position candidate includes a position coordinate.
A remote unit, comprising:

a receiver that receives one or more reference position candidates,

wherein each reference position candidate includes a position coordinate.
A base unit, comprising:

a transmitter that transmits one or more reference position candidates,

wherein each reference position candidate includes a position coordinate.