WO2023199535A1

WO2023199535A1 - Method to assist roaming of user equipment from first network to second network

Info

Publication number: WO2023199535A1
Application number: PCT/JP2022/033812
Authority: WO
Inventors: Mourad Khanfouci
Original assignee: Mitsubishi Electric Corp; Mitsubishi Electric R&D Centre Europe BV Netherlands
Current assignee: Mitsubishi Electric Corp; Mitsubishi Electric R&D Centre Europe BV Netherlands
Priority date: 2022-04-14
Filing date: 2022-09-02
Publication date: 2023-10-19
Anticipated expiration: 2024-10-14
Also published as: JP2025501409A; CN118975309A; EP4262269B1; JP7766823B2; EP4262269A1; US20250212043A1

Abstract

A method is proposed to assist a roaming of a user equipment from a first network to a second network, said first and second networks being located in respective regions separated by a border. The method comprises, upon detection of a crossing of said border by the user equipment, a use by the second network of application layer information to handle an application layer of a roaming of the user equipment from the first network to the second network. More particularly, the user equipment transmits to at least one of said first and second networks a signal according to which it belongs to a specific class of user equipment being supported by a federation of networks including at least the first and second networks, so as to update a route selection policy of the user equipment being defined as belonging to said specific class. This updated route selection policy is then used by the second network to handle the application layer for the roaming of the user equipment, said roaming being thereby seamless for the user equipment.

Description

[DESCRIPTION]

[Title of Invention]

METHOD TO ASSIST ROAMING OF USER EQUIPMENT FROM FIRST NETWORK TO SECOND NETWORK [Technical Field] [0001]

The present disclosure relates to service continuity of a telecommunication application in a border scenario (i.e. when a terminal crosses a boarder).

[Background Art]

[0002]

The service continuity is an important requirement for the design of edge network architecture, for instance when a terminal chip is implanted in a vehicle for so-called V2X applications (where “V2X” stands for “Vehicle-to- Everything” and aims at various telecommunication services made available for users of that vehicle: data, voice, video, etc.).

[0003]

Service continuity from the perspective of such applications can be viewed as the “handover” in GSM communications, when the vehicle crosses a boarder, for instance between two different countries.

[0004]

A communicating user equipment (“UE” hereafter), for example in the form of a telecommunication chip, can be implanted in a vehicle to implement V2X applications. A telecommunication context of a current application involving a V2X UE is transferred from the source edge application server to a target application server located in the new country, following the mobility of the V2X UE.

[0005] The general problem of the service continuity of the application is described by figure 1 showing two edge application servers (EAS) that are serving two locations (for example two different countries). Source EAS (S- EAS) is serving the V2X UEs located in location#! while target EAS (T-EAS) is serving the V2X UEs located in location #2.

[0006]

When the V2X UE is moving from location #1 to location #2, the latency requirement of the S-EAS is no longer maintained and the V2X application should be relocated to a closer EAS in order to maintain the latency of the application.

[Summary of Invention]

[0007]

The present disclosure aims to improve the situation.

[0008]

It proposes a method to assist a roaming of a user equipment from a first network to a second network, said first and second networks being located in respective regions separated by a border, the method comprising, upon detection of a crossing of said border by the user equipment, a use by the second network of application layer information to handle an application layer of a roaming of the user equipment from the first network to the second network, wherein the user equipment transmits to at least one of said first and second networks a signal according to which it belongs to a specific class of user equipment being supported by a federation of networks including at least the first and second networks, so as to update a route selection policy of the user equipment being defined as belonging to said specific class, said updated route selection policy being used by the second network to handle said application layer for the roaming of the user equipment, said roaming being thereby seamless for the user equipment.

[0009]

In an embodiment, prior to the border crossing, unified data repositories of the first and second networks are updated and registered with identifiers of user equipment belonging to said specific class. A user equipment belonging to said specific class is therefore detected and identified when crossing said border, based on at least one of said unified data repositories.

[0010]

In an embodiment, prior to the border crossing, at least one node of one of the first and second networks is predefined and registered as a federation node, and the first network transmits the application layer information to the federation node, to update the route selection policy of the user equipment with federation related information.

[0011]

The federation node can use then at least one of said unified data repositories to detect the user equipment as belonging to said specific class. [0012]

The federation node can be a multi-access edge computing node (MEC node) that is deployed between the first and the second network.

[0013]

Moreover, complementarily or alternatively, a federation node intervening in the roaming can be a PCF node of the second network, “PCF” relating to a “Policy Control Function”.

[0014]

Moreover, complementarily or alternatively, a federation node intervening in the roaming can be an SMF node of the second network, “SMF” relating to “session management function”, typically for a seamless application session roaming. [0015]

In an embodiment:

- prior to said roaming and when the user equipment is attached to the first network, upon reception by the first network of said signal of the user equipment belonging to the specific class, the first network updates the route selection policy of the user equipment to define the user equipment as belonging to said specific class,

- during said roaming, the first network triggers an establishment of a federated policy control function node and unified data repository with the second network by transmitting said application layer information to the federated policy control function node (S2), said federated policy control function node being delegated for updating the route selection policy of the user equipment in the second network and for updating a unified data repository of said second network,

- when the user equipment attaches to the second network, the second network uses said updated unified data repository of said second network to detect the user equipment as belonging to said specific class and uses said application layer information and said updated route selection policy of the user equipment in the second network, to handle the roaming for said user equipment.

[0016]

In this embodiment, a federated policy control function layer is implemented by delegating said federated policy control function node. [0017]

The federated policy control function node can be a multi-access edge computing node belonging to the second network typically and located near said border.

[0018] The method according to the present disclosure is advantageous notably when the first and second networks are located in distinct respective countries. In this case, even when crossing the border between these countries the roaming is seamless and for example application sessions being implemented by a user equipment can continue without interruption when crossing the border.

[0019]

In an example of embodiment, the user equipment can be implanted in a vehicle to implement V2X applications, “V2X” relating to “vehicle to everything” applications. Typically, several user equipment can be implanted in a same vehicle, or several vehicles following each other, these user equipment being then considered as a peloton of user equipment being members of the federation and to be processed all together for example. [0020]

The present disclosure aims also at a computer program comprising instructions causing the implementation of the method presented above when said instructions are executed by a processing circuit. It aims also at a non- transitory computer storage medium storing such instructions.

[0021]

It aims also at a system to assist a roaming of a user equipment from a first network to a second network, said first and second networks being located in respective regions separated by a border, comprising said user equipment and said first and second networks, said user equipment and said first and second networks being configured for performing the method as presented above.

[0022]

In an embodiment, such a system can further comprise a federation manager computer entity to store unified data repositories of said first and second networks with identifiers of user equipment belonging to said specific class, to implement the specific method presented above and involving unified data repositories.

[0023]

In this embodiment, this federation manager computer entity can store data of at least one node of' one of said first and second networks to be considered as a federation node, as presented above.

[0024]

The present disclosure aims also at a user equipment of such a system. [0025]

Other features, details and advantages will be shown in the following detailed description and on the figures.

[Brief Description of Drawings]

[0026]

[FIG. 1]

Figure 1 shows a usual management to attempt service continuity for V2X edge applications.

[FIG. 2]

Figure 2 presents schematically a context allocation in border scenario.

[FIG. 3]

Figure 3 shows an example of embodiment of a method to handle the roaming according to the present disclosure.

[FIG. 4]

Figure 4 shows a current URSP update in a usual border scenario.

[FIG. 5]

Figure 5 shows a URSP update as proposed by the present disclosure, with a federation management.

[FIG. 6]

Figure 6 shows usual communications over same interface N24. [FIG. 7]

Figure 7 shows new signalling messages exchanged especially via interface N24, between PCF nodes in the context of the present disclosure, to be compared with the usual communications over same interface N24 presented in figure 6.

[FIG. 8]

Figure 8 shows usual communications over same interface N 16.

[FIG. 9]

Figure 9 shows new signalling messages exchanged especially via interface N 16, between SMF nodes in the context of the present disclosure, to be compared with the usual communications over same interface N16 presented in figure 8.

[FIG. 10]

Figure 10 presents different entities intervening in a 5G network architecture (from 3 GPP TS 23.501).

[Description of Embodiments]

[0027]

The present disclosure proposes to build a roaming framework that allows the update of the route selection policy of a user equipment (noted “UE” hereafter) roaming from home public land mobile network (noted “H-PLMN”) to a visiting public land mobile network (V-PLMN).

[0028]

The update of the UE Route Selection Policy (URSP) is performed in the visiting Policy Control Function (PCF) for this UE, so as to improve the latency of the reconfiguration of the application layer and integrate the application layer roaming into the standard roaming procedure.

[0029]

The URSP update, made in advance for a given UE (before an effective border location of that UE) lies on the principle of building a federation of public land mobile networks (PLMNs) at the border between at least two countries such that the application layer handling is harmonized between the home and the visiting PLMNs.

[0030]

Referring to figure 3, the following steps can then be implemented:

51- Prior to the roaming, the home PLMN updates the URSP of the UE in order to define the UE as a “federation member”,

52- When the UE is roaming, the home PLMN triggers the establishment of a federated PCF and a UDR (Unified Data Repository, as detailed below) with the visited PLMN by transmitting application layer information to the visiting PCF: a) Federated PCF is established through the delegation of the update of the URSP to the visiting PCF and updates the UDR accordingly, b) Federated PCF layer can be implemented by delegating to some specific MEC node in the border that is used to update the URSP with specific federation related information.

“MEC” stands for “Multi-access Edge Computing” (or formerly “Mobile Edge computing”), a MEC node designating then a network node located near the border.

53- When the UE attaches to the v-PLMN, the visiting UDR is used for detecting the UE as a federation member and the v-PLMN uses the application layer information and the v-PLMN policy in order to handle application layer of the roaming UE. The UE experiences a continuity of service without any interruption due to the border scenario.

[0031]

In an embodiment, it is proposed to build a federated policy layer in order to facilitate the update of the URSP when UE is roaming from the home PLMN to the visiting PLMN. This URSP update is viewed as a trigger for the improvement of the application layer roaming during the border crossing scenario. The URSP is performed in the home PCF at first (prior to the roaming as such) because the subscription information for the involved UEs are stored in the unified data management node (UDM) and the unified data repository node (UDR).

[0032]

Before detailing this embodiment, reference is made again to figure 1 to describe at first how the application layer transfer is performed in a 5G system according to the prior art.

[0033]

The following general procedure is used for the application relocation, according to the prior art (and its terminology presented above):

- Arrow (1): A V2X UE is moving from location #1 to location #2.

- Arrow (2): this event (1) is notified to a source-EAS (Edge Application Server).

- Arrow (3): the source-EAS or the application orchestrator decides to relocate the V2X application to a target-EAS. The source-EAS transmits the application context to the target-EAS.

- Arrow (4): the target-EAS notifies the network and the source-EAS of the finalization of the application context relocation (arrows (3) and (4) of figure 1).

[0034]

For the border scenario, it is assumed that the network that is connecting the source-EAS and the target-EAS is a network of two different Mobile Network Operators (MNO). The network of each MNO is formed of:

- an access layer,

- a core network and multi-access edge computing layer (MEC) that is formed by an edge platform and edge orchestration and management layer. [0035]

When a vehicular UE is moving from source to target MNO networks as shown in event (1) of figure 2 showing the same prior art situation, different information is relocated from the source MNO network to the target MNO network.

[0036]

Referring now to figure 2 (where CN and RAN designate Core Network and Radio Access Network), in steps (2) and (3), information related to vehicle subscription information, vehicle session status context information and vehicle access network context information is transmitted. After the roaming, i.e. step (2) and step (3), the V2X application context is transferred between the two multi-access edge servers (source MEC and target MEC).

[0037]

UE route selection policy (“URSP”) is an important policy function that is used by the UE to determine how to route outgoing traffic. Traffic can:

- be routed to an established PDU Session (“Protocol Data Unit”),

- or be offloaded to non-3GPP access, outside a PDU Session,

- or can trigger the establishment of a new PDU Session. [0038]

Some main URSP rules are presented below as well as the application function (AF) guidance for the URSP update.

[0039]

Each URSP rule contains a list of Route Selection Descriptors containing one or multiple Route Selection Descriptors each having a different Route Selection Descriptor Precedence value.

[0040]

The structure of the URSP does not define how the PCF splits the URSP when URSP cannot be delivered to the UE in a simple message such as a single NAS message for example (Non-Access Stratum). It is expected that UE applications will not be able to change or override the PDU Session parameters in the URSP rules. A UE application can express preferences when it requests a network connection (e.g. certain connection capabilities), which can be mapped into specific PDU Session parameters by the URSP rules.

[0041]

In the case of network rejection of the PDU Session Establishment Request, the UE may trigger a new PDU Session establishment based on the rejection cause and the URSP policy. When the PCF provisions URSP rules to the UE, one URSP rule with a "match all" Traffic descriptor may be included. [0042]

The URSP rule with the "match all" Traffic descriptor is used to route the traffic of applications which do not match any other URSP rules and shall therefore be evaluated as the last URSP rule, i.e. with lowest priority. There shall be only one Route Selection Descriptor in this URSP rule. The Route Selection Descriptor in this URSP rule includes at most one value for each Route Selection Component.

[0043]

Application function (AF) can provide guidance for the determination of the URSP and the following mechanism is used in usual standard specifications as presented below.

[0044]

The AF can provide guidance for URSP determination to 5G system via the network exposure function (NEF). The AF may belong to the operator or to an external party. The PCF is in the home PLMN as it is the PCF that determines the URSP for the UE.

[0045] The home PCF is updating the URSP at first, because the UEs are identified uniquely in the home PLMN by internal identifiers provided by the unified data management (UDM) nodes. The couple network exposure function (NEF) and unified data repository (UDR) is used to secure and route the AF request to the relevant UEs in the system, as shown as an illustration in figure 4, where reference N24 designates a reference point (an interface in other words) between the PCF node in the visited network and the PCF node in the home network as indicated for example in the standard specification ETSI TS 123 501 VI 5.3.0 (2018-09) in page 28 (3GPP TS 23.501 version 15.3.0 Release 15). In this view, a new signaling over the current roaming interface N24 between home and visiting PCF nodes can be implemented in the present disclosure.

[0046]

In the border scenario, i.e. when the UE is roaming from home to visited PLMN, the update of URSP is usually performed in the home PCF which may increase the latency of the reconfiguration at the application layer and thus may complicate the seamless roaming, for example in a platooning scenario involving several interconnected user equipment and crossing the border together. Indeed, the URSP update procedure according to the prior art is relatively slow and may cause problems in case of session and service continuity SSC mode parameter or to change the DNN for the application function.

[0047]

It is proposed a solution to this problem by the means of allowing the update of the URSP in the visited PLMN and especially the visited PCF and developing the overall architecture related to this update.

[0048]

It is proposed here to build a federation framework at the border in order to provide a reconfiguration of URSP for specific UEs. The general description of the federation framework is described in the figure 5.

[0049]

Prior to an actual border crossing, the core networks register to a supervising entity labelled “federation manager” in figure 5. More specifically, the UDR of the home and visited coordinated internal identification rules are stored in the federation manager for specific UEs present in the federation. Next, involved PCF nodes are registered to the federation manager in order to harmonize the policies for the federation members. This harmonization of the policies and traffic steering is implemented before the roaming. The harmonization can be defined for example according to a particular agreement between the respective networks managers.

[0050]

Then, when one of these specific UEs is roaming to the visiting network, it is identified by the visiting UDR as a UE that is roaming from a federated network and if the UE is detected as a federated UE (one of the aforesaid “specific” UEs), then the visiting PCF can update its URSP. Typically, in the example of figure 5, the detection of the UE roaming (arrow (3)) launches:

- The identification by the visiting network’s UDR of the UE as a federated UE, and

- Consequently, an URSP update in the UE through the visited PCF, seamlessly for the UE.

[0051]

This UE identification can be done by means of transmitting application layer parameters that were used in the home PLMN. These parameters are used by the visiting PLMN to identify the home PLMN as member of the federation and to allow for jointly application relocation and roaming for the UE. This implementation can speed up and integrate the application layer roaming with the core network signalling by the means of a federated architecture in the border as presented in figure 5, while in the prior art implementation, the update in the visiting network was controlled by the policy of the home network involving then latency.

[0052]

The following relates to new signalling introduced by the method presented above.

[0053]

The N24 interface is the interface between the visiting policy control function (V-PCF) and home policy control function (H-PCF). The interface is standardized in the specification TS 29.513 and is responsible of forwarding between the PCF entities the following information:

- Policy association, update and medication between the roaming UE and the access and mobility function (AMF) in the visiting network. This association is forwarded by the visiting PCF to home PCF and the decision that is related to the policy association is performed in H-PCF,

- Authorization and provisioning of the UEs with specific QoS profiles that are forwarded from visiting PCF to home PCF. The decision of the authorisation is performed by the home PCF.

[0054]

Usual simplified communications over the interface N24 are shown in figure 6.

[0055]

The method according to the present description proposes hereafter a modification to the signalling when federations of networks are considered. In this case, all the previous policy control decisions are performed in the visiting PCF and a new message is transmitted over interface N24 in order to delegate the policy control rules from the home PCF to the visiting PCF. This new message may include an information about the UEs concerned by this particular PCF processing or is obtained by a new identification of the roaming UEs in the visiting PCF, defining a UE that is having home network in the federation. [0056]

The overall new time diagram is provided in figure 7 with a new signalling over interface N24 shown in boxes (3) and (4) as well as new processing in the different nodes, to be compared of course with figure 6. [0057]

It is proposed also hereafter a coordination of session management function (SMF) when the UE is roaming from the home PLMN to visiting PLMN. This coordination is based on adding new messages over the N16 interface between home SMF and visiting SMF. The N16 interface is standardized in the 3GPP specification TS 29.502. The information transmitted over interface N16 are essentially related to traffic handling of the roaming UE. One example of this information is for example

- Routing information of the user plan function (UPF) of the communication network towards edge application server,

- Binding rules between the QoS flow associated to a specific session of the roaming UE in the visiting core network,

- Session management context transfer during roaming between Home and visiting SMF.

[0058]

The usual call flow for interface N16 according to the prior art is provided in figure 8.

[0059]

In a similar way to the previous PCF coordination, it is proposed also that the session update decision is performed at the visiting SMF and that the session context handling should be normalized between the UEs that are members of federated networks. This normalized session context handling could be for example:

- same edge application server for all the UEs that are members of the federation, preconfigured routing at the user plan function (UPF) for all the UEs,

- Same QoS handling for packets that are belonging to the UEs that are members of the federation,

Typically, such a QoS handling can be for example priority level of the packets, and/or maximum data burst volume, etc.

[0060]

The modification to the signalling flow over interface N16 is provided in the figure 9 where new messages and information are added in boxes (3) and (4) typically.

[0061]

For the sake of completeness, figure 10 recalls a 5G network architecture (from 3GPP TS 23.501), showing different entities intervening in the description given above.

[0062]

More details are given below relatively to the messages transmitted through interfaces N24 and N 16.

[0063]

These messages of delegation between the two networks allow the update of the URSP, and can also help to identify the UE members of the federation.

[0064]

Relatively to usual operator federations in GSMA (open platform group), it is proposed here lower level federations with stronger coordination of sessions and quality of service (QoS) between networks. GSMA OPG is a platform that usually coordinates applications and does not consider the QoS conditions of each network. The networks manage to provide service as best they can without guaranteeing QoS.

[0065]

A new message over N24 interface between home PCF and visiting PCF delegates the policy control function of the home PCF to the visiting PCF for a UE identified as a member of the federation. This policy control may be for example:

- Identification of the UEs that are members of the federation,

- Update of the UE route selection policy URSP for the UEs that are members of the federation,

- Authorization of the UEs that are members of the federation to register and/or to access to a mobility node (AMF) in the visiting PLMN,

- Indication of the MEC node identifier (data network identifier) that should be considered for the update of the UE route selection policy,

- The indication of the session QoS parameters that was recently setup by the home PCF.

[0066]

After receiving the new message via N24 interface, the visiting PCF can:

- Identify the UEs that are members of the federation through: o The indication of the UEs federation membership received by the home PCF based on the new message, o The indication of the UE federation membership received from the URSP of the UE when attaching to the visiting PLMN,

- Apply policy control for the identified UEs as: o Providing authorization for the identified UEs to access to the visiting core network nodes, o Updating of the UE route selection policy for the UEs identified as members of the federation, o Updating QoS parameters of the communications of the UEs identified as members of the federation, o Updating the MEC node identification for the UEs identified as members of the federation.

[0067]

Another new message transmitted via N16 interface connects the session management functions (SMFs) in home PLMN and visiting PLMN. It is proposed also a new message that may be used to identify the federation membership of the UE that is between the user plan function and the visiting session management function (V-SMF).

[0068]

Currently over the N16 interface, usual messages are related to the control of the session during the roaming over the border. The session control messages:

- Configure the visiting SMF as intermediate SMF (I-SMF) for the session that is ongoing during the roaming,

- Transmit relevant session information such as session type (IP, ethemet, etc.) and quality of service routing information and session continuity mode (one or multiple sessions per roaming UE),

- Provide information to trigger the configuration/reconfiguration of the session at the visiting PLMN network.

[0069]

For example, figure 8 shows an example where a session for the roaming UE is updated in the visiting network. In this case, the visiting SMF (V-SMF) is relaying the information to the home SMF (H-SMF) and the session update decision is performed at the H-SMF. It is thus proposed here to add a new delegation message for the session management over N16 where the session management for the ongoing session of the UE identified as members of the federation is delegated from H-SMF to V-SMF through a new message that includes:

- Session context that could be for example, the session type, session 5G quality of service identifier (5QI) that is related to the flows of the session,

- Identification of the roaming UEs and mapping of the roaming UEs to the corresponding session context,

- Additional information such as the forwarding action rules (FAR) that are used to forward the packets in the user plan function of the home PLMN. These rules can help maintaining the session level continuity of the sessions of UEs identified as federation members.

[0070]

Similarly to the description of the signaling over N24, the session update and modification actions are delegated from the H-SMF to the V-SMF.

[0071]

It is worth to note here a main difference in the level of cooperation, compared to the usual state of the art application platform as described in GSMA open platform group that is currently developing requirements for cooperative deployment of applications among federation of operators. In the state of the art, the operator platform is considered as an over the top (OTT) application layer that does not manage the actual policy and QoS of the networks. In other words, the networks are performing best effort cooperation for the roaming UEs. The present disclosure rather proposes here a low level cooperation where the actual QoS is maintained between the H-PLMN and the V-PLMN.

[0072]

Moreover, the GSMA application platform according to the state of the art does not consider the UE route selection policy update for the application level cooperation which may cause service interruption and frequent service reconfiguration at the border.

Claims

[CLAIMS]

[Claim 1]

A method to assist a roaming of a user equipment from a first network to a second network, said first and second networks being located in respective regions separated by a border, the method comprising, upon detection of a crossing of said border by the user equipment, a use by the second network of application layer information to handle an application layer of a roaming of the user equipment from the first network to the second network, wherein the user equipment transmits to at least one of said first and second networks a signal according to which it belongs to a specific class of user equipment being supported by a federation of networks including at least the first and second networks, so as to update a route selection policy of the user equipment being defined as belonging to said specific class, said updated route selection policy being used by the second network to handle said application layer for the roaming of the user equipment, said roaming being thereby seamless for the user equipment.

[Claim 2]

The method according to claim 1 , wherein, prior to said border crossing, unified data repositories of said first and second networks are updated and registered with identifiers of user equipment belonging to said specific class, and wherein said user equipment belonging to said specific class is detected and identified when crossing said border, based on at least one of said unified data repositories.

[Claim 3]

The method according to claim 1 or 2, wherein, prior to said border crossing, at least one node of one of said first and second networks is predefined and registered as a federation node, and wherein the first network transmits said application layer information to said federation node, to update the route selection policy of the user equipment with federation related information.

[Claim 4]

The method according to claim 3, when combined with claim 2, wherein said federation node uses at least one of said unified data repositories to detect the user equipment as belonging to said specific class.

[Claim 5]

The method according to claim 3 or 4, wherein said federation node is a multi-access edge computing node that is deployed between the first and the second network.

[Claim 6]

The method according to any one of claims 3 to 5, wherein said federation node is a PCF node of the second network, “PCF” relating to a “Policy Control Function”.

[Claim 7]

The method according to any one of claims 3 to 6, wherein said federation node is an SMF node of the second network, “SMF” relating to “session management function”, for a seamless application session roaming.

[Claim 8]

The method according to any one of claims 1 to 7, wherein,

- during said roaming, the first network triggers an establishment of a federated policy control function node and unified data repository with the second network by transmitting said application layer information to the federated policy control function node, said federated policy control function node being delegated for updating the route selection policy of the user equipment in the second network and for updating a unified data repository of said second network,

- when the user equipment attaches to the second network, the second network uses said updated unified data repository of said second network to detect the user equipment as belonging to said specific class, and uses said application layer information and said updated route selection policy of the user equipment in the second network, to handle the roaming for said user equipment.

[Claim 9]

The method according to claim 8, wherein a federated policy control function layer is implemented by delegating said federated policy control function node.

[Claim 10]

The method according to claim 8 or 9, wherein said federated policy control function node is a multi-access edge computing node belonging to the second network and is located near said border.

[Claim 11]

The method according to any one of claims 1 to 10, wherein said first and second networks are located in distinct respective countries.

[Claim 12]

The method according to any one of claims 1 to 11, wherein said user equipment is implanted in a vehicle to implement V2X applications, “V2X” relating to “vehicle to everything” applications.

[Claim 13]

Computer program comprising instructions causing the implementation of a method according to any one of claims 1 to 12 when said instructions are executed by a processing circuit.

[Claim 14]

A system to assist a roaming of a user equipment from a first network to a second network, said first and second networks being located in respective regions separated by a border, comprising said user equipment and said first and second networks, said user equipment and said first and second networks being configured for performing the method according to any one of claims 1 to 12.

[Claim 15]

The system of claim 14, further comprising a federation manager computer entity to store unified data repositories of said first and second networks with identifiers of user equipment belonging to said specific class, to implement the method of claim 2.

[Claim 16]

The system of claim 15, wherein said federation manager computer entity stores data of at least one node of one of said first and second networks as a federation node, to implement the method of claim 3.

[Claim 17]

A user equipment of the system according to any one of claims 14 to 16.