GB2577530A - Synchronisation in cellular networks - Google Patents

Abstract

Selecting a synchronisation source for a mobile device to use when in a defined group of mobile devices, wherein the mobile device uses sidelink communications to communicate with other mobile devices in the group. The mobile device receives a synchronisation source message indicating at least one synchronisation source for use by the mobile device, wherein the at least one synchronisation source includes a second mobile device in the defined group, and receives a synchronisation signal from a synchronisation source indicated by the message. The synchronisation source message may indicate more than one synchronisation source and a relative priority for each indicated synchronisation source. The synchronization source message may comprise an SL-TypeTxSync Information Element and/or a synchronization signal priority in an SL-V2X-Preconfiguration Information Element.

Description

Synchronisation in Cellular Networks

Technical Field

[1] The following disclosure relates to synchronisation in cellular networks. Background [2] Wireless communication systems, such as the third-generation (3G) of mobile telephone standards and technology are well known. Such 3G standards and technology have been developed by the Third Generation Partnership Project (3GPP). The 3rd generation of wireless communications has generally been developed to support macro-cell mobile phone communications. Communication systems and networks have developed towards a broadband and mobile system.

[3] In cellular wireless communication systems User Equipment (UE) is connected by a wireless link to a Radio Access Network (RAN). The RAN comprises a set of base stations which provide wireless links to the UEs located in cells covered by the base station, and an interface to a Core Network (CN) which provides overall network control. As will be appreciated the RAN and CN each conduct respective functions in relation to the overall network. For convenience the term cellular network will be used to refer to the combined RAN & CN, and it will be understood that the term is used to refer to the respective system for performing the disclosed function.

[4] The 3rd Generation Partnership Project has developed the so-called Long Term Evolution (LTE) system, namely, an Evolved Universal Mobile Telecommunication System Territorial Radio Access Network, (E-UTRAN), for a mobile access network where one or more macro-cells are supported by a base station known as an eNodeB or eNB (evolved NodeB). More recently, LTE is evolving further towards the so-called 5G or NR (new radio) systems where one or more cells are supported by a base station known as a gNB. NR is proposed to utilise an Orthogonal Frequency Division Multiplexed (OFDM) physical transmission format.

[5] The NR protocols are intended to offer options for operating in unlicensed radio bands, to be known as NR-U. When operating in an unlicensed radio band the gNB and UE must compete with other devices for physical medium/resource access. For example, Wi-Fi, NR-U, and LAA may utilise the same physical resources.

[6] In order to share resources a Listen Before Talk (LBT) protocol is proposed in which a gNB or UE monitors the available resources and only commences a transmission if there is no conflict with another device already utilising the resources. Once an LBT process is successful (the resources are "won"), the gNB or UE gains access to the resources for up to the Maximum Channel Occupancy Time (MCOT) provided there is no interruption of transmissions for more than a pre-defined interval (for example 16iis).

Transmissions in unlicensed spectrum must comply with various regulations in force for that spectrum. For example, many regulations specify an Occupied Channel Bandwidth (OCB) and Nominal Channel Bandwidth (NCB) which must be complied with. The NCB defines the widest band of frequencies, including guard bands, allocated to a channel, and the OCB defines the bandwidth containing a defined fraction (typically 99%) of a signal's power. Often the OCB must be must be between 80% and 100% of the NCB. As an example, ETSI EN 301.893 defines requirements in the EU for the 5GHz band.

[8] A trend in wireless communications is towards the provision of lower latency and higher reliability services. For example, NR is intended to support Ultra-reliable and low-latency communications (URLLC) and massive Machine-Type Communications (mMTC) are intended to provide low latency and high reliability for small packet sizes (typically 32 bytes). A user-plane latency of 1ms has been proposed with a reliability of 99.99999%, and at the physical layer a packet loss rate of 10-6 or 10-6 has been proposed.

[9] mMTC services are intended to support a large number of devices over a long life-time with highly energy efficient communication channels, where transmission of data to and from each device occurs sporadically and infrequently. For example, a cell may be expected to support many thousands of devices.

[10] To expand the LTE platform to the automotive industry, the initial standard on support of V2V services was completed in Sep 2016. Further enhancements that focusing on additional V2X operation scenarios leveraging the cellular infrastructure, also for inclusion in Release 14, was completed in March 2017.

[11] In Release 15, it is expected to enhance the Cellular-based V2X services (V2V, V21/N, and V2P) to support advanced V2X services as identified in TR 22.886 in a holistic and complementary manner to Release 14 V2X, which will involve both Uu interface and PC5 interface.

[12] 3GPP V2X phase 2 in Rel-15 introduces a number of new features in sidelink, including: carrier aggregation, high order modulation, latency reduction, and feasibility study on both transmission diversity and short TTI in sidelink. All these enhanced features in 3GPP V2X phase 2 are primary base on LTE and require co-existing with Rel-14 UE in same resource pool.

[13] It should be noted that this evolution of Rel. 14 V2X were motivated by new use cases defined by SA. Indeed, SA1 has identified 25 use cases for advanced V2X services. They are categorized into four use case groups: vehicles platooning, extended sensors, advanced driving and remote driving.

[14] More specifically, the invention is related to the synchronization procedure on the sidelink. It explores SyncRef (SYNChronization REFerence) selection which is a procedure to select the proper source as a timing reference for sidelink transmission. Thus, this invention relates to a SyncRef procedure to address SL synchronization for Re1.16 V2X communications.

Summary

[15] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[16] The claims define the invention.

[17] The non-transitory computer readable medium may comprise at least one from a group consisting of: a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a Read Only Memory, a Programmable Read Only Memory, an Erasable Programmable Read Only Memory, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory.

Detailed description of the preferred embodiments

[18] Those skilled in the art will recognise and appreciate that the specifics of the examples described are merely illustrative of some embodiments and that the teachings set forth herein are applicable in a variety of alternative settings.

[19] Base stations (for example, eNB or gNBs depending on the particular cellular standard and terminology) form a cellular network. Typically, each of the base stations will be deployed by one cellular network operator to provide geographic coverage for UEs in the area. The base stations form a Radio Area Network (RAN). Each base station provides wireless coverage for UEs in its area or cell. The base stations are interconnected via the X2 interface and are connected to the core network via the S1 interface. As will be appreciated only basic details are shown for the purposes of exemplifying the key features of a cellular network.

[20] The base stations each comprise hardware and software to implement the RAN's functionality, including communications with the core network and other base stations, carriage of control and data signals between the core network and UEs, and maintaining wireless communications with UEs associated with each base station. The core network comprises hardware and software to implement the network functionality, such as overall network management and control, and routing of calls and data.

[21] The disclosure here targets the procedure for selecting a SL synchronization reference and introduces a notion of Group-based synchronization reference type in order to resolve the problems discussed above with platoon use-case and eNB/gNB coexistence.

[22] The following aspects that need to be considered in spec for NR V2X are tackled * (pre-)configuration of group-based source type * Priority rules for Group-based synchronization * SyncRef determination of Group-based reference * Multiple SyncRef tracking

[23] The disclosure may:-

* Resolve the issues in platoon use-case (also applicable to the other advanced use cases) where platoon members may choose different sync source and be asynchronous with each other (and possible not being able to communicate through sidelink with each other) * At the same time, the notion of group-based sync source type can solve the issue of gNB/eNB coexistence by having one priority group for each type of network.

[24] We propose to introduce in the procedure for selecting a SL synchronization reference, a notion of group-based synchronization reference type. That way, a UE can essentially receive timing information from four different source types: GNSS, Network, UE, or Group.

[25] Group-based sync references could be also seen as a lower level classification after main source types (e.g. GNSS, gNB/eNB, UE), thus, differentiated according to the timing of the main source type they propagate, e.g. Group-GNSS-based, Group-gNB-based, etc. [26] Group source type (pre-)configuration [27] (Pre-)configuration may indicate to a UE a higher priority to receive synchronization from a source belonging to a specific Group instead of prioritizing either eNB/gNB or GNSS. This group can be e.g. a platoon, a group of other vehicles, RSU(s) etc., and the V2X UE may have to maintain several sidelink groups to be able to communicate with.

[28] This (pre-)configuration could be performed for example by using a modified version of SL-TypeTxSync IE (Information Element) and/or syncPriority in SL-V2X-Preconfiguration IE which are used in LTE V2X to indicate the SL synchronization reference priority order to a UE. See example 36.331 spec modifications below.

SL-TypeTxSync information element SL-V2X-Preconfiguration information elements

TOP

[29] [29] One other way could be to reuse the Lie' value of the TypeTxSync parameter (which seems to be redundant in current spec as it is not used to perform as specific function in selection/reselection of sync reference procedure) to denote priority to group/ue-based synchronization reference.

[30] This notion of group can also solve the problem of gNB/eNB coexistence by having one priority group for each type of network.

[31] In order to introduce multiple groups and manage group IDs, and the list of groups each user belongs to, one possible way would be to have a number of possible groups (e.g. 5) and assign each one with a group ID. Then, mapping of group IDs with certain parameters (or ranges of parameters) propagated via SS block (i.e. PSSIDs, SLSSIDs, or indicators within MIB/SIB/RMSI/OSI) could be used.

[32] For example, considering the TypeTxSync parameter we could have the following: [33] SL-TypeTxSync-r16::= ENUMERATED [34] [35] group-0 (gnss) (0) [36] group-1 (network) (1) [37] group-2 (2) [38] group-3 (3) [39] group-4 (4) [40] [41] [42] and then each group-ID could be associated with e.g. a SLSSID value (for example SLSSID={2,3,4} for 3 possible platoons). Even if platoon members are changing frequently, a platoon can keep a more constant group ID -but of course the ID should be generally possible to be updated and communicated to/from the NW. Then, its members can propagate the ID through sidelink to other UEs for e.g. synchronization if needed. A UE can have stored a list of group IDs that it should be tracking for sync -updated by the network or the platoon. [43] [44]

[45] Priority rules for group-based sync [46] Synchronization Source priority/selection rules in NR-V2X could be a modified version of the LTE-V2X ones.

[47] When (pre-)configured to prioritize Group-based configuration, a UE may select to receive timing from the Group-manager/leader (which can be configured as such from the network or self-selected after a group voting process) or a lower priority entity in the Group which is directly connected to the manager e.g. if the manager sync signal is not directly available to the UE.

[48] To avoid unnecessary re-search for higher priority entities within the Group, this direct/indirect approach to connect to a Group-manager could be omitted and a UE could consider same priority among entities in a Group and simply receive timing from any entity in the Group.

[49] As an example, consider the out-of-coverage operation with GNSS-Group-based synchronization pre-configured as the highest priority. In such case, the priority of the synchronization source types could be given e.g. as follows: GNSS-Group-prioritized detailed version simplified version * Pl: UE is Group manager * Pl: UE is indirectly synced to Group manager -* P2: UE is directly synced to Group manager (or, UE is member of Group) * P2: GNSS * P3: UE is indirectly synced to Group manager (or, UE is member of Group) * P3: UE (same priority): * P4: GNSS - UE directly synchronized to GNSS * P5: UE (same priority): - UE indirectly synchronized to GNSS - UE directly synchronized to GNSS - UE indirectly synchronised to GNSS - UE indirectly synchronized to GNSS via 00C UE * P4: UE - UE indirectly synchronised to GNSS (same priority): via 00C UE - UE indirectly synchronized to * P6: UE (same priority): gNB/eNB - UE indirectly synchronized to - UE indirectly synchronized to eNB gNB/eNB P5: other ISS UEs.

- UE indirectly synchronized to eNB * P7: other TSS UEs.

[50] In a similar way as in Section 5.10.8.2 of TS 36.331, Group-based prioritization can be defined in steps.

[51] For example we could have something like the following: [52] [53] 1> if triggered by V2X sidelink communication, and in coverage on the frequency for V2X sidelink communication [54] 2> if typeTxSync is configured for the concerned frequency and set to gnss-group-I D=X, and UE belongs to group-I D=X: [55] 3> if GNSS is reliable [56] 4> select GNSS as the synchronization reference source; [57] 3> else [58] 4> search SLSSID=X on the concerned frequency to detect candidate

SLSS

[59] 4> if the S-RSRP of the SyncRef UE identified by the detected SLSS exceeds the minimum requirement [60] 5> select the SyncRef UE; [61] [62] The group-based prioritization can be communicated to the UE via configuration of typeTxSync (when in coverage), or preconfiguration of syncPriority in SL-V2X-Preconfiguration IE (when out of coverage) -and these parameters can be updated based on UE group membership status. For example, when UE starts following a platoon with ID=Y (instead of X) it will drop its main sync and start searching for SLSSID=Y instead.

[63] Reference Group determination [64] Group-members that have achieved sidelink synchronization should send SLSS/PSBH (or else termed SSB) in NR sidelink in order to be received by asynchronized group-members.

[65] One question that arises with the proposed approach is how to differentiate SyncRefs and determine a SyncRef position in sync chain. LTE approach can be considered as baseline (section 3.1.3) but additional or new factors have to be considered to identify a SyncRef Group. The following options can be considered: [66] SLSSID [67] Group based (Platoon) specific SLSSID could be used in a similar way as for GNSS in LTE V2X wherein SLSSID = 0 is used to identify that a SyncRef UE is synchronized to GNSS. Therefore, for NR SLSS for example, SLSSID = {X, Y, ...} could be allocated for determining one or several Groups within a network/cell.

[68] For out-of coverage case, i.e. when group ID cannot be communicated with the network and has to be allocated in a decentralized way, one can think of a large number of SLSSIDs (e.g. X to X+1000) allocated for group purposes and each group manager can randomly (or based on a location-based algorithm) choose one SSLID upon group formation. That way, the possibility for 2 platoons in the same area to have same ID can be minimized.

[69] PSSID [70] In RBI-14 LTE sidelink, there are two PSSID (Physical Sidelink Synchronization Identity) sets that are used to differentiate between in coverage and out-of-coverage UEs. In each PSSID set, there are 168 PSSIDs as below.

- id_nct=l 0, 1, 167; - id_oon= :168, 169, ++++ , 335: On the other hand, in Ra-is NR the number of physical cell IDs is 1008, given by N_ID^cell=3N_IDI1)-HALID^(2) * NR-PSS is a M-sequence with 3 cyclic shifts in to get 3 PSS signals: N IDA(2)=0, 1, 2 * NR-SSS is a M-sequence with scrambling to give 336 different IDs: N 1DA(1)=0, I. .... 335; [71] Therefore, NR or LTE PSS design could be reused or modified to provide extra info related to SyncRef Group via NR PSSS. For example, considering the NR PSS, two PSSID sets could again be used to differentiate between in coverage and out-of-coverage UEs while a 3' set (or more) could be used to denote UEs belonging to Group(s).

[72] To distinguish Groups/platoons from other synchronization reference sources (e.g. gNB, GNSS) and to avoid that a vehicle UE, member of a Group/platoon, does not synchronize to its Group/platoon, an additional (exclusive for Groups/platoons) PSS could be defined. A V2X UE may search for the additional PSS e.g. only if a Group/platoon membership has been acquired (or configured by the network).

[73] InC indicator in MIB [74] In-coverage indicator that is included in LTE V2X MIB could be also existent in NR V2X MIB but combined with other SyncRef info such as SyncRef Group related information, or information about number of hops from sync source, or even information about stationarity.

[75] Table below shows an example of how SyncRef Group info could be included in a modified 3-bit InC indicator Inc indicator 000 00C 100 00C, Group 001 InC, gNB 101 InC, Group, gNB InC, eNB 110 InC, Group, eNB 011 00C, RSU 111 00C, Group, RSU [76] Of course a separate indicator could be also used instead.

[77] SLSS resource [78] (Pre)configured SLSS sync resources could be also used to determine that a SyncRef UE is member of a Group. In essence, SyncRef Groups could be differentiated when multiple sync resources are (pre) configured. In case of configuration, offset indicators (as in LTE) can configure the UEs with the Group-relevant synchronization resources.

[79] Tracking of multiple SyncRef [80] In LTE V2X, only the selected synchronization reference is tracked by the vehicle UE and no other asynchronous synchronization sources are searched. Thus, two Rel-14 V2X vehicles synchronized via different asynchronous synchronization sources cannot communicate with each other. However, Rel-12/13 D2D supported this operation to search asynchronous synchronization reference (but it was not transferred in V2X). Towards the V2X preference to achieve global synchronization, and considering eNB/gNB coexistence, the platoon use-case and other advanced use cases (extended sensors, advanced driving), as well as the possible advantage of vehicles connected to different operators being able to communicate with each other, multi-group synchronization signal searching and tracking could be introduced in NR V2X.

[81] It could be possible to manage multiple groups per UE with group IDs communicated among UEs and/or between UEs and NW.

In that case for example, a vehicle belonging to a platoon willing to share its sensor information with other vehicle(s) external to the platoon should maintain two synchronisation sources: one for the platoon, and one to communicate with vehicle(s) outside the platoon. So, it could be an advantage to introduce a notion of SvncRefGroup. In addition, there could be a UE capability introduced in spec to indicate how many groups the UE is able to synchronize with which could be communicated at the connection of the UE in the network. This requires of course the UE to implement a searcher for sidelink synchronization that is constantly running asynchronous to the main SL communication operation (e.g. Tx/Rx to/from platoon member(s) in our example case) and a tracker that keeps track (and possibly updates) the different timings. So, UE needs to be able to handle two or more asynchronous timings for SL, one for data transmission and reception, and one or more asynchronous timings for search/tracking operation.

[83] Furthermore, a new metric could be introduced to evaluate the level of synchronization with different groups. For example, we could imagine such new criteria that would give to the UE a good indication if it is synchronized or not to what it tries to receive. If a UE has no external synchronization source (nodeB or GNSS), it could just try to listen to sidelink and assess its synchronization level' (e.g. in case the UE is losing its sync source for a while due to a tunnel and tries to demodulates the incoming V2X signal without going back to resynchronization). Above a defined threshold, the UE can assume it is synchronized and start using the sidelink channel.

This approach could be also used as another way to select the proper synchronization Group.

[84] Resource pools [85] The proposed Group concept could also be extended into the resource pool aspect that is part of LTE V2X and most possibly NR V2X.

[86] Considering our proposal, dedicate resources in a pool could be (pre-)configured/assigned to serve a given group.

[87] Although not shown in detail any of the devices or apparatus that form part of the network may include at least a processor, a storage unit and a communications interface, wherein the processor unit, storage unit, and communications interface are configured to perform the method of any aspect of the present invention. Further options and choices are described below.

[88] The signal processing functionality of the embodiments of the invention especially the gNB and the UE may be achieved using computing systems or architectures known to those who are skilled in the relevant art. Computing systems such as, a desktop, laptop or notebook computer, hand-held computing device (PDA, cell phone, palmtop, etc.), mainframe, server, client, or any other type of special or general purpose computing device as may be desirable or appropriate for a given application or environment can be used. The computing system can include one or more processors which can be implemented using a general or special-purpose processing engine such as, for example, a microprocessor, microcontroller or other control module.

[89] The computing system can also include a main memory, such as random access memory (RAM) or other dynamic memory, for storing information and instructions to be executed by a processor. Such a main memory also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor. The computing system may likewise include a read only memory (ROM) or other static storage device for storing static information and instructions for a processor.

[90] The computing system may also include an information storage system which may include, for example, a media drive and a removable storage interface. The media drive may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a compact disc (CD) or digital video drive (DVD) read or write drive (R or RV V), or other removable or fixed media drive. Storage media may include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive. The storage media may include a computer-readable storage medium having particular computer software or data stored therein.

[91] In alternative embodiments, an information storage system may include other similar components for allowing computer programs or other instructions or data to be loaded into the computing system. Such components may include, for example, a removable storage unit and an interface, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit to computing system.

[92] The computing system can also include a communications interface. Such a communications interface can be used to allow software and data to be transferred between a computing system and external devices. Examples of communications interfaces can include a modem, a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a universal serial bus (USB) port), a PCMCIA slot and card, etc. Software and data transferred via a communications interface are in the form of signals which can be electronic, electromagnetic, and optical or other signals capable of being received by a communications interface medium.

[93] In this document, the terms 'computer program product', 'computer-readable medium' and the like may be used generally to refer to tangible media such as, for example, a memory, storage device, or storage unit. These and other forms of computer-readable media may store one or more instructions for use by the processor comprising the computer system to cause the processor to perform specified operations. Such instructions, generally 45 referred to as 'computer program code' (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system to perform functions of embodiments of the present invention. Note that the code may directly cause a processor to perform specified operations, be compiled to do so, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.

[94] The non-transitory computer readable medium may comprise at least one from a group consisting of: a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a Read Only Memory, a Programmable Read Only Memory, an Erasable Programmable Read Only Memory, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory. In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into computing system using, for example, removable storage drive. A control module (in this example, software instructions or executable computer program code), when executed by the processor in the computer system, causes a processor to perform the functions of the invention as described herein.

[95] Furthermore, the inventive concept can be applied to any circuit for performing signal processing functionality within a network element. It is further envisaged that, for example, a semiconductor manufacturer may employ the inventive concept in a design of a stand-alone device, such as a microcontroller of a digital signal processor (DSP), or application-specific integrated circuit (ASIC) and/or any other sub-system element.

[96] It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to a single processing logic. However, the inventive concept may equally be implemented by way of a plurality of different functional units and processors to provide the signal processing functionality. Thus, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organisation.

[97] Aspects of the invention may be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may optionally be implemented, at least partly, as computer software running on one or more data processors and/or digital signal processors or configurable module components such as FPGA devices.

[98] Thus, the elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognise that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term 'comprising' does not exclude the presence of other elements or steps.

[99] Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate.

[100] Furthermore, the order of features in the claims does not imply any specific order in which the features must be performed and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to 'a', 'an', 'first', 'second', etc. do not preclude a plurality.

[101] Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognise that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term 'comprising' or "including" does not exclude the presence of other elements.

3GPP TSG RAN WG1 Meeting #94bis R1-18xxxxx Chengdu, China, October 8th -12th, 2018 Agenda Item: 7.2.4.1.3 Source: Sequans Title: Considerations on sidelink synchronization for NR V2X Document for: Discussion and decision

1 Introduction

In RAN#80, a SI [1] was approved for NR V2X including an objective: Sidelink design /RAN/, R4N2/: * Identify technical solutions for a BAR side/ink design to meet the requirements of advanced 12V services, including: o Study sidelink synchronization mechanism On RAN1#94, following agreement was achieved for NR V2X sidelink synchronization [2]: Agreements: * AR V2X sidelink Synchronization includes at least the following o sidelink synchronization signal(s) o PSBCH o Sidehnk synchronization sources and procedure(s) * Synchronization sources -at least GYSS, gATB, Ur In this contribution we provide some considerations on sidelink synchronization aspects.

2 Discussion 2.1 Synchronization sources and procedures In LTE V2X, the synchronization references defined include: GNSS, Network (i.e. eNB), and UE. TS 36.331 specifies the procedure of selection/reselection of synchronization reference and priority generally depends on (pre-)configuration (i.e. the priority rule can be overridden by eNB configuration) and coverage status.

In NR V2X, it was agreed at last RANI meeting to consider as synchronization sources at least GNSS, gNB and UE. In terms of network, however, the vehicle UE may be in coverage of NR cell only, LTE cell only, or both in case of coexistence of the two networks. For a NR V2X UE which can support both NR V2X and LTE V2X communication, eNB needs to also be considered as a source of synchronization reference to enable faster sidelink synchronization and/or harmonic coexistence among LTE and NR vehicle UEs. Then, synchronization source selection and priority issues between gNB and eNB should be further studied. In case of different gNB and eNB priorite for synchronization, it should also be considered whether SyncRef UE within synchronization procedures should be differentiated between NR UE and LTE UE. In a similar direction, it could also be considered whether groups of UEs with specific characteristics that affect synchronization performance could account for distinct synchronization sources (e.g. RSU SyncRef UEs or same platoon members could serve as more accurate synchronization sources due to their stationarity or relative static location, respectively). Such practice could lead to a more organized sidelink synchronization procedure with reduced complexity.

Moreover, considering the platooning use case, each UE in such closed-group should not select its synchronization reference independently from other members of the group. Members of the same platoon will need to 'run on the same clock' to communicate with each other. Considering the legacy LTE synchronization mechanism, in case of full or partial out-of-coverage platooning (i.e. where all or few platoon members' synchronization priority cannot be configured by eNB/gNB) it is possible that different platoon members end up to select different synchronization references. Such problem can also appear even in case of in-coverage platooning though; for example, all members can be configured to give priority to GNSS but some may not be able to have reliable GNSS connection. To avoid such issues a mechanism to prioritize synchronization signals received from platoon manager or members may need to be considered, e.g. a platoon/group ID could be used to determine priority.

Proposal 1: Synchronization source selection and prioritization mechanism needs to be studied for NR V2X Proposal 2: Consider eNB, LTE UE, RSU and platoon as potential distinct synchronization sources for NR V2X 2.2 Sidelink SSB design For NR Uu, SSB including a compact structure of PSS/SSS/PBCH is used for synchronization. Since DL SSB has been designed to support speeds up to 500Km/h it makes sense to reuse it for NR V2X to reduce standardization complexity and UE/hardware complexity.

Proposal 3: Use NR Uu &SR design as basis for NR sidelink.SSR. NR PSSS/SSSS in Rel-15 NR, the number of physical cell IDs is 1008, given by N_IDAcell=3N_IDA(1)+N_IDA(2) * NR-PSS is a M-sequence with 3 cyclic shifts in to get 3 PSS signals: N_IDA(2)=0, 1, 2 * NR-SSS is a M-sequence with scrambling to give 336 different IDs: N_IDA(1)=0, 1, ..., 335; On the other hand, In Rol-14 LTE sidelink, there are two PSSID sets that are used to differentiate between in coverage and out-of-coverage UEs. In each PSSID set, there are 168 PSSIDs NR PSS/SSS design could be reused for NR PSSS/SSSS or modified to provide extra info (e.g. related to SyncRef Group) while providing at least equivalent capacity to LTE V2X design. For example, considering the NR PSS design as basis, two PSSID sets in PSSS could be used to differentiate between in-coverage and out-of-coverage UEs as in LTE V2X, while a third set could be used to denote UEs belonging a specific group (e.g. LTE UE, RSU or platoon).

NR PSBCH

NR PSBCH should at least carry system timing information (i.e. SFN, half radio frame) and initial access information (i.e. SCS/DMRS-related info etc.) which are also part of Rel-15 NR PBCH. In addition, it could be considered if NR PSBCH should carry a coverage indicator as in LTE V2X for SyncRef determination (possibly modified if needed to combine with other SyncRef info such as eNB/gNB differentiation), information for unicast/groupcast communication, resource pool and resource configuration information, and indication about slot format.

2.3 Multiple synchronization references Towards the V2X preference to achieve global synchronization, and considering eNB/gNB coexistence, the platoon use-case and other advanced use cases (extended sensors, advanced driving), as well as the possible advantage of vehicles connected to different operators being able to communicate with each other, multi-group synchronization signal searching and tracking could be considered for NR V2X. It could be possible to manage more than one synchronization group-sources per UE. In that case for example, a vehicle belonging to a platoon willing to share its sensor information with other vehicle(s) external to the platoon should maintain at least two synchronization sources: one forthe platoon, and one to communicate with vehicle(s) outside the platoon.

Proposal 4: Consider tracking of multiple synchronization references.

3 Conclusions

In this contribution, we provide considerations on sidelink synchronization for NR V2X communication. Based on the discussion, we have the following proposals: Proposal 1: Synchronization source selection and prioritization mechanism needs to he studied for NR V2X Proposal 2: Consider eNB, LTE UE, RSU and platoon as potential distinct synchronization sources for NR V2X sidelink.

Proposal 3: Use AR Cu SSB design as basis for AR sidelink SSB. Proposal 4: Consider tracking of multiple synchronization references.

References [1]. RP-181480, New SID: Study on NR V2X", RAN#80 [2]. Chairman's notes, RANI#94

Claims (8)

1. Claims 1. A method of selecting the synchronisation source for a mobile device to use when that mobile device is in a defined group of mobile devices, wherein the mobile device is configured to use sidelink communications to communicate with other mobile devices in the defined group, the method performed at the mobile device and comprising the steps of receiving a synchronisation source message indicating at least one synchronisation source for use by the UE, wherein the at least one synchronisation source includes a second mobile device in the defined group; and receiving a synchronisation signal from a synchronisation source indicated by the message.
2. 2. A method according to claim 1, wherein the synchronisation source message is an RRC message.
3. 3. A method according to claim 2, wherein the synchronisation source message comprises an SL-TypeTxSync Information Element.
4. 4. A method according to claim 2 or claim 3, wherein the synchronisation source message comprises a synchronisation signal priority in an SL-V2X-Preconfiguration Information Element.
5. 5. A method according to claim 2, wherein the synchronisation source message indicates a group ID for a group to which the mobile device belongs and an indication of at least one synchronisation source for that group.
6. CO 6. A method according to any preceding claim wherein the mobile device is connected to an NR cellular communications network.
7. 7. A method according to any preceding claim, wherein the synchronisation source message indicates more than one synchronisation source and a relative priority for each indicated synchronisation source.I-
8. 8. A method according to any preceding claim, wherein the synchronisation signal is received from another mobile device in the defined group of mobile devices, and wherein the synchronisation signal comprises at least one of an SLSSID allocated specifically for the defined group of mobile devices; a PSSID allocated for the defined group of mobile devices; an indicator in MIB, SIB, RMSI, or OSI; and an SLSS resources.