WO2024083357A1

WO2024083357A1 - Techniques for provisioning of localized service information for network selection

Info

Publication number: WO2024083357A1
Application number: PCT/EP2023/060101
Authority: WO
Inventors: Genadi Velev; Dimitrios Karampatsis; Roozbeh Atarius
Original assignee: Lenovo (Singapore) Pte. Ltd.
Priority date: 2023-03-17
Filing date: 2023-04-19
Publication date: 2024-04-25

Abstract

An apparatus comprising a first network function is provided. The apparatus further comprises a processor and a memory coupled to the processor, the memory comprising instructions executable by the processor to cause the first network function of the apparatus to receive, from a second network function, a request to process network selection data, the network selection data identifying one or more networks offering access to a localized service, the request comprising an identifier for associating the localized service with the network selection data, to, in response to receiving the request, determine a third network function to store the network selection data, and, to enable the third network function to store the network selection data. The first network function is a Unified Data Management (UDM) network function. The second network function is a Network Exposure Function (NEF). The third network function is selected from a group of network functions comprising the UDM network function, a Unified Data Repository (UDR) network function and a Steering of Roaming Application Function (SOR-AF). Further, a corresponding UE and an apparatus comprising a SOR-AF are provided.

Description

TECHNIQUES FOR PROVISIONING OF LOCALIZED SERVICE INFORMATION FOR NETWORK SELECTION

TECHNICAL FIELD

The present disclosure generally relates to provisioning of localized service information for network selection in a mobile telecommunications network. More particularly, embodiments relate to provisioning localized service information for network selection via a Unified Data Management (UDM) network function or via a module in a management plane of the mobile telecommunications network. Embodiments additionally relate to an enhanced Steering of Roaming (SOR) procedure.

BACKGROUND

With the advance of 5th generation (5G) services (5GS) and networks, it may be possible to deploy local 5G networks at various venues which offer one or more localized services, in addition to connectivity to non-localized service providers as well as services to public network operators. A localized service is provided at a specific/limited area and/or can be bound in time. The localized service can be realized via applications (e.g., live or on-demand audio/video stream, electronic game, IP multimedia subsystem (IMS), etc), or via connectivity (e.g., user equipment (UE) to UE, UE to Data Network, etc.).

A localized service provider (LSP) is an application provider or network operator who makes their services localized. The localized services are offered to the end user via a hosting network. A hosting network can be a stand-alone non-public network (SNPN) or a Public Network Integrated Non-Public Network (PNI-NPN).

If an Application Function (AF) in a domain of the LSP wants to provide a list of preferred network identifiers to the 5G network to be configured in a UE for use of a localized service (e.g., the UE is subscribed to use the localized service), it is not clear how the 5G network handles and stores this external list of preferred network identifiers.

SUMMARY

In order to overcome the above deficiency an apparatus comprising a first network function is provided. The apparatus comprises a processor and a memory coupled to the processor. The memory comprises instructions executable by the processor to cause the first network function of the apparatus to receive, from a second network function, a request to process network selection data, the network selection data identifying one or more networks offering access to a localized service, wherein the request comprises an identifier for associating the localized service with the network selection data, to, in response to receiving the request, determine a third network function to store the network selection data, and to enable the third network function to store the network selection data.

To enable the third network function to store the network selection data, the instructions may be further executable by the processor to cause the first network function of the apparatus to generate a response message comprising a target identifier associated with the third network function, and to transmit the response message to the second network function, the response message indicating to the third network function to store the network selection data.

To generate the response message, the instructions may be further executable by the processor to cause the first network function of the apparatus to map the identifier to an internal service identifier, the internal service identifier identifying the localized service, to associate the internal service identifier with the network selection data, and to include the internal service identifier in the response message.

To transmit the response message, the instructions may be further executable by the processor to cause the first network function of the apparatus to transmit the target identifier identifying the third network function being different from the first network function to cause the second network function to provide the third network function with the network selection data and with the internal service identifier and to enable the third network function to store the network selection data and the internal service identifier.

The instructions may be further executable by the processor to cause the first network function of the apparatus to determine, based on the internal service identifier, a UE to be updated, to transmit a request for SOR data to the third network function, to receive a container comprising the SOR data from the third network function in response to the request for SOR data, and to transmit the container comprising the SOR data to an access and mobility management function (AMF) for forwarding to the UE.

The instructions may be further executable by the processor to cause the first network function of the apparatus to determine one or more user equipments (UEs) subscribed to the localized service identified by the internal service identifier, and to set, in a user context associated with each of the one or more UEs, a flag indicating the respective UE to be updated with SOR data.

The request to process network selection data may comprise the network selection data, wherein the third network function may be the first network function, and wherein the instructions are further executable by the processor to cause the first network function of the apparatus to store the network selection data and the internal service identifier in the memory, wherein to transmit the response message comprising the target identifier identifying the first network function as the third network function causes the second network function to acknowledge success, to an application function, of storage of the network selection data.

The request to process network selection data may further comprise an identifier indicating a data type, the data type being one of a localized service data type, a network selection data type and a data type specific for data identifying one or more networks offering access to a localized service, wherein the third network function is the first network function, and wherein the instructions are further executable by the processor to cause the first network function of the apparatus to send a request for the network selection data to the second network function, to receive, in response to the request, the network selection data from the second network function, and to store the network selection data and the internal service identifier in a storage, wherein sending the response message comprising the target identifier identifying the first network function as the third network function causes the second network function to acknowledge success, to an application function, of storage of the network selection data.

The instructions may be further executable by the processor to cause the first network function of the apparatus to determine, based on the internal service identifier, a UE to be updated, to generate SOR data based on the network selection data, and to transmit a container comprising the SOR data to an access and mobility management function (AMF) for forwarding the container to the UE.

The request to process network selection data may comprise the network selection data, and wherein, to enable the third network function to store the network selection data, the instructions are further executable by the processor to cause the first network function of the apparatus to map the identifier a service identifier, the service identifier identifying the localized service, to associate the service identifier with the network selection data, to generate, based on the third network function being different from the first network function, a message comprising the network selection data and the service identifier, to transmit the message comprising the network selection data and the service identifier to the third network function to initiate a storage process of the network selection data and the service identifier associated with the network selection data by the third network function, and to store, if the third network function is the first network function, the network selection data and the service identifier in a storage of the mobile telecommunications network apparatus.

The first network function may be a UDM network function. The second network function may be a Network Exposure Function (NEF). The third network function may be selected from a group of network functions comprising the UDM network function, a Unified Data Repository (UDR) network function and a Steering of Roaming Application Function (SOR-AF).

The network selection data may comprise a list of the one or more networks offering access to the localized service, each entry of the list comprising a network identifier and validity information, and wherein the validity information is at least one of time validity information indicating at least one time period when access to the network identified by the network identifier is allowed and location validity information indicating at least one geographic area where the network identifier can be used to access the network for the localized service.

A UE comprising a processor and a memory coupled to the processor is provided. The memory comprising instructions executable by the processor to cause the UE to perform a SOR method in a mobile telecommunications network, wherein the SOR method comprises sending, to an access and mobility management function (AMF) a capability support indication message comprising an indication that the UE supports a capability of processing SOR data for a localized service, wherein the SOR method further comprises receiving, from the AMF, a SOR data message comprising SOR data for a localized service, the SOR data for the localized service comprising a network identifier and validity information, the network identifier identifying a network offering access to the localized service, and the validity information indicating at least one restriction for accessing the network, and wherein the UE is configured to perform, upon activation of the localized service in the UE, a network selection using the SOR data for the localized service.

The SOR data message may further comprise a service identifier associated with the SOR data for the localized service. The capability support indication message sent to the AMF may be one of a registration message requesting registration of the UE in the mobile telecommunications network and an acknowledgment message sent in response to the SOR data message.

The SOR method may further comprise storing the SOR data for the localized service in a non-volatile memory of the UE, wherein the network selection is performed during a power on cycle of the UE by using the stored SOR data.

The at least one restriction may comprise at least one of a time period when access to the network identified by the network identifier is allowed and a geographic area where the network identifier can be used to access the network.

An apparatus comprising a SOR application function is provided. The apparatus comprises a processor and a memory coupled to the processor, the memory comprising instructions executable by the processor to cause the SOR application function of the apparatus to receive, from a module in a management plane of the mobile telecommunications network, a request to configure the SOR application function, the request comprising network selection data identifying one or more networks offering access to a localized service and a service identifier associated with the network selection data, the service identifier identifying the localized service, to, in response to receiving the request, store the network selection data and the service identifier in the storage, to discover a UDM network function serving the localized service identified by the service identifier, and to inform the discovered UDM network function that the network selection data associated with the service identifier has been received.

The instructions executable by the processor may further cause the SOR application function of the apparatus to receive, from the UDM network function, a request to provide SOR data, the request to provide SOR data comprising the service identifier, to, in response to receiving the request to provide SOR data, generate the SOR data based on the network selection data associated with the service identifier, and to transmit a container comprising the SOR data to the UDM network function.

The instructions executable by the processor may further cause the SOR application function of the apparatus to determine to update a UE with SOR data, to generate the SOR data based on the network selection data, and to transmit a request to the UDM network function comprising an identifier identifying the UE and a container comprising the SOR data, wherein the request causes the UDM network function to update the UE with the SOR data. BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments and aspects of the present disclosure will be described in the following description together with the accompanying drawings, wherein

Figure 1 is a diagram showing a system for a hosting network deployment in accordance with one or more aspects of the present disclosure;

Figure 2 is a diagram showing a SOR-AF reference model in accordance with one or more aspects of the present disclosure;

Figure 3 is a diagram showing the Secured Packet Application Function (SP-AF) reference model in accordance with one or more aspects of the present disclosure;

Figure 4 is a diagram showing an architecture for exchange of network selection data and Steering of Roaming SNPN selection information with validity information in accordance with one or more aspects of the present disclosure;

Figure 5 shows a method of provisioning of the network selection data within a telecommunications network in accordance with one or more aspects of the present disclosure;

Figure 6a shows a method of initiating a storage process to cause a third network function to store network selection data in accordance with one or more aspects of the present disclosure;

Figure 6b shows a method of initiating a storage process to cause a third network function to store network selection data in accordance with one or more aspects of the present disclosure;

Figure 6c shows a method of initiating a storage process to cause a third network function to store network selection data in accordance with one or more aspects of the present disclosure;

Figures 7a, 7b, and 7c show flow diagrams of a procedure for provisioning of network selection data to a telecommunications network in accordance with one or more aspects of the present disclosure;

Figures 8a, 8b, 8c and 8d show flow diagrams of a procedure for provisioning of network selection data to a UDM in accordance with one or more aspects of the present disclosure;

Figures 9a and 9b show a method for providing network selection data to a mobile telecommunications network according to embodiments; Figure 10 shows a flow diagram of a procedure for provisioning of network selection data to a telecommunications network in accordance with one or more aspects of the present disclosure;

Figure 11 shows a method for a SOR procedure in accordance with one or more aspects of the present disclosure;

Figure 12 shows a flow diagram of a procedure for provisioning of SOR data in accordance with one or more aspects of the present disclosure;

Figure 13 shows a mobile telecommunications network apparatus in accordance with one or more aspects of the present disclosure; and

Figure 14 shows a UE in accordance with one or more aspects of the present disclosure.

DETAILED DESCRIPTION

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings in which like reference numerals refer to like elements unless specified otherwise.

A 5G network as a hosting network offering access to localized services can be either a Public Land Mobile Network (PLMN) or a Non-Public Network (NPN).

To enable a PNI-NPN or SNPN to provide access to localized services, the PNI-NPN or SNPN operator configures the network with information enabling the UEs to access the localized services using the PNI-NPN or SNPN according to any validity of the localized services. This information is determined in agreement with a LSP. The information may comprise one or more of (a) identification of each localized service (e.g., to be used in User equipment Route Selection Policy (URSP) rules), (b) validity restrictions for each localized service (e.g., the validity of time and/or location), (c) service parameters for each localized service (e.g., Dara Network Name (DNN), Single Network Slice Selection Assistance Information (S-NSSAI) and/or Quality of Service (QoS) requirements), and (d) service authorization methods (e.g., Network Slice- Specific Authentication and Authorization (NSSAA) and/or Secondary authentication/authorization during Protocol Data Unit (PDU) Session establishment). Turning to Figure 1 , Figure 1 shows a system 100 for hosting network 120 deployment. Specifically, Figure 1 is a diagram showing a system for a hosting network deployment in accordance with one or more aspects of the present disclosure. Figure 1 shows an architecture scenario for connectivity between a hosting network 120, a home network 130, and an LSP 140. The home network 130 can be either a Home PLMN (HPLMN), subscribed SNPN or a Credential Holder (CH) domain. The LSP 140 can exchange service configuration/provisioning information with the home network 130 over interface 195 and with the Operations, Administration and Management (OAM) module 150 of the Hosting network 120 over interface 165. The interfaces 165 and 195 may be a provisioning interface (PV-IF). The OAM module 150 exchanges information with the 5G Core (5GC) 160 network of the hosting network over communications link 145. The LSP 140 may also communicate directly with the 5GC 160 over a communications link 175 provided by a NEF, such as an N33 interface. The home network 130 communicates with the 5GC 160 over Ro-interface (Ro-IF) link 185. Finally, a LIE 110 having installed an application 115 may communicate with the 5GC 160 over a communications link 155.

The hosting network 185 may offer non-local services and localized services to the UE 1 10. Non-localized services may be directed towards one or more public networks (e.g., the home network 130) or Internet access services. There may be service level agreements between the hosting network 120 and the home network 130 that may offer one or more of (a) a default Internet Protocol (IP) access using Local Break Out (LBO), and (b) home-routed services to the home network 130 (e.g., for IMS applications).

Localized services may be services which are enriched compared to services offered via an Internet connection. The end users need information/incentive/instruction to seek access to the localized services in a convenient way. In the example of Figure 1 a localized service is used by the application 115 installed on the UE 110. The application 115 can exchange application level data with the Local Service running in a domain of the LSP 140.

The LSP domain can be deployed either within the hosting network 120 or at a 3^rd party localized service provider outside the hosting network 120. In case of a 3^rd party localized service provider, the LSP 140 may be operated by an entity/company different from the hosting network 120 or the home network 130. The 3^rd party LSP may offer services to the hosting network 120 and/or the home network 130 (e.g., based on different time or location conditions).

To control the UE 110 to perform network selection of PNI-NPN or SNPN offering access to localized services, the UE 110 should be configured with a list of PLMNs (in case the hosting network 120 is deployed as PNI-NPN) or a list of SNPN (in case the hosting network 120 is deployed as SNPN). Such configuration can be pre-provisioned to the UE 110. For example, configuration data may be stored in the UE’s 110 USIM module or in a secure non-volatile memory where the subscriber credentials and other lists for PLMN/SNPN network selection are stored.

To enable the UE 110 to select a PLMN/SNPN which offers localized services, each entry of the list of PLMNs/SNPNs is associated with validity information. The validity information may comprise at least one of (a) time validity information (e.g., time periods (defined by start and end times) when access to the PLMN/SNPN is allowed), and (b) location validity information. The location validity information may comprise geolocation information and/or tracking area information of serving networks, i.e. lists of Tracking Area Codes (TACs) per PLMN Identifier (ID) or per PLMN ID and Network Identifier (NID).

The location validity information may be used to aid the UE 110 where to search for the SNPNs in the CH controlled prioritized list of SNPNs and Group IDs for Network selection (GINs) and is not used for any area restriction enforcement.

The CH is an entity (e.g., subscribed SNPN or Home PLMN (HPLMN)) where the UE’s 1 10 credentials are stored on the network side. The CH performs the primary authentication and authorization when the UE 110 accesses any SNPN different or separate from the CH (e.g., subscribed SNPN or HPLMN).

A UE 110, which is capable and allowed to access and use an SNPN, may be called SNPN-enabled UE. The SNPN-enabled UE which is also subscribed to use localized services may be configured with the following information in order to select the preferred SNPN offering access to the localized service:

If the UE supports access to an SNPN using credentials from a CH, the information may include a User controlled prioritized list of preferred SNPNs. The information may further include a CH controlled prioritized list of preferred SNPNs. Each entry of the CH controlled prioritized list of preferred SNPN may include an SNPN identifier and, optionally, validity information if the UE supports access to an SNPN providing access for Localized Services. The information may also include a CH controlled prioritized list of GINs. Each entry of the CH controlled prioritized list of GINs may include a GIN and, optionally, validity information if the UE supports access to an SNPN providing access for Localized Services.

There is also a mechanism to provision the UE 110 on demand with a list of preferred PLMNs/SNPN for network selection. This mechanism is the SOR procedure which is available in 5GS. The SOR procedure was developed to provide a standardized mechanism to steer the UE to preferred PLMN/SNPN when the UE is trying to register with the visited PLMN (VPLMN) and/or the SNPN. Specifically, the HPLMN requests the UE 110, that is in an automatic mode, to find and register on a different VPLMN/SNPN from the one it is currently using or trying to register on, provided another VPLMN/SNPN is available that is not in a Forbidden List.

For an SNPN-enabled UE with SNPN subscription, the CH controlled prioritized lists of preferred SNPNs and GINs may be updated by the CH using the SOR procedure as defined in Annex C of 3GPP TS 23.122, V17.8.0, 2022-09, “Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode”.

The control plane SOR procedure, once configured, can be utilized during the UE’s 1 10 initial registration on the VPLMN (or serving SNPN) or after its registration.

Referring now additionally to Figure 2, Figure is a diagram showing a SOR-AF reference model in accordance with one or more aspects of the present disclosure. Figure 2 shows a SOR-AF reference model 200 that supports a network function (NF) consumer 210 (e.g., a UDM) requesting SOR information from a SOR-AF 220 by using an Nsoraf service based interface 230. In one example, the SOR-AF can be deployed in the network operator domain, i.e. in the trusted network domain where also the UDM is located.

The SOR information sent from the UDM or SOR-AF 220 to the UE (such as the UE 1 10 of Figure 1 ) may have the final consumer destination to be the USIM in the UE. In such case, the UE parameters need to be protected in a secure packet. The secure packet may be created by the Secured Packet Application Function (SP-AF) 330 as shown in Figure 3. Specifically, Figure 3 is a diagram showing the Secured Packet Application Function (SP-AF) reference model 300 in accordance with one or more aspects of the present disclosure. The SP-AF 330 may use keys for over-the-air (OTA) provisioning. The UDM 320 or the SOR-AF 310 (that may correspond to the SOR-AF 220 of Figure 2) provides the SOR information to the SP-AF 330 by using an Nspaf service based interface 340.

Considering the aspects described with regard to Figures 1 , 2 and 3, if an AF (e.g., in the LSP domain) outside the hosting network 120 wants to provide the 5GC 160 with a list of preferred network identifiers (e.g., PLMNs/SNPNs/GINs, considered as SOR- related external information) to be configured in the UE 110 for use of a localized service (e.g., UE 110 subscribed to use the localized service), it is not clear how the 5GC 160 handles and stores such SOR-related external information. The SOR-related external information may be processed for a UE 1 10 into SOR-related internal information. The SOR-related internal information is then sent from the UDM within the 5GC 160 to the UE 110. However, how does the UDM in the 5GC 160 determine that an update to a specific UE 110 is needed and where to take the latest SOR-related internal information from?

To discuss the shortcomings of the techniques discussed so far with regard to Figures 1 , 2, and 3 and considering, in addition to the 3GPP Technology Specifications (TS) mentioned above, 3GPP TS 22.261 , V18.4.0, 2022-09, “Service requirements for the 5G system” and 3GPP TS 23.502, v17.2.0, 2022-09, “Procedures for the 5G System”, the AF can provide the SOR-related external information to the UDM and the UDM creates and sends this SOR information to the UE such as UE 110. However, how can the SOR-AF use the SOR-related external information (since there are network operators which rely on the SOR-AF to create the SOR container to the UE)?

3GPP TS 23.122. provides for a network selection procedure. The steering of a UE (such as UE 110) to particular networks, especially in roaming situations, is supported by this network selection procedure. In particular the automatic network selection uses an “Operator controlled PLMN selector with Access Technology” list (aka list of preferred PLMN/access technology combinations) which can be stored in the USIM profile and/or in the ME (mobile equipment).

The TS 23.122 specifies in annex C how the HPLMN may update the UE configuration by executing the SOR procedure. For instance, the UDM in the HPLMN determines whether to perform the SOR procedure based on internal configuration in the UDM. The UDM may trigger the SOR-AF to generate the SOR information to be sent to the UE. The SOR information has the same format as the “Operator controlled PLMN selector with Access Technology” list described above.

Accordingly, the AF can provide the SOR-related external information to the UDM and the UDM creates and sends this SOR information to the UE. However, how can the SOR-AF use the SOR-related external information (since there are network operators which rely on the SOR-AF to create the SOR container to the UE)?

Embodiments provide for solutions to this problem. The solution includes several variants how the external Network Selection Information for Localized Service (NSI- LS, also referred to as network selection data herein) is transmitted from the AF/LSP to the 5GC and stored as SOR-related internal information in the 5GC. Figure 4 is a diagram showing an architecture 400 for exchange of network selection data and Steering of Roaming SNPN selection information with validity information in accordance with one or more aspects of the present disclosure. The architecture 400 comprises a mobile telecommunications network 410, which may be an example of a 5GC. For example, the telecommunications network 410 may correspond to the 5GC 160 of Figure 1 . The interface 435 may be an N33 interface and may correspond to communications link 175 of Figure 1 , the LSP 430 that is outside the 5GC 410 may correspond to the LSP 140 of Figure 1 , the UE 420 may correspond to UE 110 of Figure 1 , and communications link 425 (link 425 may be used for Control Plane (CP) SOR signaling) may correspond to the communications link 155 of Figure 1 . While it is referred to an LSP 430, reference numeral 430 may also refer to an AF within the LSP domain. Accordingly, the terms LSP 430, AF 430, LSP/AF 430, and AF/LSP 430 will be used interchangeably throughout this specification.

The architecture 400 further comprises a UDR 470 network function, a UDM 460, a SOR-AF 450 and a NEF 440 that communicate over bus interface 445 with each other. Additionally, the 5GC 410 may comprise an Access and mobility Management Function (AMF) 428 that communicates with the UDM 460 over path 465 and with UE 420 over link 425.

The LSP 430 may implement an AF running within a domain of the LSP 430 that may provision external parameters to the 5GC 410. In other words, the LSP takes the AF role and uses the exposure capability provided by the PNI-NPN or SNPN.

The external parameters may comprise network selection information for localized service (NSI-LS) which are sent to the NEF 440. The NSI-LS may also be referred to herein as network selection data. The NSI-LS may include a list of preferred SNPN/GINs that identify networks which offer access to the localized service, wherein each entry of SNPN/GIN may be associated with validity information. The LSP thus uses the N33 interface 435 for provisioning of the NSI-LS information from the LSP 435 to the 5GC 410.

The 5GC 410 uses the provisioned external NSI-LS information to determine UE- specific SOR-related internal information and provides the SOR-related internal information to the UE 420, for example, using the control plane (CP) SOR procedure. Such SOR-related internal information is referred to herein as Steering of Roaming SNPN selection information with validity information (SOR SNPN-SI-VI). The SOR SNPN-SI-VI may also be referred to as SOR data herein. The SOR SNPN-SI-VI is carried via a signaling path 465 between UDM 460 and AMF 428.

The SOR SNPN-SI-VI may comprise at least one of: a) CH controlled prioritized list of preferred SNPNs, each entry of the list including:

• an SNPN identifier; and

• optionally, validity information, if the UE supports access to an SNPN providing access for Localized Services; and b) CH controlled prioritized list of GINs, each entry of the list including:

• a GIN; and

• optionally, validity information, if the UE supports access to an SNPN providing access for Localized Services

The validity information may comprise at least one of:

• Time validity information, i.e., time periods (e.g., defined by start and end times or defined by a duration) when access to the SNPN is allowed; and

• Location validity information.

The Location validity information may comprise at least one of:

• Geolocation information, and

• Tracking Area information of serving networks, i.e. lists of TACs per PLMN ID or per PLMN ID and NID.

Figure 4 shows the architecture of the network functions and interfaces applicable for embodiments. The AF (e.g., part of the domain of the LSP 430) provisions the 5GC 410 (e.g., via NEF 440) with the NSI-LS information. The details how the external NSI- LS is transmitted to the NEF 440 and stored in the 5GC is described in detail below. The UDM 460 may determine the SOR SNPN-SI-VI information, for example, the SOR- related internal either by itself or the UDM 460 may retrieve the SOR SNPN-SI-VI information from the SOR-AF 450 or UDR. The UDM 460 may create or retrieve the SOR SNPN-SI-VI information on per UE basis. Then the UDM 460 transmits the SOR SNPN-SI-VI transparently via the AMF 428 to the UE 420 using the SOR procedure.

The bus interface 445 in Figure 4 between the NEF 440, UDR 470, UDM 460 and SOR-AF 450 is intended to show that the signaling exchange between those Network Functions (NFs) can be flexible, i.e. each of these NFs can send/receive information from any other these NFs. For example, the NEF 440 can send a request to the UDM 460 to process (or authorize) the request for external NSI-LS provisioning from the AF/LSP 430, but then the NEF 440 can send the external NSI-LS to be stored in any of the UDR 470, UDM 460 or SOR-AF 450 as described below Embodiments provide for the following advantages:

• NEF enhancements: The NEF 440 receives a request (e.g., from an AF within a domain of the LSP 430) for provisioning of network selection information for localized service (NSI-LS), i.e. the request may include an indication that the information is NSI- SL information (e.g., information used to configure the UE with network selection parameters e.g. using the SOR procedure). The NSI-LS can be sent either (a) using UE-specific parameters procedure or (b) using service-specific parameters procedure. At least one of the following further impacts to NEF 440 may be introduced: a) Sending a request for service authorization to the UDM 460 by including a service identification (e.g., external or internal Group/AF/Service ID) and service data type and receiving a reply including an indication of a target network function (NF) to which the received NSI-LS is sent. The service data type may identify that the service specific parameters include data which is used for SOR for UEs using the service; or b) The NEF 440 determines which is the target NF to send the received NSI-LS based on the service data type. For example, based on the service data type being NSI-LS and/or based on local configuration (e.g., from the OAM system), the NEF 440 decides that the service specific information should be provisioned to a SOR-AF 450 or the UDR 470. In one example, if the UDM 460 is configured to use the SOR-AF 450 for the SOR procedure, then the NEF 440 is configured to send the NSI-LS data to the SOR-AF 450. In another example, if the UDM 460 is configured to use the UDR 470 for the SOR procedure, then the NEF 440 is configured to send the NSI-LS data to the UDR 470.

• UDM enhancements: The UDM 460 determines, for example, based on at least one of the network selection information for localized service data type and based on local configuration, a target network function (NF) where the network selection information for localized service should be stored. At least one of the following further impacts to UDM 460 may be introduced: a. The UDM 460 determines which UEs needs to be updated with the SOR-SNPN- SI-VI information, for example, the UDM 460 uses the Group/AF/Service ID (received from the AF 430 via NEF 440 and identifying the localized service) and the UDM 460 identifies which Ues is subscribed for this localized service (e.g., by using the UE subscription data including Group ID or Service ID subscription or the UDM 460 requests the UDR 470 to provide the UE’s service subscription data). The Ues which are subscribed with the localized service (e.g., identified by the Group/AF/Service ID) are the Ues that should be updated; b. The UDM 460 stores a flag in the each corresponding UE context that SOR update to the UE 420 is needed, and after successful update of the UE, the UDM 460 deletes the flag; c. If the UDM 460 creates the SOR data to be sent in an SOR container by itself, the UDM 460 indicates to the NEF 440 to acknowledge the successful handling in the 5GC 410 to the AF 430; d. If the UDM 460 uses the SOR-AF 450 to create the SOR container comprising the SOR data, then

■ the UDM 460 indicates to the NEF 440 to store the data in the SOR-AF 450 or in the UDR 470;

■ the UDM 460 uses the Group/AF/Service ID when requesting the SOR-AF 450 to create the SOR container for the UE 420.

• UE enhancements: The UE 420 indicates support of the SOR data type SNPN- SI-VI (i.e. CH controlled prioritized lists of preferred SNPNs/GINs, wherein each entry may be associated with validity information being time and/or location validity) in one of the following ways: a. The UE 420 includes the capability to support SOR SNPN-SI-VI in the 5GMM capability sent to the AMF 428 in the Registration Request message; or b. The UE 420 includes the capability to support SOR SNPN-SI-VI in the acknowledgement message sent to the UDM 460 as response to the SOR request. Considering Figure 5 in addition to Figure 4, the Figure 5 shows a method 500 of provisioning of the network selection data within a telecommunications network in accordance with one or more aspects of the present disclosure. Specifically, Figure 5 shows a method 500 of provisioning of the NSI-LS within a telecommunications network such as 5GC 410. Method 500 of Figure 5 may be performed by a first network function of telecommunications network 410, such as a 5GC. Specifically, a mobile telecommunications network apparatus of the telecommunications network 410 may comprise a first network function, a processor and a memory. The memory is coupled to the processor and comprises instructions executable by the one or more processors. The one or more processors are configured to execute the instructions to cause the first network function of the apparatus to perform the method 500. In an embodiment, the first network function may be the UDM 460. In embodiments, the mobile telecommunications network apparatus of the telecommunications network 410 may comprise one or more processors configured to execute computer-executable instructions for implementing the first network function, wherein the computerexecutable instructions cause the one or more processors to perform the method 500. The mobile telecommunications network apparatus of the telecommunications network 410 may be the apparatus 1300 described with regard to Figure 13.

At step 510, the first network function receives from a second network function a request to process network selection data. In some examples, the network selection data is provided or is to be provided by the second network function. The network selection data may be the NSI-LS information introduced with regard to Figure 4. The second network function is different from the first network function. According to an embodiment, the second network function may be the NEF 440 of Figure 4. A mobile telecommunications network apparatus of the telecommunications network 410 may comprise one or more processors configured to execute computer-executable instructions for implementing the second network function. The mobile telecommunications network apparatus comprising one or more processors configured to execute computer-executable instructions for implementing the second network function may be the same mobile telecommunications network apparatus comprising one or more processors configured to execute computer-executable instructions for implementing the first network function or may be a different mobile telecommunications network apparatus.

When the first network function receives a request to process network selection data provided by the second network function, the request received at step 510 may comprise the network selection data. In some embodiments, the request received at step 510 may also comprise an identifier indicating a data type, wherein the data type is one of a localized service data type, a network selection data type and a data type specific for data identifying one or more networks offering access to a localized service. When the first network function receives a request to process network selection data to be provided by the second network function, the request received at step 510 may not comprise the network selection data. When the request received at step 510 does not comprise the network selection data, the request received at step 510 comprises the identifier indicating a data type, the data type being one of a localized service data type, a network selection data type and a data type specific for data identifying one or more networks offering access to a localized service.

The network selection data may identify one or more networks offering access to a localized service. According to an embodiment, the network selection data may comprise a list of the one or more networks offering access to the localized service. In this embodiment, each entry of the list comprises a network identifier and validity information. The validity information is at least one of time validity information indicating at least one time period when access to the network identified by the network identifier is allowed and location validity information indicating at least one geographic area where the network identifier can be used to access the network for the localized service.

Accordingly, as indicated above with regard to the NSI-LS, the network selection data may comprise a list of preferred SNPN/GINs that identify networks which offer access to the localized service, wherein each entry of SNPN/GIN may be associated with validity information.

The validity information in the list of one or more networks may thus comprise at least one of:

• Time validity information, i.e., one or more time periods (e.g., each time period being defined by start and end times or defined by a duration) when access to the SNPN in the corresponding entry is allowed; and

• Location validity information indicating at least one geographic area where the network identifier can be used to access the network for the localized service.

The Location validity information may comprise at least one of:

• Geolocation information, and

In any case, the request received at step 510 comprises an identifier for associating the received network selection data with the localized service or vice versa. Hence, the identifier allows the first network function to associate the localized service with the network selection data. In some embodiments, the request received at step 510 may comprise a single identifier allowing the first network function to associate the network selection data with the localized service. In other embodiments, the network selection data received with the request at step 510 may identify one or more networks offering access to a plurality of localized services. In those embodiments, the request received at step 510 may include a plurality of identifiers allowing the first network function to associate the plurality of localized services with the network selection data. The identifier allowing the first network function to associate the localized service with the network selection data may be an identifier provided by a LSP outside the communications network to the second network functions. Further details will be discussed below with regard to Figures 7a, 7b, 7c, 8a, 8b, 8c and 8d.

In response to receiving the request at step 510, the first network function determines a third network function to store the network selection data. In embodiments, the third network function is determined based on a configuration accessible to the first network function. The third network function may be selected from a group of network functions comprising the UDM network function 460, the UDR network function 470 and the SOR-AF 450. A mobile telecommunications network apparatus of the telecommunications network 410 may comprise one or more processors configured to execute computer-executable instructions for implementing the third network function. The mobile telecommunications network apparatus comprising one or more processors configured to execute computer-executable instructions for implementing the third network function may be the same mobile telecommunications network apparatus comprising one or more processors configured to execute computerexecutable instructions for implementing the first network function. For embodiments where the third network function is selected from a group of network functions comprising the UDR 470 and the SOR-AF 450, the mobile telecommunications network apparatus comprising one or more processors configured to execute computer-executable instructions for implementing the third network function may be different from the mobile telecommunications network apparatus comprising one or more processors configured to execute computer-executable instructions for implementing the first network function.

The configuration accessible to the first network function may, for instance, indicate which target network function to select as a target network function based on one or more of the identifier allowing the first network function to associate the localized service with the network selection data, the network selection data itself, and the identifier indicating the data type received with the request at step 510. Alternatively, the request received at step 510 may include an indication of the third network function. When the request received at step 510 includes an indication of the third network function, the first network function may determine the indicated network function as the third network function.

At step 530, the first network function enables the third network function to store the network selection data. For instance, the first network function initiates a storage process to cause the third network function determined at step 520 to store the network selection data. Details of step 530 are given in Figures 6a, 6b and 6c.

Turning to Figure 6a, Figure 6a shows a method of enabling the third network function to store the network selection data. Hence, Figure 6a shows a method of initiating a storage process to cause a third network function to store network selection data in accordance with one or more aspects of the present disclosure, Specifically, Figure 6a shows details of step 530 according to an embodiment. Accordingly, Figure 6a shows a method of initiating a storage process to cause the determined third network function to store the network selection data according to an embodiment.

Specifically, step 530 may comprise step 610. At step 610, the first network function generates a response message to the request received at step 510. The response message comprises a target identifier associated with the third network function. Hence, the target identifier identifies the third network function. At step 635, the first network function transmits the message generated at step 610 to the second network function. This message indicates to the third network function to store the network selection data. Hence, the message generated at step 610 is transmitted to the second network function to initiate the storage process to cause the third network function to store the network selection data. In the embodiment described with regard to Figure 6a, the second network function may be the NEF 440 and the first network function may be the UDM 460.

Optionally, step 610 may comprise steps 615, 620 and 625. At step 615, the first network function maps the identifier allowing the first network function to associate the localized service with the network selection data to a service identifier. The service identifier identifies the localized service. Specifically, the service identifier may be an internal service identifier The internal service identifier is used within the telecommunications network 410. The service identifier may be a service identifier already present in the communications network 410 or may be a service identifier generated in response to determining the third network function in step 520. In some examples, the service identifier may be generated by the first network function. In case the request received at step 510 includes a plurality of identifiers allowing the first network function to associate a plurality of localized services with the network selection data, the first network function maps the plurality of identifiers allowing the first network function to associate a plurality of localized services with the network selection data to a plurality of service identifiers.

At step 620, the first network function associates the service identifier with the network selection data. For instance, the service identifier can be used as a key to retrieve the network selection data. In embodiments, where the plurality of identifiers allowing the first network function to associate a plurality of localized services with the network selection data are mapped to a plurality of service identifiers, each of the plurality of service identifiers is associated with the network selection data.

At step 625, the first network function includes the service identifier into the message generated in step 610.

According to some embodiments, the first network function determines at step 520 that the first network function is the third network function. Accordingly, for these embodiments, the first network function determines at step 520 that the first network function itself stores the network selection data. For these embodiments, step 530 may further include, in addition to steps 615, 620 and 625, step 630. At step 630, the first network function stores the network selection data in a storage. The first network function may additionally store the service identifier associated with the network selection data in the storage at step 630. The storage may be a storage of the mobile telecommunications network apparatus comprising one or more processors configured to execute computer-executable instructions for implementing the first network function or a storage outside this mobile telecommunications network apparatus, but accessible to this mobile telecommunications network apparatus. For the embodiments where the first network function determines at step 520 that the first network function is the third network function, step 625 may also be omitted.

In the embodiments where the first network function stores the network selection data at step 630, the target identifier included in the message sent at step 635 identifies the first network function as the third network function, i.e., the target identifier indicates that the first network function stores the network selection data. A target identifier identifying the first network function as the third network function in the message sent at step 635 causes the second network function to acknowledge success of storage of the network function to an application function that has provided the network selection data to the second network function, such as the AF 430 within the LSP domain outside the telecommunications network 410. Additionally, a message including a target identifier indicating the first network function as the third network function signals the second network function that the network selection data has been successfully stored and that the second network function needs not to initiate a storage process at a further network function of the network 410.

Further discussing embodiments where the first network function stores the network selection data at step 630, there are two different scenarios. In a first scenario, the request received at step 510 comprises the network selection data. In this case, the first network function stores, at step 630, the network selection data received with the request. The first network function may additionally store the service identifier associated with the network selection data at step 630. In a second scenario, the request received at step 510 does not include the network selection data. In this second scenario, the request received at step 510 may include an indication of the data type as discussed above with regard to step 510. In the second scenario, the first network function sends, prior to storing the network selection data at step 630, a request for the network selection data to the second network function and receives, in response to the request for the network selection data, the network selection data from the second network function. The first network function then stores the network selection data at step 630. The first network function may additionally store the service identifier associated with the network selection data at step 630.

According to some embodiments, the first network function determines at step 520 that the first network function is different from the third network function. In those embodiments, the third network function may be selected from a group of network functions comprising SOR-AF 450 and UDR 410. In these embodiments, the target identifier in the message sent at step 635 indicates that the third network function is different from the first network function. For instance the target identifier may identify the SOR-AF 450 or the UDR 410 as the third network function. In embodiments where the message sent at step 635 includes a target identifier identifying the third network function being different from the first network function, the message sent at step 635 causes the second network function to provide the third network function with the network selection data. The message sent at step 635 may also cause the second network function to initiate the storage process to cause the third network function to store the network selection data. Additionally, in embodiments where step 610 includes steps 615, 620 and 625, the message sent at step 635 may cause the second network function to provide the third network function with the service identifier. The message sent at step 635 may also cause the second network function to initiate a storage process to cause the third network function to store the service identifier associated with the network selection data.

Turning now to Figure 6b, Figure 6b shows a method of enabling the third network function to store the network selection data. Hence Figure 6b shows a method of initiating a storage process to cause a third network function to store network selection data in accordance with one or more aspects of the present disclosure. Specifically, Figure 6b shows details of step 530 according to an embodiment alternative to the embodiment described with regard to Figure 6a. In the embodiment described with regard to Figure 6b, the request received at step 510 comprises the network selection data. Additionally, the third network function determined at step 520 differs from the first network function. At step 650, the first network function maps the identifier allowing the first network function to associate the localized service with the network selection data to a service identifier. The service identifier identifies the localized service. Specifically, the service identifier may be a service identifier used within the telecommunications network 410. The service identifier may be a service identifier already present in the communications network 410 or may be a service identifier generated in response to determining the third network function in step 520. In some examples, the service identifier may be generated by the first network function. In case the request received at step 510 includes a plurality of identifiers allowing the first network function to associate a plurality of localized services with the network selection data, the first network function maps the plurality of identifiers allowing the first network function to associate a plurality of localized services with the network selection data to a plurality of service identifiers.

At step 655, the first network function associates the service identifier with the network selection data. For instance, the service identifier can be used as a key to retrieve the network selection data. In embodiments, where the plurality of identifiers allowing the first network function to associate a plurality of localized services with the network selection data are mapped to a plurality of service identifiers, each of the plurality of service identifiers is associated with the network selection data.

At step 660, the first network function generates a message. The message generated at step 660 comprises the network selection data received at step 510 and the service identifier. In case of a plurality of service identifiers, the message may include the plurality of service identifiers.

At step 665, the first network function sends the message generated at step 660 to the third network function to initiate the storage process to cause the third network function to store the network selection data and the service identifier. In case of a plurality of service identifiers, the message send at step 665 causes the third network function to initiate the storage process to cause the third network function to store the network selection data and the plurality of service identifiers.

In the embodiment described with regard to Figure 6b, the second network function may be the NEF 440, the first network function may be the UDM 460, and the third network function may be selected from a group of network functions comprising the UDR 470 and the SOR-AF 450.

Turning now to Figure 6c, Figure 6c shows a method of enabling the third network function to store the network selection data. Hence, Figure 6c shows a method of initiating a storage process to cause a third network function to store network selection data in accordance with one or more aspects of the present disclosure. Specifically, Figure 6c shows details of step 530 according to an embodiment alternative to the embodiment described with regard to Figure 6b. In the embodiment described with regard to Figure 6c, the request received at step 510 comprises the network selection data. Additionally, the third network function determined at step 520 is the first network function.

At step 670, the first network function maps the identifier allowing the first network function to associate the localized service with the network selection data to a service identifier. The service identifier identifies the localized service. Specifically, the service identifier may be a service identifier used within the telecommunications network 410. The service identifier may be a service identifier already present in the communications network 410 or may be a service identifier generated in response to determining the third network function in step 520. In some examples, the service identifier may be generated by the first network function. In case the request received at step 510 includes a plurality of identifiers allowing the first network function to associate a plurality of localized services with the network selection data, the first network function maps the plurality of identifiers allowing the first network function to associate a plurality of localized services with the network selection data to a plurality of service identifiers. At step 675, the first network function associates the service identifier with the network selection data. For instance, the service identifier can be used as a key to retrieve the network selection data. In embodiments, where the plurality of identifiers allowing the first network function to associate a plurality of localized services with the network selection data are mapped to a plurality of service identifiers, each of the plurality of service identifiers is associated with the network selection data.

At step 680, the first network function stores the network selection data in a storage. The first network function may additionally store the service identifier associated with the network selection data in the storage at step 680. The storage may be a storage of the mobile telecommunications network apparatus comprising one or more processors configured to execute computer-executable instructions for implementing the first network function or a storage outside this mobile telecommunications network apparatus, but accessible to this mobile telecommunications network apparatus. In case of a plurality of service identifiers, the first network function stores the plurality of service identifiers in the storage.

Accordingly, in the embodiments of Figures 6b and 6c, the first network function does not generate a message comprising a target identifier as generated in step 610 of Figure 6a. Instead, the first network function may optionally inform the second network function that the first network function processes the network selection data.

Referring back to Figure 5, the first network function may optionally perform steps 540 and 550. At step 540, the first network function may determine one or more user equipments subscribed to the localized service identified by the service identifier (in case of a plurality of service identifiers, the first network function may perform step 540 for each service identifier of the plurality of service identifiers).

At step 550, the first network function may set, in a user context of each of the user equipments determined at step 540, a flag indicating that the user equipment needs to be updated with Steering of Roaming (SOR) data.

With continued reference to Figure 5, the first network function may optionally perform steps 560, 570 and 580.

Discussing steps 560, 570, and 580 for embodiments where the first network function is the third network function, the first network function determines at step 560, based on the service identifier, a user equipment that needs to be updated. For example, in embodiments where steps 540 and 550 are performed, the first network function may determine a user equipment having set the flag in the user context. At step 570, the first network function generates Steering of Roaming (SOR) Data based on the network selection data. For instance, the SOR data generated at step 570 may be the SOR SNRN-SI-VI described above and below. The SOR data may comprise at least one of: a) CH controlled prioritized list of preferred SNPNs, each entry of the list including:

• an SNPN identifier; and

• a GIN; and

The validity information may comprise at least one of:

• Location validity information.

The Location validity information may comprise at least one of:

• Geolocation information, and

At step 580, the first network function transmits a container comprising the SOR data generated at step 570 to an access and mobility management function, such as AMF 428. The transmission of the container causes the AMF to forward the container to the UE determined at step 560.

Discussing steps 560, 570, and 580 for embodiments where the first network function is different from the third network function, the first network function determines at step 560, based on the service identifier, a user equipment that needs to be updated. For example, in embodiments where steps 540 and 550 are performed, the first network function may determine a user equipment having set the flag in the user context.

At step 570, the first network function generates Steering of Roaming (SOR) Data based on the network selection data. In embodiments where the first network function is different from the third network function, step 570 comprises sending a request message to the third network function for the network selection data and receiving, in response to the request message, the network selection data from the third network function. The SOR data generated at step 570 may be the SOR SNPN-SI-VI described above and below. The SOR data may comprise at least one of: a) CH controlled prioritized list of preferred SNPNs, each entry of the list including:

• an SNPN identifier; and

• a GIN; and

The validity information may comprise at least one of:

• Location validity information.

The Location validity information may comprise at least one of:

• Geolocation information, and

Discussing embodiments where the first network function is different from the third network function and the third network function is the SOR-AF 450, the first network function determines at step 560, based on the service identifier, a user equipment that needs to be updated. For example, in embodiments where steps 540 and 550 are performed, the first network function may determine a user equipment having set the flag in the user context.

In the embodiments where the first network function is different from the third network function and the third network function is the SOR-AF 450, optionally, step 570 of generating the SOR data may be omitted. Instead, the first network function sends a request to the SOR-AF 450 for SOR data and the first network function receives, in response to the request, a container comprising the SOR data from the SOR-AF 450. The SOR data received from the SOR-AF may be the SOR SNPN-SI-VI described above and below. The SOR data may comprise at least one of: a) CH controlled prioritized list of preferred SNPNs, each entry of the list including:

• an SNPN identifier; and

• a GIN; and

The validity information may comprise at least one of:

• Location validity information.

The Location validity information may comprise at least one of:

• Geolocation information, and

In the embodiments where the first network function is different from the third network function, the third network function is the SOR-AF 450, and step 570 of generating the SOR data by the first network function has been omitted, the first network function transmits at step 580 the container comprising the SOR data as received from the SOR-AF 450 to an access and mobility management function, such as the AMF 428. The transmission of the container causes the AMF to forward the container to the UE determined at step 560.

Turning now to Figures 7a, 7b and 7c, those Figures show flow diagrams of a procedure for provisioning of network selection data to a telecommunications network in accordance with one or more aspects of the present disclosure. Specifically, those Figures give the method described with regard to Figures 5 and 6a context within the architecture of Figure 4. In particular, Figures 7a, 7b and 7c show signaling procedures between components of the architecture of Figure 4. Figures 7a, 7b, and 7c show details of the procedure for provisioning of NSI-LS information to a telecommunications network such as 5GC 410, wherein the NSI-LS is sent from an external party (e.g., AF or LSP) to the 5GC 410 via NEF 440.

Figures 7a, 7b and 7c show a UE 704 having installed an application referred to as localized App1 702. UE 704 may be UE 420 of Figure 4. Additionally, Figures 7a, 7b and 7c show an AMF 706, a SOR-AF 708, an UDM 710, an UDR 712, a NEF 714 and an AF 716. The AMF 706 may be the AMF 428 of Figure 4, SOR-AF 708 may be SOR- AF 450 of Figure 4, UDM 710 may be UDM 460 of Figure 4, UDR 712 may be UDR 470 of Figure 4, NEF 714 may be NEF 440 of Figure 4, and AF 716 may be the AF within the LSP domain 430 of Figure 4.

In the embodiments described with regard to Figures 7a, 7b, and 7c, the NEF 714 requests the UDM 710 to process (authorize) service specific parameters received from the AF 716, wherein the NEF 714 may indicate the data type being NSI-LS. The UDM 710 determines the target NF where the NSI-LS has to be stored.

Discussing the steps common to Figures 7a, 7b and 7c, the UE 704 may have installed the localized App1 702 that uses a (localized) service, for example, called localized App1. The application server for the localized App1 702 may implement an AF 716 functionality so that the AF 716 can use the services exposed by the 5GC 410, for example, via the NEF 714. The AF 716 may be located in a LSP domain 430.

The Localized App1 702 and the AF 716 may exchange information at 720 on an application layer, for example, using any connectivity via Wireless Local Area Network (WLAN) or via a 3GPP access network.

At 725, the AF 716 may determine to update the 5GC 410 with network selection data such as NSI-LS. The AF 716 may be configured to use the exposed network services for provisioning of external information to a particular network operator deploying a 5GC 410. The LSP 430 may either create a new NSI-LS data or determine to update the NSI-LS data which has been already provisioned to the 5GC 410. Therefore, the AF 716 may determine to create a new or to update an existing localized services specific information such as the network selection data (also referred to as NSI-LS data) discussed with regard to Figures 5, 6 a, 6b, and 6c.

At 730, the AF 716 may send a request to update the 5GC 410 with network selection data such as NSI-LS. With the request, the AF 716 may provide the NEF 714 with the NSI-LS that may comprise a list of preferred networks identifiers (e.g., SNPNs or GINs), wherein each network entry is associated with a validity information. The AF 716 may use an AF identifier, an external application identifier, an external group ID or a list of one or more individual external user IDs (e.g., Generic Public Subscription Identifier (GPSI)) to identify the NSI-LS towards the 5GC 410. The NSI-LS may be identified as new type, for example, as localized service data type or network selection data type.

The AF 716 may use one of the following procedures for provisioning: a) Expected UE behaviour parameters provisioning: In this case the AF 716 may use the Nnef_ParameterProvision_Create or Nnef_ParameterProvision_Update or Nnef_ParameterProvision_Delete Request to the NEF 714. A new data type may be introduced indicating that data is either for localized services or for network selection or for NSI-LS (i.e. the information is for SOR); b) Service specific parameters provisioning: In this case the AF 716 may use the service operation Nnef_ServiceParameter_Create/Update/Delete request including at least one of an identification of the data to be provisioned (e.g., external group ID, AF- ID, Service ID). A new data type may be introduced indicating that data is either for localized services or for network selection or for NSI-LS (i.e. the information is for SOR); and c) A new service operation is introduced to provision localized service information or network selection specific information. For example, the new service may be called Nnef_LocalizedService_Create/Update/Delete operation.

The NSI-LS information provisioned in the 5GC 410 is used for a SOR procedure towards the UE 704.

At step 735, the NEF 714 sends to the UDM 710 a request to process network selection data (NSI-LS). The NEF 714 may send either a request for external parameter provisioning or service authorization or a request to authorize the service specific parameter provisioning. Step 735 may correspond to step 510 of Figure 5, i.e. the request to process network selection data received at step 510 may be the request sent by the NEF 714 at step 735.

For step 735, the NEF selects one of the following options: a) If the AF 716 has used the Nnef_ParameterProvision service, the NEF 714 may send the NSI-LS to the UDM 710 using the Nudm_ParameterProvision operation. A new data type may be introduced indicating that data is either for localized services or for network selection or for NSI-LS (i.e., the information is for SOR); b) If the AF 716 has used the Nnef_Service Parameter service, the NEF 714 may send Nudm_ServiceSpecificAuthorisation_Create request in order to authorize the service request. A new data type may be introduced indicating that data is either for localized services or for network selection or for NSI-LS (i.e. the information is for SOR); c) If the AF 716 uses a new service operation to send/provision the data for NSI- LS to the 5GC 410 or uses an existing service operation as per a) or b) but based on the data type being NSI-LS, the NEF 714 may also use a new UDM service operation to request the UDM 710 about the destination of the NSI-LS information.

In any of the above options, the NEF 714 further sends to the UDM 710 the external identifier which identifies the NSI-LS, for example, external group ID, AF-ID, Service ID. This external identifier may correspond to the identifier allowing the first network function (i.e., the UDM 710) to associate the localized service with the network selection data received with the request described at step 510 of Figure 5.

The NEF 714 may send either the whole NSI-LS data to the UDM 710, or only an indication that the data type is NSI-LS, but not sending the whole data.

In an alternative embodiment, the NEF 714 may internally determine to which target 5GC NF to send the NSI-LS received in 730. The NEF can determine the target 5GC NF based on the received NSI-LS data type in 730. For example, the NEF may determine (e.g., based on internal configuration) that the NSI-LS can be stored in the SOR-AF based on the data type. In such case, the NEF 714 may optionally request authorization with the UDM 710 (e.g., as shown in steps 735 and 740), and optionally the NEF 714 does not send the NSI-LS data to the UDM 710.

The UDM 710 processes the request from the NEF 714 received at step 735 and may authorize the AF 716 to provision the parameters. The UDM 710 may retrieve from UDR 712 (e.g., by using of Nudr_DM_Query service) corresponding subscription information in order to validate required NSI-LS data updates and authorize these changes for this subscriber or Group ID for the corresponding AF. The UDM 710 may optionally include the service authorization in the response message sent at step 740 to NEF 714, for example, by using Nudm_ServiceSpecificAuthorisation_Create response service operation.

The UDM 710 may map the received external identifier (e.g., external group ID, list of GPSIs, AF-ID, external Service ID) to an internal identifier (e.g., internal group ID, Application Identifier, DNN/S-NSSA information, or internal service ID). The internal identifier may correspond to the internal service identifier mentioned in step 615. This mapping may correspond step 615. The UDM 710 may determine a target NF (e.g., UDR 712, SOR-AF 708, or itself) to which the NSI-LS has to be provisioned as described with regard to step 520. The UDM 710 may determine an internal group ID or service ID to be used to reference the NSI-LS. This internal group ID or service ID may correspond to the internal service identifier discussed in step 615. The UDM 710 may send at 740 a response message to the NEF 714. The response message may correspond to the message sent at step 635 of Figure 6a. The UDM may send a Nudm ServiceSpecificAuthorisation Create response message to the NEF 714. The response may include at least one of: target NF, service identification (e.g., internal group ID, list of GPSIs, application ID or Service ID), and result of the processing ‘success'/’failure’.

Turning now to Figure 7a, the scenario of Figure 6a is described in more detail. Specifically, in this embodiment, the UDM 710 determines to store the NSI-LS data by itself. In this case, the UDM 710 has sent a response message in step 740 including a target identifier that indicates that the UDM 710 itself stores the NSI-LS. The UDM 710 may determine to process and store the received NSI-LS data locally, and therefore, there is no need by the NEF 714 to further store the data in another NF. In such case, the UDM sends “none” as the target NF parameter (the target NF parameter may correspond to the target identifier discussed with regard to Figure 6a), which identifies to the NEF 714 that the NEF 714 does not need to store the information in another NF and can acknowledge to the AF 716 the ‘success’ of the operation. The UDM 710 stores the NSI-LS at step 745 and associates the NSI-LS with the internal identifier (e.g., internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID). Step 745 may correspond to step 630.

In addition, the UDM 710 may determine the Ues which are subscribed or associated with the localized service (e.g., the UEs whose subscription context contains the internal service identifier like internal Group ID or application/service ID, etc.). The UDM 710 may store a flag in each identified UEs’ context that the UE SOR data should be updated as discussed with regard to steps 530 and 540.

In an embodiment, the UDM 710 may have decided to store the received NSI-SL data locally in the UDM 710. If the NSI-LS data was not provided in step 735, the UDM 710 may explicitly send a request message to the NEF 714 to provide the NSI-LS data. In response, the NEF 714 will send the NSI-LS data to the UDM 710. This signaling is not shown in Figure 7a. At step 750, the NEF 714 sends a response to the update request received at step 730. Specifically, the NEF 714 may send the response message to the AF 716 if the UDM 710 has indicated in the message sent at step 740 that the UDM 710 itself stores the NSI-LS, i.e., indicated “none” in the target NF parameter. The response message sent at step 750 may be a Nnef_ServiceParameter_Create/Update response to the AF 716 to acknowledge the success of the processing in the 5GC 410. The NEF 714 can also indicate a failure of the processing in the 5GC 410 if either no message is received at step 740 or the message indicates a failure of the processing by the UDM 710.

In an embodiment, if the NEF 714 has not sent the NSI-LS data in step 735, the NEF 714 may send the NSI-LS data to the UDM 710 in response to the message received at 740 indicating that the UDM will store the NSI-LS.

Turning now to Figure 7b, the UDM 710 has indicated in the response message sent at 740 that the UDR 712 should store the NSI-LS. If the UDM 710 has indicated in step 740 that the target NF is the UDR 712, the NEF 714 triggers NSI-LS provisioning to the UDR 712.

Specifically, the NEF 714 may send at 755 a message to the UDR 712 that triggers storage of the NSI-LS. The message may include the NSI-LS and the internal identifier (e.g., internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID). The NEF 714 may use the Nudr_DM_Create/Update/Delete service to provision the NSI-LS to the UDR 712. The UDR stores the NSI-LS associated with the internal identifier (e.g., internal group ID, list of GPSIs, application ID or Service ID) at step 760. The UDR 712 may later provide the NSI-LS to a consumer NF (e.g., UDM 710, or SOR-AF 708) when the consumer NF sends a request to get the NSI-LS identified by the internal identifier.

At step 765, the UDR 712 sends a response to the trigger message received at step 755. The response message is sent to NEF 714. The response message may indicate that the NSI-LS and the internal identifier have been stored.

At step 770, the NEF 714 sends a response to the update request received at step 730. The response message sent at step 750 may be a Nnef_ServiceParameter_Create/Update response to the AF 716 to acknowledge the success of the processing in the 5GC 410. The NEF 714 can also indicate a failure of the processing in the 5GC 410 if either no message is received at step 740 or the message received at 765 indicates a failure of the processing by the UDR 712. Turning to Figure 7c, the UDM 710 has indicated in the response message sent at 740 that the SOR-AF 708 should store the NSI-LS. If the UDM 710 has indicated in step 740 that the target NF is the SOR-AF 708, the NEF 714 triggers NSI-LS provisioning to the SOR-AF 708.

Specifically, the NEF 714 may send at 772 a message to the SOR-AF 708 that triggers storage of the NSI-LS. The message may include the NSI-LS and the internal identifier (e.g., internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID).

As described in the alternative embodiment with regard to step 735, the NEF may internally determine (i.e., without receiving indication about the target NF from the UDM 710) to store the NSI-LS in the SOR-AF 708. The NEF 714 may perform such internal determination based on the received data type at step 730, e.g., if the received data indicates that the type is NSI-LS, the NEF 714 determines that the received data should be stored in the SOR-AF 708 (or alternatively to UDR 712 as shown in Figured 7b but without assistance from the UDM 710). In such case, the NEF 714 may request authorization with the UDM 710, and optionally the NEF 714 does not send the NSI- LS data to the UDM 710. Alternatively, the NEF 714 may determine to directly send the NSI-LS data to the SOR-AF 708 without asking for authorization from the UDM 710. Independent whether (a) the NEF 714 has requested authorization by the UDM 710 or (b) has sent the NSI-LS data to the SOR-AF 708 without authorization by the UDM 710, the NEF 714 should indicate to the UDM 710 that NSI-LS data (e.g., identified by the external/internal identifier) has been created or updated in the SOR- AF 708 (or alternatively to UDR 712). Such indication from NEF 714 to the UDM 710 (which is not depicted on Figure 7c) would allow the UDM 710 to trigger the SOR procedure towards the UEs which are subscribed to use the localized service identified by the external/internal identifier.

Further discussing step 772, the NEF 714 may send a request to the SOR-AF 708 for creation or update of the NSI-LS data. The NEF 714 may include the NSI-LS data and the associated internal identifier (e.g., internal group ID, list of GPSIs, application ID or Service ID) into the request.

For this purpose, the NEF 714 may use an existing service operation (e.g., Nsoraf_SoR_lnfo) or a new service operation may be introduced (e.g., Nsoraf_SoR_Notificaiton request). In any of the service operations at least one of the parameters are included: NSI-LS data and the associated internal identifier. At step 774, the SOR-AF 708 stores the NSI-LS data associated with the internal identifier (e.g., internal group ID, list of GPSIs, application ID or Service ID).

At step 774, the SOR-AF 706 may locally store the NSI-LS data sent in step 772. The SOR-AF 708 associates the stored NSI-LS with the internal identifier provided in step 112..

The SOR-AF 708 uses the NSI-LS to create SOR data to be provisioned to UE(s) 704 which are subscribed or use the localized service. The SOR-AF 708 uses the internal service identifier (e.g., internal group ID, list of GPSIs, application ID or internal Service ID) as key to identify any request from a consumer NF which retrieves the SNPN-SI- VI data.

The SOR SNPN-SI-VI data may include a CH controlled prioritized lists of preferred SNPNs/GINs wherein each entry is associated with time and/or location validity information as explained above.

At step 776, The SOR-AF 708 sends a response message to the NEF 714 indicating a result, i.e. , whether the NSI-LS has been provisioned with ‘success¹ or it has ‘failed¹. At step 778, the NEF 714 sends a response to the update request received at step 730. The response message sent at step 778 may be a Nnef_ServiceParameter_Create/Update response to the AF 716 to acknowledge the success of the processing in the 5GC 410. The NEF 714 can also indicate a failure of the processing in the 5GC 410 if either no message is received at step 740 or the message received at 776 indicates a failure of the processing by the SOR-AF 708.

Turning now to a further step common to Figures 7a, 7b, and 7c, at step 790, the UDM 710 triggers a SOR procedure for each LIE for which the provisioned NSI-LS information (e.g., as per step 730) applies. In other words, the UDM 710 may determine one or more Ues 704 which are subscribed for the localized service, for which the NSI- LS information is provisioned. For example, the UDM 710 may use the stored flag in each identified Ues’ subscription context as described with regard to step 740. Step 790 may correspond to step 560.

The UDM 710 may perform the Control Plane SOR procedure towards each UE 704, where the SOR container contains the SOR SNPN-SI-VI data. Further details are described in Figure 12 in steps 1230, 1232, 1234, 1236, and 1238. After the SOR procedure is successfully performed, the UDM 710 may remove (delete) the flag in the corresponding UE user context, i.e. the flag as described in step 540. Independent which NF (SOR-AF 708, UDR 712 or UDM 710) stores the NSI-LS data, the NF uses the associated internal identifier (e.g., internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID) as a key to store the NSI-LS data. When a request for SOR is received in the NF (e.g., to retrieve the SOR SNPN-SI-VI data), the same internal identifier is used in this request.

The benefit of the solution in Figure 7a, 7b, and 7c is that the AF 716 within the LSP domain is able to dynamically provision the home network (e.g., UDM 710/UDR 712 in the HPLMN, subscribed SNPN or CH) with NSI-LS information. The home network’s UDM 710 can use the SOR-AF 708 to create the SOR SNPN-SI-VI data and the UDM 710 can update on demand the UE configuration. By using this solution, the UE 704 can be dynamically updated with the latest configuration for network selection to use the localized service.

Turning to Figures 8a, 8b, 8c, and 8d, those Figures show flow diagrams of a procedure for provisioning of network selection data to a UDM in accordance with one or more aspects of the present disclosure. Specifically, those Figures show details of the procedure for provisioning of NSI-LS information to the UDM 804 and the UDM 804 determines whether to provision the UDR 806 or the SOR-AF 802 with the NSI-LS. Accordingly, Figures 8a, 8b, 8c, and 8d give the method described with regard to Figures 5 and 6b or 6c context within the architecture of Figure 4.

Discussing the features common to Figures 8a, 8b, 8c, and 8d, the Figures show the flow of messages between an SOR-AF 802, a UDM 804, a UDR 806, a NEF 808 and an AF 810. SOR-AF 802 may correspond to SOR-AF 450, UDM 804 may correspond to UDM 460, UDR 806 may correspond to UDR 470, NEF 808 may correspond to NEF 440, and AF 810 may correspond to the AF within the LSP domain 430.

At step 820, the AF 810 may determine to update the 5GC 410 with network selection data such as NSI-LS. The AF 810 may be configured to use the exposed network services for provisioning of external information to a particular network operator deploying a 5GC 410. The LSP 430 may either create a new NSI-LS data or determine to update the NSI-LS data which has been already provisioned to the 5GC 410. Therefore, the AF 810 may determine to create a new or to update an existing localized services specific information such as the network selection data (also referred to as NSI-LS data) discussed with regard to Figures 5, 6 a, 6b, and 6c.

At step 825, the AF 810 may send a request to update the 5GC 410 with network selection data such as NSI-LS. With the request, the AF 810 may provide the NEF 808 with the NSI-LS that may comprise a list of preferred networks identifiers (e.g., SNPNs or GINs), wherein each network entry is associated with a validity information. The AF 810 may use an AF identifier, an external application identifier, an external group ID or a list of one or more individual external user IDs (e.g., Generic Public Subscription Identifier (GPSI)) to identify the NSI-LS towards the 5GC 410. The NSI-LS may be identified as new type, for example, as localized service data type or network selection data type.

The AF 810 may use one of the following procedures for provisioning: a) Expected UE behaviour parameters provisioning: In this case the AF 810 may use the Nnef_ParameterProvision_Create or Nnef_ParameterProvision_Update or Nnef_ParameterProvision_Delete Request to the NEF 808. A new data type may be introduced indicating that data is either for localized services or for network selection or for NSI-LS (i.e. the information is for SOR); b) Service specific parameters provisioning: In this case the AF 810 may use the service operation Nnef_ServiceParameter_Create/Update/Delete request including at least one of an identification of the data to be provisioned (e.g., external group ID, AF- ID, Service ID). A new data type may be introduced indicating that data is either for localized services or for network selection or for NSI-LS (i.e. the information is for SOR); and c) A new service operation is introduced to provision localized service information or network selection specific information. For example, the new service may be called NnefJ_ocalizedService_Create/Update/Delete operation.

The NSI-LS information provisioned in the 5GC 410 is used for a SOR procedure towards the UE.

At step 830, the NEF 808 sends to the UDM 804 a request to process network selection data (NSI-LS). The NEF 808 may send either a request for external parameter provisioning or service authorization or a request to authorize the service specific parameter provisioning. Step 830 may correspond to step 510 of Figure 5, i.e. the request to process network selection data received at step 510 may be the request sent by the NEF 808 at step 830.

For step 830, the NEF 808 selects one of the following options: a) If the AF 810 has used the Nnef_ParameterProvision service, the NEF 808 may send the NSI-LS to the UDM 804 using the Nudm_ParameterProvision operation. A new data type may be introduced indicating that data is either for localized services or for network selection or for NSI-LS (i.e., the information is for SOR); b) If the AF 810 has used the Nnef_Service Parameter service, the NEF 808 may send Nudm_ServiceSpecificAuthorisation_Create request in order to authorize the service request. A new data type may be introduced indicating that data is either for localized services or for network selection or for NSI-LS (i.e. the information is for SOR); c) If the AF 810 uses a new service operation to send/provision the data for NSI- LS to the 5GC 410, the NEF 808 may also use a new UDM service operation to request the UDM 804 about the destination of the NSI-LS information.

In any of the above options, the NEF 808 further sends to the UDM 804 the external identifier which identifies the NSI-LS, for example, external group ID, AF-ID, Service ID. This external identifier may correspond to the identifier allowing the first network function (i.e., the UDM 804) to associate the localized service with the network selection data received with the request described at step 510 of Figure 5.

The NEF 808 may send the whole NSI-LS data to the UDM 804.

In an alternative embodiment, the NEF 808 may internally determine to which target 5GC NF to send the NSI-LS received in 825. The NEF 808 can determine the target 5GC NF based on the received NSI-LS data type in 825. For example, the NEF 808 may determine (e.g., based on internal configuration) that the NSI-LS can be stored in the SOR-AF 802 based on the data type.

The UDM 804 processes the request from the NEF 808 received at step 830 and may authorize the AF 810 to provision the parameters. The UDM 804 may retrieve from UDR 806 (e.g., by using of Nudr_DM_Query service) corresponding subscription information in order to validate required NSI-LS data updates and authorize these changes for this subscriber or Group ID for the corresponding AF.

The UDM 804 may map the received external identifier (e.g., external group ID, list of GPSIs, AF-ID, external Service ID) to an internal identifier (e.g., internal group ID, Application Identifier, DNN/S-NSSA information, or internal service ID). The internal identifier may correspond to the internal service identifier mentioned in steps 615, 650 and 670. This mapping may correspond to one of steps 615, 650 and 670.

The UDM 804 may determine a target NF (e.g., UDR 806, SOR-AF 802, or itself) to which the NSI-LS has to be provisioned as described with regard to step 520. The UDM 804 may determine an internal group ID or service ID to be used to reference the NSI-LS. This internal group ID or service ID may correspond to the internal service identifier discussed in steps 615, 650 and 670.

Turning now to common features of Figures 8a and 8c, based on a local configuration in the UDM 804, the UDM 804 determines that the UDM can take care and provision the NSI-LS data to the correct NF where the NSI-LS data should be stored. The UDM 804 may temporary store the NSI-LS data. The UDM 804 sends a response in step 835 to the request received in step 830. For example, the UDM 804 may send to the NEF 808 Nudm_ServiceSpecificAuthorisation_Create response comprising an indication for ‘success' or ‘failure’ of the processing in the UDM 804.

At step 840, the NEF 808 sends a response to the update request received at step 825. Specifically, the NEF 808 may send the response message to the AF 810 if the UDM 804 has indicated in the message sent at step 835 that the UDM 804 has successfully processed the NSI-LS. The response message sent at step 840 may be a Nnef_ServiceParameter_Create/Update response to the AF 810 to acknowledge the success of the processing in the 5GC 410. The NEF 808 can also indicate a failure of the processing in the 5GC 410 if either no message is received at step 835 or the message indicates a failure of the processing by the UDM 804.

Turning now to common features of Figures 8a and 8b, at 845 the UDM 804 initiates storage of the network selection data at the UDR 806 by sending a message to the UDR 806 that triggers storage of the network selection data by the UDR 806. Step 845 may correspond to step 665. For instance, if the UDM 804 determines that the NSI-LS data has to be stored in the UDR 806, the UDM 804 sends a request to the UDR 806 to store the data. For example, the UDM 804 may use Nudr_DM_Create/Update/Delete request operation, wherein the message comprises the NSI-LS data and an associated internal identifier (e.g., internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID).

At step 850, the UDR 806 stores the network selection data and the associated internal identifier (e.g., internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID).

At step 855, the UDR 806 sends to the UDM 804 a response message comprising an indication for ‘success¹ or ‘failure’ of the processing in the UDR 806.

Turning now to features common to Figures 8c and 8d, if the UDM 804 determines that the NSI-LS data has to be stored in the SOR-AF 802, the UDM 804 sends a request at 860 to the SOR-AF 802 to store the NSI-LS. Step 860 may correspond to step 665. For example, the UDM 804 may use an existing service operation (e.g., Nsoraf_SoR_lnfo request) or use a new service operation (e.g., Nsoraf_Notify request) towards the SOR-AF 802. The message sent to the SOR-AF 802 may comprise the NSI-LS data and an associated internal identifier (e.g., internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID).

At step 865, the SOR-AF 802 may store the NSI-LS data sent in step 860. The SOR- AF 802 associates the stored NSI-LS with the internal identifier provided in step 860. The SOR-AF 802 uses the NSI-LS to create SOR data to be provisioned to UE(s) which are subscribed or use the localized service. The SOR-AF 802 uses the internal service identifier (e.g., internal group ID, list of GPSIs, application ID or internal Service ID) as key to identify any request from a consumer NF which retrieves the SNPN-SI-

VI data.

The SOR SNPN-SI-VI data (also referred to as SOR data) may include a CH controlled prioritized lists of preferred SNPNs/GINs wherein each entry is associated with time and/or location validity information as explained above.

The SOR-AF 802 stores the received NSI-SL and the associated internal identifier. Based on the type of the data, i.e. NSI-LS type, the SOR-AF 802 can determine that the Ues, which are subscribed with the localized service identified by the associated internal identifier, should be updated with SOR SNPN-SI-VI (also referred to as SOR data).

At step 870, the SOR-AF 802 sends to the UDM 804 a response message comprising an indication for 'success¹ or ‘failure’ of the processing in the SOR-AF 802.

Turning to features common for Figures 8b and 8d, if the UDM 804 has not performed step 835, the UDM 804 sends at 880 a response to the NEF 808 to the request received in step 830. For example, the UDM 804 may send to the NEF 808 Nudm_ServiceSpecificAuthorisation_Create response comprising an indication for 'success' or ‘failure’ of the processing in the UDM 808.

At step 890, the NEF 808 sends a response to the update request received at step 825. Specifically, the NEF 808 may send the response message to the AF 810 if the UDM 804 has indicated in the message sent at step 880 that the UDM 804 has successfully processed the NSI-LS. The response message sent at step 890 may be a Nnef_ServiceParameter_Create/Update response to the AF 810 to acknowledge the success of the processing in the 5GC 410. The NEF 808 can also indicate a failure of the processing in the 5GC 410 if either no message is received at step 880 or the message indicates a failure of the processing by the UDM 804.

For all Figures 8a, 8b, 8c and 8d applies, regardless which NF (SOR-AF 802, UDR 806 or UDM 804) stores the NSI-LS data, the NF uses the associated internal identifier (e.g., internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID) as a key to store the NSI-LS data. When a request for SOR data is received in the NF (e.g., to retrieve the SOR SNPN-SI-VI data), the same internal identifier is used in this request.

Turning now to Figures 9a and 9b, Figures 9a and 9b show a method for providing network selection data to a mobile telecommunications network according to embodiments. Specifically, those Figures show a further method for providing network selection data to a mobile telecommunications network such as 5GC 410. While the embodiments described with regard to Figures 5 to 8d use a NEF to provide the network selection data to the mobile telecommunications network, the embodiments described with regard to Figures 9a, 9b and 10 may use the interface 165 described in Figure 1 .

Method 900a of Figure 9a and method 900b of Figure 9b may be performed by a SOR- AF such as SOR-AF 450 of a mobile telecommunications network 410, such as a 5GC. Specifically, a mobile telecommunications network apparatus of the telecommunications network 410 may comprise a SOR-AF, a processor, and a memory coupled to the processor, the memory comprising instructions executable by the processor to cause the SOR application function of the apparatus to perform the method 900a or 900b. In embodiments, the mobile telecommunications network apparatus of the telecommunications network 410 may comprise one or more processors configured to execute computer-executable instructions for implementing the SOR-AF, wherein the computer-executable instructions cause the one or more processors to perform the method 900a or 900b. The mobile telecommunications network apparatus of the telecommunications network 410 may be the apparatus 1300 described with regard to Figure 13.

Discussing the steps common to Figures 9a and 9b, the SOR-AF receives at 910 a request to configure the SOR-AF. This request may be received from a module in a management plane of the telecommunications network such as OAM module 150 of Figure 1 . The configuration request may comprise network selection data identifying one or more networks offering access to a localized service and a service identifier associated with the network selection data. The service identifier identifies the localized service.

As discussed above, the network selection data may include a list of preferred SNPN/GINs that identify networks which offer access to the localized service, wherein each entry of SNPN/GIN may be associated with validity information.

In response to receiving the request, the SOR-AF stores at step 915 the network selection data and the service identifier in a storage of the mobile telecommunications network apparatus or to a storage accessible by the mobile telecommunications network apparatus.

At step 920, the SOR-AF discovers a UDM network function such as UDM 460. The discovered UDM serves the localized service identified by the service identifier.

At step 925, the SOR-AF informs the discovered UDM that the network selection data associated with the service identifier has been received.

Turning now to the steps performed by method 900a of Figure 9a, the SOR-AF may further perform the optional steps 930, 935, and 940.

At step 930, the SOR-AF may receive from the discovered UDM a request to provide SOR data. The request received at step 930 comprises the service identifier.

In response to receiving the request of step 930, the SOR-AF generates at step 935 the SOR data based on the network selection data associated with the service identifier.

At step 940, the SOR-AF transmits a container comprising the SOR data to the UDM. Turning now to Figure 9b, the SOR-AF may optionally perform steps 945, 950, and 955.

At step 945, the SOR-AF determines to update a user equipment such as UE 420.

At step 950, the SOR-AF generates SOR data based on the network selection data.

At step 955, the SOR-AF transmits a request to the discovered UDM comprising an identifier identifying the UE and a container comprising the SOR data. The request sent at step 955 causes the UDM to update the UE with the SOR data.

Turning now to Figure 10, Figure 10 shows a flow diagram of a procedure for provisioning of network selection data to a telecommunications network in accordance with one or more aspects of the present disclosure. Specifically, Figure 10 gives the method described with regard to Figures 9a and 9b context within the architecture of Figure 4. In particular, Figure 10 shows signaling procedures between components of the architecture of Figure 4. Figure 10 shows details of the procedure for provisioning of NSI-LS information to a telecommunications network such as the 5GC 410, wherein the NSI-LS is sent from an external party ( e.g., AF) to the 5GC 410 via a module in the management plane of the telecommunications network such as the OAM module 150 of Figure 1 .

Figure 10 shows a UE 1004 having installed an application 1002. UE 1004 may be UE 420 of Figure 4. Additionally, Figure 10 shows an AMF 1006, a SOR-AF 1012, an UDM 1008, an UDR 1010, a OAM 1014, an Operations Support Systems (OSS) 1016, a Binding Support Function (BSS) 1018 and an AF 1020 within a LSP domain. AMF 1006 may be AMF 428 of Figure 4, SOR-AF 1012 may be SOR-AF 450 of Figure 4, UDM 1008 may be UDM 460 of Figure 4, UDR 1010 may be UDR 470 of Figure 4, OAM 1014 may be OAM module 150 of Figure 1 , and AF 1020 may be the AF within a domain of the LSP 430 of Figure 4.

In embodiments of Figure 10, the LSP (e.g., acting as customer) provides the NSI-LS to the Mobile Network Operator (MNO) using the service level exposure, for example, service level agreement. The customer may be an AF that may reside at the LSP domain or at the subscribed SNPN / HPLMN. This is shown as interface 165 in the Figure 1. The management and business systems (i.e., OAM 1014, OSS 1016 and BSS 1018) reside at the Subscribed SNPN or HPLMN. The UE 1004 may be currently registered with a serving SNPN or the Subscribed SNPN or HPLMN.

Figure 10 shows the details of the procedure for provisioning of NSI-LS information, wherein the information is sent from an external party (e.g., AF 1020) to the 5GC via OAM 1014. The OAM 1014 system may include Exposure Governance Management Function (EGMF) which may (a) authorize the external party and provide permission to the external party and/or (b) takes control of the creation/management of operator defined management services (MnS) consumer (e.g., the SOR-AF 1012) acting on behalf of the external party (customer).

The UE 1004 may have installed an application 1002 that uses a localized service, for example, called localized App1 1002. The Localized App1 1002 and the AF 1020 may exchange information at 1022 on the application layer, for example, using any connectivity via Wireless Local Area Network (WLAN) or via a 3GPP access network. At 1024, the AF 1020 may determine to update the 5GC 410 with network selection data such as NSI-LS. The AF 1020 may determine to update application subscription to provide a list of networks (e.g., SNPNs or GINs), wherein each network entry is associated with a validity information. The AF 1020 may use an AF identifier, an external application identifier, an external group ID or a list of one or more individual external user IDs (e.g., Generic Public Subscription Identifier, (GPSI)) to identify the request towards the 5GC.

The LSP, which is a customer of the MNO, may act as an AF 1020 and may use the MNO’s Business Support System (BSS) 1018 API (e.g., BSS OpenAPI framework) to request the MNO to create/update/modify/delete the network selection data (also referred to as localized service information herein). For example, one possible update operation from the LSP to the MNO can be to send at 1026 a new or updated NSI-LS information as part of the localized service information update.

The BSS 1018 module/layer in the mobile network operator (MNO) is intended to offer to customers and business partners of the MNO a possibility to request a service or service related information. This BSS API provides a ReSTful (Representational State Transfer) web service interface. The BSS API supports four possible actions (Get, Put, Post, and Delete) on exposed resources and supports responses in either XML or JSON response formats. This API represents the set of business-related services exposed by the MNO’s portal manager that is responsible for the service exposure.

The BSS 1018 can then trigger the management system (referred as OAM 1014 system, but may also contain the OSS 1016) to update the corresponding the NF configuration. The Exposure Governance Management Function (EGMF) may be used to manage the service exposure towards the external customer, for example, the AF 1020 in the LSP domain. The EGMF may trigger the network manager to reconfigure the corresponding NF in the 5GC control plane. Such NF can be the SOR-AF 1012 or the UDR 1010 or the UDM 1008.

The management plane (OAM 1014 or OSS 1016 system) performs configuration in the SOR-AF 1012 by using a management interface towards the SOR-AF 1012. The management plane may send at 1028 a configuration request comprising the Localized service info for network selection (e.g., NSI-LS) and associated internal identifier for the information (e.g., internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID) to the SOR-AF 1012. Step 1028 may correspond to step 910 of Figures 9a and 9b.

At 1030, the SOR-AF 1012 may acknowledge processing of the NSI-LS by sending a response message. At 1032, BSS 1018 in the management plane may send a response message to the message sent at step 1026. The response message may indicate success or failure of providing the NSI-LS to the SOR-AF 1012.

At step 1034, the SOR-AF 1012 stores the NSI-LS data associated with the internal identifier (e.g., internal group ID, list of GPSIs, application ID or Service ID). The SOR- AF 1012 associates the stored NSI-LS with the internal identifier provided in step 1028. Step 1034 may correspond to step 915.

The SOR-AF 1012 uses the NSI-LS to create SOR data to be provisioned to UE(s) 1004 which are subscribed or use the localized service. The SOR-AF 1012 uses the internal service identifier (e.g., internal group ID, list of GPSIs, application ID or internal Service ID) as key to identify any request from a consumer NF which retrieves the SNPN-SI-VI data (SOR data).

At step 1036, the SOR-AF 1012 may trigger an update to UDM 1008 to indicate that the SOR data has changed for the associated Group/AF/Service ID. The SOR-AF 1012 may discover the one or more UDMs 1008 serving this Group/AF/Service ID by using NRF services. Step 1036 may correspond to step 920 and 925.

Discussing now alternative processes and starting with Process A as indicated in Figure 10, in embodiments relating to Process A the UDM 1008 triggers the SOR procedure. This embodiment corresponds to the embodiment described with regard to Figure 9a in steps 930, 935, and 940.

At step 1040, the UDM 1008 triggers the SOR procedure. For example, this may be due to a UE registration procedure and AMF registering with the UDM 1008.

At 1042, the UDM 1008 requests the SOR-AF 1012 to provide the SOR data. Step 1042 may correspond to step 930. For example, the UDM 1008 may use the Nsoraf_SoR_Get request including at least one of Subscription Permanent Identifier (SUPI) of the UE, current registered network ID (e.g., current PLMN ID) and internal identifiers (e.g., Group/AF/Service ID(s) associated with the UE’s subscription data.

The SOR-AF 1012 uses the internal identifier to create SOR container (e.g., SOR SNPN-SI-VI data) (corresponding to step 935) tailored for this particular UE with the internal identifiers. At step 1044, the SOR-AF 1012 sends to the UDM 1008 the SOR container which may be encrypted by using secure data as shown in Figure 3. Step 1044 may correspond to step 940. For example, the SOR-AF 1012 may use the service operation Nsoraf_SoR_Get response including the one of SUPI of the UE, the SOR container (e.g., SOR-SNPN-SI-VI).

At 1046, the UDM 1008 triggers UE parameter update (UPU) procedure to the UE 1004 for SOR SNPN-SI-VI, for example, as described in Figure 12 steps 1230 to 1238. Discussing now alternative Process B, in embodiments relating to Process B, the SOR- AF 1012 triggers the update to the UDM 1008 for the SOR procedure at step 1050. Process B may correspond to steps 945 to 955 of Figure 9b.

The SOR-AF 1012 may determine that an SOR update of the UE 1008 is needed (this may correspond to step 945). The SOR-AF 1012 may send at 1052 Nudm_ParameterProvision_Update request message comprising the UE’s SUPI (or alternatively any internal identifier like Group ID or Service ID), the SOR container comprising SNPN-SI-VI. Step 1052 may correspond to step 955.

At 1054, the UDM 1008 triggers UPU procedure to UE 1004 for SOR SNPN-SI-VI, for example, as described in Figure 12 steps 1230 to 1238.

The following applies to all Figures 5, 6, 7a, 7b, 7c, 8a, 8b, 8c, 8d, 9a, 9b, 10, and 11 . While in the following components of Figures 8a to 8d will be discussed, the same applies to corresponding components of Figures 7a, 7b, 7c and 10. Specifically, the UDM 804 may determine the UEs that are subscribed to use the (localized) service for which the NSI-LS has been provisioned. The UDM 804 may set an ‘update for SNPN- SI-VI’ flag in the determined UEs’ contexts wherein the ‘update for SNPN-SI-VI’ flag identifies that the corresponding UE should be updated with SOR information based on the stored NSI-LS information. The UDM may determine to set the ‘update for SNPN-SI-VI’ flag for a UE when the UDM receives an indication (e.g., as per steps 735, 830 or 1040) that either new NSI-LS information is provisioned, or existing NSI- LS information is updated, or existing NSI-LS information is deleted. If the UE is subscribed to multiple localized services, the UDM 804 may set/store either a single ‘update for SNPN-SI-VI’ flag for all localized services, or alternatively the UDM 804 may set/store an ‘update for SNPN-SI-VI’ flag for each subscribed localized service. After the UDM 804 has successfully performed the SOR procedure (e.g., as described in Figure 12) to a UE , for which the ‘update for SNPN-SI-VI’ flag has been set, the UDM 804 may delete or unset the ‘update for SNPN-SI-VI’ flag. The deletion or unsetting of the ‘update for SNPN-SI-VI’ flag means that the UE is not subject to SOR update for localized service (e.g. based on stored NSI-LS data in SOR-AF 802 or UDR 806 or UDM 804). When the NSI-LS information is updated (e.g. upon a new request form the LSP or AF 810), the UDM 804 should set again the ‘update for SNPN-SI-VI’ flag for SOR update towards the UE.

Upon at least one of the following events: a. when the NSI-LS information is deleted or removed from the 5GC 410 (e.g., upon a new request form the LSP or AF 810 to delete previously provisioned NSI-LS data), or b. the UE is not any longer subscribed with the localized service (i.e., the UE’s subscription data is update to remove the identifier of the corresponding localized service from the UE’s subscription data), the UDM 804 should set a flag to update the UE(s) by using SOR procedure. In such case, the UDM 804 should create new SOR data that should cause the deletion in the UE of the SNPN-SI-VI data corresponding to the removed NSI-LS (e.g., in case a.) or to the unsubscribed localized service (e.g., in case b.). In other words, the CH controlled list of preferred SNPNs/GINs with validity conditions (i.e., the network selection information which correspond to the localized service) should be removed from the UE configuration. After the UE, for which an ‘update for SNPN-SI-VI’ flag has been stored, is updated, the UDM 804 should delete or unset the ‘update for SNPN- SI-VI’ flag.

Turning now to Figures 11 and 12, embodiments described with regard to these Figures relate to a SOR procedure based on the procedure described in the Annex C “Control plane solution for steering of roaming in 5GS” in TS 23.122. The SOR procedure described with regard to Figures 11 and 12 is enhanced compared to the SOR procedure of TS 23.122. The enhancements mainly show how the UE provides its capability of handling the SNPN-SI-VI data type for SOR.

Firstly discussing Figure 11 , Figure 11 shows a method 1100 for a SOR procedure in accordance with one or more aspects of the present disclosure. Specifically, Figure 11 shows a method 1100 that provides for a SOR procedure that is enhanced to the SOR procedure of TS 23.122. The method 110 is performed by a UE such as UE 420. Specifically, the UE comprises one or more processors configured to execute computer-executable instructions to perform the method 1100 in a mobile telecommunications network. Details of the UE are described in Figure 14. The method comprises sending a message to an AMF. The message is a capability support message that comprises an indication that the UE supports a capability of processing SOR data for localized services.

In embodiments, the message sent at step 1 110 may be a registration message requesting registration of the UE in a mobile telecommunications network such as network 410. In other embodiments, the message sent at step 1110 may be an acknowledgement message sent in response to a message providing the SOR data such as the message received at step 1120.

At step 1120, the UE receives a SOR data message comprising SOR data for a localized service. The SOR data for the localized service in the message received at step 1120 comprises a network identifier and validity information. The network identifier identifies one or more networks offering access to the localized service. The validity information indicates at least one restriction for accessing the network. Specifically, as described above, the restriction of the validity information may comprise one or more of a time period when access to the network identified by the network identifier is allowed an a geographic area where the network identifier can be used to access the network. Optionally, the message received at step 1120 may additionally comprise a service identifier associated with the SOR data for the localized service.

At step 1140, the UE may perform, upon activation of the localized service in the UE, a network selection using the SOR data for the localized service.

In some embodiments, the UE may optionally store the SOR data for the localized service in a non-volatile memory of the UE and may perform the network selection of step 1140 at a power on cycle of the UE by using the SOR data for the localized service stored in the non-volatile memory.

Turning now to Figure 12, Figure 12 shows a flow diagram of a procedure for provisioning of SOR data in accordance with one or more aspects of the present disclosure. Specifically, Figure 12 gives the method described with regard to Figure 11 context within the architecture of Figure 4. In particular, Figure 12 shows signaling procedures between components of the architecture of Figure 4. Figure 12 shows details of the procedure for provisioning of SOR SNPN-SI-VI information, wherein the information is sent from a UDM (optionally received by the SOR-AF) to the UE.

Figure 12 shows a UE 1202 that may have installed an application (not shown). UE 1202 may be UE 420 of Figure 4. Additionally, Figure 11 shows an AMF 1204, a SOR- AF 1210, an UDM 1206, and an UDR 1208. AMF 1204 may be AMF 428 of Figure 4, SOR-AF 1210 may be SOR-AF 450 of Figure 4, UDM 1206 may be UDM 460 of Figure 4, and UDR 1208 may be UDR 470 of Figure 4.

The Figure 12 shows 2 alternatives how the UE 1202 provides its capability of handling the SNPN-SI-VI data to the network (e.g., UDM 1206):

1 ) The UE 1202 includes a new 5GMM capability to the AMF 1204 during a registration procedure. In detail, the UE 1202 sends a registration message requesting registration of the UE in a mobile telecommunications network at 1212. This message comprises an indication that the UE supports a capability of processing SOR data for localized services;

2) The UE 1202 includes the new SOR capability of SNPN-SI-VI in the SOR response message sent from the UE 1202 to the UDM 1206 via the AMF 1204, wherein the UE also indicates ‘success’ or ‘failure’ of the SOR SNPN-SI-VI provisioning. In detail, the IE 1202 sends an acknowledgement message at step 1234. This acknowledgement message may include an indication that the UE supports a capability of processing SOR data for localized services.

Discussing Figure 12 in more detail, Figure 12 shows a signaling flow for UE configuration with SOR comprising SNPN-SI-VI.

Firstly discussing Alternative A (Alt. A) shown in Figure 12, the UE 1202 sends at step 1212 a Registration request message to the AMF 1204 network for any type of registration (e.g., initial or mobility registration). If the UE supports the capability of receiving, storing or handling of SNPN selection information with validity information (SNPN-SI-VI), the UE includes in the Registration request message a 5GMM capability which includes indication for SNPN-SI-VI support. Step 1212 may correspond to step 1 110.

At step 1214, the AMF 1204 registers with the UDM 1206 as serving AMF 1204. For example, the AMF 1204 may send Nudm_UECM_Registration request message for the UE 1202.

At step 1216, the UDM 1206 replies to the AMF 1204. For example, the UDM 1206 sends Nudm UECM Registration response message to the AMF 1204.

At 1218, the AMF 1204 may request UE subscription data from the UDM 1206. If the UE 1202 has indicated support of SNPN-SI-VI in step 1212, the AMF 1204 sends in the Nudm_SDM_Get request message an indication for the UE’s support of SNPN-SI- VI. At step 1220, the UDM 1206 may determine to trigger SOR procedure towards the UE 1202 to update the UE configuration for selection of SNPNs for a Localized Service, based on at least one of the following conditions:

1 ) The UE 1202 has indicated support of SNPN-SI-VI; or

2) The UE 1202 is subscribed to a Localized service, for which there is stored network selection information, i.e. there is stored NSI-LS information for this Localized service. For example, the UDM 1206 may determine that the UE 1202 is subscribed for an application service identified by service identifier ID#1 and the UDM 1206 is also aware that there is stored NSI-LS information identified by the service identifier ID#1 . If the UDM 1206 is able to create the SOR information by itself, the UDM 1206 creates the SOR SNPN-SI-VI container data to be sent to the UE 1202. If the network selection data (e.g., NSI-LS) is stored in the UDR 1208, the UDM 1206 may retrieve the network selection data by using the localized service(s) identifier(s), for example, associated identifier like internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID. The UDR 1208 would then send to the UDM 1206 the list of networks which apply to this UE 1202 and to the subscribed Localized service(s).

If the UDM 1206 is locally configured that the SOR-AF services are used to create SOR information, the UDM 1206 requests the SOR-AF 1210 at step 1222 to create SOR information for the UE 1202. The UDM 1206 may send Nsoraf_SoR_Get request message including the UE’s SUPI, current registered network ID, and the localized service(s) identifier(s), for example, associated identifier like internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID, at 1222 to the SOR-AF 1210.

At 1224, the SOR-AF 1210 creates and sends to the UDM 1206 the SOR data container comprising the SOR-SNPN-SI-VI. For example, the SOR-AF 1210 sends Nsoraf_SoR_Get response message comprising the UE’s SUPI and the SOR-SNPN- SI-VI container at step 1224.

As to Alternative B (Alt. B):

If the SOR-AF 1210 stores Localized service information (e.g., NSI-LS) that is associated with internal identifier (e.g., like internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID), the SOR-AF 1210 may trigger at 1226 an update to the corresponding UDM(s) 1206 to update the SOR information in the corresponding UE(s) 1202. In an example, the SOR-AF 1210 may have received the NSI-LS with the associated internal identifier as described in the Figure 7a, 7b or 7c with regard to SOR-AF 708, in Figures 8a, 8b, 8c or 8d with regard to SOR-AF 802 or in Figure 10 with regard to SOR-AF 1012.

At 1228, the SOR-AF 1210 updates the UDM 1206 with the SOR information. For example, the SOR-AF 1210 may send Nudm_ParameterProvision__Update request message comprising the UE’s SUPI,or internal identifier for the localized service and the SOR container comprising SNPN-SI-VI. The internal identifier for the localized service can be one of internal group ID, Application Identifier, DNN/S-NSSAI, or internal service ID. The UDM 1206 may determine based on the internal identifier for the localized service which UE(s) 1202 needs to be updated with the SOR SNPN-SI- VI container. For example, the UE(s) 1202 which are subscribed with a localized service identified by the internal identifier are determined to be updated with the SOR SNPN-SI-VI.

The following steps apply to any of the Alternative A or Alternative B:

At 1230, the UDM 1206 transmits the SOR container to the AMF 1204 to be provided to the UE 1202. For example, the UDM 1206 may use one of:

1 ) If the Alternative A applies, the UDM 1206 can send Nudm_SDM_Get response message comprising the SOR SNPN-SI-VI; or

2) If the Alternative B applies, the UDM 1206 can send Nudm_SDM_Notification message comprising the SOR SNPN-SI-VI container.

At step 1232, the AMF 1204 transmits the received SOR container either in a Registration accept message or in Downlink NAS transport message to the UE 1202. Step 1232 may correspond to step 1120. In embodiments, the SOR container data may comprise the SNPN-SI-VI that is associated with a service ID. The service ID identifies the localized service. The UE’s local configuration in the upper layers may comprise the same service ID. When the user or the upper layers activate the localized service, the upper layers may provide to the UE 1202 (or UE’s modem which performs the network selection) the service ID.

At step 1234, if the UE 1202 receives the SOR container in Registration accept message, the UE 1202 may send Registration complete message containing the SOR transparent container including the UE acknowledgement and the UE shall set a "ME support of SOR SNPN-SI-VI" indicator. If the UE 1202 doesn’t support the SNPN-SI- VI, the UE 1202 would send a Non-Acknowledgement (or ‘failure’ indication) with the corresponding cause value indicating non-support of the received SNPN-SI-VI.

If the UE 1202 receives the SOR container in Downlink NAS transport message, the UE may send Uplink NAS message including SOR transparent container including the UE acknowledgement and the UE shall set the "ME support of SOR SNPN-SI-VI" indicator. This step may correspond to step 1110 in the case where the indication that the UE supports a capability of processing SOR data for a localized service is sent in an acknowledgment message.

At step 1236, the AMF 1204 forwards the received SOR transparent container to the UDM 1206. For example, the AMF 1204 may invoke Nudm_SDM_lnfo request service operation to provide the received SOR transparent container to the UDM 1206.

At step 1238, the UDM 1208 may invoke the Nsoraf_SoRJnfo service operation including the UE’s SUPI or internal identifier for the localized service, successful delivery, "ME support of SOR SNPN-SI-VI" indicator.

If the "ME support of SOR SNPN-SI-VI" indicator is stored for the UE 1202, the UDM shall include "ME support of SOR SNPN-SI-VI" indicator to the SOR-AF 1210.

At step 1240, at any time later, when the user or upper layers in the UE 1202 activates the use of the localized service, the UE 1202 may start network discovery by using the stored SNPN-SI-VI information. Step 1240 may correspond to step 1140

In addition, if the UE 1202 stores SNPN-SI-VI associated with a service ID and the user or upper layers in the UE 1202 has activated the localized service associated with the same service ID, the UE 1202 uses the SNPN-SI-VI associated with the same service ID as provided by the upper layers. This is also described in 1232 above. The UE or the upper layers may be locally configured with one or more localized services wherein each localized service is identified by a localized service ID. The localized service ID is used to map the request from the upper layers to the SNPN-SI-VI associated with the same service ID.

The advantages of the solution in the Figure 12 is that the UE 1202 is able to provide to the home network’s UDM 1206 its capability to support SOR SNPN-SI-VI. Furthermore, the home network’s UDM 1206 is able to provide the SOR SNPN-SI-VI to the UE 1202. By using this solution, the UE 1202 can be dynamically updated with the latest configuration for network selection to use the localized service.

Turning briefly to Figures 13 and 14, Figure 13 shows a mobile telecommunications network apparatus 1300 in accordance with one or more aspects of the present disclosure. Specifically, Figure 13 shows a mobile telecommunications network apparatus 1300 having one or more processors 1310, a storage 1330 and a memory 1320. The memory 1320 may have stored computer-executable instructions that, when executed by the one or more processors, cause the processor to perform one of the methods described with regard to Figures 5, 6a, 6b, 6c, 9a and 9b. The memory may have also stored computer-executable instructions for implementing any of the AMF, UDM, UDR, SOR-AF, NEF, OAM, OSS, and BSS described in this specification. The memory 1320 is coupled to the one or more processors 1310. The storage 1330 may also be coupled to the one or more processors 1310.

Figure 14 shows a user equipment 1400 in accordance with one or more aspects of the present disclosure. Specifically, Figure 14 shows a user equipment 1400 having one or more processors 1410, a storage 1430 and a memory 1420. The storage 1430 may be a non-volatile memory. The memory 1420 may have stored computerexecutable instructions that, when executed by the one or more processors, cause the one or more processors to perform the method described with regard to Figure 11 . The memory 1420 is coupled to the one or more processors 1410. The storage 1430 may also be coupled to the one or more processors 1410.

As described throughout this disclosure in detail, the embodiments described provide for an UE that:

• Supports new capabilities (e.g., new SOR data types) to receive, store and use SOR SNPN-SI-VI information; and

• Sends the new capabilities to the network (final destination is the UDM) by using one of the following options: o The UE includes the capability to support SOR SNPN-SI-VI in the 5GMM capability sent to the AMF in the Registration Request message; or o The UE includes the capability to support SOR SNPN-SI-VI in the acknowledgement message sent to the UDM as response to the SOR request.

The embodiments described also provide for a UDM that:

• Receives a request from a second network function (NF, e.g., from NEF) to authorize (process) a provisioning of network selection information (e.g., NSI-LS) data type, wherein the NSI-LS is associated with a service identifier (service ID, e.g., Group/AF/Service ID);

• Determines which target NF has to be used to store the NSI-LS data; and • Sets a flag for ‘SOR update’ in all UE contexts to which the NSI-LS applies, wherein the UDM uses the Service ID (e.g., Group/AF/Service ID) to figure out the UEs to be updated.

The embodiments described also provide for a NEF that:

• Identifies a new data type for network selection information (e.g., NSI-LS);

• Sends a request to the UDM to authorize (process) the further processing of the network selection information (e.g., NSI-LS);

• Receives one of: o a target network function (NF, e.g., UDR or SOR-AF), to which the network selection information (e.g., NSI-LS) is to be sent; or o an acknowledgement that the UDM has stored (or will store) the network selection information (e.g., NSI-LS), and therefore, the NEF can further send an acknowledgement to the AF (i.e. without sending the data to the UDR).

While the present disclosure has been described with respect to the physical embodiments constructed in accordance therewith, it will be apparent to those skilled in the art that various modifications, variations and improvements of the present disclsoure may be made in light of the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the disclosure. In addition, those areas in which it is believed that those of ordinary skill in the art are familiar, have not been described herein in order to not unnecessarily obscure the present disclosure described herein. Accordingly, it is to be understood that the present disclosure is not to be limited by the specific illustrative embodiments, but only by the scope of the appended claims.

Claims

1. An apparatus comprising a first network function, the apparatus further comprising: a processor; and a memory coupled to the processor, the memory comprising instructions executable by the processor to cause the first network function of the apparatus to: receive, from a second network function, a request to process network selection data, the network selection data identifying one or more networks offering access to a localized service, the request comprising an identifier for associating the localized service with the network selection data; in response to receiving the request, determine a third network function to store the network selection data; and enable the third network function to store the network selection data.

2. The apparatus of claim 1 , wherein, to enable the third network function to store the network selection data, the instructions are further executable by the processor to cause the first network function of the apparatus to: generate a response message comprising a target identifier associated with the third network function; and transmit the response message to the second network function, the response message indicating to the third network function to store the network selection data.

3. The apparatus of claim 2, wherein, to generate the response message, the instructions are further executable by the processor to cause the first network function of the apparatus to: map the identifier to an internal service identifier, the internal service identifier identifying the localized service; associate the internal service identifier with the network selection data; and include the internal service identifier in the response message.

4. The apparatus of claim 3, wherein, to transmit the response message, the instructions are further executable by the processor to cause the first network function of the apparatus to transmit the target identifier identifying the third network function being different from the first network function to cause the second network function to provide the third network function with the network selection data and with the internal service identifier and to enable the third network function to store the network selection data and the internal service identifier.

5. The apparatus of claim 3, wherein the instructions are further executable by the processor to cause the first network function of the apparatus to: determine, based on the internal service identifier, a user equipment (UE) to be updated; transmit a request for Steering of Roaming (SOR) data to the third network function; receive a container comprising the SOR data from the third network function in response to the request for SOR data; and transmit the container comprising the SOR data to an access and mobility management function (AMF) for forwarding to the UE.

6. The apparatus of claim 3, wherein the instructions are further executable by the processor to cause the first network function of the apparatus to: determine one or more user equipments (UEs) subscribed to the focalized service identified by the internal service identifier; and set, in a user context associated with each of the one or more UEs, a flag indicating the respective UE to be updated with Steering of Roaming (SOR) data.

7. The apparatus of claim 3, wherein the request to process network selection data comprises the network selection data, wherein the third network function is the first network function, and wherein the instructions are further executable by the processor to cause the first network function of the apparatus to: store the network selection data and the internal service identifier in the memory, wherein to transmit the response message comprising the target identifier identifying the first network function as the third network function causes the second network function to acknowledge success, to an application function, of storage of the network selection data.

8. The apparatus of claim 3, wherein the request to process network selection data further comprises an identifier indicating a data type, the data type being one of a focalized service data type, a network selection data type and a data type specific for data identifying one or more networks offering access to a focalized service, wherein the third network function is the first network function, and wherein the instructions are further executable by the processor to cause the first network function of the apparatus to: send a request for the network selection data to the second network function; receive, in response to the request, the network selection data from the second network function; and store the network selection data and the internal service identifier in a storage, wherein sending the response message comprising the target identifier identifying the first network function as the third network function causes the second network function to acknowledge success, to an application function, of storage of the network selection data.

9. The apparatus of claim 3, wherein the instructions are further executable by the processor to cause the first network function of the apparatus to: determine, based on the internal service identifier, a user equipment (UE) to be updated; generate Steering of Roaming (SOR) data based on the network selection data; and transmit a container comprising the SOR data to an access and mobility management function (AMF) for forwarding the container to the UE.

10. The apparatus of claim 1 , wherein the request to process network selection data comprises the network selection data, and wherein , to enable the third network function to store the network selection data, the instructions are further executable by the processor to cause the first network function of the apparatus to: map the identifier to a service identifier, the service identifier identifying the localized service; associate the service identifier with the network selection data; generate, based on the third network function being different from the first network function, a message comprising the network selection data and the service identifier; transmit the message comprising the network selection data and the service identifier to the third network function to initiate a storage process of the network selection data and the service identifier associated with the network selection data by the third network function; and store, if the third network function is the first network function, the network selection data and the service identifier in a storage of the mobile telecommunications network apparatus.

1 1 . The apparatus of claim 1 , wherein the first network function is a Unified Data Management (UDM) network function, wherein the second network function is a Network Exposure Function (NEF), and wherein the third network function is selected from a group of network functions comprising the UDM network function, a Unified Data Repository (UDR) network function and a Steering of Roaming Application Function (SOR-AF).

12. The apparatus of claim 1 , wherein the network selection data comprises a list of the one or more networks offering access to the localized service, each entry of the list comprising a network identifier and validity information, and wherein the validity information is at least one of time validity information indicating at least one time period when access to the network identified by the network identifier is allowed and location validity information indicating at least one geographic area where the network identifier can be used to access the network for the localized service.

13. A user equipment (UE) comprising a processor and a memory coupled to the processor, the memory comprising instructions executable by the processor to cause the UE to perform a Steering of Roaming (SOR) method in a mobile telecommunications network, wherein the SOR method comprises sending, to an access and mobility management function (AMF) a capability support indication message comprising an indication that the UE supports a capability of processing SOR data for a localized service, wherein the SOR method further comprises receiving, from the AMF, a SOR data message comprising SOR data for a localized service, the SOR data for the localized service comprising a network identifier and validity information, the network identifier identifying a network offering access to the localized service, and the validity information indicating at least one restriction for accessing the network, and wherein the UE is configured to perform, upon activation of the localized service in the UE, a network selection using the SOR data for the localized service.

14. The UE of claim 13, wherein the SOR data message further comprises a service identifier associated with the SOR data for the localized service.

15. The UE of claim 13, wherein the capability support indication message sent to the AMF is one of a registration message requesting registration of the UE in the mobile telecommunications network and an acknowledgment message sent in response to the SOR data message.

16. The UE of claim 13, wherein the SOR method further comprises: storing the SOR data for the localized service in a non-volatile memory of the

UE, wherein the network selection is performed during a power on cycle of the UE by using the stored SOR data.

17. The UE of claim 13, wherein the at least one restriction comprises at least one of a time period when access to the network identified by the network identifier is allowed and a geographic area where the network identifier can be used to access the network.

18. An apparatus comprising a Steering of Roaming (SOR) application function, the apparatus further comprising: a processor; and a memory coupled to the processor, the memory comprising instructions executable by the processor to cause the SOR application function of the apparatus to: receive, from a module in a management plane of the mobile telecommunications network, a request to configure the SOR application function, the request comprising network selection data identifying one or more networks offering access to a localized service and a service identifier associated with the network selection data, the service identifier identifying the localized service; in response to receiving the request, store the network selection data and the service identifier in the storage; discover a Unified Data Management (UDM) network function serving the localized service identified by the service identifier; and inform the discovered UDM network function that the network selection data associated with the service identifier has been received.

19. The apparatus of claim 18, the instructions executable by the processor further causing the SOR application function of the apparatus to: receive, from the UDM network function, a request to provide SOR data, the request to provide SOR data comprising the service identifier; in response to receiving the request to provide SOR data, generate the SOR data based on the network selection data associated with the service identifier; and transmit a container comprising the SOR data to the UDM network function.

20. The apparatus of claim 18, the instructions executable by the processor further causing the SOR application function of the apparatus to: determine to update a user equipment (UE) with SOR data; generate the SOR data based on the network selection data; and transmit a request to the UDM network function comprising an identifier identifying the UE and a container comprising the SOR data, wherein the request causes the UDM network function to update the UE with the SOR data.