EP3959916A1

EP3959916A1 - Method and apparatus for zone adaptation in a network

Info

Publication number: EP3959916A1
Application number: EP20725988.8A
Authority: EP
Inventors: Elke Roth-Mandutz; Khaled Hassan; Shubhangi BHADAURIA; Martin Leyh; Dariush Mohammad SOLEYMANI; Bernhard Niemann
Original assignee: Fraunhofer Gesellschaft zur Foerderung der Angewandten Forschung eV
Current assignee: Fraunhofer Gesellschaft zur Foerderung der Angewandten Forschung eV
Priority date: 2019-04-26
Filing date: 2020-04-24
Publication date: 2022-03-02
Also published as: WO2020216942A1; EP3731554A1

Abstract

The present disclosure relates to a method and a network node for defined geographical area such as zone or validity area adaptation in a network. The network node is configured to enhance an information element associated with configuration of defined geographical areas by including at least a third dimension in addition to the two other dimensions, and to adapt the defined geographical area based on at least the speed of vehicles and the topology of highways, and to further adapt the length, width and height of a defined geographical area. The network node may also configure defined geographical areas for unicast, groupcast and broadcast communications, and to adapt the defined geographical areas to fulfil QoS requirements.

Description

METHOD AND APPARATUS FOR ZONE ADAPTATION IN A NETWORK

Technical Field

The present disclosure relates to the field of telecommunications and in particular to a method and a network node for defined geographical area such as zone, validity area adaptation in a network.

Background

Sidelink in Long Term Evolution (LTE) is a feature first introduced in 3^rd Generation Partnership Project (3GPP) Release 12 aiming at enabling device-to-device (D2D) communications within legacy cellular- based LTE radio access networks. Sidelink has been enriched in Releases 13 and 14 with various features. D2D is applicable to public safety and commercial communication use-cases, and to vehicle- to-everything (V2X) scenarios (Rel. 14 and Rel. 15). In legacy uplink/downlink, two UEs communicate through the Uu interface and data are always traversing the LTE radio base station (or eNB). Differently, sidelink enables the direct communication between proximal UEs using the defined PC5 (Proximity Communication 5) interface, and data does not need to go through the eNB. Services provided in this way are often called“Proximity Services” (or ProSe) and the UEs supporting this feature“ProSe”-enabled UEs.

For sidelink (SL) resource allocation within cells, in e.g. an LTE-based network, two-dimensional (2D) zones may be defined using the width and the length as described in 3GPP Technical Specification standard document 3GPP TS 36.331. A maximum of 16 2D geo-zones maybe set up. The zones are geometrically fixed which is that they are (quasi) static over time.

The concept with 16 geo-zones in LTE V2X (Vehicle-to-everything) based network is that it is too inflexible with respect to the requirements posed by sidelink in New Radio (NR) also known as 5G, especially regarding unicast, groupcast and broadcast.

For LTE V2X, only broadcast is supported. For example, groupcast (or platooning) may need an allocated resource pool (RP), which is defined along its track considering:

- the current position of the GL / complete platoon (a group of vehicles)

- the driving direction

- the speed

- the length of the platoon

Furthermore, LTE zones do not consider different services, Quality-of-Service (QoS), traffic type (sporadic, periodic) and related requirements. For the zone concept in LTE, sidelink communication is broadcast-based with open-loop power control, which inherently is subject to the near-far problem, and consequently unbalanced receiving power at different vehicles.

Release14 introduced - to mitigate this undesired effect, i.e. the near-far problem - a geographical zone-based resource usage concept (geo-zoning).

Geo-zoning allows a group of vehicles located in one geo-zone (e.g., a segment of a road) and other vehicle groups in neighboring zones to use radio resources in a time-multiplexed manner, based on their GPS coordinates.

Geo-zones as well as the mapping between the geo-zones and sidelink/PC5 radio resource pools may be configured by a network node or an eNodeB (or eNB) or may be pre-configured for vehicles that are out of network coverage. A Vehicle determines the geo-zone identity based on the (pre-) configuration and its current location. The vehicle uses resource pools mapped to that particular zone

As mentioned earlier, For LTE V2X in Release 14/15, zones are defined, which are used for resource allocation. A maximum 16 2-dimensional geographical zones ( geo-zones ) may be defined, and only 2-dimensional: width/length is defined (see 3GPP TS 36.331 V 15.3.0, Release 15 (2018-10). In this standard document, an prior art information element (IE) is defined and denoted SL-ZoneConfig, which indicates zone configurations used for V2V sidelink communication.

SL-ZoneConfig

where:

zoneLength

Indicates the length of each geographic zone. Value m5 corresponds to 5 meters, m10 corresponds to 10 meters and so on.

zoneWidth

Indicates the width of each geographic zone. Value m5 corresponds to 5 meters, m10 corresponds to 10 meters and so on.

zoneldLongiMod

Indicates the total number of zones that is configured with respect to longitude. zoneldLatiMod

Indicates the total number of zones that is configured with respect to latitude.

Also mentioned earlier is that the 16 geo-zones in LTE V2X are not flexible enough for NR (or 5G) and possibly for future enhancements of LTE V2X, e.g. regarding unicast, multicast and broadcast, but also regarding highway scenarios and huge park houses. For example, currently the size of each zone is limited to a maximum of 500 meters, which might not be sufficient for fast driving cars on the highway.

Furthermore, LTE zones do not consider different services, QoS, traffic type (sporadic, periodic) and related requirements. Also the mobility in V2X should be considered, e.g. groupcast for groups moving into one direction.

There is therefore a need for at least one solution that overcomes at least the drawbacks presented above.

Summary

In view of the drawbacks disclosed earlier, there are provided a method and a network node ( gNB or eNB ) for zone adaption in a network wherein V2X is employed as will in the detailed description. Identical zones defined for LTE V2X, which may also apply for NR V2X zones. Another advantage is to provide new approaches to enhance the overall static LTE V2X zone concept, which apply for NR, but may also be used to enhance LTE. NR may use LTE zones as a baseline. Therefore, any ideas related to LTE defined zones may also apply for NR.

The invention relates to the configuration of geographical area(s) defined by at least one or multiple zone(s) or validity area(s) for sidelink(s) when signaled or preconfigured to at least one User Equipment (UE), where these defined geographical areas are used to overcome limitations of the LTE-based zones. The term“zone” or“dynamic zone” can be used and in relation to the invention “defined geographical area” has the same meaning as zone, however, the term“defined geographical area” has been used to clearly define the invention in relation to the background art.

The inventive method comprises the configuration of defined geographical area(s) by adapting the static zones to become dynamic or flexible defined geographical area(s). Also, the vehicle moving direction and speed may be considered for broadcast, groupcast and unicast, e.g. groupcast for groups moving into one direction.

A minimum communication range is a parameter newly introduced in release 16 for NR V2X to describe the minimum distance to be covered from the source vehicle to any destination vehicle, as described in the technical report 3GPP TR 23.786 V16.0.0, (Release 16) (2019-03). It is the distance within which a User Equipment (UE) shall perform an ultra-reliable, low latency transmission as per the requirements in [3GPP TS 23.287, 3GPP TR 22.886, and 3GPP TS 22.186]

Brief Description of the Drawings

The present disclosure will now be described, for exemplary purposes, in more detail by way of embodiment(s) and with reference to the enclosed drawings, in which:

Fig. 1 schematically illustrates a highway scenario wherein embodiments herein may be employed. Fig. 2 schematically illustrates another highway scenario wherein embodiments herein may be employed.

Fig. 3 schematically illustrates a defined geographical area based on direction of motion.

Fig. 4 shows an example of overlapping inter-RAT defined geographical areas.

Fig. 5 schematically depicts hybrid zones (overlapping) based on speed of vehicles.

Fig. 6 illustrates an example of a mapping between a validity area and multiple zones/cells/partial- cells.

Fig. 7 is a block diagram depicting a network node according to an exemplary embodiment.

Detailed Description

In the following, in several scenarios, a detailed description is presented of the exemplary embodiments in conjunction with the accompanying drawings to enable easier understanding of the solution(s) described herein.

According to an exemplary embodiment, a network node (gNB or eNB) is adapted to configure at least one defined geographical area by enhancing zone definitions considering the height as a third dimension in addition to the two existing defined zone dimensions, i.e. zone length and zone width. The embodiments herein may be applied or implemented for e.g. large parking areas e.g. multi-floor buildings or other areas

To achieve this, the network node is configured to enhance the information element (IE) SL- ZoneConfig, in accordance with an exemplary embodiment, such that the IE includes a third dimension: height e.g. used for parking garage, complex highway crossings, either absolute height or relative height e.g. floor levels. The network node is adapted/configured to signal the new IE to UEs and/or vehicles or platoons etc. Hence, a method performed by the network node includes configuring an IE SL-ZoneConfig to further include at least height related information and to signal said IE to UEs or vehicles in the network.

An example of the content of this IE is shown below, where bold features show the new enhancement compared to the prior art IE shown earlier:

SL-ZoneConfig

It should be noted that Release“-r1*” at the given SL-ZoneConfig may refer to any release e.g. Release 14, 15, 16, etc.

Bold colored features in the IE above indicate changes, in terms of field descriptions, compared to the original IE SL-ZoneConfig previously presented. zoneHeight

Indicates the height of each geographic zone. Value m5 corresponds to 5 meters, m10 corresponds to 10 meters and so on.

zoneldHeightUnit or zoneldHeight

Provide an indication of the height in meters, - in case, it refers to levels. E.g., there could be levels with a height of 3 meters or in a parking garage - of 5 or even 10 meters. It should be noted that Instead of height in meters, also the floor level might be used to differentiate between e.g. resource pools for different heights.

Due to the high speed of the vehicles on highways, but also due to the structure of the highway (mostly straight lanes), the LTE V2X maximum zone length (currently defined for Release 15) of 500 m may not cover these highway specific characteristics. Therefore, according to an embodiment, the network node may configure the zone length of the IE to include an increased zone length.

Below is presented the IE SL-ZoneConfig according to yet another exemplary embodiment where the zone-length is enhanced with additional distances m1000, m2000, m5000, m10000,..,,,

SL-ZoneConfig

where“L” in zoneldHeightMod-r1*may refer to a number of possible vertical (height) layers. Bold features show the new enhancement compared to the IE shown earlier.

The number of layers may be fixed for pre-configurations or being adapted by the network node or the network and signaled (e.g., via Radio Resource Control (RRC) or higher layer signalling) based on e.g. the road complex topology (for example the number of stores, bridges, etc.)

In addition, also the“zoneWidth” may be extended in the same way as the the“zoneLength”.

Again release“-r1*” at the given SL-ZoneConfig may refer to any release. It should be mentioned that the current LTE zone concept seems to apply mostly for urban scenarios. However, vehicles on the highway are at least as important to be considered as especially autonomous driving and platooning focus - at least initially - on highways.

Therefore, the LTE / NR zone concept, according to an embodiment herein, is adapted, by the network node, considering the structure, lanes, driving direction and speed on highways. Frequent resource allocation due to the limited zone size would be inefficient, as continuously new resources would need to be allocated to all vehicles. Also additional signal exchange would be required.

According to an embodiment, a network or a network node may:

• Configure different defined geographical areas based on the driving direction on the highway o i.e. at least two defined geographical areas, one for each driving direction should be established

o separate defined geographical area or each lane

• The dimension of a defined geographical area may cover

o In one dimension (width): all lanes in the same driving direction, e.g. 10 to 30 meters o In the second dimension (length): strongly increased size compared to the max. 500 m for LTE zones, e.g. 1 to 50 or 100 km.

^■ The length could cover one entire cell / sector or even continue over several cells.

The method performed by the network node thus includes: configuring different defined geographical areas based on the driving direction on the highway i.e. at least two defined geographical areas, one for each driving direction should be established.

Figure 1 illustrates an example of a highway scenario in which some embodiments herein may be employed. This scenario shows an example involving 2 driving lanes in each direction plus shoulder; separate defined geographical areas (x respectively y) per driving direction, and width of defined geographical area covering all lanes in one direction

According to an embodiment, the network or the network node may:

• Configure defined geographical areas based on the entire width of the highway

• The dimension of a defined geographical area may cover

o In one dimension (width): all lanes in both driving directions, e.g. 20 to 60 meters. The width could be increased depending on the environment

o In the second dimension (length): strongly increased size compared to the max. 500 m for LTE zones, e.g. 1 to 50 or 100 km.

^■ The length could cover one entire cell / sector or even continue over several cells. Hence the method performed by the network node may include: configuring defined geographical areas based on the entire width of the highway, wherein the dimension of a defined geographical area may cover, in one dimension (width): all lanes in both driving direction, e.g. 20 to 60 meters, and in the second dimension (length): strongly increased size compared to the max. 500 m for LTE zones, e.g. 1 to 50 or 100 km.

Figure 2 illustrates such a scenario depicting a highway involving: two driving lanes in each direction plus shoulder; common zones for driving direction, and defined geographical areas width covering all lanes in one direction

The network or network node may configure (sub-) defined geographical areas based on different velocity allowed in the different lanes of the highway.

According to another embodiment, the network node is configured to include in the IE SL- ZoneConfig flexible dimensions. This IE is presented below: (Note: Release“-r1*” at the given SL- ZoneConfig refers to any release as previously mentioned.

SL-ZoneConfig

Wherein:

mFlexibleLength: is a defined length as a function of:

Speed/direction only (for preconfigured cases) or

speed/direction and highway characteristics for connected/idle use cases, i.e. , configured by the network or network node.

mFlexibleWidth: is a defined width as a function of:

minimum communication range only (for preconfigured cases) or

minimum communication range and the number of lanes for connected/idle use cases, i.e., configured by the network or network node.

mFlexibleHeight: is a defined height as a function of: maximum_hight_per_layer * maximum_no_Layer

actual_hight_per_layer * actual_no_Layer (L).

Hence, the method performed by the network node may include: configuring the IE by including flexible dimensions are presented above.

Below are presented calculations for network-assisted cases, according to some embodiments herein:

Calculations for network-assisted cases:

mFlexibleLength = f( speed [m/s], highway_length[m]) [m],

mFlexibleWidth = max(min_communication_range [m], Number_Lanes*Lane_Width [m]) [m], mFlexibleHeight = number(L-layers)*Layer_Hight [m]

Road topology may be conveyed by the network or network node or upper-layers for connected/idle scenarios. In this case, the road topology may include:

Road maximum spanning/length, e.g., Extra-Long, Long, moderate, country roads, ... . These values may be interpreted as integers from 1 to N, where N is the maximum length and 1 is the shortest road.

Road width, which may include the number of lanes, e.g., as an integer from 1 to M, where M is the maximum number of lanes

Road height topology, e.g., including the actual number of layers from 1 to L, where L is the maximum number of layers vertically and 1 is, again, 2D case. Additionally, the height of the layers in meters.

Below is described, flexible resource allocation involving a zone concept that may be applied in NR or 5G. However, this concept may also be applied for LTE V2X zones.

Use case specific may be defined. Also flexible zones/resource pools may be defined as defined geographical areas, which could differentiate between geographical areas, e.g. highways, urban, suburban.

In addition, for the different use cases, different zone concepts or concepts for defined geographical areas may apply, considering e.g. high mobility and groupcast (e.g. platooning). - Also the communication type, the QoS and the minimum communication range could be considered to design the resource pools for NR.

Note: Any NR specific enhancements for zones / resource pools may also apply for LTE V2X zones. Defined geographical areas, or dynamic zones, may be beneficial to avoid continuous allocation of new resources/resources pools. This may be the case for vehicles moving in the same direction in groups.

The defined geographical areas should not be limited to static geographic zones, but move with the vehicle/group of vehicles. Fixed geographical zones, as originally defined for LTE, demand additional signalling exchange with an additional risk not to get the required resources at all or in time.

Therefore, according to an embodiment herein, a defined geographical area moving along with the associated vehicle(s) may be provided. A platoon is an example setup with a pre-defined number of trucks moving in line in the same direction, typically using the same lane.

The defined geographical area (using the parameters given in LTE) adapted its origin based on the speed of vehicle(s).

The defined geographical area according to an embodiment may be defined by:

• The origin of the defined geographical area defined as shown in Figure 3

o The velocity of the associated vehicle(s)

o The direction of motion (optional)

o the length/size of the vehicle(s), e.g. the platoon (optional)

^■ the defined geographical area may be resizable, i.e. the size of the defined geographical area is dynamic and may be adapted e.g. according to the size of a platoon.

Vehicles moving on groups could be either:

• Predefined groups, e.g. groupcast for platooning

• Ad-hoc groups, e.g. vehicles moving in the same direction with similar speed, e.g. on the highway, especially for (partial) autonomously driving cars / trucks.

For groupcast (controlled/ad hoc groups), the entire length of the group could be known. The allocated defined geographical area may therefore use the zone size fitting to the length of the group.

A group may include a single vehicle or 2 or more vehicles using unicast communication.

At least as long as the defined geographical area is contained within the validity area (as will be described) it can be assumed, that the same resources can be used.

According to an embodiment, LTE and NR (or 5G) zones may be combined and may overlap. As an example, one LTE zone could be split into several NR zones and vice versa, e.g. inter-RAT (Radio Access Technology) co-existence.

For overlapping zones, several zones may completely or partially overlap. This could be the case for: LTE zones with LTE zones

• NR zones with NR zones

• NR zones with LTE zones

• OEM (Original Equipment Manufacture) specific zones with any other type of zone

• Any other specific zones related to speed, QoS, etc.

OEM specific zones, refers to e.g. a vehicle vendor, which may request for zones just for their vehicles, e.g. for collecting vehicle measurements or distributing software. As an example, a defined geographical area may be associated with a network slice (typically higher layer) which may support one specific service or multiple services. A zone/type of zone (physical layer for V2V or V2X direct communication may also support one or multiple services). Therefore, a higher layer network slice could be mapped to one or multiple defined geographical area or a specific type of defined geographical area. The embodiments herein are thus not restricted to physical network zones, but may also be implemented in a network employing network slices.

It should be mentioned that network slicing allows a network operator to provide dedicated virtual networks with functionality specific to the service or customer over a common network infrastructure. Thus it will be able to support the numerous and varied services envisaged in 5G. Associating a defined geographical area to a network slice, according to some embodiments herein, allows the allocation of resources and the provisions of resources in vehicles within a defined geographical area.

Figure 4 depicts an example of overlapping inter-RAT zones i.e. LTE (or 4G) zones and NR (5G) zones.

According to an embodiment, the network node may configure at least one defined geographical area for specific conditions, requirements, etc., such as e.g. data traffic, QoS settings, and speed.

Hence, hybrid zone sizes may be considered in one cell or one validity area.

Therefore, defined geographical areas might be overlapping (coinciding or non-coinciding).

Different defined geographical areas might have same coordinate orientation (i.e., starts from the same 0,0 position) or might have different orientation (i.e., every zone starts with different x,y coordinate)

The number of defined geographical areas for every case/requirement might be the same (e.g., 16, 32, 64, etc.) or different, e.g., wide-spanning cases may have less defined geographical areas than high dense cases.

The cases and requirements could be: Traffic conditions, i.e., overlapping, but different defined geographical areas for different traffic type, e.g.:

• Defined geographical areas for periodic traffic

• Defined geographical areas for aperiodic / sporadic traffic

Communication type

• For unicast, groupcast and broadcast, specific defined geographical areas could be configured.

E.g., broadcast defined geographical areas, can be wider/larger than groupcast and unicast

Speed

Depending on the speed, different defined geographical areas could be configured, e.g. for pedestrians, bikes, slow vehicles, and fast vehicles. E.g., fast vehicles may require wider defined geographical areas (see Figure 1)

QoS

The QoS may be derived from the 5QI (5G QoS Identifier), PQI (Performance Quality Improvement), etc.

Besides 5QI or PQI or VQI specific defined geographical areas, QoS may also distinguish regarding reliability/latency /priority, etc.

• Defined geographical areas to be defined per QoS requirements, e.g.

o URLLC (Ultra Reliable Low-Latency Communication) defined geographical areas or only "latency or reliability” Size 1

o High capacity (eMBB (enhanced Mobile Broadband)) defined geographical areas Size 2

For example, defined geographical area Size 1 may be smaller than defined geographical area Size 2

According to an embodiment, smaller defined geographical areas may be limited to less allowed power. However, wider defined geographical areas may use higher power values.

According to another embodiment, smaller defined geographical areas may be associated to smaller number of pools. However, wider defined geographical areas may use higher number of resource pools.

Figure 5 illustrates an example of hybrid defined geographical areas which are overlapping based on speed. High-speed vehicles and low-speed vehicles are exemplified. The defined geographical areas are also shown. As previously described, a minimum communication range is a parameter newly introduced in release 16 for NR V2X to describe the minimum distance to be covered from the source vehicle to any destination vehicle.

According to an embodiment, the network node may be configured to adapt a defined geographical area size using reduced defined geographical area size based on the minimum communication range. Hence, the method in the network node may include adapting a defined geographical area size based on the minimum communication range.

In other words, depending on the setting of the minimum communication range the size of the defined geographical area could be adapted.

For example, vehicles may only communicate with other vehicles within a certain relative distance e.g. for specific use cases, such as extended sensor sharing.

This concept may also consider the Time-Frequency Resource Pattern (TFRP) i.e. resource patterns defined by time and frequency.

Major advantages of the adaptive moving defined geographical areas with restricted size are:

• Less interference

• Efficient resource reuse: resources can be reused more frequently

It should be mentioned that, in the state of the art, the network may provide pools of resources in which UE autonomously selects sidelink grant for‘sidelink unicast/groupcast/broadcast’ via broadcast system information and/or dedicated signalling;-Mode 2 resource configuration can be provided for a given validity area where the UE(s) does not need to acquire a new mode-2 resource configuration while moving in the validity area, as least when this configuration is provided by SIB (e.g. to reuse valid area of NR SIB (System Information Block));”

“3GPP (Radio Access Network) RAN2 supports mode-2 resource configuration for a given validity area where the UE(s) does not need to acquire a new mode-2 resource configuration while moving in the validity area, as least when this configuration is provided by SIB (e.g. to reuse valid area of NR SIB).”

According to some embodiments herein, the definition of the validity area is enhanced. A network node (e.g. a radio base station) may be configured to define a validity area for a specific UE using dedicated messages conveying the validity area information element for the UE. The base station or the network node may also be configured to broadcast the validity area for more UEs using broadcast signaling conveying the validity area information element for all UEs. According to an embodiment, the UE may be adapted to perform the following:

o If a comm_validity_area_specific message is received on a dedicated RRC message, the UE is configured to read the comm_validity_area_info from the received file

o If the UE didn’t receive a comm_validity_area_specific message on the dedicated RRC message, the UE is configured to scan the V2X SIBs for a comm_validity_area_common. If the latter is received, the UE is configured to decode the comm_validity_area_info for the validity information. The comm_validity_area_common message may comprise, e.g.:

comm_validity_area_info

• validity cells

• validity beams

• validity zones

• validity regions (may comprise partial cells/sectors/beams)

• validity height information

• validity power information

• validity time information

• validity communication range

validity carrier information

validity regulatory and barring information

validity UE capability and permissions

o The comm_validity_area_specific message may comprise, e.g.:

comm_validity_area_info

• validity cells

• validity beams

• validity zones

• validity regions (may comprise partial cells/sectors/beams)

• validity height information

• validity power information

• validity time information

• validity communication range

• if needed: validity carrier information

• if needed: validity regulatory and barring information

• if needed: validity UE capability and permissions

A validity area information element may be pre-configured by a network node (e.g. of a vendor) and/or slightly updated by the network or network node using the V2X SL_Preconfiguration. Hence, if the UE is out of coverage or the UE does not receive the right V2X SIBs, the UE may use the SL_Preconfiguration to read the SL_ Preconfiguration_validity_preconfig. This comprises:

o SL_ Preconfiguration_validity_preconfig_

Validity region per-country information

validity zones

validity height information

validity power information

validity time information

validity communication range

validity carrier information dedicated SL carriers

validity regulatory and barring information on the dedicated SL carriers if needed: validity UE capability and permissions

According to an embodiment, a validity area may be defined by the network node in two ways regarding defined geographical areas (e.g. zones) and cells:

1^st A Validity Area comprises multiple defined geographical areas/cells:

Hence, a validity area may be split into cells (or partial cells) where cells may have defined geographical areas. A validity area may also be divided into multiple defined geographical areas, where the UE is configured to receive from all resources in the validity area while transmitting only on the resources dedicated for the defined geographical area where the UE is located. In this case, the UE does not have to change the grants due to, e.g., leaving one cell to another cell or one defined geographical area (within the validity area) to another defined geographical area.

2^nd A validity Area may comprise one defined geographical area and or one Cell

In this case, one validity area may be configured with all possible resource pools assuming a validity area is one defined geographical area in one cell. In this case, the UE does not have to change the grants within such an area (i.e. , which comprises one zone).

According to an exemplary embodiment, a validity area has one defined geographical area and/or the validity area has multiple defined geographical areas/cells as previously described. All the previous embodiments for defined geographical areas are valid in both cases. Figure 6 depicts a example of a mapping between a validity area and multiple defined geographical areas/cells/partial-cells.

One aspect of the invention teaches that the UE may be in out-of-coverage or in coverage using a given frequency range within or outside the ITS-band. Another aspect of the invention proposes that the relative distance between communicating User Equipments (UEs) can be derived from either the position of both UEs within the same defined geographical area, where the distance is limited by the size of the defined geographical area; or alternatively in case the UEs are located in different defined geographical areas, such as in adjacent defined geographical areas, derived from the position and size of the geographical areas the UEs are located in. For example, in case 2 communicating UEs are located in 2 adjacent defined geographical areas each with a width and length of 100m, the maximum relative distance of the 2 UE can be derived as approximately 200m. This would be the case, when each UE is located at the opposite outer side of the defined geographic area, the UE is located. The accuracy of the relative UE distance is depending on the size of the cell and can be approximated using the distance of the center of the individual geographical area each UE is located.

It is then proposed that the transmission and/or response and/or acknowledgement which are aspects included in the communication between the other UE(s), such as in unicast or groupcast communication, is sent depending on the evaluated relative UE distance between communicating UEs.

As previously described the exemplary embodiments herein may be performed by a network node (or eNB or gNB). In order to perform the previously described process or method steps related to the network node, the network node 700 includes, as shown in Figure 7, a processor 710 or processing circuit or a processing module or a processor or means; a receiver circuit 740 or receiver module; a transmitter circuit 750 or transmitter module; a memory module 720 a transceiver circuit 730 or transceiver module which may include the transmitter circuit and the receiver circuit. The network node 700 may further comprise an antenna system 760 which includes antenna circuitry for transmitting and receiving signals to/from in the network topology

Detailed performed by the network node have already been described and need not be repeated.

There is also provided a computer program comprising instructions which when executed on at least one processor of the network node, cause the at least said one processor to carry out the method or procedure previously described.

The network node may belong to any radio access technology including 3G, 4G or LTE, LTE-A, 5G, WLAN, and WiMax etc.

The processing module/circuit includes a processor, microprocessor, an application specific integrated circuit (ASIC), field programmable gate array (FPGA), or the like, and may be referred to as the“processor.” The processor of the network node controls the operation of the node and its components. Memory (circuit or module) includes a random access memory (RAM), a read only memory (ROM), and/or another type of memory to store data and instructions that may be used by processor. In general, it will be understood that the network node may include fixed or programmed circuitry that is configured to carry out the operations in any of the embodiments disclosed herein. Further, it will be appreciated that the network node may comprise additional components.

As demonstrated, many advantages are achieved which enhancements of the geographical zones defined for LTE V2X, which may also apply for NR V2X zones. Another advantage is to provide new approaches to enhance the overall static LTE V2X zone concept, which apply for NR, but may also be used to enhance LTE. NR may use LTE zones as a baseline. Therefore, any ideas related to LTE defined zones may also apply for NR. Other advantages achieved include less interference and efficient resource reuse. Throughout this disclosure, the word "comprise" or“comprising” has been used in a non-limiting sense, i.e. meaning "consist at least of". Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation. The embodiments herein may be applied in any wireless systems including 3G or WCDMA, LTE or 4G, LTE-A (or LTE- Advanced), 5G, WiMAX, WiFi, satellite communications, TV broadcasting etc.

Claims

1. A method performed by a network node for the configuration of geographical area(s) defined by at least one or multiple zone(s) or validity area(s) for sidelink(s) when signaled or preconfigured to at least one User Equipment (UE), the method comprising the configuration of said defined geographical area(s) by adapting the static zones to become dynamic or flexible defined geographical area(s), wherein a dynamic or flexible defined geographical area is associated to a moving or mobile group consisting of at least one UE to at least allow said moving group to remain in the identical defined geographical area while moving through an extended geographical area.

2. The method according to claim 1 , wherein a group of UEs is an Ad-hoc group.

3. The method according to claim 1 , wherein a group of UEs is a predefined group.

4. The method according to any preceding claim, wherein the length of the group is known, and the length of the defined geographical area is adapted to fit to the length of the group.

5. The method according to claim 4, wherein the length of the group is adapted to the distance between the first and last UE in the group, and the length of the defined

geographical area is resizable and adapted to when the number of UEs in the group changes.

6. The method according to any preceding claim, wherein groupcast/multicast and/or broadcast and/or unicast is used for said group.

7. The method according to any preceding claim, wherein said group is defined by additional parameters, such as group length, group position, number of UEs in the group, group speed, and group driving direction.

8. The method according to any preceding claim, wherein the allocated resources maintain with the group at least as long as the dynamic defined geographical area is contained within the validity area.

9. The method according to any preceding claim, wherein defined geographical areas are configured for defined conditions and or requirements, which comprises but are not limited to:

• Traffic conditions, e.g. periodic, aperiodic traffic

• Communication type, e.g. specific zones for unicast, groupcast and broadcast

• Speed, e.g. specific zones for pedestrians, bikes, slow vehicles, fast vehicles and allowed speed.

• QoS, e.g. based on QoS metrics such as 5QI, PQI or VQI or based on individual QoS requirements e.g. reliability, latency, priority

• Different radio access technologies

10. A method performed by a network node for the configuration of geographical areas defined by at least one or multiple zones(s) or validity area(s) for sidelink(s) when signaled or preconfigured to at least one User Equipment (UE), the method comprising adapting the spatial dimension of the defined geographical area(s) based on at least one of the following conditions:

• Traffic conditions, e.g. periodic, aperiodic traffic

• Moving speed, e.g. specific zones for pedestrians, bikes, slow vehicles, and fast vehicles

• QoS requirements, e.g. based on QoS metrics such as 5QI, PQI or VQI or based on individual QoS requirements e.g. reliability, latency, priority

• Road topologies

• Radio access technologies.

1 1. The method according to claim 10, wherein the length and/or the width of a defined geographical area is increased on a road e.g. based on the type and/or structure of the road or the driving speed.

12. The method according to claim 10 or 11 , wherein the width of said defined geographical area cover at least both driving directions on said road.

13. The method according to claim 10 or 11 , comprising the configuration of at least one defined geographical area for each driving direction on said road.

14. The method according to claim 13, wherein the width of said defined geographical area cover at least all lanes in the same driving direction on said road.

15. The method according to claim 13 or 14, wherein the width of said defined geographical area cover at least one lane on said road, where different lanes in the same driving direction are covered by different defined geographical areas.

16. The method according to any one of claims 10 to 15, where length and the width of the defined geographical area are flexible and defined as a function of the driving speed and direction.

17. The method according to any one of claims 10 to 16, wherein height is represented as a third dimension in addition length and width, and wherein height availability or limitations are represented by said third dimension.

18. The method according to claim 17, wherein the height is expressed in absolute height, such as in meters, or in relative height, such as in floor plans.

19. The method according to claim 17 or 18, wherein said third dimension is used in parking areas, multi-floor buildings or complex highway crossings.

20. The method according to any one of claims 17 to 19, wherein height may be pre configured or adapted by the network and signaled, e.g. via RRC.

21. The method according to any preceding claim, wherein a defined geographical area is associated with a network slice for providing at least one virtual network.

22. The method according to any preceding claim, comprising configuring the defined geographical area based on Quality of Service requirements, such as high capacity zones, or enhanced Mobile Broadband zones that can be larger than Ultra Reliable Low-Latency Communication zones or only "latency or reliability” zones.

23. The method according to any preceding claim, wherein smaller defined geographical areas are limited to less allowed power, and larger defined geographical areas are allowed to use higher power values.

24. The method according to any preceding claim, wherein smaller defined geographical areas use to a smaller number of resource pools, and larger defined geographical areas use higher number of resource pools.

25. The method according to any preceding claim, wherein the defined geographical area size is adapted to a minimum communication range.

26. The method according to claim 25, wherein UEs within said defined geographical area is only allowed to communicate with other UEs within a certain relative distance e.g. for specific use cases, such as extended sensor sharing.

27. The method according to claim 9 or any one of claims 10 to 26, comprising configuring the defined geographical area based on cast type, such as defined geographical areas for broadcast can be larger than defined geographical areas for groupcast or unicast.

28. The method according to claim 9 or any one of claims 10 to 27, wherein overlapping defined geographical areas are configured for any of the defined conditions.

29. The method according to any preceding claim, wherein the information element is a side link zone configuration, SL-ZoneConfig, used for V2V sidelink communication.

30. The method according to any one of claims 10 to 29, wherein the UE is in out-of- coverage or in coverage using a given frequency range within or outside the ITS-band.

31. A method wherein the relative distance between communicating User Equipments (UEs) is derived from either the position of both UEs within the same defined geographical area, where the distance is limited by the size of the defined geographical area; or alternatively in case the UEs are located in different defined geographical areas, such as in adjacent defined geographical areas, derived from the position and size of the geographical areas the UEs are located in.

32. The method according to claim 31 , wherein the transmission and/or response and/or acknowledgement which are aspects included in the communication to the other UE(s), such as in unicast or groupcast communication, is sent depending on the evaluated relative UE distance between communicating UEs.

33. A network node comprising a processor, a memory and a transmitter circuit, said memory containing instructions executable by said processor whereby the network node is operative to perform any of the subject-matter of any one of claims 1 to 32.