CN112314013A

CN112314013A - Synchronization in cellular networks

Info

Publication number: CN112314013A
Application number: CN201980035105.1A
Authority: CN
Inventors: 埃夫斯塔西奥斯·格德拉纳若斯; 纪尧姆·维维亚
Original assignee: Jiekai Communications Shenzhen Co Ltd
Current assignee: Jiekai Communications Shenzhen Co Ltd
Priority date: 2018-09-27
Filing date: 2019-09-25
Publication date: 2021-02-02
Anticipated expiration: 2039-09-25
Also published as: WO2020063697A1; CN112314013B; GB2577530A; GB201815796D0

Abstract

In new cellular radio standards, UEs may be grouped together in groups. Methods and systems for selecting a synchronization source for UEs in such a group are disclosed.

Description

Synchronization in cellular networks

Technical Field

The present application relates to synchronization in cellular networks.

Background

Wireless communication systems such as third generation (3G) mobile telephone standards and technologies are well known. Such 3G standards and technologies have been developed by the 3 rd generation partnership project (3 GPP). Third generation wireless communications were developed generally to support macrocell mobile telephone communications. Communication systems and networks have evolved towards broadband and mobile systems.

In a cellular wireless communication system, User Equipment (UE) is connected to a Radio Access Network (RAN) over a radio link. The RAN comprises a set of base stations and an interface to a Core Network (CN). The base station provides a radio link to UEs located in the cell covered by the base station. The core network provides overall network control. It is to be understood that the RAN and CN each perform corresponding functions related to the overall network. For convenience, the term cellular network will be used to refer to the combined RAN and CN. And it is to be understood that the term is used to refer to a corresponding system for performing the disclosed function.

The 3 rd generation mobile communication partnership project has developed a so-called Long Term Evolution (LTE) system, i.e., evolved universal mobile telecommunications system terrestrial radio access network (E-UTRAN). The Long Term Evolution (LTE) system is used for mobile access networks supported by base stations in which one or more macro cells are called enodebs or enbs (evolved nodebs). Recently, LTE has evolved further towards so-called 5G or NR (new radio) systems. In the 5G or NR (new radio) system, one or more cells are supported by a base station called a gNB. NR is proposed to utilize an Orthogonal Frequency Division Multiplexing (OFDM) physical transmission format.

The NR protocol is intended to provide an option for operating in the unlicensed radio band, referred to as NR-U. When operating in the unlicensed radio band, the gNB and UE must contend with other devices for physical medium/resource access. For example, Wi-Fi, NR-U, and LAA can utilize the same physical resources.

In order to share resources, a listen-before-talk (LBT) protocol is proposed. In listen-before-talk protocols, the gNB or UE monitors the available resources and initiates a transmission only if there is no conflict with other devices already utilizing the resources. Once the LBT procedure is successful (the resource is "seized"), the gNB or UE accesses the resource for up to a Maximum Channel Occupancy Time (MCOT) as long as no transmission interruption occurs for more than a predefined interval (e.g., 16 μ s).

Transmissions in unlicensed spectrum must comply with various regulations in force in the spectrum. For example, many regulations specify Occupied Channel Bandwidth (OCB) and Nominal Channel Bandwidth (NCB) that must be adhered to. The NCB defines the widest frequency band allocated to the channel, including the guard band. While OCB defines a bandwidth that contains a defined fraction (typically 99%) of the signal power. Generally, OCB must be between 80% and 100% of NCB. For example, ETSI EN 301.893 defines the European Union (EU) requirements for the 5GHz band.

The trend in wireless communications is to provide services with lower latency and higher reliability. For example, NR is intended to support ultra-high reliable and ultra-low latency communication (URLLC), while mass machine communication (mtc) is intended to provide low latency and high reliability for small data packets (typically 32 bytes). A1 ms user plane delay with 99.99999% reliability is suggested. And at the physical layer, proposal 10^-5Or 10^-6The packet loss rate of (1).

mtc services aim to support a large number of devices over energy efficient communication channels over a long lifetime. In mtc, transmissions to and from each device occur occasionally. For example, one cell may be expected to support thousands of devices.

To extend the LTE platform to the automotive industry, the initial standard for supporting V2V service has been completed in 2016 at 9 months. Further enhancement was completed in 2017 and month 3. This enhanced functionality focuses on other V2X operating scenarios (which are also included in release 14) that utilize the cellular infrastructure.

In release 15, it is expected that cellular-based V2X services (V2V, V2I/N, and V2P) will be enhanced in an overall and complementary manner relative to release 14V 2X to support advanced V2X services as determined in TR 22.886, which will involve both the Uu and PC5 interfaces.

3GPP V2X stage 2 in release 15 (Rel-15) introduces a number of new features in the sidelink, including: carrier aggregation, high order modulation, latency reduction, and feasibility study for both transmission diversity and short TTI in the sidelink. All these enhanced features in phase 2 of 3GPP V2X are primarily based on LTE and require coexistence with UEs of release 14 in the same resource pool.

It should be noted that this evolution of V2X, 14 th edition, was motivated by the new use case defined by SA. In fact, SA1 has determined 25 use cases for advanced V2X services. They are divided into four use case groups: vehicle formation, extended sensors, advanced driving, and remote driving.

More particularly, the present application relates to synchronization procedures on sidelink. The present application discusses SyncRef (SYNCHronization REFerence) selection. This is a process of selecting the appropriate source as a timing reference for sidelink transmissions. Thus, the present application is directed to a SyncRef process for resolving SL synchronization for version 16 (rel.16) V2X communications.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form. These concepts 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.

The claims define the application.

The non-transitory computer readable medium may include at least one of: hard disks, CD-ROMs, optical storage devices, magnetic storage devices, read-only memories, programmable read-only memories, electrically erasable programmable read-only memories, and flash memories.

Detailed Description

Those skilled in the art will recognize and appreciate that the specifics of the described examples are merely illustrative of some embodiments and that the teachings set forth in this application are applicable in a variety of alternative settings.

The base stations (e.g., enbs or gnbs depending on the particular cellular standard and terminology) form a cellular network. Typically, each base station will be deployed by one cellular network operator to provide geographic coverage for UEs in that area. The base stations form a Radio Area Network (RAN). Each base station provides radio coverage for UEs in its area or cell. The base stations are interconnected by an X2 interface and connected to the core network by an S1 interface. It will be understood that only the basic details are shown in order to illustrate key features of the cellular network.

Each base station includes hardware and software for implementing RAN functions. These RAN functions include communication with the core network and other base stations, transfer of control and data signals between the core network and the UEs, and maintenance of wireless communication with the UEs associated with each base station. The core network includes hardware and software for implementing network functions such as overall network management and control and routing of calls and data.

The disclosure herein is directed to a process of selecting a SL synchronization reference and introduces the concept of a group-based synchronization reference type to solve the above-mentioned problems regarding the coexistence of a formation user case and eNB/gNB.

The following aspects to be considered in the NR V2X specification are solved:

● group-based (pre-) configuration of source types

● priority rules for group-based synchronization

● group-based reference SyncRef determination

● multiple SyncRef tracking

The application can:

● solve the problem in the formation user case (the same applies to other advanced user cases). In the queuing user case, the queuing members may select different synchronization sources and be asynchronous to each other (and may not be able to communicate with each other over the sidelink).

● at the same time, the concept of group-based sync-source type can solve the problem of gNB/eNB coexistence by setting a priority group for each type of network.

We propose to introduce the concept of group-based (or queue-based, cluster-based) synchronization reference types for the process of selecting SL synchronization references. As such, the UE can be basically from four different source types: the GNSS, network, UE or group receives timing information.

The group-based synchronization reference may also be considered as a lower level classification after the master source type (e.g., GNSS, gNB/eNB, UE). Thus, group-based synchronization references may be distinguished by timing according to the type of master source they propagate, e.g., GNSS-based groups, gNB-based groups, etc.

Group source type (pre) configuration

The (pre-) configuration may for example indicate a higher priority for the UE to receive synchronization from sources belonging to a specific group, rather than prioritizing eNB/gNB or GNSS. The group may be, for example, a formation, a group of other vehicles, an RSU, or the like. And the V2X UE may have to maintain several sidelink groups to communicate with each other.

This (pre-) configuration may be performed, for example, by using a modified version of the SL-TypeTxSync IE (information element). It is used in LTE V2X to indicate the synchronization reference used for the UE. See example modifications below.

Another way may be to reuse the 'ue' value of the TypeTxSync parameter to indicate priority for group/ue-based synchronization references. The 'ue' value appears redundant in the current specification (spec) because it is not used to perform a specific function in the selection/reselection of the synchronization reference process.

The group concept can also address the problem of gbb/eNB coexistence by setting a priority group for each type of network.

Priority rules for group-based synchronization

The synchronization source priority/selection rule in NR-V2X may be a modified version of the LTE-V2X rule.

When (pre) configured to prioritize the group-based configuration, the UE may choose to receive timing from the group-manager/leader (which may be configured to receive timing from the network, or choose itself after the group voting process) or a less prioritized entity directly connected to the manager in the group (e.g., if the manager synchronization signal is not directly available to the UE).

To avoid unnecessarily re-searching for higher priority entities within the group, this direct/indirect method of connecting to the group manager may be omitted, and the UE may consider the entities within the group to have the same priority and simply receive timing from any entity within the group.

For example, consider a loss of coverage operation, where GNSS group based synchronization is preconfigured to the highest priority. In this case, the priority of the synchronization source type may be given, for example, as follows:

reference group determination

The group members that have achieved sidelink synchronization should send SLSS/PSBH (otherwise known as SSB) in the NR sidelink to be received by the asynchronous group-members.

One problem that arises with the proposed method is how to distinguish the SyncRef and determine the location of the SyncRef in the synchronization chain. The LTE approach may be considered as baseline (section 3.1.3), but other factors or new factors must also be considered to identify SyncRef groups. The following options may be considered:

SLSSID

the explicit group (formation) based slsid may be used in a similar way as the GNSS in LTE V2X. Wherein slsid ═ 0 is used to identify SyncRef UEs for GNSS synchronization. Thus, for example, for NR SLSS, slsid may be assigned { X, Y.

PSSID

In LTE release 14 sidelink, there are two PSSID (physical sidelink synchronization identifier) groups. These two groups are used to distinguish between covered and uncovered UEs. In each PSSID group, there are 168 PSSIDs as follows.

-id_net＝{0,1,...,167}

-id_oon＝{168,169,...,335}

On the other hand, in NR release 15, the number of physical cell IDs is 1008, which comes from:

N_ID^cell＝3N_ID^(l)+N_ID^(2)

● NR-PSS is an M sequence with 3 cyclic shifts to obtain 3 PSS signals: n _ ID ^ (2) is 0,1,2

● NR-SSS is an M-sequence with scrambling (scrambling) to give 336 different IDs: n _ ID ^ (l) 0, 1.., 335;

thus, NR or LTE PSS designs may be reused or modified to provide additional information about the SyncRef group through the NR PSSs. For example, considering NR PSS, two PSSID groups may again be used to distinguish between in-coverage and out-of-coverage UEs, while a third group (or more) may be used to identify UEs belonging to a group.

InC indicator (indicator) in MIB

The in-coverage indicator included in the LTE V2X MIB may also be present in the NR V2X MIB (or in SIB/RMSI/OSI), but combined with other SyncRef information. The SyncRef information is, for example, SyncRef cluster related information, or information of the number of hops (hops) from a synchronization source, or even information about stability (stability).

The following table shows an example of how SyncRef cluster information can be included in the modified 3-bit InC indicator.

Of course, a separate indicator may also be used.

SLSS source

A (pre-) configured SLSS synchronization source may also be used to determine that a SyncRef UE is a member of the cluster. Essentially, SyncRef groups can be distinguished when a plurality of synchronization resources are (pre-) configured. In the configured case, the offset indicator (as in LTE) can configure the synchronization resources related to the group for the UE.

Tracking of multiple SyncRefs

In LTE V2X, only the selected synchronization reference is tracked by the vehicle UE, while no other asynchronous synchronization sources are searched. Thus, two 14 th release V2X vehicles that are synchronized by different asynchronous synchronization sources cannot communicate with each other. However, D2D, version 12/13, supports this operation of searching for asynchronous synchronous references (but this operation is not carried over in V2X). Targeting the preference of V2X for global synchronization and considering eNB/gNB coexistence, formation user cases and other advanced user cases (extended sensors, advanced driving), and the possible advantage of vehicles connected to different operators being able to communicate with each other, multi-group synchronization signal search and tracking can be introduced in NR V2X.

For example, in this case, a vehicle belonging to one formation and willing to share its sensor information with other vehicles outside the formation should maintain two synchronization sources: one for formation; and one for communicating with vehicles outside the convoy. Therefore, the introduction of the concept of SyncRefGroup may be an advantage. In addition, a UE capability may be introduced in the specification. The UE capability is used to indicate how many groups the UE can synchronize with. These groups may communicate at the connections of the UEs in the network. This of course requires the UE to conduct a search for the sidelink synchronization and tracker. Sidelink synchronization always runs asynchronously with respect to the main SL communication operation (e.g., from Tx/Rx to the convoy members or from convoy members to Tx/Rx in our example case). The tracker keeps track of (and possibly updates) the different timings. Therefore, the UE needs to be able to handle two or more asynchronous timings for SL, one for data transmission and reception and another one or more asynchronous timings for search/trace operations.

Furthermore, new metrics (metrics) can be introduced to evaluate the synchronization level with different groups. For example, we can imagine that this new criterion will give the UE a good indicator to indicate whether the UE is synchronized with what it is trying to receive. If the UE does not have an external synchronization source (nodeB or GNSS), it can only attempt to listen to the sidelink and evaluate its "synchronization level" (e.g., if the UE temporarily loses its synchronization source due to the tunnel and attempts to demodulate the incoming V2X signal without returning a resynchronization). As soon as a defined threshold is exceeded, the UE can assume that it has been synchronized and start using the sidelink channel.

The method may also be used as another method for selecting a suitable synchronization group.

Source pool

The proposed group concept can also be extended to the source pool aspect that is part of LTE V2X and more likely part of NR V2X.

Considering our proposal, a dedicated source in the pool can be (pre-) configured/allocated to serve a given group.

Further details of the present disclosure are provided in the following paragraphs.

In RAN #80 conferencing, RP-181480 is approved for NR V2X, including targets for sidelink design [ RAN1, RAN2 ]:

● determine a technical solution for BNR sidelink design to meet the requirements of advanced V2X services, including:

study of sidelink synchronization mechanism

On RAN1#94 conferencing, the following protocol has been agreed for NR V2X side link synchronization (RAN1#94 conference chairman specification):

● NR V2X sidelink synchronization includes at least the following:

o.sidelink synchronization signal

〇PSBCH

Good-side downlink synchronization source and process

■ synchronous source-at least GNSS, gNB, UE

In the following, some considerations regarding sidelink synchronization are provided.

Synchronization source and process

In LTE V2X, the defined synchronization reference includes: GNSS, network (i.e., eNB), and UE. TS 36.331 specifies the process of selecting/reselecting the synchronization reference, and the priority typically depends on the (pre-) configuration (i.e. the priority rules that can be covered by the eNB configuration) and the coverage status.

In NR V2X, the last RAN1 conference agreed to have at least GNSS, gNB, and UE as synchronization sources. However, with respect to the network, in the case where both networks coexist, the vehicular UE may be covered by only the NR cell, only the LTE cell, or both. For NR V2X UEs capable of supporting both NR V2X communications and LTE V2X communications, it is also necessary to treat the eNB as a synchronization reference source to achieve harmonious coexistence and/or faster sidelink synchronization between LTE and NR vehicular UEs. Then, synchronization source selection and priority issues between the gNB and eNB should be further studied. In case the gbb and eNB priorities for synchronization are different, it should also be considered whether SyncRef UEs in the synchronization process should be distinguished between NR UEs and LTE UEs. In a similar direction, it may also be considered whether a group of UEs with specific characteristics affecting the synchronization performance may count as different synchronization sources (e.g. RSU SyncRef UEs or the same convoy members may act as more accurate synchronization sources, due to their stationary or relatively stationary positions, respectively). This approach may result in a more organized sidelink synchronization procedure with less complexity.

Also, considering the formation user case, each UE in such a closed group should not choose its synchronization reference independently of the other members of the group. Members in the same convoy will need to "run according to the same clock" to communicate with each other. Considering the conventional LTE synchronization mechanism, in case of full or partial out-of-coverage queuing (i.e. where the synchronization priority of all or a few members of the queuing cannot be configured by the eNB/gNB), it is possible that different members of the queuing eventually choose different synchronization references. But even in the case of in-coverage convoy, this problem can arise; for example, all members may be configured to prefer using GNSS, but some members may not be able to establish a reliable GNSS connection. To avoid this problem, a mechanism for prioritizing (prioritizing) the synchronization signals received from the queuing manager or members may need to be considered, e.g., the queuing/group ID may be used to determine priority.

Therefore, it is proposed to treat eNB, LTE UE, RSU and the formation as potential different synchronization sources for the NR V2X sidelink.

Sidelink SSB design

For NR Uu, SSB including compact structure PSS/SSS/PBCH is used for synchronization. Since DL SSB is designed to support speeds up to 500Km/h, it is reasonable to reuse it for NR V2X to reduce standardization complexity and UE/hardware complexity. Therefore, it is proposed to use the NR Uu SSB design as a basis for the NR side downlink SSB.

NR PSSS/SSSS

In NR release 15, the number of physical cell IDs is 1008, given by N _ ID ^ cell ^ 3N _ ID ^ (1) + N _ ID ^ (2).

Good NR-PSS is an M sequence with 3 cyclic shifts to obtain 3 PSS signals: n _ ID ^ (2) is 0,1,2

Good NR-SSS is one M sequence with scrambling code to give 336 different IDs: n _ ID ^ (1) 0, 1.., 335;

on the other hand, in LTE release 14 sidelink, there are two PSSID groups to distinguish between in-coverage and out-of-coverage UEs. There are 168 PSSIDs in each PSSID group.

The NR PSS/SSS design may be reused for the NR PSSs/SSSs or modified to provide additional information (e.g., information related to SyncRef groups) while providing at least equivalent capacity to the LTE V2X design. For example, based on the NR PSS design, two PSSID groups in the PSSs may be used as in LTE V2X to distinguish between in-coverage and out-of-coverage UEs, while the third group may be used to identify UEs belonging to a particular group (e.g., LTE UEs, RSUs, or convoy).

NR PSBCH

The NR PSBCH should carry at least system timing information (i.e., SFN, half radio frame) and initial access information (i.e., SCS/DMRS related information, etc.), which is also part of the NR PBCH release 15. Furthermore, it may be considered whether the NR PSBCH should carry a coverage indicator for SyncRef determination as in LTE V2X (which may be modified if needed in combination with other SyncRef information, e.g. eNB/gNB differentiated), messages for unicast/multicast communication, resource pool and resource configuration information, and an indication on the slot format.

Multiple synchronization references

Targeting the preference of V2X for global synchronization and considering the possible advantages of eNB/gNB coexistence, formation user cases and other advanced user cases (extended sensors, advanced driving) and vehicles connected to different operators being able to communicate with each other, it can be considered to use multi-group synchronization signal search and tracking for NR V2X. Each UE may manage more than one synchronization group-source. For example, in this case, a vehicle belonging to one formation and willing to share its sensor information with other vehicles outside the formation should maintain at least two synchronization sources: one for formation; and one for communicating with vehicles outside the convoy. It is therefore proposed to consider tracking multiple synchronization references.

It is proposed to treat eNB, LTE UE, RSU and the formation as potential different synchronization sources for the NR V2X sidelink. The NR Uu SSB may be used as a design basis for the NR side downlink SSB.

Although not shown in detail, any device or apparatus forming part of a network may include at least one processor, a memory unit, and a communication interface. Wherein the processor unit, the memory unit and the communication interface are configured to perform the method of any aspect of the present application. Further options and choices are described below.

The signal processing functions of the embodiments of the present application (particularly the gNB and the UE) may be implemented using computing systems or architectures known to those skilled in the art. Computing systems such as desktop, laptop or notebook computers, handheld computing devices (PDAs, cell phones, palmtops, etc.), mainframes, servers, clients, 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 may include one or more processors. The processor may be implemented using a general-purpose or special-purpose processing engine. Such as a microprocessor, microcontroller or other control module.

The computing system may also include a main memory (e.g., Random Access Memory (RAM) or other dynamic memory) to store information and instructions to be executed by the processor. The main memory may also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor. The computing system may also include a Read Only Memory (ROM) or other static storage device for storing static information and instructions for the processor.

The computing system may also include an information storage system. The information storage system 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), a read-write drive (R or RW), or other removable or fixed media drive. The 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 can be read by and written to by a media drive. The storage media may include a computer-readable storage medium having stored therein particular computer software or data.

In alternative embodiments, the information storage system may include other similar components for allowing computer programs or other instructions or data to be loaded into the computer system. Such components may include, for example, removable storage units and interfaces, such as program cartridges and cartridge interfaces, removable memory (e.g., flash memory or other removable memory modules) and memory slots, and other removable storage units and interfaces. The interface allows software and data to be transferred from the removable storage unit to the computing system.

The computing system may also include a communications interface. Such communication interfaces can be used to allow software and data to be transferred between the computing system and external devices. Examples of communication interfaces may include modems, network interfaces (e.g., ethernet or other NIC cards), communication ports (e.g., Universal Serial Bus (USB) ports), PCMCIA slots and cards, and the like. Software and data transferred via the communication interface are in the form of signals. The signal can be an electronic signal, an electromagnetic signal, an optical signal, or other signal capable of being received by the communication interface medium.

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 memory, storage devices, or storage units. These and other forms of computer-readable media may store one or more instructions for use by a processor, including a computer system, to cause the processor to perform specified operations. These instructions, which are generally referred to as "computer program code" (which may be grouped in the form of computer programs or otherwise), when executed, enable the computing system to perform the functions of embodiments of the present application. Note that the code may directly cause the processor to perform specified operations, be compiled to cause the processor to perform specified operations, and/or be combined with other software, hardware, or firmware elements (e.g., libraries for performing standard functions) to cause the processor to perform specified operations.

The non-transitory computer readable medium may include at least one of: hard disks, CD-ROMs, optical storage devices, magnetic storage devices, read-only memories, programmable read-only memories, electrically erasable programmable read-only memories, and flash memories. In embodiments in which the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into the computing system using, for example, a removable storage drive. When executed by a processor in a computer system, the control module (in this example, software instructions or executable computer program code) causes the processor to perform the functions of the present application as described herein.

Furthermore, the concepts of the present application can be applied to any circuit that performs a signal processing function within a network element. For example, it is also contemplated that a semiconductor manufacturer may employ the concepts of the present application in the design of a stand-alone device (e.g., a microcontroller of a Digital Signal Processor (DSP)) or an Application Specific Integrated Circuit (ASIC) and/or any other subsystem element.

It should be appreciated that the above description, for clarity, describes embodiments of the application with reference to single processing logic. However, the inventive concept may equally be implemented by a plurality of different functional units and processors to provide the signal processing functionality. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, and not indicative of a strict logical or physical structure or organization.

Aspects of the present application may be implemented in any suitable form including hardware, software, firmware or any combination of these. The present application may optionally be implemented at least in part as computer software. The computer software may be run on one or more data processors and/or digital signal processors or configurable element modules such as FPGA devices.

Thus, the elements and components of an embodiment of the application 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 application has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. The scope of the application is limited only by the claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the application. In the claims, the term "comprising" does not exclude the presence of other elements or steps.

Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by e.g. 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. Likewise, 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.

Furthermore, the order of features in the claims does not imply that the features must be performed in any particular order. Especially the order of individual steps in the method claims does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. Furthermore, singular references do not exclude a plurality. Thus, references to "a", "an", "first", "second", etc., do not preclude a plurality.

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

Claims

1. A method of selecting a synchronization source to be used by a mobile device when the mobile device is in a defined group of mobile devices, the mobile device being configured to use sidelink communications to communicate with other mobile devices in the defined group, the method being performed at the mobile device and comprising the steps of:

receiving a synchronization source message indicating at least one synchronization source for use by the UE, wherein the at least one synchronization source message includes a second mobile device in the defined group; and

receiving a synchronization signal from a synchronization source indicated by the message.

2. The method of claim 1, wherein the synchronization source message is an RRC message.

3. The method of claim 2, wherein the sync source message comprises a SL-TypeTxSync information element.

4. A method according to claim 2 or 3, characterized in that the synchronization source message comprises a synchronization signal priority in a SL-V2X-preconfigured information element.

5. The method of claim 2, wherein the synchronization source message indicates a group ID for a group to which the mobile device belongs and an indication of at least one synchronization source for the group.

6. The method according to any of the preceding claims, characterized in that the mobile device is connected to an NR cellular communication network.

7. The method of any of the preceding claims, wherein the synchronization source message indicates more than one synchronization source and a relative priority for each indicated synchronization source.

8. The method of any of the preceding claims, wherein the synchronization signal is received from another mobile device in the defined group of mobile devices, and wherein the synchronization signal comprises at least one of:

slsid assigned specifically for the defined group of mobile devices;

assigning a PSSID for the defined group of mobile devices;

an indicator in MIB, SIB, RMSI, or OSI; and

an SLSS source.