CN115336379A

CN115336379A - Client device for exchanging sidelink configuration

Info

Publication number: CN115336379A
Application number: CN202080099152.5A
Authority: CN
Inventors: 泰摩尔·阿巴斯; 古斯塔夫·格莱森; 本特·林多夫; 毗湿奴·普雷曼; 拉马·库马尔·莫匹代韦
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-03-31
Filing date: 2020-03-31
Publication date: 2022-11-11
Also published as: WO2021197581A1

Abstract

The present disclosure relates to a first client device for exchanging assistance information and a sidelink configuration with a network entity and one or more second client devices with which the first client device is in sidelink communication. The first client device obtains assistance information from the one or more second client devices and sends the assistance information to the network entity. In response to the sending the assistance information, the first client device receives an updated sidelink configuration from the network entity and sends at least a portion of the updated sidelink configuration to the one or more second client devices. Thus, the network entity is enabled to update the sidelink configuration of the one or more second client devices through the first client device.

Description

Client device for exchanging sidelink configurations

Technical Field

The present disclosure relates to a first client device for exchanging sidelink configurations with a network entity and one or more second client devices. Furthermore, the disclosure also relates to a corresponding method and computer program.

Background

Vehicle-to-transportation (V2X) communication is one of the key driving factors of future cooperative intelligent transportation systems (C-ITS). The term V2X collectively denotes that the vehicle is in communication with anything on or along the roadway. V2X communication has two modes of operation, one is called PC5 or Sidelink (SL), i.e. direct device-to-device (D2D) communication, and the other is communication over the Uu interface, which is the interface between the User Equipment (UE) and the base station. These modes may be used by the UE independently or jointly. V2X communication over Uu is supported by Long Term Evolution (LTE) connected to 5G core network (5G core network,5 GC) and/or Evolved Universal Terrestrial Radio Access (EUTRA) in New Radio (NR) connected to 5 GC. Interworking between the 5GS V2X and the Evolved Packet System (EPS) V2X does not require any new interface between the 5GS V2X and the EPS V2X architecture, nor affects existing network functional entities in the Evolved Packet Core (EPC) and the 5 GC. V2X SL is introduced in LTE, supports direct communication between UEs, is in the dedicated ITS spectrum for V2X services, mainly in the 5.9GHz band. The SL is specifically designed to meet the requirements of advanced security applications. Compared to LTE which supports broadcast mode, the NR SL should also support unicast, multicast and broadcast communication. The carriers that the NR SL supports for direct SL communication are both licensed spectrum (which can also be used for NR Uu/LTE Uu operation) and dedicated ITS spectrum operating scenarios.

The parameter configuration for V2X communication through the PC5 or SL may be provided to the UE in various ways. If the UE is camped on a cell, the parameters may be provided/updated from a next generation node B (gNB), a network node (e.g., a Policy Control Function (PCF), a Session Management Function (SMF), etc.) through Radio Resource Control (RRC) messages, or from a V2X Application Server (AS) through a V1 interface. Some of the parameters may be pre-configured in a Mobile Equipment (ME) or may be configured in a Universal Integrated Circuit Card (UICC) for out-of-coverage or partial coverage operation.

Disclosure of Invention

It is an object of embodiments of the present invention to provide a solution to reduce or solve the disadvantages and problems of the conventional solutions.

The above and other objects are achieved by the subject matter of the independent claims. Further advantageous embodiments of the invention are provided in the dependent claims.

According to a first aspect of the present invention, the above and other objects are fulfilled by a first client device for a communication system, the first client device being adapted for sidelink communication with one or more second client devices based on a first sidelink configuration, the first client device being further adapted to:

obtaining assistance information associated with the sidelink communications from the one or more second client devices;

sending the assistance information to a network entity;

receiving, from the network entity, a second sidelink configuration associated with the sidelink communication in response to the sending the assistance information;

transmitting at least a portion of the second sidelink configuration to the one or more second client devices.

The assistance information associated with the sidelink communications may be any information that can assist in determining a sidelink configuration for the sidelink communications.

According to the first aspect, the first client device has the advantage that assistance information associated with the sidelink communication (e.g. assistance information about a second client device not within network coverage) is provided to the network entity. The side link configuration may then be used to determine the side link configuration to improve the robustness and reliability of the system. For example, the assistance information may be used to determine resources needed for efficient and reliable sidelink communications. Thereby optimizing system performance.

According to a first aspect, in one implementation form of a first client device, the obtaining the assistance information from the one or more second client devices comprises:

receiving the assistance information from the one or more second client devices in one or more direct link setup messages or one or more application layer messages.

An advantage of this implementation is that the assistance information may be obtained by the first client device in various ways, increasing the robustness of obtaining information from one or more second client devices. The received information may then be used by the first client device or sent to a network entity to determine a new sidelink configuration for efficient and reliable sidelink communications.

In an implementation form of the first client device according to the first aspect, after receiving the second sidelink configuration, sidelink communications are performed with the one or more second client devices based on the second sidelink configuration.

The advantage of this implementation is that system performance can be optimized in terms of robustness and reliability.

In an implementation manner of the first client device, after determining that the first client device is within a coverage area of a cell, the assistance information is sent to the network entity according to the first aspect.

In this disclosure, a first client device in coverage may be understood to mean that the first client device is connected to and/or registered in a cell. In the present disclosure, a cell may be understood to mean a cell supporting a sidelink function.

The advantage of this implementation is that a first client device that is in coverage is beneficial and plays a key role by sending assistance information to the network entity, which makes it possible for the network to learn about one or more second client devices that may be out of coverage and unable to connect to the network.

In an implementation form of a first client device according to the first aspect, the assistance information is sent to the network entity after determining that the first client device is within the coverage of the cell and determining that the one or more second client devices are outside the coverage of the cell.

In this disclosure, one or more second client devices being out of coverage may be understood to mean that the one or more second client devices are not connected to and/or not registered in the cell.

An advantage of this implementation is that the information sent by the first client device is about a second client device that is not connected to the network and therefore is unknown to the network. After the information is received by the network, the network may use the information to optimize system performance and determine the resources needed for efficient and reliable sidelink communications.

According to a first aspect, in an implementation form of a first client device, the first client device is configured to:

sending a measurement report to the network entity;

receiving an anchor configuration from the network entity in response to the sending the measurement report;

prior to sending the second sidelink configuration to the one or more second client devices, configuring to become an anchor client device based on the anchor configuration.

An advantage of this implementation is that the first client device may be used to act as an anchor for the network entity and there may be multiple anchor devices simultaneously connected to the cell. Anchor devices configured and/or managed by the network may help reduce signaling overhead and minimize interference.

According to the first aspect, in one implementation of the first client device, the measurement report is associated with at least one of: signal strength, channel busy ratio in the sidelink, guaranteed-quality-of-service (QoS), and priority vehicle information.

The advantage of this implementation is that these parameters are sufficiently versatile to be well-defined metrics for determining whether the system state is reliable and robust.

According to the first aspect, in an implementation manner of the first client device, the assistance information is at least one of the following: client device capabilities, subscription information, vehicle to networking (V2X) traffic types, sidelink QoS parameters, special priority information, application layer information, network layer protocol for sidelink, and sidelink group information.

The advantage of this implementation is that these parameters summarize the necessary information that may be needed on the network to understand the system requirements and determine the sidelink configuration in order to achieve a reliable and robust system based on time constraints.

In an implementation form of the first client device according to the first aspect, the assistance information is group assistance information of the first client device and the one or more second client devices or individual assistance information of a single client device.

An advantage of this implementation is that a first client device, being part of a group or communicating with respective second client devices, receives relevant information from one or more second client devices that are out of coverage. Thus, this information can be fully shared to the network for different use cases, thereby reducing the complexity of client device implementation.

In an implementation form of the first client device according to the first aspect, the first sidelink configuration and the second sidelink configuration are at least one of: radio bearer configuration, resource configuration, per-region resource configuration, and region configuration.

The advantage of this implementation is that well-defined containers are used to provide or update the sidelink configuration, thereby reducing interference and enabling optimal resource selection for sidelink communications in a well-defined and deterministic manner.

In one implementation form of the first client device according to the first aspect, the second sidelink configuration is received in any one of a radio resource control message, a non-access stratum signaling or an application message.

The advantage of this implementation is that it covers many possible known options for information exchange, thereby reducing the complexity of the client device implementation.

According to the first aspect, in an implementation manner of the first client device, the network entity is at least one of: a road side unit, a base station, an access and mobility management function, a policy control function, a unified data management, a V2X control function, a V2X application server, a V2X network function, or a V2X application function.

The advantage of this implementation is that it covers many possible options for the network entity, thereby reducing the complexity of the client device implementation.

According to a second aspect of the invention, the above and other objects are achieved by a method for a first client device for sidelink communication with one or more second client devices based on a first sidelink configuration, the method comprising:

sending the assistance information to a network entity;

The method according to the second aspect may be extended to implementations corresponding to the implementations of the first client device according to the first aspect. Accordingly, one implementation of the method includes the features of a corresponding implementation of the first client device.

The advantages of the method according to the second aspect are the same as the advantages of the corresponding implementation of the first client device according to the first aspect.

Embodiments of the invention also relate to a computer program, characterized by program code, which, when run by at least one processor, causes the at least one processor to perform any of the methods provided by embodiments of the invention. Furthermore, an embodiment of the invention relates to a computer program product comprising a computer readable medium and the computer program, wherein the computer program is comprised in the computer readable medium and comprises one or more of the group of: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), flash memory, electrically EPROM (EEPROM), and a hard disk drive.

Other applications and advantages of embodiments of the present invention will be apparent from the following detailed description.

Drawings

The attached drawings are included to describe and explain illustrative examples of the present invention. In the drawings:

FIG. 1 illustrates a first client device provided by an embodiment of the invention;

FIG. 2 illustrates a method for a first client device provided by an embodiment of the invention;

figures 3a to 3b illustrate a communication system provided by an embodiment of the present invention;

fig. 4 illustrates an interface between a first client device, a second client device, and a network entity provided by an embodiment of the invention;

FIG. 5 illustrates a method for a first client device provided by an embodiment of the invention;

fig. 6 illustrates a method for a first client device provided by an embodiment of the invention.

Detailed Description

In the 3GPP NR V2X work item of Rel-16, at least two SL resource allocation modes, mode 1 and mode 2, are defined. In mode 1, a Node B (NB) schedules SL resources, and in mode 2, the UE determines SL transmission resources within the NB and/or network configured SL resources or within pre-configured SL resources. NB here denotes an evolved node B (eNB) or a gNB, since both can control NR SL.

In the work item, four subcategories are assigned for SL resource allocation pattern 2:

in mode 2a, the UE autonomously selects SL resources for transmission.

In mode 2b, the UE assists other UEs in selecting SL resources.

In mode 2c, the UE is configured with NR configured grants (e.g. type 1) for SL transmission.

In mode 2d, the UE schedules SL transmissions for other UEs.

Mode 1, mode 2a and mode 2c have been considered for rel.16 work items, but mode 2b and mode 2d (where the UE may assist or schedule SL transmission resources for other UEs) are left in future releases.

For mode 1 and mode 2, the NB may provide the SL resource configuration directly to the UE when the UE is in coverage. For mode 2, the UE may also be preconfigured with a transmission pool. Mode 2b and mode 2d provide enhancements to the resource allocation mechanism for both V2X and non-V2X cases. The key aspects associated with these modes are:

(1) The UE relays the resource configuration from the gNB to another UE, an

(2) The scheduling UE determines SL resources for other UEs (e.g., a group of UEs).

The benefits of the UE assisting or scheduling resources for other UEs are mainly to improve packet transmission reliability, resource optimization and reduce communication overhead. A UE that assists or schedules resources for other UEs may be referred to as a scheduling UE, a relay UE, or an anchor UE.

In conference No. 3gpp TSG RAN WG1 96, it is agreed that NR V2X in the context of mode 2d for multicast communication supports the following functions: the UE informs the NB about the group members, and the NB provides a separate resource configuration to each group member UE within the same group via the UE, e.g., through RRC signaling. It does not require a connection between each member UE and the NB. However, the UE cannot modify the configuration provided by the NB. Furthermore, higher layer (L2, L3) signaling will be used to provide the configuration.

Therefore, in the context of multicast communications, it is proposed that the NB may provide a separate resource configuration to each group member, called member UE, through the anchor UE, but the details are yet to be explained in detail. This concept provides additional benefits, particularly in the case where the group members are out of coverage and the anchor UE is in coverage.

An out-of-coverage UE (OoC UE) may also establish a unicast link with an in-coverage UE. The UE in coverage may then establish a Uu link with the network. However, the in-coverage UE may not have enough information from the OoC UE to transmit to the network, e.g. capabilities of other UEs belonging to the same group as the OoC UE, subscription information of the OoC UE and its group members, etc.

From the above proposals, at least the following problems have been found:

the anchor UE does not provide the network with the required information about the OoC UE or member UEs so that resources can be determined and configurations provided.

All information needed for UE subscription authorization, granting service requests, and resource estimation may or may not be available to the anchor UE. The anchor UE acquires information required by the network from the member UEs through sidelink communication, or determines itself from previously acquired information, and then transfers the information to the network.

No connection is required between the member UEs and the NB, which means that all required information must be exchanged via the anchor UE, and higher layer signaling will be used to provide the configuration. The details of how the process proceeds, and which high layers are involved, are not clear.

When an OoC UE wishes to send information to the network via a unicast link through a relay UE, there is now no mechanism to include the required information in the unicast link setup.

Therefore, a solution to the above-mentioned disadvantages is needed. It is therefore an object of the present disclosure to identify and specify information content and parameters in signaling from an anchor UE to a network entity to enable different types of sidelink communications. Another object is to provide a method of exchanging information between an OoC UE and an anchor UE and between the anchor UE and a network entity, in particular when the anchor UE is in coverage and is scheduling resources or assisting relay resource configuration for at least one UE that is out of coverage and not connected to an NB.

Fig. 1 illustrates a first client device 100 provided by an embodiment of the present invention. In the embodiment shown in fig. 1, the first client device 100 includes a processor 102, a transceiver 104, and a memory 106. The processor 102 may be coupled to the transceiver 104 and the memory 106 by a communication module 108 as is known in the art. The first client device 100 may also include an antenna or antenna array 110 coupled to the transceiver 104, which means that the first client device 100 may be used to communicate in a communication system.

The first client device 100 may be used to perform certain actions as understood in this disclosure to mean that the first client device 100 includes suitable modules, such as the processor 102 and the transceiver 104, for performing the actions.

The processor 102 of the first client device 100 may be referred to as one or more general purpose Central Processing Units (CPUs), one or more Digital Signal Processors (DSPs), one or more application-specific integrated circuits (ASICs), one or more Field Programmable Gate Arrays (FPGAs), one or more programmable logic devices, one or more discrete gates, one or more transistor logic devices, one or more discrete hardware components, one or more chipsets.

The memory 106 of the first client device 100 may be read-only memory, random access memory, or non-volatile random access memory (NVRAM).

The transceiver 104 of the first client device 100 may be a transceiver circuit, a power controller, an antenna, or an interface to communicate with other modules or devices.

In embodiments, the transceiver 104 of the first client device 100 may be a separate chipset, or it may be integrated with the processor 102 in one chipset. While in some embodiments, the processor 102, transceiver 104, and memory 106 of the first client device 100 are integrated in one chipset.

According to an embodiment of the present invention, first client device 100 is configured to conduct sidelink communications with one or more

second client devices

600a, 600b, \ 8230 \ 8230;, 600n based on a first sidelink configuration. First client device 100 is also configured to obtain ancillary information associated with the sidelink communications from one or more

second client devices

600a, 600b, \8230;, 600n. The first client device 100 is further configured to send assistance information to the network entity 300; receiving, from the network entity 300, a second sidelink configuration associated with the sidelink communication in response to sending the assistance information; and sends at least a portion of the second sidelink configuration to one or more

second client devices

600a, 600b, \ 8230 \ 8230;' 600n.

Fig. 2 shows a flow diagram of a corresponding method 200 that may be performed in the first client device 100 (such as the first client device shown in fig. 1). First client device 100 is configured to communicate with one or more

second client devices

600a, 600b, \8230;, 600n for sidelink based on a first sidelink configuration. Method 200 includes obtaining (202) secondary information associated with the sidelink communication from one or more

second client devices

600a, 600b, \8230;, 600n. The method 200 further comprises: sending (204) assistance information to the network entity 300; receiving (206), from the network entity 300, a second sidelink configuration associated with the sidelink communication in response to sending the assistance information; and sending (208) at least a portion of the second sidelink configuration to one or more

second client devices

600a, 600b, \ 8230 \ 8230;' 600n.

Fig. 3a to 3b illustrate a communication system 500 provided by an embodiment of the present invention. Communication system 500 includes a network entity 300, a first client device 100, and one or more

second client devices

600a, 600b, \ 8230 \ 8230;, 600n, all configured to operate in communication system 500. In the embodiment shown in fig. 3 a-3 b, a first client device 100 and one or more

second client devices

600a, 600b, \ 8230; \ 8230;, 600n are used for multicast sidelink communications with each other over a PC5 interface. However, the sidelink communications may also be unicast communications or broadcast communications. In an embodiment, the sidelink communications may be V2X communications for V2X traffic or applications. Further, the sidelink communication may be based on NR or LTE Radio Access Technology (RAT), but is not limited thereto.

In fig. 3a, a first client device 100 and one or more

second client devices

600a, 600b, \ 8230; \ 8230;, 600n are out of coverage, i.e., not connected or registered to any cell in the communication system 500. First client device 100 and one or more

second client devices

600a, 600b, \ 8230; \8230;, 600n thus communicate within the group over the sidelink using either pre-configured resources or provisioned resources.

In fig. 3b, the group has moved and the first client device 100 has entered the cell coverage. Upon entering the cell coverage, the first client device 100 may detect the cell identity and connect or register to the cell. Thus, the first client device 100 is in coverage and connected to the network. In the embodiment shown in fig. 3a to 3b, the network entity 300 is a base station, and a Uu interface is established between the first client device 100 and the network entity 300. However, in embodiments, the network entity 300 may instead be at least one of: a road side unit, a base station, an access and mobility management function, a policy control function, a unified data management, a V2X control function, a V2X application server, a V2X network function, or a V2X application function.

The connection between the first client device 100 and the network node 300 enables the network entity 300 to exchange information with one or more

second client devices

600a, 600b, \8230;, 600n through the first client device 100, i.e. the first client device 100 may act as an anchor and/or relay client device. If network entity 300 wishes to provide a separate resource pool configuration and/or a separate resource configuration to one or more

second client devices

600a, 600b, \ 8230; \8230;, 600n via first client device 100, then network entity 300 needs certain information about one or more

second client devices

600a, 600b, \8230;, 600n and their presence. Embodiments of the present invention provide methods of exchanging such information between a first client device 100 and one or more

second client devices

600a, 600b, \8230;, 600n, and between the first client device 100 and a network entity 300. The information may be assistance information that may assist in determining a sidelink configuration and/or a sidelink configuration for sidelink communications.

According to embodiments of the present invention, the exchange of the side information and the sidelink configuration may be performed over different interfaces. Fig. 4 shows an example of interfaces (shown with arrows in fig. 4) between the first client device 100 and one second client device 600n and between the first client device 100 and the network entity 300, over which the assistance information and the sidelink configuration may be transmitted. The network entity 300 may be any one of a base station (NB) in fig. 4, an access and mobility management function (AMF) in a Core Network (CN), and an Application (APP) server in a Data Network (DN).

Fig. 5 shows a flow diagram of a method 400 for exchanging assistance information and sidelink configuration provided by an embodiment of the present invention. Method 400 may be performed by first client device 100 when first client device 100 is configured to communicate with one or more

second client devices

600a, 600b, \8230; \ 600n for sidelink based on a first sidelink configuration. The first sidelink configuration may be at least one of: radio bearer configuration, resource configuration, per-region resource configuration, and region configuration.

Sidelink communications between first client device 100 and one or more

second client devices

600a, 600b, \8230;, 600n based on the first sidelink configuration may be unicast, multicast, and/or broadcast communications, and may occur, for example, over a PC5 interface. Sidelink communications may be performed to exchange information such as secure messages (e.g., collaboration Aware Messages (CAM), decentralized Environment Notification Messages (DENM)), or non-secure messages received at an upper layer (e.g., an application layer in

client devices

100, 600a, 600b, \ 8230; \ 8230;, 600 n). Some of this information may be further forwarded to lower layers.

In step 402, first client device 100 obtains auxiliary information associated with sidelink communications from one or more

second client devices

600a, 600b, \8230;, 600n. First client device 100 may obtain assistance information from one or more

second client devices

600a, 600b, \ 8230; \8230; \ 8230; 600n during sidelink establishment or after sidelink establishment (i.e., during sidelink communication). In an embodiment, first client device 100 may obtain the assistance information by receiving the assistance information from one or more

second client devices

600a, 600b, \8230 \ 8230;, 600n in one or more direct link setup messages or in one or more application layer messages.

When the first client device 100 receives the assistance information from one or more

second client devices

600a, 600b, \8230;, 600n in one or more direct link setup messages, the assistance information may be included in one or more containers in the one or more direct link setup messages, e.g., as one or more information elements. In a V2X scenario, the direct link setup message may be a direct link setup request message defined in 3GPP technical specification 24.587. The direct link setup request message may be sent from the

second client device

600a, 600b, \8230;, 600n to the first client device 100 during unicast sidelink setup. The direct link setup request message may be extended/enhanced with a new V2X information container including the side information. Table 1 shows the contents of such an extended direct link setup request message including a V2X information container.

TABLE 1

Similar V2X information containers may also be included in the setup messages for broadcast and multicast communications.

As described above, the assistance information may also be received in one or more application layer messages from one or more

second client devices

600a, 600b, \8230; \8230, 600n. The one or more application layer messages may be, for example, messages exchanged over a V5 interface between V2X applications in first client device 100 and one or more

second client devices

600a, 600b, \8230 \ 8230;, 600n, respectively, see fig. 4.

According to an embodiment of the present invention, the auxiliary information may be at least one of: client device capabilities, subscription information, vehicle networking (V2X) traffic type, sidelink QoS parameters, special priority information, application layer information, network layer protocol for sidelink, and sidelink group information. In a non-limiting embodiment:

the client device capabilities may include V2X capability parameters.

The subscription information may include data related to a subscription or policy of the client device.

The V2X service type may include a Provider Service Identifier (PSI)/Intelligent Transportation System (ITS) application ID of the V2X application.

The sidelink QoS parameters may include QoS parameters associated with V2X traffic, such as PC5 flow ID (PC 5 flow ID, PFI), PC 5G QoS indicator (PC 5G QoS indication, PQI), scope, packet priority, and the like.

The special priority information may include information about special vehicles (e.g., rescue vehicles, emergency vehicles, or safety vehicles) that may require dedicated resources to ensure certain QoS. This information may include vehicle role, vehicle type, individual vehicles or groups of vehicles moving in the fleet, and other geographic situation data.

The application layer information may include an application layer ID of the client device. The application layer ID may be used at a lower layer that dynamically forms a group, and the application does not notify the V2X layer of the group ID. Instead, the V2X layer passes the mapping of the application ID and the group ID, and the 5QI and scope parameters to the access layer for group formation.

The network layer protocol of the sidelink may vary from stack to stack and implementation (e.g., geoNetworking, WSMP, IPv6, etc.).

The sidelink group information may include:

general group-related information, such as group size in terms of number of vehicles, size of each vehicle, total weight including weight of container (if applicable), inter-vehicle distance, position of vehicle in queue, platooning level, or automation level.

When the first client device 100 is not part of a group, the destination layer 2ID of the group, also referred to as group ID.

Group leader the UE layer 2ID of the group leader when multicasting the communication.

-UE layer 2ID of group members; making the network aware of each group member. So that the network is better informed of the situation because the group members will also participate in other multicast or unicast communications.

-the respective coverage status of the member client devices, i.e. in-coverage or out-of-coverage.

Further, the assistance information may be group assistance information of the first client device 100 and one or more

second client devices

600a, 600b, \8230;, 600n or individual assistance information of a single client device. In this way, the auxiliary information can be adjusted according to different use cases. For example, the group assistance information may be associated with a group of client devices configured for multicast communication over a sidelink for use in a queued travel, or the like, use case. In this case, the group assistance information may include information on the group size, the number of members, the direction, the ability, the type and size of vehicles in the group, and the like.

In step 404 of fig. 4, the first client device 100 sends assistance information to the network entity 300. The transmitted assistance information may include all or part of the assistance information acquired by the first client device 100 in step 402. The assistance information informs the network entity 300 about information of one or more

second client devices

600a, 600b, \8230;, 600n engaged in sidelink communication with the first client device 100 and assists the network entity 300 in determining whether to change and/or update the first sidelink configuration. In an embodiment, the first client device 100 may send the assistance information to the network entity 300 in an existing RRC message, in a new container in an existing RRC message or in a new RRC message. Examples of existing RRC messages that may be used are the sidelinkuekinformation message or the UE AssistanceInformation message specified for EUTRA.

In an embodiment, upon determining that the first client device 100 is within the coverage of the cell, the first client device 100 may send assistance information to the network entity 300. The first client device 100 being within the coverage of a cell may be understood to mean that the first client device 100 is connected to and/or registered in a cell, e.g. the first client device 100 is camping on. Thus, in an embodiment, the sending of assistance information to the network entity 300 may be triggered when the first client device 100 moves from out-of-coverage to in-coverage of a cell, i.e. when connecting to a cell and/or registering in a cell.

Further, upon determining that first client device 100 is within the coverage of a cell and determining that one or more

second client devices

600a, 600b, \ 8230 \ 8230;, 600n are outside the coverage of the cell, first client device 100 may send assistance information to network entity 300. In this way, the assistance information may be sent to the network entity 300 to inform the network entity 300 about information of one or more

second client devices

600a, 600b, \8230;, 600n engaged in sidelink communication with the first client device 100, which are out of coverage and therefore do not communicate directly with the network entity 300.

In step 406, the first client device 100 receives a second sidelink configuration associated with the sidelink communication from the network entity 300 in response to sending the assistance information. The received second sidelink configuration may be determined by the network entity 300 based on assistance information received from the first client device 100, and optionally based on additional information obtained by the network entity 300 from other client devices or network entities. For example, when one or more

second client devices

600a, 600b, \8230 \ 8230; \8230;, 600n are within the coverage, the auxiliary information may be provided directly to the network entity 300 from one or more

second client devices

600a, 600b, \8230;, 600n. In a V2X scenario, a

second client device

600a, 600b, \8230;, a V2X application in 600n may provide auxiliary information to a V2X application server in a network through a V1 interface, and a V2X control function may interact with the V2X application server through a V2 interface. When the network entity 300 is a core network node, the supplementary information may also be sent to the network entity 300 using Non Access Stratum (NAS) signaling. The network entity 300 may also receive configuration updates from the core network and the application servers. The second sidelink configuration may also be determined by the network entity 300 in cooperation with one or more other network nodes.

The first client device 100 may receive the second sidelink configuration in any of a radio resource control message, non-access stratum signaling, or an application message. In the same manner as the first sidelink configuration, the second sidelink configuration may be at least one of: radio bearer configuration, resource configuration, per-region resource configuration, and region configuration. The radio bearer configuration may include physical information and/or configurations, such as hybrid automatic repeat request (HARQ) and Channel State Information (CSI). For example, the resource configuration may be a resource pool or a dedicated resource per QoS flow per V2X service, wherein the resource may be a time and/or frequency resource. The per-region resource configuration may include one or more resource pools per region configured by the network, and the mapping may be sent via an RRC message in one of the containers, e.g., one of v2x-comm (tm) port normalcommon, v2x-comm (tm) port normalcredicted, v2x-comm (tm) port normalcommal, etc. Further, the zone configuration may indicate that the zone configuration of one or more

second client devices

600a, 600b, \8230; \8230, 600n, which are out of cell-specific coverage, may be sent through an RRC message in one of the containers (e.g., zoneConfig, etc.).

In step 408, first client device 100 sends at least a portion of the second sidelink configuration to one or more

second client devices

600a, 600b, \ 8230 \ 8230;, 600n. First client device 100 may send at least a portion of the second sidelink configuration to one or more

second client devices

600a, 600b, \8230;, 600n in a number of different manners, such as at the application layer, using RRC signaling, or using other lower layer control signaling.

Depending on the content of the second sidelink configuration and the applicability to one or more

second client devices

600a, 600b, \8230;, 600n, first client device 100 may send the complete second sidelink configuration or a subset of the second sidelink configuration to one or more

second client devices

600a, 600b, \8230;, 600n. First client device 100 may also determine and allocate one or more

second client devices

600a, 600b, \8230;, 600n of particular resources based on the second sidelink configuration. For example, in a queue use case, the first client device 100 may be a queue leader that leads a group of vehicles. The first client device 100 may then determine and allocate resources for each member of the group based on the second sidelink configuration. In this case, the first client device 100 may also take into account assistance information from members of the group when determining and allocating resources.

In step 410, upon receiving the second sidelink configuration, the first client device 100 may conduct sidelink communications with one or more

second client devices

600a, 600b, \ 8230 \ 8230;, 600n based on the second sidelink configuration. When the second sidelink configuration applies to the first client device 100, e.g. when the first client device 100 is part of a unicast or multicast sidelink communication, step 410 is performed, with which the network has allocated a new resource configuration using the second sidelink configuration. When the second sidelink configuration is not applicable to the first client device 100, the first client device 100 in step 408 may only relay the second sidelink configuration received from the network entity 300 in step 406 to one or more

second client devices

600a, 600b, \8230; \8230, 600n, which may then be used for sidelink communication based on the second sidelink configuration by one or more

second client devices

600a, 600b, \8230; \8230, 600n.

According to embodiments of the present invention, first client device 100 may be configured to act as an anchor client device for one or more

second client devices

600a, 600b, \8230;, 600n. A first client 100 may be in coverage and used to act as an anchor client device for one or more

second client devices

600a, 600b, \8230;, 600n that are out of coverage. In this way, a first client 100 that is within coverage and thus capable of communicating directly with network entity 300 may relay information to one or more

second client devices

600a, 600b, \8230;, 600n.

Fig. 6 illustrates a flow chart of a method 600 for configuring the first client device 100 as an anchor client device provided by an embodiment of the present invention. The method 600 may be performed in the first client device 100 and may be initiated by the first client device 100, for example, when the first client device 100 moves within the coverage of a cell and establishes communication with the network entity 300.

In step 602, the first client device 100 may indicate to the network entity 300 that the first client device 100 is in sidelink communication with one or more

second client devices

600a, 600b, \ 8230 \ 823030, 600n that are out of coverage. The indication may include very basic or limited information about one or more

second client devices

600a, 600b, \8230;, 600n.

Once network entity 300 has identified one or more out-of-coverage

second client devices

600a, 600b, \8230;, 600n, network entity 300 may wish to assist one or more

second client devices

600a, 600b, \8230;, 600n with resource configuration. To this end, the network entity 300 may request the first client device 100 to perform measurements and report the measurement results.

Thus, the first client device 100 may perform measurements and monitor the measurement results in step 604, wherein the measurement results may be monitored based on the threshold and/or trigger conditions received from the network entity 300.

In step 606, the first client device 100 sends a measurement report to the network entity 300. The measurement report may be sent upon detecting that a threshold and/or a trigger condition is met. The measurement report may be associated with at least one of: signal strength, channel busy ratio in the sidelink, guaranteed sidelink quality of service (QoS), and priority vehicle information.

In response to sending the measurement report, the first client device 100 receives an anchor point configuration from the network entity 300 in step 608. The anchor configuration may include information for at least one of: enabling a first client device 100 to obtain information from one or more

second client devices

600a, 600b, \8230;, 600 n; enabling the first client device 100 to send the obtained information and the assistance information to the network entity 300; and enabling the first client device 100 to schedule resources for one or more

second client devices

600a, 600b, \ 8230; \8230;, 600n by processing the obtained information and determining appropriate resources.

In step 610, the first client device 100 is configured to become an anchor client device based on the anchor configuration. For example, first client device 100 acting as an anchor client device may assist in relaying resource configurations from network entity 300 to one or more

second client devices

600a, 600b, \8230;, 600n that are out of coverage. For example, first client device 100, as an anchor client device, may relay the second sidelink configuration to one or more

second client devices

600a, 600b, \8230;, 600n, as described with reference to fig. 5. In this case, first client device 100 is configured to become an anchor client device based on the anchor configuration prior to sending the second sidelink configuration to one or more of

second client devices

600a, 600b, \ 8230 \ 8230;, 600n, i.e., prior to step 408 in method 400. In an embodiment, method 600 may be performed prior to method 400 such that first client device 100 receives assistance information from one or more

second client devices

600a, 600b, \ 8230; \8230;, 600n after first client device 100 has been configured to act as an anchor client device.

The auxiliary information from one or more

second client devices

600a, 600b, \ 8230; \8230;, 600n to first client device 100 acting as an anchor client device may be application specific for certain use cases. The following are some examples of possible assistance information from one or more

second client devices

600a, 600b, \ 8230; \8230;, 600n (hereinafter referred to as out-of-coverage (oC) UEs) to the first client device 100 when the first client device 100 is acting as an anchor client device:

client device capabilities: the OoC UE may indicate its V2X capability parameters, e.g. UE supporting LTE or NR (V2X-EUTRA), to the first client device 100. Depending on whether the OoC UE is preconfigured with radio access parameters, such as radio frequency, physical layer or layer 2 parameters, there are two options:

-pre-configuration: in this case, it is sufficient for the network entity 300 to know whether the OoC UE supports LTE or NR.

Thus, the first client device 100 collects this information and may send, for example, the number of oc UEs supporting LTE and the number of oc UEs supporting NR to the network entity 300.

-not preconfigured: in this case, the first client device 100 needs to collect and send the capabilities of the OoC UE to the network entity 300. The first client device 100 may extend the existing mechanism (e.g. receive "PC 5" from OoC UE)

Capability information in RRC message ") to collect capability information of the OoC UE. The first client device 100 may ask the OoC UE for the UE capability information in the "PC5 UE capability query", or the OoC UE may announce the capability information to the first client device 100. Once the information is collected by the first client device 100, the information may be sent to the network entity 300 in a UE-EUTRA-Capability and/or UE-NR-Capability information element, such as:

existing RRC messages (e.g., sidelinkUEInformation) may be extended to carry new information elements or new messages may be defined.

V2X traffic type and associated PC5 QoS parameters: in the case of multicast communication, these parameters are known to all group members when the group is established, and so in the unicast case. However, if the first client device 100 is scheduling resources for unicast or multicast sidelink communications where the first client device 100 is not part of a unicast or multicast communication, the first client device 100 is unaware of these parameters. Therefore, the group member has to provide the first client device 100 with parameters, e.g. V2X traffic type, e.g. Provider Service Identifier (PSI)/ITS application ID of the V2X application, and for each V2X traffic type, associated QoS parameters, e.g. PC5 flow ID (PFI), PC 5G QoS indication (PQI), scope, packet priority, etc., as auxiliary information.

In an embodiment, a first client device 100 acting as an anchor client device may be a Road Side Unit (RSU) in a V2X application, and one or more

second client devices

600a, 600b, \8230 \ 8230;, communication between 600n and the RSU may be a sidelink communication or a Uu communication, depending on whether the RSU is a UE type or a gNB type. The RSU unit may be any device/node deployed along a road to improve vehicle network performance, as well as extend coverage. The RSU unit may be a stand-alone device/node or may be integrated with e.g. a network access node.

First client device 100 and one or more

second client devices

600a, 600b, \8230 \ 8230;, 600 in this disclosure include, but are not limited to: UEs, such as smart phones, cellular phones, cordless phones, session Initiation Protocol (SIP) phones, wireless Local Loop (WLL) stations, personal Digital Assistants (PDAs), handheld devices with communication capabilities, computing or other processing devices connected to wireless modems, in-vehicle devices, wearable devices, access-backhaul Integrated (IAB) nodes, such as mobile cars or devices installed in cars, drones, terminal-direct-to-device (D2D) devices, wireless cameras, mobile stations, access terminals, subscriber units, wireless networks, wireless Local Area Network (WLAN) stations, wireless CPE-enabled tablets, laptop-type devices, universal Serial Bus (USB) converters, wireless premises equipment (WLAN) devices, and embedded chipsets. In an Internet of things (IOT) scenario, the first client device 100 may represent a machine or another device or chipset that communicates with another wireless device and/or network device.

The UE may also be referred to as a mobile phone, a cellular phone, a tablet computer with wireless capability, or a notebook computer. In this context, a UE may be, for example, a portable, pocket-storage, hand-held, computer-comprised, or vehicle-mounted mobile device capable of transmitting voice and/or data with another entity (e.g., another receiver or server) over a radio access network. A UE may be a Station (STA), which is any device that includes IEEE 802.11 compliant Medium Access Control (MAC) and physical layer (PHY) interfaces to the Wireless Medium (WM). The UE may also be used for communication in 3GPP related LTE and LTE-Advanced, in WiMAX and its evolution, and in fifth generation wireless technologies such as NR.

Furthermore, any of the methods provided by embodiments of the invention may be implemented in a computer program having code means which, when run by a processing module, causes the processing module to perform the method steps. The computer program is embodied in a computer readable medium of a computer program product. The computer-readable medium may include substantially any memory, such as a read-only memory (ROM), a programmable read-only memory (PROM), an Erasable PROM (EPROM), a flash memory, an Electrically Erasable PROM (EEPROM), or a hard drive.

Furthermore, those skilled in the art realize that embodiments of the first client device 100 comprise necessary communication capabilities in the form of, for example, functions, modules, units, elements, etc. for performing the scheme. Examples of other such modules, units, elements and functions are: processors, memories, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selection units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiving units, transmitting units, DSPs, MSDs, TCM encoders, TCM decoders, power supply units, power feeders, communication interfaces, communication protocols, etc., suitably arranged together to implement a scheme.

In particular, the processor of the first client device 100 may include, for example, one or more of the following: a Central Processing Unit (CPU), processing unit, processing circuit, processor, application Specific Integrated Circuit (ASIC), microprocessor, or other processing logic that may interpret and execute instructions. The expression "processor" may thus denote processing circuitry comprising a plurality of processing circuits, for example any, some or all of the items listed above. The processing circuitry may also perform data processing functions for inputting, outputting, and processing data, including data buffering and device control functions, such as call processing control, user interface control, and the like.

Finally, it is to be understood that the embodiments of the invention are not limited to the embodiments described above, but that they also relate to and incorporate all embodiments within the scope of the appended independent claims.

Claims

1. A first client device (100) for a communication system (500), the first client device (100) for sidelink communication with one or more second client devices (600 a, 600b, \8230; 600 n) based on a first sidelink configuration, the first client device (100) further for:

obtaining auxiliary information associated with the sidelink communications from the one or more second client devices (600 a, 600b, \8230; 600 n);

sending the assistance information to a network entity (300);

receiving, from the network entity (300), a second sidelink configuration associated with the sidelink communication in response to the sending the assistance information;

at least a portion of the second sidelink configuration is transmitted to the one or more second client devices (600 a, 600b, \8230;, 600 n).

2. The first client device (100) of claim 1, wherein obtaining the assistance information from the one or more second client devices (600 a, 600b, \8230;, 600 n) comprises:

the assistance information is received from the one or more second client devices (600 a, 600b, \8230;, 600 n) in one or more direct link setup messages or one or more application layer messages.

3. The first client device (100) of claim 1 or 2, configured to:

sidelink communications with the one or more second client devices (600 a, 600b, \ 8230; \8230;, 600 n) based on the second sidelink configuration are performed after receiving the second sidelink configuration.

4. The first client device (100) of any one of the preceding claims, configured to:

upon determining that the first client device (100) is within a coverage area of a cell, sending the assistance information to the network entity (300).

5. The first client device (100) of claim 4, configured to:

upon determining that the first client device (100) is within a coverage area of the cell and determining that the one or more second client devices (600 a, 600b, \8230; 600 n) are outside the coverage area of the cell, sending the assistance information to the network entity (300).

6. The first client device (100) of any one of the preceding claims, configured to:

sending a measurement report to the network entity (300);

receiving an anchor point configuration from the network entity (300) in response to the sending of the measurement report;

prior to sending the second sidelink configuration to the one or more second client devices (600 a, 600b, \8230;, 600 n), the client device is configured to become an anchor client device based on the anchor configuration.

7. The first client device (100) of claim 6, wherein the measurement report is associated with at least one of: signal strength, channel busy ratio in the sidelink, guaranteed sidelink quality of service (QoS), and priority vehicle information.

8. The first client device (100) according to any one of the preceding claims, wherein the assistance information is at least one of: client device capabilities, subscription information, vehicle networking (V2X) traffic type, sidelink QoS parameters, special priority information, application layer information, network layer protocol for sidelink, and sidelink group information.

9. The first client device (100) of any one of the preceding claims, wherein the assistance information is group assistance information of the first client device (100) and the one or more second client devices (600 a, 600b, \8230;, 600 n) or individual assistance information of a single client device.

10. The first client device (100) of any one of the preceding claims, wherein the first sidelink configuration and the second sidelink configuration are at least one of: radio bearer configuration, resource configuration, per-region resource configuration, and region configuration.

11. The first client device (100) of any one of the preceding claims, being configured to:

receiving the second sidelink configuration in any of a radio resource control message, non-access stratum signaling, or an application message.

12. The first client device (100) according to any one of the preceding claims, wherein the network entity (300) is at least one of: a road side unit, a base station, an access and mobility management function, a policy control function, a unified data management, a V2X control function, a V2X application server, a V2X network function, or a V2X application function.

13. A method (200) for a first client device (100), the first client device (100) for sidelink communication with one or more second client devices (600 a, 600b, \8230; 600 n) based on a first sidelink configuration, the method (200) comprising:

obtaining (202) secondary information associated with the sidelink communications from the one or more second client devices (600 a, 600b, \8230; 600 n);

sending (204) the assistance information to a network entity (300);

receiving (206), from the network entity (300), a second sidelink configuration associated with the sidelink communication in response to the sending the assistance information;

sending (208) at least a portion of the second sidelink configuration to the one or more second client devices (600 a, 600b, \8230;, 600 n).

14. A computer program having a program code for performing the method according to claim 13, when the computer program runs on a computer.