TRANSITION AREA RECONFIGURATION

TECHNICAL FIELD

The present invention relates to the field of mobile communication, in particular vehicle to anything (V2X) and sidelink communication. The present invention more specifically relates to dynamic coordination among operators in agreeing on a resource distribution among them and also to a vehicular UE’s notification about the new resource distribution.

BACKGROUND

Vehicular communication is typically based on a multi- operator environment since it cannot be guaranteed that only one operator is going to coordinate vehicular interactions in an overall area.

In vehicular communications, a UE may communicate using an infrastructure network (i.e. Radio Access Network (RAN) and Core Network (CN)) or direct links (i.e. sidelink communication, supported by the RAN or autonomous). In a single operator environment the RAN and CN are controlled by one operator which simplifies the problem and facilitates the operator to proceed in optimizations. In multiple operators environments, the operators are hard to coordinate, thus making it hard to meet the stringent communication requirements of the V2X services in terms of delay (e.g. information needs to be exchanged from 5 to 100msec depending on the case) and reliability (e.g. transmission needs to be performed with 99% to 99.999% reliability, depending on the case).

Prior art solutions facilitate a transformation of the multi operator problem to a single operator one, by forcing all UEs in a certain area to roam in only one operator responsible for the resource coordination in this particular area. These type of solutions propose a static or semi-static configuration of the transition area and they fail to deal with potential required updates. In case that several operators offer vehicular communication services, inter- operator coordination is required at least for sidelink communication, assuming that each operator will support its infrastructure based communications; the schemes that work based on the force roaming fail to deal with this approach.

The present invention in particular addresses regional split cases and cross border cases, as explained in the following: Direct communication among vehicles, so called Sidelink V2X communication, Direct vehicle to vehicle (V2V) communication, or PC5 communication, refer to communication among vehicles directly, without the content of the communication to go through an operators’ network, radio access network or core network. Two types of direct communication have been considered in the past for vehicular communication: network assisted/controlled one and autonomous one. In the former case (also called Mode 3 in LTE) the UEs are being scheduled by the network and in the latter case (also called Mode 4 in LTE) the UEs select resources on their own, using their local view based on sensing. In this case the network may provide directions on resource use (e.g. which resources the UEs are allowed to use for transmission, in which they are allowed to receive data, which coding schemes they are permitted to use, etc.)

In a multi operator environment, operators have to coordinate about the resources to be used for delivering the V2V services and the respective configurations. The UE may acquire the V2V configurations:

- by reading the System Information Blocks (SIBs) of the non-serving operator,

- via pre-configuration,

- by Serving BS signaling (i.e., SIB from serving operator), or

- from a V2X server.

Regarding spectrum resources to be used for V2V communication, two options may be considered:

- Separate carriers are allocated for different operators for V2V services over sidelink: In this case a UE has to listen to multiple channels requiring carrier switching with interruption and delay or multiple reception chains. For avoiding the interruptions the UE has to have one reception chains (i.e. modem) for each operator. Alternatively, the operators may coordinate and use time division schemes in order to avoid half duplex and scheduling UEs at the same time.

- The same carrier is shared among different operators for V2V services over sidelink: In this case the UEs have to be reconfigured every time the spectrum configuration has been updated for the autonomous resource selection (Mode 4 in LTE) and in the case of network assisted/controlled the BSs need to know the resource pool configuration of other operators and also apply time division schemes for the avoiding overlaps of the resource allocation.

As mentioned above regional split may reduce the complexity of the multi operator problem. In this case, a geographical area is divided into disjoint areas each one served by a single operator, as e.g. shown in Fig. 18. Even in this case though, problems arise around the border area between operators. The challenges are:

- how a vehicle will be reached from vehicles attached to different operators, and

- how interference will be handled in case the same spectrum pool/resources is used.

Even if a dual operator area is defined, where the UEs are configured to receive information from vehicles belonging to different operators, interference problems will still arise, as e.g. shown in Fig. 19:

- Case 1: Because of the transmission range.

- Case 2: Because the vehicles even if they change the resources that they use to new resources they will cause interference to the other vehicles.

One way to handle the problem of interference in the previous multi operator scenario is to form the dual operator area (i.e. the transition area) in such way so as to orthogonalize the used resources in some parts of the dual operator area. One exemplary implementation of such scheme is presented in Fig. 20. Assuming that all the available spectrum resources are comprising six separate spectrum chunks (A, B, C, D, E, F) in each single operator area all the resources can be used. In the dual operator area one scheme to orthogonalize the resources could be the following:

- In Part 1 : operator A schedules resources A and B

- In Part 2: operator A schedules resources C and operator B schedules resources D

- In Part 3: operator B schedules resources E and F The three parts described above in particular can be called transition area.

The vehicles switch from one operator to the other by a local decision, by indication from the operator, by joint decision with the vehicles that they have a communication session, or by other ways. The common area (Part 2 in Fig. 20 is scheduled by both operators and is the area where the vehicles are switching from the one operator to the other).

This scheme manages to handle the interference from the one operator to the other, and deals with the half duplex problem since the two operators properly coordinate. Finally, one modem - with same/global (e.g. GLONASS/GPS) synchronization manages to deal with the communication between the two operators.

The challenge that such approach faces is that in case that updates are required (in case of e.g. traffic jams or failures in the dual operator area, which would result in resource management problems, resource shortage, etc.) the configuration of the multi operator zone (i.e. the transition area) has to be updated, in particular in a network device and in a mobile device.

SUMMARY

In view of the above-mentioned problems and disadvantages, the present invention aims to improve the conventional network device and mobile device. The present invention in particular enables to handle the coordination among operators in a transition area, e.g. in case of force roaming or regional split solutions. In case of schemes where several operators cover an overall area, the present invention can be applied for facilitating the operators’ coordination. This is in particular the case if the transition area is infinitely large.

In other words, the present invention allows for:

- coordination of operators regarding used resources and the respective signaling, and

- notification of UEs about the updates in the considered resources. That is, the present invention allows for determining a demand for resource reconfiguration (e.g. of an operator, or of a UE) in a transition area, and for providing information how to reconfigure the resources (e.g. resource provided by an operator, or used by a UE) available in the transition area.

The object of the present invention is achieved by corresponding network devices and by a mobile device.

A first aspect of the present invention provides a network device, in particular an operator device or an operator-independent device, for sidelink communication, configured to obtain a transition area reconfiguration demand, TARD, information, and provide a transition area reconfiguration, TAR, information based on the TARD information.

This ensures that a demand for reconfiguration of resources or parameters relating to a transition area can be determined, and that the resources and parameters can be effectively adjusted.

In particular, the TAR information can be provided to a base station, or to a mobile device. In both cases, the TAR information can be provided directly, or indirectly. In particular, the base station can forward the TAR information to the mobile device.

In an implementation form of the first aspect, the network device is implemented by means of an Access and Mobility Management function, AMF; a Management server; an Application Function, AF, or Vehicle to Anything, V2X, control server; or an Application Fayer Protocol.

This ensures that various network entities in a communication network can be equipped with the network device according to the first aspect.

The above functions and servers are not restricted to 4G or 5G, only because the naming is similar or the same. In particular, the above functions and servers can relate to any kind of mobile communication technology. In a further implementation form of the first aspect, the network device is further configured to provide the TAR information by means of a broadcast message; radio control signaling; application layer information; and/or non-access stratum signaling.

This ensures that the network device according to the first aspect can efficiently make use of several already present ways for signaling information.

In particular, the broadcast message can comprise a system information block, SIB, message. In particular, the radio control signaling can comprise radio resource control signaling. In particular, the non access stratum signaling can comprise a tracking area update.

In a further implementation form of the first aspect, the network device is further configured to determine a demand for reconfiguration of a transition area, and to obtain the TARD information based on the demand.

This ensures, that the network device not only can obtain information regarding a desired reconfiguration, but also determine the demand itself.

In a further implementation form of the first aspect, the network device is further configured to provide a TAR request, based on the TARD information, obtain a TAR response, according to the TAR request, and provide the TAR information based on the TAR response.

This ensures that the network device is not restricted to determining the TAR information on its own, but also can communicate with a second network device (preferably located at a second network operator) to agree on a reconfiguration and provide TAR information accordingly.

In a further implementation form of the first aspect, the transition area is an area in which at least two operators are available, in particular for configuration of communication resources, in particular for roaming between said at least two operators. In a further implementation form of the first aspect, the TAR request is based on and/or comprises at least one of: packet error rate; channel busy rate, CBR; base station, BS, failure indication; latency; bit error rate; data rate.

In a further implementation form of the first aspect, the TAR request includes a reconfiguration parameter.

In particular, the reconfiguration parameter can be at least one of a transition area configuration type, a resource allocation configuration, a transition area location configuration, or a transition area border configuration.

A second aspect of the present invention provides a network device, in particular an operator device or an operator-independent device, for sidelink communication, configured to support another network device in providing a transition area reconfiguration, TAR, information based on a transition area reconfiguration demand, TARD, information.

This ensures that several network device can communicate with each other and can agree on TAR information according to which resources and parameters in a transition area are going to be reconfigured. Thereby, several network operators which use such network devices can reconfigure the transition area in a joint manner.

In particular, the network device of the second aspects or any of its implementation forms corresponds to the network device of the first aspect or any of its implementation forms. More specifically, one of said devices can be run by a first operator, while the other one of said devices can be run by a second operator.

In an implementation form of the second aspect, the network device is further configured to obtain a TAR request; determine a TAR response based on the TAR request; and provide the TAR response, to support the other network device.

The TAR request that the network device of the second aspect receives is the TAR request that is sent by the network device for the first aspect. The TAR response that the network device of the second aspect sends is the TAR response that the network device first aspect receives.

In a further implementation form of the second aspect, the TAR request is based on and/or comprises at least one of a packet error rate; a channel busy rate, CBR; a base station, BS, failure indication; a latency; a bit error rate; or a data rate; and the network device is further configured to determine the TAR response based on at least one of the packet error rate; the channel busy rate, CBR; the base station, BS, failure indication; the latency; the bit error rate; or the data rate.

In a further implementation form of the second aspect, the TAR request includes a reconfiguration parameter, and wherein the network device is further configured to determine the TAR response based on the reconfiguration parameter.

In particular, the reconfiguration parameter includes at least one of a transition area configuration type, a resource allocation configuration, a transition area location configuration, or a transition area border information.

A third aspect of the present invention provides a mobile device, configured to obtain a transition area reconfiguration, TAR, information; and adjust a transition area configuration of the mobile device according to the TAR information.

This ensures that the mobile device of the third aspect can be reconfigured according to the TAR information which is determined by means of the network device according to the first aspect, wherein the network device of the first aspect can be supported by the network device of the second aspect.

In an implementation form of the third aspect, the mobile device is further configured to obtain the TAR information by means of a broadcast message; radio control signaling; application layer information; and/or non-access stratum signaling.

In particular, the broadcast message can comprise a system information block, SIB, message. In particular, the radio control signaling can comprise radio resource control signaling. In particular, the non access stratum signaling can comprise a tracking area update.

A fourth aspect of the present invention provides a method for a network device, the method comprising the steps of obtaining, by the network device, a transition area reconfiguration demand, TARD, information; and providing, by the network device, a transition area reconfiguration, TAR, information based on the TARD information.

In an implementation form of the fourth aspect, the method further includes providing, by the network device, the TAR information by means of a broadcast message; radio control signaling; application layer information; and/or non-access stratum signaling.

In a further implementation form of the fourth aspect, the method further includes determining, by the network device, a demand for reconfiguration of a transition area, and obtaining, by the network device, the TARD information based on the demand.

In a further implementation form of the fourth aspect, the method further includes providing, by the network device, a TAR request, based on the TARD information, obtaining, by the network device, a TAR response, according to the TAR request, and providing, by the network device, the TAR information based on the TAR response.

In a further implementation form of the fourth aspect, the transition area is an area in which at least two operators are available, in particular for configuration of communication resources, in particular for roaming between said at least two operators.

In a further implementation form of the fourth aspect, the TAR request is based on and/or comprises at least one of: packet error rate; channel busy rate, CBR; base station, BS, failure indication; latency; bit error rate; data rate.

In a further implementation form of the fourth aspect, the TAR request includes a reconfiguration parameter. In particular, the reconfiguration parameter can be at least one of a transition area configuration type, a resource allocation configuration, a transition area location configuration, or a transition area border configuration.

The fourth aspect and its implementation forms include the same advantages as the first aspect and its respective implementation forms.

A fifth aspect of the present invention provides a method for a network device, the method comprising the step of supporting, by the network device, another network device in providing a transition area reconfiguration, TAR, information based on a transition area reconfiguration demand, TARD, information TARD information.

In an implementation form of the fifth aspect, the method further includes obtaining, by the network device, a TAR request; determining, by the network device, a TAR response based on the TAR request; and providing, by the network device, the TAR response, to support the other network device.

In a further implementation form of the fifth aspect, the TAR request is based on and/or comprises at least one of a packet error rate; a channel busy rate, CBR; a base station, BS, failure indication; a latency; a bit error rate; or a data rate; and the method further includes determining, by the network device, the TAR response based on at least one of the packet error rate; the channel busy rate, CBR; the base station, BS, failure indication; the latency; the bit error rate; or the data rate.

In a further implementation form of the fifth aspect, the TAR request includes a reconfiguration parameter, and the method further includes determining, by the network device, the TAR response based on the reconfiguration parameter.

In particular, the reconfiguration parameter includes at least one of a transition area configuration type, a resource allocation configuration, a transition area location configuration, or a transition area border information.

The fifth aspect and its implementation forms include the same advantages as the second aspect and its respective implementation forms. A sixth aspect of the present invention provides a method for a mobile device, the method comprising the steps of obtaining, by the mobile device, a transition area reconfiguration, TAR, information; adjusting, by the mobile device, a transition area configuration of the mobile device according to the TAR information.

In an implementation form of the sixth aspect, the method further includes obtaining, by the network device, the TAR information by means of a broadcast message; radio control signaling; application layer information; and/or non-access stratum signaling.

In particular, the broadcast message can comprise a system information block, SIB, message. In particular, the radio control signaling can comprise radio resource control signaling. In particular, the non access stratum signaling can comprise a tracking area update.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above-described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a schematic view of a network device according to an embodiment of the present invention. FIG. 2 shows a schematic view of a network device according to an embodiment of the present invention in more detail.

FIG. 3 shows a schematic view of a network device according to another embodiment of the present invention.

FIG. 4 shows a schematic view of a network device according to an embodiment of the present invention in more detail. FIG. 5 shows an operating principle of network devices according to the present invention.

FIG. 6 shows an operating principle of network devices according to the present invention.

FIG. 7 shows an operating principle of network devices according to the present invention.

FIG. 8 shows an operating principle of network devices according to the present invention.

FIG. 9 shows an operating principle of network devices according to the present invention. FIG. 10 shows a schematic view of information signaling according to the present invention.

FIG. 11 shows a schematic view of a mobile device according to an embodiment of the present invention.

FIG. 12 shows a schematic view of information signaling according to the present invention. FIG. 13 shows a schematic view of information signaling according to the present invention.

FIG. 14 shows a schematic view of information signaling according to the present invention.

FIG. 15 shows a schematic view of a method according to an embodiment of the present invention. FIG. 16 shows a schematic view of a method according to an embodiment of the present invention.

FIG. 17 shows a schematic view of a method according to an embodiment of the present invention.

FIG. 18 shows a schematic view of a transition area according to the prior art.

FIG. 19 shows a schematic view of a transition area according to the prior art. FIG. 20 shows a schematic view of a transition area according to the prior art.

DETAILED DESCRIPTION OF EMBODIMENTS FIG. 1 shows a schematic view of a network device 100 according to an embodiment of the present invention. The network device 100 can in particular be an operator device or an operator-independent device, and is preferably suitable for sidelink communication.

To allow for reconfiguration of a transition area, the device 100 is configured to obtain a transition area reconfiguration demand, TARD, information 101. In particular, this can be information which indicates that reconfiguration of resources or parameters relating to the transition area is required, e.g. required by a UE or a network operator. Obtaining the TARD information 101 e.g. includes determining the TARD information 101 in the device 100, or receiving the TARD information 101 by the device 100. The device 100 is further configured to provide a transition area reconfiguration, TAR, information 102 based on the TARD information 101. The TAR information 102 can e.g. be provided to a base station and/or a UE. The base station and/or the UE are then reconfigured according to the TAR information 102 accordingly. The base station can also for war the TAR information 102 to the UE. The TAR information 102 in particular indicates how a reconfiguration of the transition area is to be performed.

The network device 100 preferably is operated by a first network operator, and can communicate with (and be supported by) another network device, e.g. the network device 300 (which is going to be described below), which can be operated by another network operator.

Optionally, the network device 100 can be implemented by means of an Access and Mobility Management function, AMF; a Management server; an Application Function, AF, or Vehicle to Anything, V2X, control server; or an Application Layer Protocol. The network device 100 is however not restricted to such implementation manners. In particular, the above-mentioned functions and server do not only relate to 4G or 5G, but can relate to any mobile communication means.

Further optionally, the network device 100 can provide the TAR information 102 by means of a broadcast message; radio control signaling; application layer information; and/or non-access stratum signaling.

Further optionally, the network device 100 can determine a demand for reconfiguration of a transition area, and obtain the TARD information 101 based on the demand. That is, the TARD information 101 is determined in the network device 100 itself, and does not need to be provided externally to the network device 100.

Further optionally, the transition area can be an area in which at least two operators are available, in particular for configuration of communication resources, in particular for roaming between said at least two operators. FIG. 2 shows a schematic view of a network device 100 according to an embodiment of the present invention in more detail. The network device 100 of FIG. 2 builds on the network device 100 of FIG. 1 and therefore includes all of its features and functions.

As it is illustrated in FIG. 2, the network device 100 optionally can provide a TAR request 201 , based on the TARD information 101; obtain a TAR response 202, according to the TAR request 201, and provide the TAR information 102 based on the TAR response 202. E.g. the TAR request 201 can be provided to the network device 300, which is going to be described below, and the TAR response 202 can be received from the network device 300. Thereby, the network device 300 can support network device 100 in determining the TAR information 102.

Further optionally, the TAR request 201 can be based on and/or comprises at least one of a packet error rate; a channel busy rate, CBR; a base station, BS, failure indication; a latency; a bit error rate; a data rate. In other words, the TAR request 201 optionally indicates a cause of the request.

Further optionally, the TAR request 201 can include a reconfiguration parameter. The reconfiguration parameter e.g. suggests a newly desired transition area configuration.

FIG. 3 shows a schematic view of a network device 300 according to another embodiment of the present invention. The network device 300 may be a network device corresponding to the network device 100. The network device 300, in particular can be an operator device or an operator-independent device. Further optionally, the network device 300 is suitable for sidelink communication.

The network device 300 supports the network device 100 (as e.g. shown in FIG. 1) in providing a transition area reconfiguration, TAR, information 102 based on a transition area reconfiguration demand, TARD, information 101. This is illustrated in FIG. 3 schematically by the dotted arrow.

FIG. 4 shows a schematic view of the network device 300 according to an embodiment of the present invention in more detail. The network device 300 of FIG. 4 builds on the network device 300 of FIG. 3 and therefore includes all its functions and features. As illustrated in FIG. 4, the network device 300 further can obtain a TAR request 401; determine a TAR response 402 based on the TAR request 401; and provide the TAR response 402. Thereby, the device 300 supports the other network device 100.

Thereby, two operators, one of which is operating the network device 100, and the other one of which is operating the network device 300, can jointly agree on a transition area reconfiguration, by means of the TAR request 401 and the TAR response 402. E.g. the network device 100 suggests a new configuration, and the network device 300 accepts the new configuration or makes a counter proposal.

In particular, the TAR request 401 which is received by the device 300 is the TAR request 201 which is sent by the network device 100. In particular, the TAR response 402 sent by the network device 300 is the TAR response 201 which is received by the device 100.

Further optionally, the TAR request 401 is based on and/or comprises at least one of a packet error rate; a channel busy rate, CBR; a base station, BS, failure indication; a latency; a bit error rate; or a data rate. Thus, the network device 300 optionally can determine the TAR response 402 based on at least one of the packet error rate; the channel busy rate, CBR; the base station, BS, failure indication; the latency; the bit error rate; or the data rate.

Further optionally, the TAR request 401 includes a reconfiguration parameter. Thus, the network device 300 optionally can determine the TAR response 402 based on the reconfiguration parameter.

In view of FIG. 5 to FIG. 9, inter- operator coordination for transition area reconfiguration is going to be discussed.

FIG. 5 illustrates interactions between two operators for agreeing on a spectrum allocation/configuration in a dual operator area (i.e. the transition area) and the ones in the sides - with restricted resources. The interactions may be direct, as shown in the figure, or indirect, via an intermediate entity such as a server belonging to a service provider, a regulator, or any other entity with the respective authority. In FIG. 5, operator “A” implements the network device 100, and operator “B” implements the network device 300.

In at least one operator, a functional entity has to be in charge of detecting the need for a reconfiguration of the transition area. The interactions among the two entities could be summarized in:

- interactions between the network operators to request a reconfiguration with a possible indication of the request cause (e.g. Channel Busy Ratio (CBR) measurement, BS failure, etc.), and a configuration proposal, and/or

- interactions between the network operators to notify the acceptance of the change or propose alternative solution.

The configuration proposal could be:

- the type of reconfiguration proposed (change of resource allocation or change of Transition Area location), and/or

- the details of the new configuration (new resource split, change of Transition Area location, the definition of the new border lines, etc.)

Inter- operator coordination may take place using:

- a Mobility sever in the network core (such as the Access and Mobility Management function (AMF)) which knows the position of the UEs. Then it can decide the resource pools for the involved BS and notify them dynamically;

- an Application Function or a (V2X) Control Server (such as the V2X Control Function in the 5G core);

- a Network Management Entity in the Network Management (NM) system of the operator;

- an Application layer protocol can be in charge of the configuration.

In view of FIG. 6 and FIG. 7, inter- operator coordination for transition area reconfiguration using mobility servers is going to be discussed.

In the illustrated case, Mobility Servers of two operators communicate in order to transmit a:

- Transition area reconfiguration request - Transition area Reconfiguration response

FIG. 6 shows a simplified network topology (comprising BS, User Plane Functions - UPF, etc.) of an exemplary implementation, where mobility servers of the two operators (OP-A and OP-B) are directly connected. Other alternative implementations with indirect communication may be applied. In FIG. 6, OP-A implements the network device 100, while OP-B implements the network device 300.

FIG. 7 shows the message exchange between the two Mobility Servers. The communication may be direct or through intermediate gateways. One alternative implementation is to use exposure functions such as the Network Exposure Function of 5G. In this case the mobility server should be connected to the exposure function of the other operator to provide requests. In alternative implementations the requests could be provided to the local exposure function and the other operator may retrieve it using pull model.

In view of FIG. 8, inter- operator coordination using an Application Function or a V2X Control Function is discussed.

A similar implementation like the one implemented above using the Mobility Server can be applied in cases where the responsible entity for the spectrum coordination is performed via an Application Function or a V2X Control Function. The application functions or V2X Control Function can be from a trust domain or not. Those from not trust domain, require an interface with the Network Exposure Function (NEF) to send/receive information to/from NFs as shown in FIG. 8. Those from trust domain may interface with the NEF or communicate directly with NFs. Again push or pull models may be implemented for these interactions between the application functions or the V2X Control Functions and the NEF functions. FIG. 8 shows an exemplary implementation between application functions belonging to different operator networks. In FIG. 8, the network device 100 is implemented by the left-hand AF, while the network device 300 is implemented by the right-hand AF.

FIG. 9 illustrates inter-operator coordination using Network Management. As shown in FIG. 9, alternative implementations use a network management system to perform coordination of spectrum resources between operators. FIG. 9 shows an exemplary implementation of such a system. Spectrum resource coordination between operators using this approach may be performed using the interface between the Network Manager (NM) or between the Domain Manager (DM). Then the NM will provide the respective configuration to the DM and these will forward the configuration to the Network Elements (NE). Again, in FIG. 9, the network device 100 is run by OP- A, while the network device 300 is run by OP-B.

In an alternative embodiment, which is not shown in the figures, inter- operator coordination using an Application Layer Protocol is addressed:

Network entities may receive their configuration using an Application Layer Protocol. This may be implemented as follows:

- a node is switched on, with a pre-configuration file with the address of the application server,

- the node registers to the server and requests for a configuration file,

- the server sends the configuration template the node has to apply, and

- the server can update this configuration, provided that the node is registered.

Further, other approaches using online implementations and configurations may be applied.

In view of FIG. 10, information transfer from a network device to the RAN is discussed.

The information for BS or UE configuration can be transferred to a network entity that has the spectrum configuration to the respective Access Network elements. The information may be available to the Mobility Server (e.g. MME in LTE networks or AMF in 5G networks) or any other logically centralized entity. In case the negotiation is performed via the V2X Control Function, V2X Application Server, or via the Management System, the information can be transferred to the Mobility Server using dedicated signaling. FIG. 10 presents the information transfer regarding the transition area configuration from the Mobility Server to the BS. In 5G networks this information could be transferred using already available messages such as the Downlink RAN Configuration Transfer message. That is, in FIG. 10, the network device 100 is implemented by the mobility server.

FIG. 11 shows a mobile device 1100 according to an embodiment of the present invention. The mobile device 1100 obtains a transition area reconfiguration, TAR, information 1101. The TAR information 1101 received by the mobile device 1101 e.g. is the TAR information 102 that is provided by the network device 100. To allow for transition area reconfiguration, the mobile device 1100 adjusts a transition area configuration 1102 of the mobile device 1100 according to the TAR information 1102.

Optionally, the mobile device 1100 can obtain the TAR information 1101 by means of a broadcast message; radio control signaling; application layer information; and/or non- access stratum signaling, as it is discussed in the following. In these cases, the TAR information 1101 is e.g. provided by the network device 100 (i.e. the TAR information 1101 is the TAR information 102).

The mobile device 1100 can also be called UE in the following.

In view of FIG. 12 to 14, signaling used for UE notification by means of the network device 100 is discussed. The UEs may be notified for a certain reconfiguration in the spectrum configuration by the following alternatives.

FIG. 12 shows UE notification using system information broadcast messages.

A UE may be notified for a certain reconfiguration in the spectrum configuration using system information broadcast messages. Since the transition area configuration is the same for all the UEs in a certain geographical zone, this configuration could be a broadcast message. Such message could be the broadcasting of system information (such as the System Information in the LTE systems via the System Information Blocks - SIBs). For such a case, the information may be in generic broadcast messages or in broadcast messages that the UEs should be notified to listen to. In the second case (FIG. 13) the UE should be notified by an incoming notification message (such as the RAN paging or typical paging message in LTE, and other previous cellular generations). Then the UE listens by synchronizing to the respective channels to the broadcast message with the system information. In FIG. 12, the mobility server implements the network device 100.

FIG. 13 shows UE Notification using Radio Control Signaling.

As shown in FIG. 13, a UE may be notified for a certain reconfiguration in the spectrum configuration using Radio Control signaling (such as the Radio Resource Control in LTE). In this case, once a UE enters a transition area, it will receive a notification message by the BS (such as the RAN paging message in LTE). Then the UE will send a Radio Control Reconfiguration Request and the BS will provide a Radio Control Reconfiguration Response with the respective reconfiguration. The overall procedure is provided in FIG. 13. In FIG. 13, the mobility server implements the network device 100.

FIG. 14 shows UE Notification using non access stratum signaling.

As shown in FIG. 14, a UE may be notified for a certain reconfiguration in the spectrum configuration using non access stratum signaling (such as the Tracking Area Update in LTE). In this case, once a UE enters a transition area, it will receive a notification message by the Mobility Server (such as the paging message in LTE from the Mobility Management Server). Then the UE will send a Tracking Area Update Request to the Mobility Server and the latter will provide with a Tracking Area Update Response the respective reconfiguration. The overall procedure is provided in FIG. 14. The same procedure may be applied without applying the Tracking Area Update procedure but by using dedicated signaling. In FIG. 14, the mobility server implements the network device 100.

FIG. 15 shows a schematic view of a method 1500 according to an embodiment of the present invention. The method 1500 is for the network device 100 and comprises a first step of obtaining 1501, by the network device 100, a transition area reconfiguration demand, TARD, information 101. The method 1500 also comprises a step of providing 1502, by the network device 100, a transition area reconfiguration, TAR, information 102 based on the TARD information 101.

FIG. 16 shows a schematic view of a method 1600 according to an embodiment of the present invention. The method 1600 is for the network device 300, and comprises a first step of supporting 1601, by the network device 300, another network device 100 in providing a transition area reconfiguration, TAR, information 102 based on a transition area reconfiguration demand, TARD, information 101. The another network device 100 is the network device 100 as described in FIG. 1 above.

FIG. 17 shows a schematic view of a method 1700 according to an embodiment of the present invention. The method 1700 is for the mobile device 1100 and comprises a first step of obtaining 1701, by the mobile device 1100, a transition area reconfiguration, TAR, information 1101. The method comprises a second step of adjusting 1702, by the mobile device 1100, a transition area configuration 1102 of the mobile device 1100 according to the TAR information 1101.

The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word“comprising” does not exclude other elements or steps and the indefinite article“a” or“an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.