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.

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.

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.

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

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.

[PR 5.1.6-001]

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.

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.

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.

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.

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

[PR 5.2.6-001]

• 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.

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.

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.

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

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.

[PR 5.3.6-001]