Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

TR 22.877
Study on Roaming Value Added Services

V19.0.0 (Wzip)2022/12  12 p.
Rapporteur:
Mr. Bleckert, Peter
Ericsson LM

Content for  TR 22.877  Word version:  19.0.0

Here   Top

1  Scopep. 6

The present document describes use cases related to the following three Roaming Value-Added Services (RVAS) that are enabled by the PLMN for 5GS roaming:
  • Welcome SMS
  • Steering of Roaming (SoR) during the registration procedure
  • Subscription-based routing to a particular core network (e.g., in a different country)
Potential requirements are derived for these three services and consolidated in a dedicated chapter. The report ends with recommendation regarding the continuation of the work.
Up

2  Referencesp. 6

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 33.501: "Security architecture and procedures for 5G System"
[3]
TR 22.003: "Circuit Teleservices supported by a Public Land Mobile Network (PLMN)".
[4]
TS 22.011: "Service Accessibility".
Up

3  Definitions of terms, symbols and abbreviationsp. 6

3.1  Termsp. 6

For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

3.2  Abbreviationsp. 6

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
RVAS
Roaming Value-Added Services

4  Overviewp. 7

Roaming Value-Added Services (RVAS) form part of the roaming services ecosystem and have traditionally been provided by either the PLMN or outsourced to a fully trusted entity. The RVAS provider acting on behalf of the PLMN could be any trusted 3rd party. The focus of this work is on RVAS enabled by the PLMN for 5GS roaming.
With the introduction of e2e encryption for roaming in 5GS [2], it is in some cases not possible for the trusted entities to provide RVAS in a proprietary way and they therefore need to be standardized in order to work in a multi-vendor environment.
This report describes the following three RVAS that are enabled by the PLMN for 5GS roaming:
  • Welcome SMS
  • Steering of Roaming (SoR) during the registration procedure
  • Subscription-based routing to a particular core network (e.g. in a different country)
Up

5  Use casesp. 7

5.1  Use case on welcome SMSp. 7

5.1.1  Descriptionp. 7

A welcome SMS is a SMS sent to a roaming subscriber's UE when the UE is registered in a new network for the first time. The SMS typically follows a predefined template and is sent on behalf of the home operator and may contain relevant information related to the visited country e.g., the cost to call home, how to reach the operator's customer service etc.
The use case describes how the home operator identifies that a user is registered in a new network and trigger sending a welcome SMS to the UE. The formatting and sending of the welcome SMS are done by an application server in the same way as many other SMS applications and is not described further in the use case.
Up

5.1.2  Pre-conditionsp. 7

A user X has a subscription with operator MNO1.
User X is going to a country for trip and brings the phone.
One of the operators in the country is MNO2.

5.1.3  Service Flowsp. 7

User X arrives to the countries capital airport and turns off airplane mode on the UE at arrival.
The UE register to MNO2's network.
MNO2 forwards the registration to user X's HPLMN (i.e., MNO1).
MNO1 identifies that User X is registered in a new network and initiates a welcome SMS using a northbound API including the information about MNO2's network and the needed subscriber information.
Either the HPLMN or a trusted 3rd party will trigger a welcome SMS to user X's UE.

5.1.4  Post-conditionsp. 7

Shortly an SMS is delivered to the UE with a welcome SMS containing useful information related to the new country.

5.1.5  Existing features partly or fully covering the use case functionalityp. 8

The functionality to send MT SMS to the UE is "old as a rock" and is defined in a normative annex in TS 22.003.

5.1.6  Potential New Requirements needed to support the use casep. 8

[PR 5.1.6-001]
The 5G system shall be able to support mechanisms for the HPLMN to provide a notification, including equipment and subscription identifiers, to a trusted application server when a UE successfully registers in a VPLMN. In response to the notification, the trusted application server can indicate specific actions to the HPLMN (e.g., send an SMS to the UE).

5.2  Use case on Steering of Roaming (SoR) during the registration procedurep. 8

5.2.1  Descriptionp. 8

HPLMNs can steer their subscribers to preferred partner networks in case of roaming by means of issuing commands and updating the Operator Controlled PLMN Selector list on the USIM, either by using SMS or via signalling, as defined in TS 22.011.
Additionally, for more short-term balancing of distribution across VPLMNs, operators use mechanisms to reject registration attempts from some share of UEs to certain VPLMNs to make them select a different VPLMN.
Both mechanisms - SoR as defined in 3GPP and the here described SoR during the registration procedure - can be applied in parallel by a HPLMN.
This use case describes how the home operator identifies that a roaming user attempts to register in a new network and triggers the sending of reject messages to the UE, resulting in the UE attempting to register to another VPLMN. The details of how often a reject is sent to a particular UE to achieve the desired result and to prevent the UE from being without a network, are left to the application server and not described here.
Up

5.2.2  Pre-conditionsp. 8

Users X and Y have a subscription with operator HPLMN1.
Both users X and Y are travelling to another country, where two networks are available - VPLMN1 and VPLMN2. Both networks have a roaming agreement with HPLMN1.
VPLMN1 has a higher priority for both users.

5.2.3  Service Flowsp. 8

Users X and Y arrive at the country and switch on their phones. According to existing procedures both UEs select VPLMN1 as their first choice for registration and try to register on that network.
VPLMN1 forwards the registration request messages of the UEs of users X and Y to the HPLMN1.
HPLMN1 recognises the registration attempts and invokes the steering service via a northbound API. The steering service, hosted by the HPLMN or some trusted 3rd party, decides if some steering action is needed for any of the UEs.
In this use case it decides to allow the UE of user X to register on VPLMN1 whereas user Y's UE should not use VPLMN1.
The steering service triggers the steering action using the northbound API for user Y's UE, which results in a reject message being sent to this UE, including an appropriate reason for the rejection. The registration process for user X's UE is not affected.
Up

5.2.4  Post-conditionsp. 9

While the UE of user X successfully registered to VPLMN1 the UE of user Y selects VPLMN2 as the only other available network and registers there.
If more than one remaining VPLMN is available, the UE picks one of them according to network selection procedures. The process of rejecting could be repeated as needed.

5.2.5  Existing features partly or fully covering the use case functionalityp. 9

Registration to networks and rejecting registration attempts with different information corresponding to the reason for rejection, causing the UE to search for other networks.

5.2.6  Potential New Requirements needed to support the use casep. 9

[PR 5.2.6-001]
The 5G system shall be able to support mechanisms enabling the HPLMN to:
  • provide a notification, including subscription and equipment identifiers, to a trusted application server when a UE tries to register in a VPLMN
  • receive a notification reply from the trusted application server indicating specific actions to the HPLMN e.g., reject UE registration (with a specific cause), trigger a SoR command.
Up

5.3  Use case on Subscription-based routing to a particular core networkp. 9

5.3.1  Descriptionp. 9

Some operators use more than one PLMN ID, e.g., multi-national operators. Due to certain business and operational demands, it might be necessary to route signalling traffic of a certain customer segment, typically from a certain IMSI range of USIMs, of a PLMN to another PLMN and to further handle the subscriber there. This means the signalling is not handled by the "real" HPLMN (according to MNC and MCC) but by some alternative PLMN.
This e.g. enables the case where several national subsidiaries of a multi-national operator offer various services for different customer segments but for operational efficiency the actual service for a certain group is provided by only one dedicated network.
This mechanism is not visible for the UE and it therefore do not need any additional features to support this RVAS.
Up

5.3.2  Pre-conditionsp. 9

Subscriptions a, b, c and d are with operator MNO1.
Subscriptions b and c are part of a certain customer segment X and this information is part of the subscription.
MNO1 has an agreement with MNO2 that MNO2 shall handle the signalling of subscriptions of all UEs belonging to the customer segment X. For this purpose, there is a connection between the networks of MNO1 and MNO2.

5.3.3  Service Flowsp. 9

5.3.3.1  Non roaming casep. 9

The UEs of subscribers a, b, c and d attach to the PLMN of MNO1.
The network recognizes subscriptions b and c to be part of customer segment X and forwards the signalling to the PLMN of MNO2 via the pre-established connection.
Subscriptions a and d are not affected.
Later, subscription c is removed from customer segment X by customer care. This results in removal of the corresponding information in the subscription. From now on signalling related to subscription c will be handled by the network of MNO1 again.
Further on, subscription a is added to the customer segment X by customer care and subscription data are updated accordingly. So, signalling related to subscription a will be handled by the network of MNO2.
The UEs of subscribers c and a are not aware of these updates.
Up

5.3.3.2  Roaming casep. 10

Subscribers a, b, c and d attach to a VPLMN. The corresponding signalling is routed to their HPLMN (network of MNO1).
The further procedure is the same as in the non-roaming case: The HPLMN recognizes subscriptions b and c to be part of customer group X and forwards the signalling to the PLMN of MNO2 via the pre-established connection.

5.3.4  Post-conditionsp. 10

Subscriptions of customer group X are handled by the network of MNO2, all other subscriptions by the regular HPLMN MNO1.

5.3.5  Existing features partly or fully covering the use case functionalityp. 10

Subscriptions can contain a routing indicator which might be re-used for assigning a subscription to a certain customer group which requires routing to a different network.

5.3.6  Potential New Requirements needed to support the use casep. 10

[PR 5.3.6-001]
The 5G system shall be able to support a mechanism for forwarding signalling traffic pertaining to UEs of specific subscribers from their HPLMN to a target PLMN, e.g., to enable further handling of those UEs by the target PLMN. The forwarding mechanism shall minimize signalling traffic in the HPLMN, e.g., by using efficient means to forward traffic from selected UEs.
Up

6  Consolidated potential requirementsp. 11

CPR # Consolidated Potential Requirement Original PR # Comment
CPR 6-001 The 5G system shall be able to support mechanisms for the HPLMN to provide a notification, including equipment and subscription identifiers, to a trusted application server when a UE successfully registers in a VPLMN. In response to the notification, the trusted application server can indicate specific actions to the HPLMN (e.g., send an SMS to the UE). PR 5.1.6-001
CPR 6-002 The 5G system shall be able to support mechanisms enabling the HPLMN to:
  • provide a notification, including subscription and equipment identifiers, to a trusted application server when a UE tries to register in a VPLMN
  • receive a notification reply from the trusted application server indicating specific actions to the HPLMN e.g., reject UE registration (with a specific cause), trigger a SoR command.
PR 5.2.6-001
CPR 6-003 The 5G system shall be able to support a mechanism for forwarding signalling traffic pertaining to UEs of specific subscribers from their HPLMN to a target PLMN, e.g., to enable further handling of those UEs by the target PLMN. The forwarding mechanism shall minimize signalling traffic in the HPLMN, e.g., by using efficient means to forward traffic from selected UEs. PR 5.3.6-001
Up

7  Conclusion and recommendationsp. 12

This technical report provides use cases and potential new requirements for the three RVAS:
  • Welcome SMS
  • Steering of Roaming (SoR) during the registration procedure
  • Subscription-based routing to a particular core network (e.g., in a different country)
The resulting service requirements have been consolidated and can be found in clause 6.
It is recommended to consider the consolidated requirements identified in this TR as the baseline for subsequent normative work.
Up

$  Change historyp. 12


Up   Top