WO2021069057A1

WO2021069057A1 - Network entities for intra and inter plmn roaming

Info

Publication number: WO2021069057A1
Application number: PCT/EP2019/077122
Authority: WO
Inventors: Sheeba Backia MARY; Andrey Krendzel; Ali HAMIDIAN
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2019-10-07
Filing date: 2019-10-07
Publication date: 2021-04-15

Abstract

The invention relates to network entities for intra and inter PLMN roaming in a communication system. A first network entity (100) is located in a first domain and is configured to send a first message (510) to a second network entity (300) which is located in a second domain. The first domain is a first region in a PLMN and the second domain is a second region in the PLMN or the first domain is a first PLMN and the second domain is a second PLMN. The first message (510) indicates information about at least one of: a source PLMN ID, a target PLMN ID, a source region ID, and target region ID. Thereby, network data analytics provision among different PLMNs, i.e. inter PLMN, and different region, i.e. inter region, to support roaming scenarios is provided. Furthermore, the invention also relates to corresponding methods and a computer program.

Description

NETWORK ENTITIES FOR INTRA AND INTER PLMN ROAMING

Technical Field

The invention relates to network entities for intra and inter PLMN roaming in a communication system. Furthermore, the invention also relates to corresponding methods and a computer program.

Definitions of Acronyms & Glossaries acronyms and glossaries are used in the present disclosure: Core Network System Access Network Globally Unique Temporary Identifier plication Function ess and Mobility Management Function

ess Stratum

CP Control Plane

GPSI Generic Public Subscription Identifier

GUAM I Globally Unique AMF Identifier l-NEF Intermediate NEF l-NWDAF Intermediate Network Data Analytics Function

S-(l) NWDAF Source Intermediate Network Data Analytics Function

T-(l) NWDAF Target Intermediate Network Data Analytics Function

N3IWF Non-3GPP InterWorking Function

NAI Network Access Identifier

NEF Network Exposure Function

NF Network Function

NR New Radio

NRF Network Repository Function

NSSF Network Slice Selection Function

NWDAF Network Data Analytics Function

OAM Operation, Administration and Management

PCF Policy Control Function

(R)AN (Radio) Access Network

SCP Service Communication Proxy

SEAF Security Anchor Functionality

SMF Session Management Function SMSF Short Message Service Function

SUCI Subscription Concealed Identifier

SUPI Subscription Permanent Identifier

TMSI Temporary Mobile Subscription Identifier

UDM Unified Data Management

UDR Unified Data Repository

UPF User Plane Function.

Background

Currently the 3GPP 5G System only supports network data analytics in the non-roaming scenario and can’t support network data analytics in the roaming scenario.

The Network Data Analytics Function (NWDAF) is part of the architecture specified in TS 23.501 and uses the mechanisms and interfaces specified for 5GC and Operation, Administration and Management (OAM). The NWDAF interacts with different entities for different purposes, such as:

• Data collection based on event subscription, provided by Access and Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), Unified Data Management (UDM), Application Function (AF) (directly or via Network Exposure Function (NEF)), User Plane Function (UPF) and OAM;

• Retrieval of information from data repositories, e.g. Unified Data Repository (UDR) via UDM for subscriber-related information;

• Retrieval of information about Network Functions (NFs), e.g. Network Repository Function (NRF) for NF-related information, and Network Slice Selection Function (NSSF) for slice-related information; and

• On demand provision of analytics to consumers.

Summary

In case of roaming scenario between different public land mobile networks (PLMNs), if an optimal network selection in target networks during roaming is required, then the existing network data analytics support should be extended from the non-roaming to roaming cases. Similarly, for roaming between two different regions/countries within a same PLMN, having different information provision/data collection policies, restrictions, and/or Service Level Agreements (SLA), the analytics subscription, analytics information request and data collection procedure need to meet the regional requirements over data sharing policy. An objective of embodiments of the invention is to provide a solution which mitigates or solves the drawbacks and problems of conventional solutions.

The above and further objectives are solved by the subject matter of the independent claims. Further advantageous embodiments of the invention can be found in the dependent claims.

According to a first aspect of the invention, the above mentioned and other objectives are achieved with a first network entity for a communication system, the first network entity being located in a first domain and being configured to send a first message to a second network entity located in a second domain, wherein the first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN, and wherein the first message indicates information about at least one of: a source PLMN ID, a target PLMN ID, a source region ID, and target region ID.

Hence, when the first domain is a first region in a PLMN and the second domain is a second region in the PLMN relates to the intra PLMN and inter region case. Hence, when the first domain is a first PLMN and the second domain is a second PLMN relates to the inter PLMN case.

In embodiments the information about the first PLMN and/or the second PLMN includes an PLMN ID and/or an address of an entity located in the PLMN.

An advantage of the first network entity according to the first aspect is that it enables network data analytics provision among different PLMNs, i.e. inter PLMN, and different region, i.e. inter region, to support roaming scenarios.

In an implementation form of a first network entity according to the first aspect, at least one of the first network entity and the second network entity is a NWDAF or an intermediate NWDAF, wherein the intermediate NWDAF is configured to provide data network analytics for roaming scenarios in the communication system.

An advantage with this implementation form is that having a dedicated NWDAF instance or intermediate NWDAF to provide data analytics information for roaming case can reduce the complexity of handling both roaming and non-roaming data analytics with different data provision restrictions by a single network function or instance. In an implementation form of a first network entity according to the first aspect, the first network entity is further configured to send a discovery request message to the second network entity previous to sending the first message, wherein the discovery request message indicates at least one of the target PLMN ID, the source PLMN ID, the source region ID, and the target region ID; and receive a discovery response message from the second network entity, wherein the discovery request response message indicates the NWDAF or a NWDAF instance profile and its address.

An advantage with this implementation form is that a network function from the source PLMN or source region can request the target network through NRFs to receive information about a NWDAF or intermediate NWDAF at the target network for requesting roaming related data analytics information.

In an implementation form of a first network entity according to the first aspect, the first message is an analytics subscription request message indicating: a requested analytics set, a PLMN and region-specific notification target address, a PLMN and region specific notification correlation ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a requested analytics set, a PLMN specific notification target address, a PLMN specific notification correlation ID when the first domain is the first PLMN and the second domain is the second PLMN; and further configured to receive an analytics subscription response message from the second network entity, wherein the analytics subscription response message indicates: a PLMN and region-specific notification target address, a PLMN and region-specific subscription correlation ID, and an allowed analytics ID(s) when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a PLMN specific notification target address, a PLMN specific subscription correlation ID, and an allowed analytics ID(s) when the first domain is the first PLMN and the second domain is the second PLMN.

An advantage with this implementation form is that this procedure enables the analytics subscription in inter PLMN and intra-PLMN inter-region roaming cases. Further the usage of PLMN and region specific correlation ID resolves the subscription correlation ID related duplication issues. In an implementation form of a first network entity according to the first aspect, the first message is a data collection request message indicating: a requested event ID(s); and further configured to receive a data collection response message from the second network entity, wherein the data collection response message indicates an allowed event ID(s) and an event report(s).

An advantage with this implementation form is that this procedure enables the data collection in inter PLMN and intra-PLMN inter-region roaming cases.

In an implementation form of a first network entity according to the first aspect, the first message is a data analytics request message indicating: a requested analytics set, a analytic reporting information, a PLMN and region-specific notification target address, and a PLMN and region specific subscription correlation ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or an analytics ID(s), an analytic reporting information, a PLMN specific notification target address, and a PLMN specific subscription correlation ID when the first domain is the first PLMN and the second domain is the second PLMN; and further configured to receive a data analytics response message from the second network entity, wherein analytics response message indicates: a PLMN and region-specific notification target address, a PLMN and region-specific subscription correlation ID, an allowed analytics ID(s), an analytics information, and a validity period when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a PLMN specific notification correlation ID, a PLMN specific subscription correlation ID, an allowed analytics ID(s), an analytics information, and a validity period when the first domain is the first PLMN and the second domain is the second PLMN.

An advantage with this implementation form is that this procedure enables the analytics request and response for data analytics provision in inter PLMN and intra-PLMN inter-region roaming cases.

According to a second aspect of the invention, the above mentioned and other objectives are achieved with a second network entity for a wireless communication system, the second network entity being located in a second domain and being configured to receive a first message from a first network entity located in a first domain, wherein the first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN, and wherein the first message indicates information about at least one of a source PLMN ID, a target PLMN ID, source region ID, and target region ID.

An advantage of the second network entity according to the second aspect is that it enables network data analytics provision among different PLMNs, i.e. inter PLMN, and different region, i.e. inter region, to support roaming scenarios.

Further, the target PLMN or target region can have control over the NWDAF selection for data analytics provision to the requesting source network. Hence, the target network can select a NWDAF or intermediate NWDAF at the target network based on the source PLMN ID or Region ID and the related inter PLMN or region NWDAF access restriction information available at the target network.

In an implementation form of a second network entity according to the second aspect, at least one of the first network entity and the second network entity is a NWDAF or an intermediate NWDAF, wherein the intermediate NWDAF is configured to provide data network analytics for roaming scenarios.

An advantage with this implementation form is that having a dedicated NWDAF instance or intermediate NWDAF to provide data analytics information exclusively for roaming case can reduce the complexity of handling both roaming and non-roaming data analytics with different data provision restrictions by a single network function or instance.

In an implementation form of a second network entity according to the second aspect, the second network entity is further configured to receive a discovery request message from the first network entity, wherein the discovery request message indicates at least one of the following: the target PLMN ID, the source PLMN ID, the source region ID, and the target region ID; and transmit a discovery response message to the first network entity, wherein the discovery request response message indicates the NWDAF or the NWDAF instance profile and its address.

An advantage with this implementation form is that a network function in the target PLMN or target region can have control over the NWDAF or intermediate NWDAF selection at the target network to provide analytics information for any network function requesting from the source PLMN or region.

In an implementation form of a second network entity according to the second aspect, configured to transmit a discovery response message to the first network entity upon verifying the source region ID and the target region ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or the target PLMN ID and the source PLMN ID when the first domain is the first PLMN and the second domain is the second PLMN.

An advantage with this implementation form is that a network function in the target PLMN or target region can have control over the NWDAF or intermediate NWDAF selection by verifying the source PLMN ID and/or region ID and corresponding target NWDAF instance access restrictions to provide analytics information for any network function requesting from the source PLMN or region.

In an implementation form of a second network entity according to the second aspect, the first message is an analytics subscription request message indicating: a requested analytics set, a PLMN and region-specific notification target address, a PLMN and region specific notification correlation ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a requested analytics set, a PLMN specific notification target address, a PLMN specific notification correlation ID when the first domain is the first PLMN and the second domain is the second PLMN; and further configured to transmit an analytics subscription response message to the first network entity, wherein the analytics subscription response message indicates: a PLMN and region-specific notification target address, a PLMN and region-specific subscription correlation ID, and an allowed analytics ID(s) when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a PLMN specific notification target address, a PLMN specific subscription correlation ID, and an allowed analytics ID(s) when the first domain is the first PLMN and the second domain is the second PLMN.

An advantage with this implementation form is that this procedure enables the analytics subscription in inter PLMN and intra-PLMN inter-region roaming scenario. Further the usage of PLMN and region specific correlation ID resolves the subscription correlation ID related duplication issues.

In an implementation form of a second network entity according to the second aspect, the first message is a data collection request message indicating: a requested event ID(s); and further configured to transmit a data collection response message to the first network entity, wherein the data collection response message indicates an allowed event ID(s) and an event report(s).

An advantage with this implementation form is that this procedure enables the data collection in inter PLMN and intra-PLMN inter-region roaming scenarios.

In an implementation form of a second network entity according to the second aspect, the first message is a data analytics request message indicating: a requested analytics set, a analytic reporting information, a PLMN and region-specific notification target address, and a PLMN and region specific subscription correlation ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or an analytics ID(s), an analytic reporting information, a PLMN specific notification target address, and a PLMN specific subscription correlation ID when the first domain is the first PLMN and the second domain is the second PLMN; and further configured to transmit a data analytics response message to the first network entity, wherein analytics response message indicates: a PLMN and region-specific notification target address, a PLMN and region-specific subscription correlation ID, an allowed analytics ID(s), an analytics information, and a validity period when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a PLMN specific notification correlation ID, a PLMN specific subscription correlation ID, an allowed analytics ID(s), an analytics information, and a validity period when the first domain is the first PLMN and the second domain is the second PLMN.

An advantage with this implementation form is that this procedure enables the analytics request and response for data analytics provision in inter PLMN and intra-PLMN inter-region roaming cases. In an implementation form of a second network entity according to the second aspect, when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, is further configured to transmit the data collection response message, or the data analytics response message to the first network entity upon verifying at least one of the source region ID, a PLMN and region-specific subscription correlation ID, an inter-Region geo-political data sharing restrictions, and an inter-region data analytics and/or exposure restriction information.

An advantage with this implementation form is that the target region can have control over the event exposure and data analytics exposure to a network functions in source region by verifying the source region ID and conforming to the inter-region geo-political data sharing restrictions, and an inter-region data analytics and/or exposure restriction information available in the target network. Further using and verifying a PLMN and region-specific subscription correlation ID will resolve ID duplication issues.

In an implementation form of a second network entity according to the second aspect, the second network entity is further configured to transmit the analytics subscription response message to the first network entity upon further verifying inter-region data analytics restriction information.

An advantage with this implementation form is that the target region can have control over the data analytics subscription provision to a network function in source region by conforming to the inter-region data analytics restriction information available in the target network.

In an implementation form of a second network entity according to the second aspect, when the first domain is a first PLMN and the second domain is a second PLMN, is further configured to transmit the data collection response message, or the data analytics response message to the first network entity upon verifying at least one of a PLMN specific subscription correlation ID, the source PLMN ID and corresponding inter-PLMN data analytics and/or exposure restriction information.

An advantage with this implementation form is that the target PLMN can have control over the event exposure and data analytics exposure to a network functions in source PLMN by verifying the source PLMN ID and conforming to the inter-PLMN data analytics and/or exposure restriction information available in the target network. Further using and verifying a PLMN specific subscription correlation ID will resolve ID duplication issues. In an implementation form of a second network entity according to the second aspect, configured to transmit the analytics subscription response message to the first network entity upon further verifying a inter PLMN data analytics restriction information.

An advantage with this implementation form is that the target PLMN can have control over the data analytics subscription provision to a network function in source region by conforming to the inter PLMN data analytics restriction information available in the target network.

According to a third aspect of the invention, the above mentioned and other objectives are achieved with a method for a first network entity, the first network entity being located in a first domain, the method comprising sending a first message to a second network entity located in a second domain, wherein the first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN, and wherein the first message indicates information about at least one of: a source PLMN ID, a target PLMN ID, a source region ID, and target region ID.

The method according to the third aspect can be extended into implementation forms corresponding to the implementation forms of the first network entity according to the first aspect. Hence, an implementation form of the method comprises the feature(s) of the corresponding implementation form of the first network entity.

The advantages of the methods according to the third aspect are the same as those for the corresponding implementation forms of the first network entity according to the first aspect.

According to a fourth aspect of the invention, the above mentioned and other objectives are achieved with a method for a second network entity, the second network entity being located in a second domain, the method comprising receiving a first message from a first network entity located in a first domain, wherein the first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN, and wherein the first message indicates information about at least one of a source PLMN ID, a target PLMN ID, source region ID, and target region ID. The method according to the fourth aspect can be extended into implementation forms corresponding to the implementation forms of the second network entity according to the second aspect. Hence, an implementation form of the method comprises the feature(s) of the corresponding implementation form of the second network entity.

The advantages of the methods according to the fourth aspect are the same as those for the corresponding implementation forms of the second network entity according to the second aspect.

The invention also relates to a computer program, characterized in program code, which when run by at least one processor causes said at least one processor to execute any method according to embodiments of the invention. Further, the invention also relates to a computer program product comprising a computer readable medium and said mentioned computer program, wherein said computer program is included in the computer readable medium, and comprises of one or more from the group: ROM (Read-Only Memory), PROM (Programmable ROM), EPROM (Erasable PROM), Flash memory, EEPROM (Electrically EPROM) and hard disk drive.

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

Brief Description of the Drawings

The appended drawings are intended to clarify and explain different embodiments of the invention, in which:

- Fig. 1 shows data collection architecture from any NF according to a conventional solution;

- Fig. 2 shows network data analytics exposure architecture according to a conventional solution;

- Fig. 3 shows a first network entity according to an embodiment of the invention;

- Fig. 4 shows a method for a first network entity according to an embodiment of the invention;

- Fig. 5 shows a second network entity according to an embodiment of the invention;

- Fig. 6 shows a method for a second network entity according to an embodiment of the invention;

- Figs. 7 - 12 illustrates different network architecture types;

- Fig. 13 shows a NWDAF instance role model 1 ;

- Fig. 14 shows a NWDAF instance role model 2; - Fig. 15 shows a signalling diagram between different network entities according to an embodiment of the invention - more particularly network data analytics subscribe/unsubscribe in roaming/inter PLMN case based on Type 1a/b/c architecture;

- Fig. 16 shows a signalling diagram between different network entities according to an embodiment of the invention - more particularly network data analytics subscribe/unsubscribe in roaming/inter PLMN case based on Type 3a/b/c architecture;

- Fig. 17 shows a signalling diagram between different network entities according to an embodiment of the invention - more particularly indirect source (l)NWDAF event exposure subscribe/unsubscribe for NRFs/NFs/AFs;

- Fig. 18 shows a signalling diagram between different network entities according to an embodiment of the invention - more particularly direct source (l)NWDAF event exposure subscribe/unsubscribe for NRFs/NFs/AFs;

- Fig. 19 shows a signalling diagram between different network entities according to an embodiment of the invention - more particularly inter PLMN network data analytics request procedure without SCP based on Type 1a/b/c architecture;

- Fig. 20 shows a signalling diagram between different network entities according to an embodiment of the invention - more particularly inter PLMN network data analytics request procedure based on Type 3a/b/c architecture;

- Fig. 21 shows a signalling diagram between different network entities according to an embodiment of the invention - more particularly network data analytics subscribe/unsubscribe in intra PLMN-inter region case based on Type 1a/b/c architecture;

- Fig. 22 shows a signalling diagram between different network entities according to an embodiment of the invention - more particularly a data collection procedure in intra PLMN-inter region case; and

- Fig. 23 shows a signalling diagram between different network entities according to an embodiment of the invention - more particularly intra PLMN-inter region network data analytics request procedure based on Type 1a/b/c architecture.

Detailed Description

As aforementioned, there are some shortcomings with conventional solutions. For example, such conventional solutions cover the network data analytics for the non-roaming scenario. As depicted in Fig. 1 , the 5G System architecture allows NWDAF to collect data from any NF. The NWDAF belongs to the same PLMN where the network function that notifies the data is located.

The Nnf interface is defined for the NWDAF to request subscription to data delivery for a particular context, to cancel subscription to data delivery, and to request a specific report of data for a particular context. The 5G System architecture allows NWDAF to retrieve the management data from OAM by invoking the existing OAM services.

As depicted in Fig. 2, the 5G System architecture allows any NF to request network analytics information from NWDAF. The NWDAF belongs to the same PLMN where the network function that consumes the analytics information is located.

The Nnwdaf interface is defined for the NFs, to request subscription to network analytics delivery for a particular context, to cancel subscription to network analytics delivery, and to request a specific report of network analytics for a particular context. The interactions between the NWDAF and the other NFs are only considered in the same PLMN case and hence roaming architecture does not apply in the conventional solutions.

Therefore, embodiments of the invention relate to network data analytics related procedures for the Inter PLMN roaming scenario, including both local breakout and home routed roaming, and Intra PLMN roaming scenario along with a suitable roaming architecture for NWDAF discovery, analytics subscription, analytics request, data collection and event exposure.

Fig. 3 shows a first network entity 100 according to an embodiment of the invention. In the embodiment shown in Fig. 3, first network entity 100 comprises a processor 102, a transceiver 104 and a memory 106. The processor 102 may be coupled to the transceiver 104 and the memory 106 by communication means 108 known in the art. The first network entity 100 may further comprise a communication interface 110 coupled to the transceiver 104 which means that the first network entity 100 may be configured for communications in a communication system.

That the first network entity 100 may be configured to perform certain actions can in this disclosure be understood to mean that the client device 100 comprises suitable means, such as e.g. the processor 102 and the transceiver 104, configured to perform said actions.

The processor 102 of the first network entity 100 may be referred to as one or more general- purpose central processing units (CPUs), one or more digital signal processors (DSPs), one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more programmable logic devices, one or more discrete gates, one or more transistor logic devices, one or more discrete hardware components, and one or more chipsets. The memory 106 of the first network entity 100 may be a read-only memory, a random access memory, or a non-volatile random access memory (NVRAM).

The transceiver 104 of the first network entity 100 may be a transceiver circuit, a power controller, an antenna, or an interface which communicates with other modules or devices.

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

According to embodiments of the invention the first network entity 100 is located in a first domain and is configured to send a first message to a second network entity 300 located in a second domain The first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN. The first message indicates information about at least one of: a source PLMN ID, a target PLMN ID, a source region ID, and target region ID.

Fig. 4 shows a flow chart of a corresponding method 200 which may be executed in a first network entity 100, such as the one shown in Fig. 3. The first network entity 100 is located in a first domain, and the method 200 comprises sending 202 a first message to a second network entity 300 located in a second domain. The first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN. The first message indicates information about at least one of: a source PLMN ID, a target PLMN ID, a source region ID, and target region ID. Further processing steps not shown in Fig. 4 can thereafter be performed.

Fig. 5 shows a second network entity 300 according to an embodiment of the invention. In the embodiment shown in Fig. 5, the second network entity 300 comprises a processor 302, a transceiver 304 and a memory 306. The processor 302 is coupled to the transceiver 304 and the memory 306 by communication means 308 known in the art. The second network entity 300 may further comprise a communication interface 310 coupled to the transceiver 304 which means that the second network entity 300 may be configured for communications in a communication system.

That the second network entity 300 is configured to perform certain actions can in this disclosure be understood to mean that the second network entity 300 comprises suitable means, such as e.g. the processor 302 and the transceiver 304, configured to perform said actions.

The processor 302 of the second network entity 300 may be referred to as one or more general-purpose CPUs, one or more DSPs, one or more ASICs, one or more FPGAs, one or more programmable logic devices, one or more discrete gates, one or more transistor logic devices, one or more discrete hardware components, and one or more chipsets.

The memory 306 of the second network entity 300 may be a read-only memory, a random access memory, or a NVRAM.

The transceiver 304 of the second network entity 300 may be a transceiver circuit, a power controller, an antenna, or an interface which communicates with other modules or devices.

In embodiments, the transceiver 304 of the second network entity 300 may be a separate chipset or being integrated with the processor 302 in one chipset. While in some embodiments, the processor 302, the transceiver 304, and the memory 306 of the second network entity 300 are integrated in one chipset.

According to embodiments of the invention the second network entity 300 is located in a second domain and is configured to receive a first message from a first network entity 100 located in a first domain. The first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN. The first message indicates information about at least one of a source PLMN ID, a target PLMN ID, source region ID, and target region ID.

Fig. 6 shows a flow chart of a corresponding method 400 which may be executed in a second network entity 300, such as the one shown in Fig. 5. The second network entity 300 is located in a second domain and the method 400 comprises receiving 402 a first message from a first network entity 100 located in a first domain. The first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN. The first message indicates information about at least one of a source PLMN ID, a target PLMN ID, source region ID, and target region ID. Further processing steps not shown in Fig. 6 can thereafter be performed. In embodiments at least one of the first network entity and the second network entity is a NWDAF or an intermediate NWDAF. The intermediate NWDAF is configured to provide data network analytics for roaming scenarios in the communication system.

Roaming architectures for network data analytics

The following section with reference to Figs. 7-12 describes possible non-limiting examples of roaming architecture types for the network data analytics provision which includes analytics subscription, data collection and network data analytics exposure.

It is noted that either a NWDAF or a novel Intermediate NWDAF (l-NWDAF) can take the function of requesting and/or providing the target PLMN related network data analytics information to the analytics consumer in the source PLMN.

Among all types of roaming network data analytics architecture provided below, Type 1 (a, b & c), Type 3 (a, b & c), Type 4 and Type 6 are embodiments which permits target/home control over their NF’s analytics information provision to analytics consumer NFs requesting and residing in a different network.

In the inter PLMN case PLMN 1 and 2 can be interpreted as vPLMN and hPLMN, respectively.

In the intra PLMN inter region case region 1 and 2 can be interpreted as source target and target region, respectively, belonging to a single PLMN. The Service Communication Proxy (SCP), NEF, Intermediate NEF (l-NEF) and Network Repository Function (NRF) can be part of the architectures shown below and involve in the described procedures but are not shown in the Figs.

Type 1a shown in Fig. 7a

The target-PLMN, e.g. handover cases, and/or home PLMN, e.g. home routed roaming, can have control over the target NF based analytics provided to the source PLMN and/or visited PLMN.

Data collection: both NWDAF that collects data and the NF that notifies or exposes the data lies within the same target PLMN.

Analytics exposure: the NWDAF provides the analytics information and the NF consuming the analytics information belong to different networks. Type 1 b shown in Fig. 7b

In case of local breakout scenario as shown in both Type 1b and Type 3b, the NF service producer(s) or data collection source can be UDM and hPCF accordingly. Therefore, the analytics consumers in the vPLMN for analytics involving hNRF and UDM as source may need to request home PLMN (HPLMN) NWDAF through hNRF either directly or through v(l)NWDAF and vNRF for analytics subscription and analytics information request. The vNRF and hNRF is involved to support target NWDAF/I-NWDAF discovery which can be capable of inter PLMN analytics provision.

Data collection: both NWDAF and the NF that notifies the data lie within the target PLMN.

Analytics exposure: the NWDAF and the NF consuming the analytics information belong to different networks.

Type 1c shown in Fig. 7c

In home routed scenario shown in both Type 1c and Type 3c, the NF service producer(s) or data collection source can be NSSF, home SMF (hSMF), home PCF (H-PCF), UPF, AF, NEF and UDM accordingly. Therefore, the analytics consumers in the visited PLMN (vPLMN) for analytics involving above source NFs may need to request hPLMN NWDAF through hNRF either directly or through v(l)NWDAF and vNRF for analytics subscription and analytics information request.

Data collection: both NWDAF and the NF that notifies the data lies within the target PLMN.

Analytics exposure: the NWDAF and the NF consuming the analytics information belong to different PLMNs.

Type 2 shown in Fig. 8

Data collection: the NWDAF and the NF that notifies the data lies in the different PLMN.

Analytics exposure: both the NWDAF and the NF consuming the analytics information belongs to the same PLMN and lies in the source PLMN.

Type 3a shown in Fig. 9a

Data collection: both NWDAF and the NF that notifies the data lies within the target PLMN. Analytics exposure: The NWDAF and the NF consuming the analytics information belong to the same source PLMN.

Type 3b shown in Fig. 9b

In case of Local breakout scenario as shown in both Type 1b and Type 3b, the NF service producer(s) and data collection source can be UDM and hPCF residing in the target PLMN accordingly. Therefore, the analytics consumers in the vPLMN for analytics involving hNRF and UDM as source may need to request hPLMN NWDAF through hNRF either directly or through v(l)NWDAF and vNRF for analytics subscription and analytics information request.

Data collection: both the master/analytics producer NWDAF/I-NWDAF and the NF that notifies the data lies within the target PLMN.

Analytics exposure: both the secondary/analytics consumer NWDAF and the NF consuming the analytics information belong to the same source PLMN.

Type 3c shown in Fig. 9c

In home routed scenario shown in both Type 1c and Type 3c, the NF service producer(s) or data collection source can be NSSF, hSMF, hPCF, UPF, AF, NEF and UDM accordingly. Therefore, the analytics consumers in the VPLMN for analytics involving above source NFs may need to request hPLMN NWDAF through home NRF (hNRF) either directly or through visited (I) NWDAF (v(l)NWDAF) and visited NRF (vNRF) for analytics subscription and analytics information request.

Type 4 shown in Fig. 10

Data collection: both l-NWDAF and the NF that notifies the data lies within the target PLMN.

Analytics exposure: the l-NWDAF and the NF consuming the analytics information belong to different network.

Type 5 shown in Fig. 12 Data collection: the l-NWDAF and the NF that notifies the data lies in the different PLMN.

Analytics exposure: both the NWDAF and the NF consuming the analytics information belongs to the same PLMN.

Type 6 shown in Fig. 7a

Data collection: both master/service producer l-NWDAF and the NF that notifies the data lies within the target PLMN.

Analytics exposure: the secondary/service consumer l-NWDAF and the NF consuming the analytics information belong to the same source PLMN.

NWDAF instance role model

In an embodiment where both NWDAFs (instances) in source PLMN/region and target PLMN/region are involved, the NWDAF in the source PLMN/region acts as the master NWDAF and the NWDAF in the target PLMN/region acts as the secondary NWDAF. The master NWDAF requests to the secondary NWDAF for analytics subscription, analytics data and receives on behalf of any NF residing in it is network. Further the master NWDAF performs inter NWDAF co-ordination and data consolidation for roaming related analytics subscription, data collection and analytics provision.

In an implementation where more than one NWDAF (or instances) are deployed exclusively to handle roaming and non-roaming analytics separately, there can be an intermediate NWDAF to handle roaming analytics in every PLMN. The intermediate NWDAF in the source PLMN/region can take the master NWDAF role and the intermediate NWDAF in the target PLMN/region can take the secondary NWDAF role and the master NWDAF can take care of inter NWDAF interactions and data consolidation for roaming related analytics subscription, data collection and analytics provision.

Interface Nxnwdaf can be used as the inter NWDAF interface between the master and secondary NWDAF in the intra-PLMN inter-region scenario as shown in Fig. 13. Interface Ninwdaf can be used as the inter NWDAF interface between the master and secondary NWDAF in the inter PLMN scenario as shown in Fig. 13. Nxnwdaf-i (inter NWDAF interface) can be used as the inter NWDAF interface between the master and secondary intermediate NWDAF in the intra-PLMN inter-region scenario as shown in Fig. 14. Ninwdaf-i can be used as the inter NWDAF interface between the master and secondary intermediate NWDAF in the inter PLMN scenario as shown in Fig. 14. NWDAF instance role model 1

Implementation aspect: inter PLMN and intra PLMN inter region scenarios. Current NWDAFs (or instances) taking roles of master and secondary NWDAFs instances.

Fig. 13 shows in case 1 PLMN1 in region 1 and PLMN1 in region 2; and in case 2 PLMN1 and PLMN2.

NWDAF Instance role model 2

Implementation aspect: inter PLMN and intra PLMN inter region scenarios. A dedicated NWDAF (instances) called intermediate NWDAF takes role of master NWDAF in the target PLMN/region to provide inter PLMN/region analytics information. Further the NWDAF (instances) in the source PLMN/region takes the role of secondary NWDAF which forwards/requests the subscription/analytics info on behalf of an analytics consumer in the source PLMN/region.

Fig. 14 shows in case 1 PLMN1 in region 1 and PLMN1 in region 2. In case 2 PLMN1 and PLMN2.

According to embodiments of the invention four major procedures are disclosed. These are discovery procedure, analytics subscription procedure, data collection procedure and data analytics procedure. Additionally, different verification procedures at the second network entity 300 is also disclosed. These procedures are covered for the intra PLMN and inter region case and the inter PLMN case. Generally, in the intra PLMN and inter region case the first domain is a first region in a PLMN and the second domain is a second region in the PLMN. Generally, in the inter PLMN case the the first domain is a first PLMN and the second domain is a second PLMN.

In the following disclosure with reference to Figs. 15 to 20 mentioned procedure will be described. However, the following can be noted about mentioned procedure.

Discovery procedure

The first network entity 100 is configured to send a discovery request message to the second network entity 300 previous to sending the first message, wherein the discovery request message indicates at least one of the target PLMN ID, the source PLMN ID, the source region ID, and the target region ID. The first network entity 100 is configured to receive a discovery response message from the second network entity 300, wherein the discovery request response message indicates the NWDAF or a NWDAF instance profile and its address.

Analytics subscription procedure

The first message is an analytics subscription request message indicating: a requested analytics set, a PLMN and region-specific notification target address, a PLMN and region specific notification correlation ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a requested analytics set, a PLMN specific notification target address, a PLMN specific notification correlation ID when the first domain is the first PLMN and the second domain is the second PLMN.

The first network entity 100 is configured to receive an analytics subscription response message from the second network entity 300, wherein the analytics subscription response message 510aa indicates: a PLMN and region-specific notification target address, a PLMN and region-specific subscription correlation ID, and an allowed analytics ID(s) when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, ora PLMN specific notification target address, a PLMN specific subscription correlation ID, and an allowed analytics ID(s) when the first domain is the first PLMN and the second domain is the second PLMN.

Data collection procedure

The first message is a data collection request message indicating a requested event ID(s).

The first network entity 100 is configured to receive a data collection response message from the second network entity 300, wherein the data collection response message indicates an allowed event ID(s) and an event report(s).

Data analytics procedure

The first message is a data analytics request message indicating: a requested analytics set, a analytic reporting information, a PLMN and region-specific notification target address, and a PLMN and region specific subscription correlation ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or an analytics ID(s), an analytic reporting information, a PLMN specific notification target address, and a PLMN specific subscription correlation ID when the first domain is the first PLMN and the second domain is the second PLMN. The first network entity 100 is configured to receive a data analytics response message from the second network entity 300, wherein analytics response message indicates: a PLMN and region-specific notification target address, a PLMN and region-specific subscription correlation ID, an allowed analytics ID(s), an analytics information, and a validity period when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a PLMN specific notification correlation ID, a PLMN specific subscription correlation ID, an allowed analytics ID(s), an analytics information, and a validity period when the first domain is the first PLMN and the second domain.

Verification in the intra PLMN and inter region case

When the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, the second network entity 300 is configured to transmit the data collection response message, or the data analytics response message to the first network entity 100 upon verifying at least one of the source region ID, a PLMN and region-specific subscription correlation ID, an inter-Region geo-political data sharing restrictions, and an inter-region data analytics and/or exposure restriction information.

The second network entity is configured to transmit the analytics subscription response message to the first network entity 100 upon further verifying inter-region data analytics restriction information.

Verification in the inter PLMN case

When the first domain is a first PLMN and the second domain is a second PLMN, the second network entity 300 is configured to transmit the data collection response message or the data analytics response message to the first network entity 100 upon verifying at least one of a PLMN specific subscription correlation ID, the source PLMN ID and corresponding inter-PLMN data analytics and/or exposure restriction information.

The second network entity 300 is configured to transmit the analytics subscription response message to the first network entity 100 upon further verifying a inter PLMN data analytics restriction information.

NWDAF discovery and selection in inter PLMN roaming

In local breakout scenario, if the NF notifying the analytics and NWDAF or intermediate NWDAF (l-NWDAF) lies in the home network, i.e., in a different network than the analytics consumer, then the S-NSSAI, analytics ID(s) and NWDAF serving area information will not be sufficient enough to discover the NWDAF (or l-NWDAF) lying in the home network.

In case of home routed roaming, any analytics consumer residing in the visited network/source network may require network data analytics information from both NFs in the same PLMN and from NFs in the different PLMN i.e. the target PLMN/home PLMN. Meanwhile in other cases such as inter PLMN service operation i.e. inter PLMN handover, the analytics consumer residing in one PLMN may need to know the target NF’s analytics information where the target NF resides in a different PLMN.

Therefore, in the above cases if any analytics consumer NF residing in the source PLMN attempts to discover by itself or through NRFs (e.g. vNRF and hNRF) the NWDAF/I-NWDAF residing in the target PLMN, the analytics consumer and/or the NRF need to consider the following proposed information:

• The target PLMN ID and the source PLMN ID, respectively, for the NWDAF/I-NWDAF selection;

• Inter-PLMN data analytics/subscription restriction information; and/or

• Inter-PLMN NWDAF instance access restriction information.

Intra PLMN roaming case

In the intra PLMN roaming case the NF consumer in the source region and the NRF can also consider:

• The Tracking Area Identifiers (TAIs) and region ID for the NWDAF selection accordingly. The region ID can indicate any geographical area or province. o The region ID can be a geographical zone identification information that contains the mapping of NWDAF network slice instance coverage information and the set of all cell IDs or base station (BS) areas or any geographical partitioning information lying within the NWDAF network slice instance coverage;

• Inter-region geo-political data sharing restrictions;

• Inter-region data analytics restriction information; and/or

• Inter-region NWDAF instance access restriction information.

Inter PLMN analytics provision to support roaming scenario

It is to be noted that for the intra PLMN case, in the following Figs the PLMN 1 should be considered as region 1 and PLMN should be considered as region 2 accordingly.

Analytics subscription procedure for roaming case It is to be noted that the main embodiment involving NEF/I-NEF in the procedure, the NEF/I- NEF is not shown in the following analytics subscription procedures for simplicity. But the analytics subscription request message from the NWDAF service consumer can go a NEF/I- NEF to the target NWDAF, where the NEF/I-NEF in the target network performs the validation and filtration of the analytics subscription request based on the inter PLMN analytics and data sharing restriction information. The NEF/I-NEF controls the analytics exposure mapping among the source PLMN ID with allowed analytics ID, and associated inbound restrictions (i.e., applied to subscription of the analytics ID for any analytics consumer from the source PLMN) and/or outbound restrictions, i.e., applied to notification of analytics ID to any analytics consumer from the source PLMN. The source analytics consumer or the source NWDAF is configured with the appropriated NEF/I-NEF to subscribe to analytics information, the allowed analytics ID(s), and with allowed inbound restrictions (i.e., parameters and/or parameter values) for subscription to each analytics ID in the target PLMN.

Inter PLMN network data analytics subscription procedure (Based on Type 1a/b/c architecture) This embodiment is based on the Type 1a/b/c architecture. It is noted that restriction over analytics provision between PLMNs. The restrictions can be applied by the NWDAF or NEF/I- NEF or NRF in the target PLMN.

The following procedure shown in Fig. 15 is used by any NWDAF service consumer (e.g. including NFs/OAM) to subscribe/unsubscribe at target NWDAF (or an intermediate NWDAF at the target network) residing at a different PLMN either directly (or through serving/source/visited NWDAF) to be notified on analytics information, using Ninwdaf_AnalyticsSubscription service defined in this disclosure. Any network entity from different PLMNs can consume this service based on the inter PLMN service agreements specific to the network data analytics restrictions for roaming and inter PLMN cases. PLMN 1 can be the source network or visited network (or serving network) and PLMN2 can be the target network or home network.

The proposed Ninwdaf_AnalyticsSubscription service operation is defined to support inter NWDAF based communication. Otherwise, the Ninwdaf_AnalyticsSubscription service can support analytics subscription related message request and response to and from target NWDAF instance exclusively responsible for inter PLMN network data analytics support.

It is noted that the embodiment involving NEF/I-NEF in the procedure, the NEF/I-NEF is not shown in the Fig. 15 for simplicity, but the analytics subscription request message from the NWDAF service consumer can go a NEF/I-NEF to the target NWDAF, where the NEF/I-NEF in the target network performs the validation and filtration of the analytics subscription request based on the inter PLMN analytics and data sharing restriction information. The NEF/I-NEF controls the analytics exposure mapping among the source PLMN ID with allowed analytics ID, and associated inbound restrictions (i.e. applied to subscription of the analytics ID for any analytics consumer from the source PLMN) and/or outbound restrictions (i.e., applied to notification of analytics ID to any analytics consumer from the source PLMN). The source analytics consumer or the source NWDAF is configured with the appropriated NEF/I-NEF to subscribe to analytics information, the allowed analytics ID(s), and with allowed inbound restrictions (i.e., parameters and/or parameter values) for subscription to each analytics ID in the target PLMN.

In step 1 in Fig. 15, the NWDAF service consumer can perform discovery if the target NWDAF address or routing information is not locally configured at its side. The NWDAF service consumer interacts with an NRF by sending Nnrf_NWDAFDiscovery request message (i.e. discovery request message) containing request analytics set, S-PLMN ID and T-PLMN ID.

In step 2 in Fig. 15, the NRF in PLMN1 and NRF in PLMN2 interact using the Nnrf_NF Discovery service. The NRF in the serving PLMN identifies NRF in home PLMN (hNRF) based on the home PLMN ID (T-PLMN ID), and it requests "NF discovery" service from NRF in home/target PLMN to get the expected NWDAF profile(s) of the NWDAF instance(s) corresponding to the requested analytics set deployed in the home PLMN. As the NRF in the serving PLMN triggers the "NF discovery" on behalf of the NF service consumer, the NRF in the serving PLMN shall not replace the information of the service requester NF, i.e. NF consumer ID, in the discovery request message (i.e. discovery request message) it sends to the hNRF. The hNRF may further query an appropriate local NRF in the home PLMN based on the input information received from NRF of the serving PLMN. The FQDN of the local NRF or endpoint address of local NRF's NF discovery service in the home PLMN may be configured in the hNRF or may need to be discovered based on the input information. The home/target NRF responds to the serving/source NRF in NnrfJMWDAFDiscoveryResponse message (i.e. discovery response message) with one or more NWDAF instance profile(s) based on the home PLMN’s privacy, inter PLMN analytics access restriction and network data analytics provision related service level agreement.

In step 3 in Fig. 15, the source/serving NRF responds to the NWDAF service consumer with one or more NWDAF instance profile(s) based on the home PLMN’s privacy, inter PLMN analytics access restriction and network data analytics provision related service level agreement. In step 4 in Fig. 15, the NWDAF service consumer then subscribes to or cancels subscription to analytics information by invoking the Ninwdaf_AnalyticsSubscription_Subscribe/ Ninwdaf_AnalyticsSubscription_Unsubscribe service operation (i.e. analytics subscription request message), which contains the input such as the requested analytics set with one or more analytics ID(s), target of analytics reporting, notification target address, PLMN specific notification correlation ID, analytics reporting information, source PLMN identification information (S-PLMN ID) and target PLMN identification information (T-PLMN ID). Inputs, optional: analytics Filter information, PLMN specific subscription correlation ID in case of modification of the analytics subscription, preferred level of accuracy, time when analytics information can be included.

In step 5 in Fig. 15, when a subscription to analytics information is received, the target (I) NWDAF verifies the inter-PLMN network data analytics provision restriction and further determines whether triggering new data collection is needed.

In step 6 in Fig. 15, if the verification of the source PLMN’s subscription request for any requested analytics set is acceptable for the target (l)NWDAF based on the target PLMN’s inter PLMN access restriction information, then the target (l)NWDAF notifies the NWDAF service consumer with the analytics information by invoking Ninwdaf_AnalyticsSubscription_Notify service operation (i.e. analytics subscription response message) containing received S-PLMN specific notification target address, T-PLMN specific subscription correlation ID (required for management of this subscription), target NWDAF profile with allowed analytics ID(s), allowed target NF analytics profile/ allowed target analytics NF profile.

It is noted that the allowed target NF analytics profile contains the NF IDs and NF set ID/NF service set ID which a NWDAF analytics consumer is allowed to request for the analytics from the target PLMN.

It is further noted that the PLMN specific subscription correlation ID has to be provisioned to make the subscription unique across different PLMN analytics provided to the consumer. This avoids subscription correlation ID duplication issues at the analytics consumer. Also, inter NWDAF communication can either be supported by the existing N32 interface or using a new Ninwdaf interface. The above procedures can also function with SCP involvement based on the implementation. The NF/NWDAF service consumer can interact directly with the NRF and T-(I)NWDAF accordingly.

Intra PLMN inter region roaming scenario This embodiment is also applicable to the embodiment described in the following section based on Type 3a/b/c architecture. For the intra PLMN case the subscription procedure shown in Fig. 21 works as follows.

PLMN 1 region-1 is considered as source region and the PLMN 1 region-2 is considered as the target region. It is noted that the discovery procedure briefed in the steps 1-3 below are optional based on the NWDAF address availability at the NWDAF service consumer or NRF in the serving/source region.

In step 1 in Fig. 21 , the NWDAF service consumer can perform discovery if the target NWDAF address or routing information (for NWDAF instance residing in a different region) is not locally configured at its side. The NWDAF service consumer interacts with an NRF by sending Nnrf_NWDAFDiscovery request message (i.e. discovery request message) containing request analytics set, S-PLMN ID, source - tracking area ID (S-TAI), source - region ID, target - tracking area ID (T-TAI) and target region ID (T-region ID).

In step 2 in Fig. 21 , the NRF in region 1 and NRF in region 2 interact using the Nnrf_NF Discovery service. The NRF in the serving region identifies NRF in target region with in the same PLMN based on the source PLMN ID, source TAI/region ID and target TAI/region ID to request the "NF discovery" service from NRF in target region to get the expected NWDAF profile(s) of the NWDAF instance(s) corresponding to the requested analytics set deployed in the target region. As the NRF in the source region triggers the "NF discovery" on behalf of the NWDAF service consumer, the NRF in the serving region shall not replace the information of the service requester NF, i.e. NF consumer ID, in the discovery request message it sends to the NRF in the target region.

The NRF in the target region may further query an appropriate local NRF in the home PLMN based on the input information received from NRF of the serving region. The FQDN of the local NRF or endpoint address of local NRF's NF discovery service in the same PLMN’s target region may be configured in the target NRF or may need to be discovered based on the input information. The target NRF responds to the serving/source NRF in Nnrf_NWDAFDiscoveryResponse message (i.e. discovery response message) with one or more NWDAF instance profile(s) based on the target region’s privacy, target region geopolitics restrictions over the subscriptions, inter region analytics access restriction and network data analytics provision related service level agreement.

In step 3 in Fig. 21 , the serving NRF responds to the NWDAF service consumer with one or more NWDAF instance profile(s) based on the target region’s privacy, target region geopolitics restrictions over the subscriptions, inter region analytics access restriction and network data analytics provision related service level agreement.

In step 4 in Fig. 21 , the NWDAF service consumer then subscribes to or cancels subscription to analytics information by invoking the Nxnwdaf_AnalyticsSubscription_Subscribe/ Ninwdaf_AnalyticsSubscription_Unsubscribe service operation (i.e. analytics subscription request message), which contains the input such as the requested analytics set with one or more analytics ID(s), target of analytics reporting, notification target address, PLMN and region specific notification correlation ID, analytics reporting information, source PLMN identification information (S-PLMN ID), S-TAI, S-region ID, T-TAI and T-region ID. Inputs, optional: analytics filter information, PLMN and region specific subscription correlation ID in case of modification of the analytics subscription, preferred level of accuracy, time when analytics information can be included.

In step 5 in Fig. 21 , when a subscription request to analytics information is received, the target (I) NWDAF (instance) (an intermediate NWDAF located in the target network) verifies the inter region network data analytics provision restriction, geopolitics restrictions over the data sharing among different regions and further determines whether triggering new data collection is needed.

In step 6 in Fig. 21 , if the verification of the source region’s subscription request for any requested analytics set is acceptable for the target (l)NWDAF based on the target region’s inter region access restriction information, then the target (l)NWDAF notifies the NWDAF service consumer with the analytics information by invoking Ninwdaf_AnalyticsSubscription_Notify service operation (i.e. analytics subscription response message) containing received S-PLMN and region specific notification target address, source PLMN and T-region specific subscription correlation ID required for management of this subscription, target NWDAF profile with allowed analytics ID(s), allowed target NF analytics profile/allowed target analytics NF profile. It is noted that allowed target NF analytics profile contains the NF IDs and NF set ID/NF service set ID which a NWDAF analytics consumer is allowed to request for the analytics from the target region with the same PLMN.

It is further noted that the PLMN and region-specific subscription correlation ID has to be provisioned to make the subscription unique across different regions analytics provided to the consumer. This avoids subscription correlation ID duplication issues at the analytics consumer. It is further noted that inter NWDAF communication can be supported in this procedure using a new Nxnwdaf interface in case there exists dedicated NWDAFs or instances for every single region. For this case, the above procedure will involve a source NWDAF in the source region which forwards the subscription request/response procedure between the NWDAFs in the source and target regions with in the same PLMNs.

Inter PLMN network data analytics subscription procedure (Based on Type 3a/b/c architecture) In this embodiment SCP may be used if needed and based on the Type 3a/b/c architecture. It is noted a restriction over analytics provision between PLMNs. This embodiment is illustrated in Fig. 16.

In step 1 in Fig. 16, the NWDAF service consumer subscribes to or cancels subscription to analytics information by invoking the Nnwdaf_AnalyticsSubscription_Subscribe/ Nnwdaf_AnalyticsSubscription_Unsubscribe (i.e. analytics subscription request message) service operation towards a source/serving (l)NWDAF (S-(I)NWDAF). The analytics subscription request message input can contain requested analytics set with one or more analytics ID(s), target of analytics reporting, notification target address, PLMN specific notification correlation ID, analytics reporting information, source PLMN identification information (S-PLMN ID) and target PLMN identification information (T-PLMN ID).

In step 2 in Fig. 16, the source/serving (l)NWDAF can perform discovery upon the request either by interacting with an NRF by sending Nnrf_NWDAFDiscovery request message (i.e. discovery request message) containing received request analytics set, S-PLMN ID and T-PLMN ID. Otherwise the source/serving (l)NWDAF can use information collected during the previous interactions with an NRF (by the Nnrf_NFDiscovery service or Nnrf_NFManagement_NFStatusNotify service operation) (i.e. discovery response message). The source/serving (l)NWDAF recognises that the request is for a NWDAF service producer (e.g. an NWDAF instance suitable for the requested analytics set) in another PLMN. In step 3 in Fig. 16, the NRF in PLMN-1 and NRF in PLMN 2 interact using the Nnrf_NF Discovery service. The NRF in serving PLMN identifies NRF in home PLMN (hNRF) based on the home PLMN ID (T-PLMN ID), and it requests "NF discovery" service from NRF in home/target PLMN to get the expected NWDAF profile(s) of the NWDAF instance(s) corresponding to the requested analytics set deployed in the home PLMN. As the NRF in the serving PLMN triggers the "NF discovery" on behalf of the NF service consumer, the NRF in the serving PLMN shall not replace the information of the service requester NF, i.e. NF consumer ID, in the discovery request message it sends to the hNRF. The hNRF may further query an appropriate local NRF in the home PLMN based on the input information received from NRF of the serving PLMN. The FQDN of the local NRF or endpoint address of local NRF's NF discovery service in the home PLMN may be configured in the hNRF or may need to be discovered based on the input information. The home/target NRF responds to the serving/source NRF with one or more NWDAF instance profile(s) based on the home PLMN’s privacy, inter PLMN analytics access restriction and network data analytics provision related service level agreement.

In step 4 in Fig. 16, the source/serving NRF responds to the source/serving (l)NWDAF in Nnrf_NWDAFDiscoveryResponse message (i.e. discovery response message) with one or more NWDAF instance profile(s) based on the home PLMN’s privacy, inter PLMN analytics access restriction and network data analytics provision related service level agreement.

In step 5 in Fig. 16, the source/serving (l)NWDAF sends the Ninwdaf_AnalyticsSubscription_Subscribe/Ninwdaf_AnalyticsSubscription_Unsubscribe service operation message (i.e. analytics subscription request message) as received from the NWDAF service consumer, which contains the input such as the requested analytics set with one or more analytics ID(s), target of analytics reporting, notification target address, a PLMN specific notification correlation ID, analytics reporting information, source PLMN identification information (S-PLMN ID) and target PLMN identification information (T-PLMN ID).

In step 6 in Fig. 16, when a subscription to analytics information is received, the target (I) NWDAF verifies the inter-PLMN network data analytics provision restriction and further determines whether triggering new data collection is needed.

In step 7 in Fig. 16, if the verification of the source PLMN’s subscription request for any requested analytics set is acceptable for the target (l)NWDAF based on the target PLMN’s inter PLMN access restriction information, then the target (l)NWDAF notifies the source/serving (l)NWDAF with the analytics information by invoking Ninwdaf_AnalyticsSubscription_Notify (i.e. analytics subscription response message) service operation containing received S-PLMN specific notification target address, T-PLMN specific subscription correlation ID (required for management of this subscription), target NWDAF profile with allowed analytics ID(s), allowed target NF analytics profile/ allowed target analytics NF profile.

It is noted that allowed target NF analytics profile contains the NF IDs and NF set ID/NF service set ID which a NWDAF analytics consumer is allowed to request for the analytics from the target PLMN. It is also noted that PLMN specific subscription correlation ID has to be provisioned to make the subscription unique across different PLMN analytics provided to the consumer. This avoids subscription correlation ID duplication issues at the analytics consumer.

In step 8 in Fig. 16, the source/serving (l)NWDAF forwards the Nnwdaf_AnalyticsSubscription_Notify service operation message (i.e. analytics subscription response message) to the NWDAF service consumer along with the received S-PLMN specific notification target address, T-PLMN specific subscription correlation ID (required for management of this subscription), target NWDAF profile with allowed analytics ID(s), allowed target NF analytics profile/ allowed target analytics NF profile.

It is noted that inter NWDAF communication can either be supported by the existing N32 interface or using a new Ninwdaf interface.

Data collection and co-ordination in the roaming case

It is to be noted that the main embodiment involving NEF/I-NEF in the procedure, the NEF/I- NEF is not shown in the following analytics data collection procedures for simplicity. But the data collect request message from the source NWDAF can go to a NEF/I-NEF to collect the data from a target NF service producer either directly or through a target NWDAF residing in the target PLMN, where the NEF/I-NEF in the target network performs the validation and filtration of the event exposure information specified in the data collection request/response based on the inter PLMN data collection and sharing restriction information. The NEF/I-NEF controls the data collection exposure mapping among the source PLMN ID with allowed event ID, and associated inbound restrictions (i.e. applied to subscription of the event ID for any analytics consumer from the source PLMN) and/or outbound restrictions (i.e., applied to notification of event ID to any event exposure consumer from the source PLMN). The source event exposure consumer or the source NWDAF is configured with the appropriated NEF/I-NEF to subscribe to data exposure information, the allowed event ID(s), and with allowed inbound restrictions (i.e., parameters and/or parameter values) for subscription to each event ID in the target PLMN. Embodiment: data collection in inter PLMN roaming scenario with new direct interface between S-INWDAF and T-INWDAF.

The procedure shown in Fig. 17 is used by (l)NWDAF in the source/serving/visited PLMN to subscribe/unsubscribe at NFs/AFs residing in the target/home network through the serving NWDAF to be notified for data collection on a related event (s), using the event exposure services specified in TS 23.288 Clause 6.2.2.2 and proposed inter NWDAF exposure services specified in this disclosure.

Data Collection Procedure for Inter PLMN Case (Indirect Model)

Pre-condition: the NF service consumer has subscribed to the source/serving NWDAF for (inter PLMN/roaming related) network data analytics information. In continuation to that, if the serving NWDAF has no related information subscribed to any NF service producer residing in target/Home PLMN on the corresponding event exposure, the source/Visited NWDAF initiates the following procedure to subscribe to the even exposure service from the NRFs/NFs/AFs residing in the target/home PLMN either directly or through an NEF/I-NEF.

In step 0 in Fig. 17, the source (I) NWDAF performs discovery procedure involving NRFs in the source and target PLMN to receive the target (I) NWDAF address.

In step 1 in Fig. 17, the serving NWDAF subscribes to or cancels subscription for a set of event ID(s) by invoking the Ninwdaf_Nnf/Naf_lnterPLMNEventExposure_Subscribe/Nnf /Naf_lnterPLMNEventExposure_ UnSubscribeservice operation (i.e. data collection request message) containing S-PLMN ID, T-PLMN ID and requested event IDs. It is noted that the event ID(s) are defined in TS 23.502.

In step 2 in Fig. 17, on receiving the Ninwdaf_Nnf/Naf_lnterPLMNEventExposure_Subscribe message (i.e. data collection request message), the target (l)NWDAF verifies inter PLMN event exposure restriction information based on its own PLMN ID and source PLMN ID. Based on the restriction level imposed by the target PLMN ID, the target NWDAF finalize on the set of event ID that can be exposed to the source NWDAF and the target (l)NWDAF requests only the finalized event IDs to the target NF service producer for the source (l)NWDAF.

In step 3 in Fig. 17, the target NWDAF performs the existing Nnrf_NFManagement_NFRegister/Nnrf_NFManagement_NFStatusSubscribe request/response Procedure based on TS 23.502 if the target NWDAF has no subscription for related information with the NFs/AFs in its same PLMN (target PLMN). In step 4 in Fig. 17, the target NWDAF sends the Nnf/

Naf_lnterPLMNEventExposure_Subscribe/Nnf/NafJnterPLMNEventExposure_UnSubscribe message (i.e. data collection request message) containing S-PLMN ID, allowed event ID(s), and S-NWDAF ID (S-NWDAF Instance ID) to the target NRFs/NFs/AFs on behalf of the source NWDAF.

In step 5 in Fig. 17, the target NRF/NF/AF on receiving the event exposure subscribe message (i.e. data collection request message), performs the subscription procedure and stores the subscription information along with the source NWDAF information (S-NWDAF ID and instance ID). Further target NRF/NF/AF which are the service producer provides the

Nnf/Naf_EventExposure_Notify message (i.e. data collection response message) containing the event report to the T-(I)NWDAF for the allowed event ID(s) along with the allowed event ID(s) to the target (l)NWDAF.

In step 6 in Fig. 17, the T-(l) NWDAF verifies the allowed event ID(s) and the corresponding event report to check if it conforms to the inter PLMN event exposure restrictions and filter accordingly the relevant data to be exposed to the source (I) NWDAF.

In step 7 in Fig. 17, the target (I) NWDAF sends the Ninwdaf_Nnf/Naf_EventExposure_Notify message (i.e. data collection response message) containing the allowed/accepted event IDs along with the corresponding event report to the source NWDAF.

Intra PLMN inter region roaming scenario

For the intra PLMN case the data collection procedure shown in Fig. 22 works as follows.

In step 0 in Fig. 22, the source (I) NWDAF performs discovery procedure involving NRFs in the source region and target region to receive the target (I) NWDAF address residing in the target region. PLMN 1 region-1 is considered as source/serving/Visited region and the PLMN 1 region-2 is considered as the target region.

In step 1 in Fig. 22, the serving NWDAF subscribes to or cancels subscription for a (set of) event ID(s) by invoking the Ninwdaf_Nnf/Naf_lnterPLMNEventExposure_Subscribe/Nnf /Naf_lnterPLMNEventExposure_ UnSubscribeservice operation (i.e. data collection request message) containing S-PLMN ID, T-PLMN ID and requested Event IDs. In an embodiment the proposed interface Nxnwdaf can be used instead of the proposed Ninwdaf. In such case, all the service operation message will start with the keyword Nxnwdaf instead of Ninwdaf. It can be noted that the event ID (s) can be defined according to 3GPP TS 23.502.

In step 2 in Fig. 22, on receiving the Ninwdaf_Nnf/Naf_lnterPLMNEventExposure_Subscribe message (i.e. data collection request message), the target (l)NWDAF verifies inter region event exposure restriction information. Geopolitical data sharing restrictions based on its own PLMN ID (source PLMN ID provided by the source NWDAF), its T-TAI, T-region ID and the requesting NWDAF’s information such as S-PLMN ID, S-TAI, S-region ID. Based on the restriction level imposed by the target TAI and region ID, the target NWDAF (instance) determines the set of event ID that can be exposed to the source NWDAF.

In step 3 in Fig. 22, further the target NWDAF performs the existing

Nnrf_NFManagement_NFRegister/Nnrf_NFManagement_NFStatusSubscribe request response procedure based on TS 23.502 if the target NWDAF has no subscription for related information with the NFs/AFs in the same PLMN (i.e. target region).

In step 4 in Fig. 227, the target NWDAF sends the Nnf/

Naf_lnterPLMNEventExposure_Subscribe/Nnf / NafJnterPLMNEventExposureJJnSubscribe message (i.e. data collection request message) containing S-PLMN ID, S-region ID, S-TAI allowed event ID(s), and S-NWDAF ID (S-NWDAF Instance ID) to the target NRFs/NFs/AFs on behalf of the source NWDAF.

In step 5 in Fig. 22, the target NRF/NF/AF on receiving the event exposure subscribe message, performs the subscription procedure and stores the subscription information along with the source NWDAF information (S-NWDAF ID and instance ID). Further, target NRF/NF/AF which are the service producer provides the Nnf/Naf_EventExposure_Notify message containing (i.e. data collection response message) the event report to the T-(I)NWDAF for the allowed event ID(s) along with the allowed event ID(s) to the target (l)NWDAF.

In step 6 in Fig. 22, the T-(l) NWDAF verifies the allowed event ID(s) and the corresponding event report to check if it conforms to the inter region event exposure restrictions, inter region geopolitics data sharing restrictions and filter accordingly the relevant data to be exposed to the source (I) NWDAF. In step 7 in Fig. 22, the target (I) NWDAF sends the Ninwdaf_Nnf/Naf_EventExposure_Notify message i.e. data collection response message) containing the allowed/accepted event IDs along with the corresponding event report to the source NWDAF in the source region.

It is noted that the network functions and entities discussed in the above procedures lying in the source region and the target region belongs to the same PLMN and so the source PLMN ID is the PLMN ID is same for both regions.

Data collection in inter PLMN roaming scenario (Direct Model)

An embodiment with data collection in inter PLMN roaming scenario is illustrated in Fig. 18. It is noted that this embodiment is without T-INWDAF involvement.

This procedure is used by (l)NWDAF in the source/serving/Visited PLMN to subscribe/unsubscribe at NFs/AFs residing in the target/home network either directly through the NRFs and/or through the NEF/I-NEF to be notified for data collection on a related event(s), using the event exposure services specified in TS 23.288 Clause 6.2.2.2.

Pre-condition: the NF service consumer has subscribed to the source/serving NWDAF for (inter PLMN/roaming related) network data analytics information. In continuation to that, if the serving NWDAF has no related information subscribed to any NF service producer residing in target/home PLMN on the corresponding event exposure, the source/visited NWDAF initiates the following procedure to subscribe to the even exposure service from the NRFs/NFs/AFs residing in the target/home PLMN.

In step 1 in Fig. 18, the source (I) NWDAF performs discovery procedure involving NRFs in the source and target PLMN to receive the address of the target NF service producers (NFs/NRFs/AFs) for the event exposure services related to data collection. The source (I) NWDAF sends the Nnrf_NF discovery request (i.e. discovery request message) (requested event information, S-PLMN ID, T-PLMN ID) to the source NRF. The source NRF on receiving the target PLMN ID, identifies that the discovery is for NF service producer in a different PLMN.

In step 2 in Fig. 18, the source NRF sends the Nnrf_NF discovery request (i.e. discovery response message) (requested event information, S-PLMN ID, T-PLMN ID) to the target NRF in the different based on the target PLMN ID.

In step 3 in Fig. 18, the target NRF on receiving the discovery request, performs the verification of requested event information and the S-PLMN ID based on the inter PLMN event notifications restrictions and decide on the allowed event ID(s) and target NFs/AFs which can be exposed to the source NWDAF according to the inter PLMN event exposure restriction information.

In step 4 in Fig. 18, the target NRF then sends the Nnrf_NF discovery response message (i.e. discovery response message) containing the allowed event ID(s) and the related NF/AF profile to the source NRF.

In step 5 in Fig. 18, the source NRFs sends the Nnrf_NF discovery response message (i.e. discovery response message) along with the received allowed event ID(s) and the target NF/AF profile information to the source (I) NWDAF.

In step 6 in Fig. 18, based on the received target NF/AF profile information, the source (I) NWDAF sends the

Nnf/Naf_lnterPLMNEventExposure_Subscribe/Nnf/Naf_lnterPLMNEventExposure_unSubscr ibe request message (i.e. data collection request message) with S-PLMNID, T-PLMNID and event ID(s)) to target NFs/AFs.

In step 7 in Fig. 18, on receiving the event exposure subscription request, the target NFs/AFs need to verify the inter PLMN requested event ID(s), the event exposure and notifications restrictions for the S-PLMN ID and generate the corresponding event exposure subscription ID, accepted event ID and related event report if available.

In step 8 in Fig. 18, the target NFs/NFs service provider sends the event exposure subscription related result indication message (i.e. data collection response message) with the event subscription ID, accepted event ID(s), S-PLMNID and T-PLMNID to the S-(l) NWDAF.

In step 9 in Fig. 18, as and when any event related to the subscription occurs, the service provider NFs/AFs sends the Nnf/Naf_EventExposure_Event notification message (i.e. data collection response message) to the S-(l) NWDAF along with the event ID(s) and the corresponding event report.

Analytics request by NWDAF/I-NWDAF service consumers in roaming case

The procedure shown in Fig. 19 is used by the NWDAF/I-NWDAF service consumers (e.g. including NFs/OAM) to request and get from target NWDAF, the target network data analytics information, or inter PLMN data analytics information, using the proposed Ninwdaf_Analyticslnfo service and the existing Nnwdaf_Analyticslnfo service defined in TS 23.288 Clause 7.3. It is to be noted that the embodiment involving NEF/I-NEF in the procedure, the NEF/I-NEF is not shown in the following analytics request/response procedures for simplicity. But the network data analytics request message from the NWDAF service consumer can go via a NEF/I-NEF to the target (l)NWDAF, where the NEF/I-NEF in the target network performs the validation and filtration of the data analytics request (requested analytic ID(s)) based on the inter PLMN analytics and data sharing restriction information. The NEF/I-NEF controls the analytics exposure mapping among the source PLMN ID with allowed analytics ID, and associated inbound restrictions (i.e. applied to requesting analytics IDs for any analytics consumer from the source PLMN) and/or outbound restrictions (i.e., applied to notification of allowed analytics ID to any analytics consumer from the source PLMN). The source NWDAF analytics consumer is configured with the appropriated NEF/I-NEF to request to analytics information (with corresponding analytic IDs), the allowed analytics ID(s), and with allowed inbound restrictions (i.e., parameters and/or parameter values) for requesting each analytics ID in the target PLMN.

Inter PLMN network data analytics request procedure (Based on Type 1a/b/c architecture)

An embodiment with inter PLMN network data analytics request procedure is illustrated in Fig. 19 without SCP and based on the Type 1a/b/c architecture.

It is noted that restriction over analytics provision between PLMNs. The SCP may or may not involve in the following procedure between the NF/NWDAF service consumer and NRF based on the implementation.

In step 1 in Fig. 19, the NWDAF service consumer if not configured with the target (I) NWDAF address locally, can perform discovery by interacting with an NRF by sending Nnrf_NWDAFDiscovery request message (i.e. discovery request message) containing received request analytics ID, S-PLMN ID and T-PLMN ID. Otherwise the NWDAF service consumer can use information collected during the previous interactions with an NRF (by the Nnrf_NF Discovery service (i.e. discovery request message) or

Nnrf_NFManagement_NFStatusNotify service operation (i.e. discovery response message)).

In step 2 in Fig. 19, the NRF in the S-PLMN recognizes that the request is for a NWDAF service producer (e.g. an NWDAF instance suitable for the requested analytics set) in another PLMN. NRF in PLMN-1 and NRF in PLMN 2 interact using the Nnrf_NFDiscovery service. The NRF in serving PLMN identifies NRF in home PLMN (hNRF) based on the home PLMN ID (T-PLMN ID), and it requests "NF discovery" service from NRF in home/target PLMN to get the expected NWDAF profile(s) of the NWDAF instance(s) corresponding to the requested analytics ID deployed in the home PLMN. As the NRF in the serving PLMN triggers the "IMF discovery" on behalf of the NF service consumer, the NRF in the serving PLMN shall not replace the information of the service requester NF, i.e. NF consumer ID, in the discovery request message (i.e. discovery request message) it sends to the hNRF.

The hNRF may further query an appropriate local NRF in the home PLMN based on the input information received from NRF of the serving PLMN. The FQDN of the local NRF or endpoint address of local NRF's NF discovery service in the home PLMN may be configured in the hNRF or may need to be discovered based on the input information. The home/target NRF responds to the serving/source NRF with one or more NWDAF instance profile(s) based on the home PLMN’s privacy, inter PLMN analytics access restriction and network data analytics provision related service level agreement. The target NRF further selects the suitable target NWDAF instance profile(s) from the received list based on the NWDAF service consumer requested analytics information and inter PLMN service agreement verification over the network data analytics information provision.

In step 3 in Fig. 19, the source/serving NRF further optionally selects the suitable target NWDAF instance profile(s) from the received list based on the NWDAF service consumer requested analytics information.

In step 4 in Fig. 19, the source/serving NRF responds to the NWDAF service consumer in Nnrf_NWDAFDiscoveryResponse message (i.e. discovery response message) with one or more NWDAF instance profile(s) based on the home PLMN’s privacy, inter PLMN analytics access restriction and network data analytics provision related service level agreement.

In step 5 in Fig. 19, the NWDAF service consumer sends to the target (I) NWDAF the Ninwdaf_Analyticsinfo_Request message (i.e. data analytics request message) containing the analytics ID(s), analytics filter information, target of analytic reporting, PLMN specific notification target address, a PLMN specific subscription correlation ID, an analytics reporting information, S-PLMN ID, and T-PLMN ID.

In step 6 in Fig. 19, when a analytics information request (i.e. data analytics request message) is received, the target (I) NWDAF verifies the correctness of the subscription correlation identifier and further the target (l)NWDAF checks based on its inter-PLMN network data analytics provision restriction information if the analytics request can be provided to the S- PLMN. In step 7 in Fig. 19, the target (I) NWDAF determines whether triggering new data collection is needed. If needed the data collection can be done by the target (I) NWDAF from the NF service producers.

In step 8 in Fig. 19, if the verification of the source PLMN’s analytics information request for any requested analytics ID is acceptable for the target (l)NWDAF based on the target PLMN’s Inter PLMN access restriction information, then the target (l)NWDAF notifies the NWDAF service consumer in the source/serving PLMN with the analytics information by invoking Ninwdaf_Analyticsinfo_Request response message (i.e. data analytics response message) with PLMN specific notification correlation information, S-PLMN ID, T-PLMN ID, analytics information and validity period.

Intra PLMN inter region roaming scenario

For the intra PLMN case the analytics request/response procedure shown in Fig. 23 works as follows.

The network data analytics request/response procedure for the inter region roaming scenario works based on the following procedure. PLMN 1 region-1 is considered as source/serving/visited region and the PLMN 1 region-2 is considered as the target region.

In step 1 in Fig. 23, the NWDAF service consumer if not configured with the target (I) NWDAF address locally, can perform discovery by interacting with an NRF by sending a Nnrf_NWDAFDiscovery request message (i.e. discovery request message) containing received request analytics ID, S-PLMN ID, S-TAI, S-region ID, T-TAI and T-region-ID. Otherwise the NWDAF service consumer can use information collected during the previous interactions with an NRF (by the Nnrf_NFDiscovery service or Nnrf_NFManagement_NFStatusNotify service operation.

In step 2 in Fig. 23, the NRF in the S-region recognizes that the request is for a NWDAF service producer (e.g. an NWDAF instance suitable for the requested analytics set) in another region of the same PLMN. NRF in PLMN-1 region-1 and NRF in PLMN-1 region-2 interact using the Nnrf_NF Discovery service. The NRF in serving region (region-1 ) identifies NRF in region-2 based on the T-TAI and T-region ID, and it requests "NF discovery" service from NRF in region- 2 to get the expected NWDAF profile(s) of the NWDAF instance(s) corresponding to the requested analytics ID deployed in the region-2. As the NRF in the serving region triggers the "NF discovery" on behalf of the NF service consumer, the NRF in the serving region shall not replace the information of the service requester NF, i.e. NF consumer ID, in the discovery request message (i.e. discovery request message) it sends to the target region.

The NRF in the target region may further query an appropriate local NRF in the target region based on the input information received from NRF of the serving region. The FQDN of the local NRF or endpoint address of local NRF's NF discovery service in the target region may be configured in the target NRF or may need to be discovered based on the input information.

The target NRF responds to the serving/source NRF with (i.e. discovery response message) one or more NWDAF instance profile(s) based on the home region’s privacy, inter region’s geopolitical data sharing restrictions, inter region analytics access restriction and network data analytics provision related service level agreement.

The target NRF further selects the suitable target NWDAF instance profile(s)from the received list based on the NWDAF service consumer requested analytics information and inter region service agreement verification over the network data analytics information provision.

The source/serving NRF further optionally selects the suitable target NWDAF instance profile(s) from the received list based on the NWDAF service consumer requested analytics information.

In step 3 in Fig. 23, the source/serving NRF responds to the NWDAF service consumer in a Nnrf_NWDAFDiscoveryResponse message (i.e. discovery request message) with one or more NWDAF instance profile(s) based on the target region’s privacy, inter region geopolitics data sharing restrictions, inter region analytics access restriction and network data analytics provision related service level agreement.

In step 4 in Fig. 23, the NWDAF service consumer sends to the target (I) NWDAF the Ninwdaf_Analyticsinfo_Request message (i.e. data analytics request message) containing the analytics ID, analytics filter information, target of analytic reporting, PLMN and region specific notification target address, PLMN and region specific subscription correlation ID, analytics reporting information, PLMN ID, S-TAI, S-region ID, T-TAI, and T-region ID.

In step 5 in Fig. 23, when an analytics information request is received, the target (I) NWDAF verifies the correctness of the subscription correlation identifier and further the target (l)NWDAF checks if the analytics request (i.e. data analytics request message) can be provided to the S-PLMN based on its inter-region network data analytics provision restriction information and inter region geopolitical data sharing restrictions available in the PLMN-1 region-2. Then the target (I) NWDAF determines whether triggering new data collection is needed. If needed the data collection can be done by the target (I) NWDAF from the NF service producers.

In step 6 in Fig. 23, if the verification of the source region’s analytics information request for any requested analytics ID is acceptable for the target (l)NWDAF based on the target region’s Inter PLMN access restriction information, then the target (l)NWDAF notifies the NWDAF service consumer in the source/serving region with the analytics information by invoking Ninwdaf_Analyticsinfo_Request response message (i.e. data analytics response message) with PLMN and region specific notification correlation information, PLMN ID, S-TAI, S-region ID, T-TAI, T-region ID, analytics information and validity period.

Inter PLMN analytics request procedure (Based on Type 3a/b/c architecture)

An embodiment with inter PLMN analytics request procedure is illustrated in Fig. 20 and in this embodiment, SCP may be used if needed. Restriction over analytics provision between PLMNs and based on Type 3a/b/c architecture. It is noted restriction over analytics provision between PLMNs in embodiment.

In step 1 in Fig. 20, the NWDAF service consumer in the source PLMN requests analytics information by sending the Ninwdaf_Analyticsinfo_Request message (i.e. data analytics request message) containing the analytics ID, analytics filter information, target of analytic reporting, PLMN specific notification target address, a PLMN specific subscription correlation ID), analytics reporting information, S-PLMN ID and T-PLMN ID to the source (I) NWDAF (S- (I) NWDAF).

In step 2 in Fig. 20, the source (I) NWDAF if not configured with the target (I) NWDAF address (or routing information) can perform discovery upon receiving the request either by interacting with an NRF by sending Nnrf_NWDAFDiscovery request message (i.e. discovery request message) containing received request analytics ID, S-PLMN ID and T-PLMN ID. Otherwise the source (I) NWDAF can use information collected during the previous interactions with an NRF (by the Nnrf_NFDiscovery service or Nnrf_NFManagement_NFStatusNotify service operation (i.e. discovery response message)).

In step 3 in Fig. 20, the source NRF recognizes that the request is for a NWDAF service producer (e.g. an NWDAF instance suitable for the requested analytics set) in another PLMN. The NRF in PLMN-1 and NRF in PLMN 2 interact using the Nnrf_NFDiscovery service. The NRF in serving PLMN identifies NRF in home PLMN (hNRF) based on the home PLMN ID (T- PLMN ID), and it requests "IMF discovery" service from NRF in home/target PLMN to get the expected NWDAF profile(s) of the NWDAF instance(s) corresponding to the requested analytics ID deployed in the home PLMN. As the NRF in the serving PLMN triggers the "NF discovery" on behalf of the NF service consumer, the NRF in the serving PLMN shall not replace the information of the service requester NF, i.e. NF consumer ID, in the discovery request message it sends to the hNRF. The hNRF may further query an appropriate local NRF in the home PLMN based on the input information received from NRF of the serving PLMN. The FQDN of the local NRF or endpoint address of local NRF's NF discovery service in the home PLMN may be configured in the hNRF or may need to be discovered based on the input information. The home/target NRF responds to the serving/source NRF with one or more NWDAF instance profile(s) based on the home PLMN’s privacy, inter PLMN analytics access restriction and network data analytics provision related service level agreement.

In step 4 in Fig. 20, the source/serving NRF further optionally selects the suitable target NWDAF instance profile(s) from the received list based on the NWDAF service consumer requested analytics information.

In step 5 in Fig. 20, the source/serving NRF responds to the source (I) NWDAF in Nnrf_NWDAFDiscoveryResponse message (i.e. discovery request message) with one or more NWDAF instance profile(s) based on the home PLMN’s privacy, inter PLMN analytics access restriction and network data analytics provision related service level agreement.

In step 6 in Fig. 20, the source (I) NWDAF sends to the target (I) NWDAF the Ninwdaf_Analyticsinfo_Request message (i.e. data analytics request message) containing the analytics ID, analytics filter information, target of analytic reporting, PLMN specific notification target address (+ PLMN specific subscription correlation ID), analytics reporting information, S-PLMN ID, and T-PLMN ID.

In step 7 in Fig. 20, when a analytics information request (i.e. data analytics request message) is received, the target (I) NWDAF verifies the correctness of the subscription correlation identifier and further the target (l)NWDAF checks based on its inter-PLMN network data analytics provision restriction information if the analytics request can be provided to the S- PLMN.

In step 8 in Fig. 20, the target (I) NWDAF determines whether triggering new data collection is needed. If needed the data collection can be done by the target (I) NWDAF from the NF service producers. In step 9 in Fig. 20, if the verification of the source PLMN’s analytics information request for any requested analytics ID is acceptable for the target (l)NWDAF based on the target PLMN’s Inter PLMN access restriction information, then the target (l)NWDAF notifies the source (I) NWDAF with the analytics information by invoking Ninwdaf_Analyticsinfo_Request response message (i.e. data analytics response message) with PLMN specific notification correlation information, S-PLMN ID, T-PLMN ID, analytics information and Validity Period.

In step 10 in Fig. 20, the source (I) NWDAF forwards the received Ninwdaf_Analyticsinfo_Request response message (i.e. data analytics response message) with PLMN specific notification correlation information, S-PLMN ID, T-PLMN ID, analytics information and Validity Period to the NWDAF service consumer in the source PLMN.

Intra PLMN inter region analytics provision to support roaming scenario

The solution defined for the inter PLMN case above can be adopted considering the two different PLMNs as two different regions. The subscription for requested analytics and requested analytics information provided from NWDAF in target region to analytics consumer in source region can be determined by the NWDAF (TR) based on the inter-region analytics provision restrictions available in the NWDAF (TR). The NWDAF location and the corresponding data collection approach are specified below.

Data Collection:

I. NWDAF (instance) lies in the target region: If the NWDAF instance in the target region requests data collection to a NF service producer in the same TR to provide analytics information for the analytics consumer in the SR, then either the NWDAF requests limited data from the NF service producer (based on the inter region analytics restriction information) or the NF service producer provides limited data to the NWDAF in the TR based on the inter region data collection restriction configured in the NF service producer (TR)

II. NWDAF (instance) lies in the source region: If the NWDAF instance in the source region requests data collection to a NF service producer in the target region to provide analytics information for the analytics consumer in the source region, then the NF service producer in the target region provides limited data to the NWDAF in the source region based on the inter region data collection restriction configured in the NF service producer (TR).

III. NWDAF instances lies in both source and target region: Always the target NWDAF instance acts as the Master NWDAF instance and performs the determination of level of analytics information that can be provided for an analytics consumer and level of data collection that need to be done from a NF service producer to serve an analytics consumer from the source region based on the inter region analytics and Data Collection restriction information available for target region towards the source region NFs. Always the NWDAF in the source region acts as the Secondary NWDAF and just act a proxy in forwarding the request/response between the source and target region and performs limited filtering/formatting of data based on source region Polies/Restrictions.

The analytics subscription, data collection and analytics request/response for the intra PLMN- inter region scenario can be similar to the inter PLMN roaming case with few differences as mentioned in this IDF.

The communication system 500 herein presented can be any of the 5G System or any next generation network system.

The first network entity 100 can e.g. be any of NF (Analytics Service Consumers and network service consumers) that exists in the 5G or next generation network system including AMF, SMF, NSSF, UPF, PCF, AF NRF, NEF, NWDAF, Intermediate NWDAF, OAM and so on.

The second network entity 100 can be any of NF (Analytics Service Producers and network service producers) that exists in the 5G or next generation network system including AMF, SMF, NSSF, UPF, PCF, AF NRF, NEF, NWDAF, Intermediate, OAM and so on.

In summary embodiments of the invention relates at least to the following aspects here now presented.

Inter PLMN and intra PLMN roaming scenario

1. There can be a dedicated NWDAF/NWDAF instances called Intermediate NWDAF (I- NWDAF) in every PLMN/region to handle network data analytics provision to different PLMNs/regions accordingly.

• Either a dedicated NWDAF (instance) or the proposed (l)NWDAF (instance) in serving PLMN, can handle analytics related requests from NWDAF service consumers residing in their PLMN for different target PLMN’s data analytics information.

• Further an (l)NWDAF in Home PLMN, can handle data analytics requests coming from different PLMN (source PLMN) towards the NF service producers residing in its PLMN (i.e. target/Home PLMN).

• There can be inter NWDAF communication between two NWDAF instances (NWDAF/(I)-NWDAF instances) residing either with in the same PLMN (over Nxnwdaf interface) or different PLMN (over Ninwdaf interface) to support Inter PLMN Data analytics provision in roaming cases or handover scenarios.

• NWDAF instances with in the same PLMN communicates with each other over the Nxnwdaf interface to consolidate the analytics information generated from the source PLMN and analytics information received from the target PLMN.

• Inter PLMN analytics subscription and data collection procedures can also involve the inter NWDAF communication between the source and target PLMN using Ninwdaf interface.

• The (l)NWDAF instances between two different PLMN or (ii) NWDAF service consumer from source PLMN and NWDAF instance in the target PLMN communicate with each other over the interface Ninwdaf to exchange data analytics related subscription and analytics info request/response message.

2. The roaming architecture for network data analytics provision can be based on any of the options mentioned in this document and especially it can be based on Type 1a/b/c or 3a/b/c and further the roaming analytics architecture is not limited to these embodiments.

3. The subscription correlation ID generated and used by the NWDAF/(I)NWDAF/NF service producer need to be a PLMN specific ID to avoid correlation duplication issues. i. Inter PLMN case: the NF service producer or the NWDAF can generate a PLMN specific subscription correlation ID using any PLMN specific code along with the communicating parts identities / the code for the inter PLMN subscription and a nonce ii. Intra PLMN case: the NF service producer or the NWDAF can generate a region specific subscription correlation ID using any region specific code along with the communicating parts identities / the code for the intra PLMN-inter region subscription and a nonce.

4. NWDAF/(I)NWDAF instance discovery

Inter PLMN case: the NWDAF/(I)NWDAF discovery in the inter PLMN roaming based analytics should consider the following information as the input parameters in addition to the existing information. a) The target PLMN ID and the source PLMN ID for the NWDAF/I-NWDAF selection accordingly. b) Inter-PLMN data analytics/subscription restriction information and/or c) Inter-PLMN NWDAF instance access restriction information

Intra PLMN-lnter region case: the NWDAF / (l)NWDAF selection/discovery in the inter region roaming based analytics should consider the following as the input parameters in addition to the existing information. a. The source PLMN ID, target TAI and target region ID for the NWDAF/I-NWDAF selection accordingly.

• The region ID can be a geographical zone identification information that contains the mapping of NWDAF network slice instance coverage information and the set of all Cell IDs or Base Station areas or any geographical partitioning information lying within the NWDAF network slice instance coverage. b. Inter-region geo political data sharing restrictions, c. Inter-region data analytics/subscription restriction information and/or d. Inter-region NWDAF instance access restriction information.

5. Analytics subscription, data collection and analytics information provision in roaming scenario.

The NWDAF/(I)NWDAF in the home network can take control over the data analytics information provided to the source NWDAF/(I)NWDAF service consumer by verifying the analytics subscription request/analytics information request/event exposure request containing the requested analytic ID(s)/ event ID(s) and the source PLMN information with the inter PLMN analytics restriction information, service agreement, analytics privacy of the target PLMN to determine the allowed analytics subscriptions/analytics ID(s)/event ID(s) that can be provided/exposed by the target PLMN to the source PLMN.

On a successful analytics subscription procedure/analytics information request validation process at the NWDAF/(I)NWDAF in the target network, it can send the allowed analytics IDs to the source NWDAF service consumer or source NWDAF/(I)NWDAF accordingly based on the inter PLMN analytics restrictions.

On a successful event Exposure subscription procedure, the NF service producer can provide the allowed event ID(s) to the NWDAF/(I)NWDAF residing in the target PLMN or NWDAF/(I)NWDAF residing in the source PLMN through the target PLMN (T- NWDAF/(I)NWDAF) based on the inter PLMN event exposure restrictions.

Factors related to intra PLMN-inter region case: or every inter region analytic subscription/data collection/analytics information request received from the NWDAF service consumer/NWDAF in the source region, the NWDAF/NF service producer in target region should verify the inter region analytic data provision restrictions, data privacy and inter region geopolitical data sharing and exposure restriction to determine the subscription, analytics information and data collection exposure information accordingly.

On a successful analytics subscription procedure/analytics information request validation process at the NWDAF/(I)NWDAF in the target region, it can send the allowed analytics IDs to the source NWDAF service consumer or source NWDAF/(I)NWDAF accordingly based on the intra PLMN - inter region analytics and geopolitical data sharing restrictions.

On a successful event exposure subscription procedure, the NF service producer can provide the allowed event ID(s) to the NWDAF/(I)NWDAF residing in the target region or NWDAF/(I)NWDAF residing in the source region through the target region (T- NWDAF/(I)NWDAF) based on the intra PLMN inter region event exposure restrictions.

Furthermore, any method according to embodiments of the invention may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program is included in a computer readable medium of a computer program product. The computer readable medium may comprise essentially any memory, such as a ROM (Read-Only Memory), a PROM (Programmable Read-Only Memory), an EPROM (Erasable PROM), a Flash memory, an EEPROM (Electrically Erasable PROM), or a hard disk drive.

Moreover, it is realized by the skilled person that embodiments of the first network entity 100 and the second network entity 300 comprises the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, MSDs, TCM encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

Especially, the processor(s) of the first network entity 100 and the second network entity 300 may comprise, e.g., one or more instances of a Central Processing Unit (CPU), a processing unit, a processing circuit, a processor, an Application Specific Integrated Circuit (ASIC), a microprocessor, or other processing logic that may interpret and execute instructions. The expression “processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

Finally, it should be understood that the invention is not limited to the embodiments described above, but also relates to and incorporates all embodiments within the scope of the appended independent claims.

Claims

1 . A first network entity (100) for a communication system (500), the first network entity (100) being located in a first domain and being configured to send a first message to a second network entity (300) located in a second domain, wherein the first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN, and wherein the first message indicates information about at least one of: a source PLMN ID, a target PLMN ID, a source region ID, and target region ID.

2. The first network entity (100) according to claim 1 , wherein at least one of the first network entity (100) and the second network entity (300) is a NWDAF or an intermediate NWDAF, wherein the intermediate NWDAF is configured to provide data network analytics for roaming scenarios in the communication system (500).

3. The first network entity (100) according to claim 2, configured to send a discovery request message to the second network entity (300) previous to sending the first message, wherein the discovery request message indicates at least one of the target PLMN ID, the source PLMN ID, the source region ID, and the target region ID; and receive a discovery response message from the second network entity (300), wherein the discovery request response message indicates the NWDAF or a NWDAF instance profile and its address.

4. The first network entity (100) according to any one of the preceding claims, wherein the first message is an analytics subscription request message indicating: a requested analytics set, a PLMN and region-specific notification target address, a PLMN and region specific notification correlation ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a requested analytics set, a PLMN specific notification target address, a PLMN specific notification correlation ID when the first domain is the first PLMN and the second domain is the second PLMN; and further configured to receive an analytics subscription response message from the second network entity (300), wherein the analytics subscription response message indicates: a PLMN and region-specific notification target address, a PLMN and region-specific subscription correlation ID, and an allowed analytics ID(s) when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a PLMN specific notification target address, a PLMN specific subscription correlation ID, and an allowed analytics ID(s) when the first domain is the first PLMN and the second domain is the second PLMN.

5. The first network entity (100) according to any one of the preceding claims, wherein the first message is a data collection request message indicating: a requested event ID(s); and further configured to receive a data collection response message from the second network entity (300), wherein the data collection response message indicates an allowed event ID(s) and an event report(s).

6. The first network entity (100) according to any one of the preceding claims, wherein the first message is a data analytics request message indicating: a requested analytics set, a analytic reporting information, a PLMN and region-specific notification target address, and a PLMN and region specific subscription correlation ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or an analytics ID(s), an analytic reporting information, a PLMN specific notification target address, and a PLMN specific subscription correlation ID when the first domain is the first PLMN and the second domain is the second PLMN; and further configured to receive a data analytics response message from the second network entity (300), wherein analytics response message indicates: a PLMN and region-specific notification target address, a PLMN and region-specific subscription correlation ID, an allowed analytics ID(s), an analytics information, and a validity period when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a PLMN specific notification correlation ID, a PLMN specific subscription correlation ID, an allowed analytics ID(s), an analytics information, and a validity period when the first domain is the first PLMN and the second domain is the second PLMN.

7. A second network entity (300) for a communication system (500), the second network entity (300) being located in a second domain and being configured to receive a first message from a first network entity (100) located in a first domain, wherein the first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN, and wherein the first message (510) indicates information about at least one of a source PLMN ID, a target PLMN ID, source region ID, and target region ID.

8. The second network entity (300) according to claim 7, wherein at least one of the first network entity (100) and the second network entity (300) is a NWDAF or an intermediate NWDAF, wherein the intermediate NWDAF is configured to provide data network analytics for roaming scenarios.

9. The second network entity (300) according to claim 8, configured to receive a discovery request message from the first network entity (100), wherein the discovery request message indicates at least one of the following: the target PLMN ID, the source PLMN ID, the source region ID, and the target region ID; and transmit a discovery response message to the first network entity (100), wherein the discovery request response message indicates the NWDAF or the NWDAF instance profile and its address.

10. The second network entity (300) according to claim 9, configured to transmit a discovery response message to the first network entity (100) upon verifying the source region ID and the target region ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or the target PLMN ID and the source PLMN ID when the first domain is the first PLMN and the second domain is the second PLMN.

11. The second network entity (300) according to any one of claims 7 to 10, wherein the first message is an analytics subscription request message indicating: a requested analytics set, a PLMN and region-specific notification target address, a PLMN and region specific notification correlation ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a requested analytics set, a PLMN specific notification target address, a PLMN specific notification correlation ID when the first domain is the first PLMN and the second domain is the second PLMN; and further configured to transmit an analytics subscription response message to the first network entity (300), wherein the analytics subscription response message indicates: a PLMN and region-specific notification target address, a PLMN and region-specific subscription correlation ID, and an allowed analytics ID(s) when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a PLMN specific notification target address, a PLMN specific subscription correlation ID, and an allowed analytics ID(s) when the first domain is the first PLMN and the second domain is the second PLMN.

12. The second network entity (300) according to any one of claims 7 to 11 , wherein the first message is a data collection request message indicating: a requested event ID(s); and further configured to transmit a data collection response message to the first network entity (300), wherein the data collection response message indicates an allowed event ID(s) and an event report(s).

13. The second network entity (300) according to any one of claims 7 to 12, wherein the first message is a data analytics request message indicating: a requested analytics set, a analytic reporting information, a PLMN and region-specific notification target address, and a PLMN and region specific subscription correlation ID when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or an analytics ID(s), an analytic reporting information, a PLMN specific notification target address, and a PLMN specific subscription correlation ID when the first domain is the first PLMN and the second domain is the second PLMN; and further configured to transmit a data analytics response message to the first network entity (100), wherein analytics response message indicates: a PLMN and region-specific notification target address, a PLMN and region-specific subscription correlation ID, an allowed analytics ID(s), an analytics information, and a validity period when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, or a PLMN specific notification correlation ID, a PLMN specific subscription correlation ID, an allowed analytics ID(s), an analytics information, and a validity period when the first domain is the first PLMN and the second domain is the second PLMN.

14. The second network entity (300) according to any one of claims 11 to 13, when the first domain is the first region in the PLMN and the second domain is the second region in the PLMN, is further configured to transmit the data collection response message, or the data analytics response message to the first network entity (100) upon verifying at least one of the source region ID, a PLMN and region-specific subscription correlation ID, an inter-Region geo-political data sharing restrictions, and an inter-region data analytics and/or exposure restriction information.

15. The second network entity (300) according to claim 14, configured to transmit the analytics subscription response message to the first network entity (100) upon further verifying inter-region data analytics restriction information.

16. The second network entity (300) according to any one of claims 11 to 15, when the first domain is a first PLMN and the second domain is a second PLMN, is further configured to transmit the data collection response message or the data analytics response message to the first network entity (100) upon verifying at least one of a PLMN specific subscription correlation ID, the source PLMN ID and corresponding inter-PLMN data analytics and/or exposure restriction information.

17. The second network entity (300) according to claim 16, configured to transmit the analytics subscription response message to the first network entity (100) upon further verifying a inter PLMN data analytics restriction information.

18. A device comprising: a processor, and a memory coupled to the processor and having processor-executable instructions stored thereon, which when executed by the processor, cause the processor to perform the method of claim 16 or 17.

19. A method for a first network entity, the first network entity being located in a first domain, the method comprising: sending a first message to a second network entity located in a second domain, wherein the first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN, and wherein the first message indicates information about at least one of: a source PLMN ID, a target PLMN ID, a source region ID, and target region ID.

20. A method for a second network entity, the second network entity being located in a second domain, the method comprising receiving a first message from a first network entity located in a first domain, wherein the first domain is a first region in a PLMN and the second domain is a second region in the PLMN or wherein the first domain is a first PLMN and the second domain is a second PLMN, and wherein the first message indicates information about at least one of a source PLMN ID, a target PLMN ID, source region ID, and target region ID.

21. A computer readable medium comprising program code or instructions for performing a method according to claim 19 or 20.