User Story

General information
- - - - - - - - - - -

With mobile phones, there is a possibility to roam (see roaming definition here: https://en.wikipedia.org/wiki/Roaming) and hence call from any country in the world (even with multiple carriers in each country). It is possible to call any destination in the world. This many-to-many situation results in a rating and billing nightmare. Thus correct billing would need hundreds of tariffs each with thousands of destinations, which is obviously not very manageable. 

As a work-around to the many-to-many problem, a mobile carrier might group the world into zones, and based on these zones make a few hundred manageable "average" rates. The mobile carrier will then pre-process the CDRs by running the raw CDRs through a zone grouping algorithm, producing grouped CDRs ready for rating. 

As a result, CDRs from a mobile carrier might include "roaming" CDRs which is produced by a call when the mobile user is roaming, and if these CDRs are pre-processed they may include zone grouping and roaming information.

Customer situationnumbers
- - - - - - - - - -
The customer actively uses CDR Importer functionality. They import different types of CDRs, one of them is CDRs from a mobile carrier. This mobile carrier do pre-process CDRs and include zone grouping and roaming information in the CDRs. To simplify the CDR format, the mobile carrier always include the country code of the calling and called numbers in the CDRs. These country codes will always match the country of the calling and called numbers except in case of a roaming CDR. In case of a roaming CDR the called country code or calling country code will represent the country where a roaming call/message was made/sent from or received in. 

Such CDRs are charged in PortaBilling system by special "PortaBilling_RatePattern" which is generated by the CDR Importer based on the zone grouping information. 

As the CDRs the customer receives utilize rating based on zones, this will to an extent make it impossible for the end user to check and validate the rating done. In other words, end user needs a visual identifier clearly stating that call was placed or received while he was roaming.

In order to validate such CDRs on the web interface and in the Invoices some more information is needed. To be more specific, roaming information is needed together with CLI and CLD information

The calling (CLI) and called (CLD) numbers are present in the received CDRs. As a workaround to enable validation of CDRs, the country codes present in the CDRs are added to the CLI and CLD (example: CLD '4756320324 (47)'; CLI 4748100403 (380)) before these are propagated by the CDR Importer to PortaBilling.

With this information the end customer can correctly identify the calls/messages/internet sessions and see why they have been billed the way they have. Without displaying this information two 'identical' records (same CLI, CLD, duration, time of day and volume discount) might be rated differently, because the usage happened in different zones while roaming.

As the addition of the country code information to CLD and CLI breaks billing logic and requires the usage of the custom patch that hacks RADIUS, another way of storing roaming information (e.g. country code) is required.

Use Cases

Use case #1: Roaming CDR of the outgoing call

Roles: End-user, Operator

Preconditions: 

Customer ABC with mobile number 4748100403 was in Ukraine (country code 380) in March and made a call to 4756320324 number.

When he came back to Norway he made a call to the same number 4756320324.

All calls were imported by xDR importer and file for import had special header with country code (380)

Scenario #1.1: Roaming identification in the CDR browser

• Customer ABC receives a monthly invoice for March with the total amount of USD 300.

• Customer thinks it is too expensive so he decides to talk to operator. Customer calls Customer Care and asks why the sum in the invoice is so big.

• Customer care representative checks customer's ABC CDRs for March and sees the CDR with the following details:

• From: 4748100403

• Roaming: 380

• To: 4756320324

• Duration: 01:10:00

• Amount: USD 90

• Customer Care representative explains that this is roaming CDR and customer understands that the user with 4748100403 account was in Ukraine and made an international call to a Norwegian number. That's why it was so expensive.

Scenario #1.2: Roaming identification in the Invoice

• Customer ABC receives a monthly invoice for March with the total amount of USD 300.

• Customer thinks it is too expensive, but before talking to operator he decides to see detailed information about calls.

• Customer sees in the invoice:

• From: 4748100403

• Roaming: 380

• To: 4756320324

• Duration: 01:10:00

• Amount: USD 90

• Customer ABC understands that the user with 4748100403 account was in Ukraine and made an international call to a Norwegian number, thus the roaming was utilized. That's why the call was so expensive.

• From: 4748100403; 

• To: 4756320324

• Duration: 01:10:00

• Amount: USD 1

• Customer ABC sees that the user with 4748100403 account came back and made a call to the same number. The call was charged as usual.

Roles: End-user, Operator

Preconditions: 

Customer ABC with mobile number 4748100403 was in Ukraine  (country code 380) in March. He received incoming call from 4756320324 number.

When he came back to Norway he received incoming call from 4756320324 number.

All calls were imported by xDR importer and file for import had special header with country code (380)

Scenario #2.1: Roaming identification in the CDR browser

• Customer ABC receives a monthly invoice for March with the total amount of USD 300.

• Customer thinks it is too expensive so he decides to talk to operator. Customer calls Customer Care and asks why the sum in the invoice is so big.

• Customer care representative checks customer's ABC CDRs for March and sees the CDR with the following details:

• From: 4756320324  

• To:  4748100403

• Roaming: 380

• Duration: 01:10:00

• Amount: USD 90

• Customer Care representative explains that this is roaming CDR and customer understands that the user with 4748100403 accountwas in Ukraine and received a call, thus roaming was utilized. That's why it was so expensive.

Scenario #2.2: Roaming identification in the Invoice

• Customer ABC receives a monthly invoice for March with the total amount of USD 300.

• Customer thinks it is too expensive, but before talking to operator he decides to see detailed information about calls.

• Customer sees in the invoice:

• From: 4756320324

• To:  4748100403

• Roaming: 380

• Duration: 01:10:00

• Amount: USD 90

• Customer ABC understands that the user with 4748100403 account was in Ukraine and received a call, thus roaming was utilized. That's why it was so expensive

• From: 4756320324

• To: 4748100403;

• Duration: 01:10:00

• Amount: USD 0

• Customer ABC understands that the user with 4748100403 account came back from Ukraine and received a call. 

Other requirements / constraints

1) If it is not possible to dynamically show the country code information as a key to roaming, only in case of roaming calls (when all the CDRs contain country code information), the removal of the Country Code for non-roaming CDRs can be made on the CDR importer side. So only the roaming CDRs will contain Country Code that  should be displayed in the Invoices/CDRs and Customer Self-Care.

2) As with other phone calls, it is not relevant where the other end of the call physically might be.
If a mobile user receives a call, the cost will be based on where the mobile user physically is.
If a mobile user places a call, the cost will be based both on where the mobile user physically is and also the number of the called party.
In other words, if a user calls a mobile user the caller's cost for the call will not be dependent on the location of the destination phone.
If a mobile user is roaming, receiving a call will cost more but the user placing the call will not notice this.

Prefix holding header for roaming: We'll keep it simple - we'll name it just "Roaming". Note that in our case this field will contain the country code of the country where the roaming call/message took place. This is not necessarily so in all other cases. This could just as well be information about the carrier that was used. Imagine a large country with several carriers each having partial coverage. An end user might be allowed to 'roam' between carriers, but the country code would always be the same. Hence this would be of no value for the end user if carriers charge differently. CDRs would have to include carrier information to enable validation. The title 'Roaming' does not limit the content to a country code and it does sufficiently indicate that the information is related to roaming. If you insist on a more detail description, then we suggest 'Roaming code' or 'Roaming info(rmation)'.