New Proposal - Steering of Roaming Management

[joydeepb2]

The API can be used to control the distribution of outbound roaming traffic to different visited networks (VPLMN) from the home network (HPLMN) according to a certain steering policy. Typically, this can be used by mobile operators themselves to manage steering of roaming operations from a remote location through internet. The same can be used by their reselling partners who lack sufficient expertise in directly working with steering of roaming system.

Some typical examples where mobile operators find it useful are:

• to drive outbound roamers to a specific visited network to meet certain provisions in Inter Operator Tariff (IOT) discount agreements set according to GSMA RAEX/AA.14 between HPLMN and different VPLMNs at a certain roaming location.
• to drive outbound roamers away from the VPLMN across locations with who HPLMN is getting into a roaming dispute.

Some typical examples where Telco reseller or MVNO will benefit are:

• to drive their outbound roaming subscribers to a specific visited network to meet certain quality of service issues reported from a specific VPLMN.
• to drive their outbound roaming subscribers to a visited network to enjoy some premium services sponsored by the reseller or MVNO (e.g., MVNO has tied up with a licensed content provider who, in turn, has content sharing and distribution agreement with VPLMN A in country X. MVNO will try to make all its outbound roaming subscribers to country X to latch on to VPLMN A's network as long as it is within coverage) .

[TEF-RicardoSerr]

Hello @joydeepb2 please you need to follow the following steps:

1. Fill this API Backlog Template in Markdown format with your API proposal

2. Make a Pull Request to this API Proposals Path with the filled template.

3. If there is a YAML available (recommended but not mandatory) you can make a Pull Request to this Supporting Documents Path and then reference the link in the Template. It is nice to have the YAML file compliance with the design guidelines from the Commonalities working group but this is not mandatory at this stage (it is mandatory when making a release of the API, but this can be done once the subgroup is opened)

[joydeepb2]

Hello @TEF-RicardoSerr
Please share the branch info where I can have the permission to create the PR.

[TEF-RicardoSerr]

You can fork the main branch of the repo and PR from your own forked repo to camaraproject/WorkingGroups:main

[joydeepb2]

Added the PR - kindly check.

[hdamker]

Looking on the proposal my initial thoughts are

a) that it is most probably not within the scope of the CAMARA Project (as it is a Telco ecosystem internal API, not a northbound service API)
b) the service definition and maybe also the API definition should be done within GSMA and its respective working groups (e.g. for roaming), at least to ensure the support from MNOs

[joydeepb2]

The API family is for a set of APIs meant for different stakeholders. Some are meant for Telco and their partners (MNO/MVNO/resellers), but some others are for non-telco business entities like enterprises (telco subscribers) and individual retail subscribers. Service endpoints will differ in this case. In the context of CAMARA project, we are trying to address the latter use case because these will not be handled by either GSMA or 3GPP.
Enterprises and retail subscribers will use the API at a level of granularity that is never done by MNO or any of its partners. For example, direct mapping from IMSI to VPLMN id and RAT is never done by MNO/MVNO. Only these type of service endpoints will be covered in the YAML file.
Probably we can suitably amend the API family description (mainly the examples cited) to take out Telco centric use cases. Please suggest.
Moreover, according to GSMA Open Gateway API initiative (https://www.gsma.com/solutions-and-impact/gsma-open-gateway/gsma-open-gateway-frequently-asked-questions/) they seem to be contributing to CAMARA as well. So according to GSMA's own submission their contribution to CAMARA API very well covers east-west relation apart from vertical business relation. Excerpts below:
"Those who will benefit from the initiative include:

• Application developers / content and gaming developers / software developers (i.e., the mobile industry’s direct and indirect customers)
• Regulators
• Enterprise customers
• The telecom industry – other operators and suppliers
• End customers / consumers."

[hdamker]

Hi @joydeepb2, you are right that the GSMA Open Gateway (OGW) API initiative has as beneficiary the telecom industry, and CAMARA is an important part(ner) in this initiative. But there is also clear scope split between GSMA OGW and CAMARA which you can find within the Project Charter of CAMARA:

From a functional perspective the scope is limited to telco APIs, that means APIs in the domain of telco mobile networks, telco fixed line networks, telco edge cloud, etc. or supporting these (e.g. for authentication). CAMARA only works on customer-facing northbound APIs. East-west federation / roaming APIs are out of scope for CAMARA.

GSMA Open Gateway is contributing towards CAMARA in the form of API proposals which were discussed and prioritised within the Open Gateway Product team from a product perspective. It might make sense to bring the proposal first there, as you eventually need MNOs who are willing to offer the service as a product. But it is also possible to contribute it directly here, but then it would be good to have also already network operators as supporters. Otherwise there is the risk that you spent the time to define an API but it won't be implemented.

For your proposal I have two further recommendations:

• Indeed focus on northbound, customer-facing API and its use cases. The current proposal would be from my perspective completely within the scope of GSMA (most probably not even OGW)
• Try to describe the proposal in a way that it is possible to understand the proposal also without deep telco network knowledge, so that potential customers can understand the benefits. Some abbreviations will be unavoidable but as a general principle we try to avoid them.

[joydeepb2]

GSMA Open Gateway (OGW) could have been a good way to start the initiative. However, we must also note that the underlying backend support for these APIs are already standardized in various 5G SA Technical Specifications and MNOs should implement that in the 5G core to be fully complaint with the specification. 3GPP TS 29.550 V18.1.0 (2023-06) deals specifically with characterization of SOR-AF Nsoraf Service based interface while 3GPP TS 23.122 V18.4.0 (2023-09) deals with call flow details and overall sequence of events (see Annex C 1.1.C2, C3, C4 etc.). So, MNO support should come in automatically for the application and related API.

While a part of the API family is specific to (or typical for) Telco business partners, a large part of it is in retail business domain. It has some APIs which can help a northbound application directly select appropriate visited network for a UE under home network supervision. This will give the roaming user a unique ability to exercise more control in terms of visited network selection and better visibility. Today, when an user activates international roaming for his SIM, only thing he gets is a promised set of services (e.g., certain minutes of call, certain number of SMSs, a few Gb of data etc. during a certain period) along with an obligation to purchase such service package upfront in terms of International Roaming Pack (IRP) offered by the home network operator. So, only remedy he will have in the event of roaming activation behaving unexpectedly is to call up customer care of the home network operator while roaming abroad and try to rectify the issue. This is a very tedious process with low success rate and almost next to impossible in most cases. Roaming user will not be in a position to know if the roaming activation is done correctly for his UE until and unless he himself is actually roaming abroad and tries to register in the visited network. This automatically leads to a situation where the roaming user has paid fully for the IRP but denied of the underlying services while roaming. This affects customer experience severely which impacts not only the Telco roaming business but also the domestic market because retail subscribers normally do not have sufficient understanding between the different mechanism between domestic and roaming service activation.

It should also be noted that, present day PLMN selection mechanisms based on Automatic and Manual mode have their own drawbacks. Manual mode selection depends on the list of available networks at the visited location. Because it may happen that some of these available visited networks not having active roaming agreements with the roaming user's home network operator, user registration to these networks would fail and, in all probability, the visited network will be placed in the forbidden PLMNN list of the SIM of the roaming user. Roaming user will be forced to spend inordinate amount of time in doing a trial and error by sending registration to each of these available visited networks one by one and wait till either the list ends or he is able to get one for the time being which accepts his registration. In automatic mode, roaming user gets a prioritized list of preferred visited networks from the home network operator, but the moment a particular visited network indicates not to allow roaming, it finds its place in forbidden PLMN list inside roaming user's SIM.

The application has been planned to remove these obstacles by giving a proper control and visibility to the roaming user on the mapping between his UE's SIM (in terms of IMSI) and the visited network which have been "approved" by the home operator. For example, through the API access the roaming user will know if the roaming has been technically approved by the home operator for a specific destination for his UE and SIM. The application and the API invocation will automatically check the required service information for the roaming subscriber with the home network (e.g., whether the phone being used is lost or stolen through IMEI blacklist, and whether the mobile device is authorized for international use). Once this is done, it checks the visited network by searching through the home operator's roaming agreement database for the destination (more specifically RAEX/AA.14) to ensure that the roaming user considers only such networks with which home network has roaming agreement. It then offers a subset of such visited networks to the roaming user for registration in a "preferred order". Roaming user can exercise the option to select the "preferred" visited network(s) through the portal (which he can access through Wi-Fi unless he can latch into some visited network, and this will typically be a one-time activity). Now, once he puts his UE in automatic selection mode, it latches into the preferred network (in the same order already set using API) with guaranteed roaming entitlement because most of the factors that can possibly bar roaming were already pre-verified by the northbound API and application.

The entire process will immensely benefit the retail users who struggle to get their roaming connectivity issues fixed in foreign country through a self-service option. It will also help Telcos (MNO/MVNO) through lower customer care tickets and better customer experience.

[joydeepb2]

What is the next step for this pull request? Kindly suggest.

[TEF-RicardoSerr]

Hello @joydeepb2 we need you to connect to the API Backlog meetings were this is being discussed:

Meeting Cadence:

2nd Thursdays at 10:00 CE(S)T / 08:00 UTC / 01:00 PT

• Meeting Registration / Join

4th Thursdays at 15:00 CE(S)T / 13:00 UTC / 06:00 PT

• Meeting Registration / Join

Upcomming meeting is May 23rd at 3pm CE(S)T (Madrid, Paris, Berlin, Rome)