New Proposal - Steering of Roaming Management #24
Comments
joydeepb2
changed the title
|
Hello @joydeepb2 please you need to follow the following steps:
|
|
Hello @TEF-RicardoSerr |
|
You can fork the |
|
Added the PR - kindly check. |
|
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) |
|
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.
|
|
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:
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:
|
|
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. |
|
What is the next step for this pull request? Kindly suggest. |
|
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 4th Thursdays at 15:00 CE(S)T / 13:00 UTC / 06:00 PT Upcomming meeting is May 23rd at 3pm CE(S)T (Madrid, Paris, Berlin, Rome) |
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:
Some typical examples where Telco reseller or MVNO will benefit are:
The text was updated successfully, but these errors were encountered: