Reviewers (PMD-2773):

User Story

In order to reduce daily operational costs, CSP wants to integrate PortaBilling with WTL mobile core to automate provisioning tasks, such as SIM activation/barring or service parameter change, e.g. internet download rate.

Example of use

Subscriber activation, MSISDN assignments, service parameter update & account barring(suspension) are good examples of mandatory provisioning operations in mobile core

Business model

MNO, MVNO, MVNE

Technology

Mobile core provisioning events are produced in PortaBilling by its ESPF. ESPF EventSender in-turn delegates the event processing to an external app, e.g. Boomi IPaaS who's job is to validate event and finally synchronize changes to HLR/HSS

Current Solution

Not available

Stakeholders and their benefits

Benefit/Stakeholders

More Comfort

Increased Efficiency

Saves Time

Tighter Control

Replaces Human

CSP


✓

✓

✓

✓

Network operations /

Support of CSP

✓

✓

✓

✓

✓

End user

✓





CSP owner will get an increased source of revenue via extending scalability and shortening OPEX on provisioning

Use Cases

Use case #1: New account is created in PortaBilling; the account is assigned a SIM card from inventory.

Primary Actor: PB administrator/external App

Supporting actors: PortaBilling system (PB), ESPF, Boomi

Preconditions:  

  1. SIM cards are pre-provisioned with proper security in HLR/HSS

  2. SIM IMSIs are uploaded to the SIM inventory of PortaBilling.

  3. Multiple Products with mobile services are created in PortaBilling

  4. Multiple Service Policies managing CS and EPS profiles in HLR/HSS are created in PortaBilling:

    • cs-barred, cs-prepaid, cs-postpaid

    • ps-barred, ps-1mbps, ps-10mbps

  5. A SIM is supplied to the end user.

Use scenario #1.1, Successful provisioning of new account

  • PB administrator/external App assigns SIM from the inventory to the active account with the associated product and service policy

  • PB system sets the SIM status to "In Use" from either "Reserved" or "Available"
  • PB systems produces the event for ESPF

  • ESPF EventSender delivers the event to Boomi

  • Boomi handles the event by provisioning SIM data to HLR/HSS over REST API

    • sets active status

    • updates MSISDN

    • updates CS and EPS profile

      • if effective service policy does not define CS profile explicitly, then default cs-barred is used

      • if effective service policy does not define EPS profile explicitly, then default ps-barred is used

Use case #2: Account is blocked/terminated in PortaBilling. 

Primary Actor: PB administrator/external App

Supporting actors: PortaBilling system (PB), ESPF, Boomi 

Preconditions:  

  1. Use scenario #1.1 is successful

Use scenario #2.1: Successful block

  • PB administrator/external App blocks the account.

  • PB system triggers an event for ESPF.

  • ESPF EventSender delivers the event to Boomi

  • Boomi updates associated SIM via HLR/HSS REST API

    • sets inactive status

Use scenario #2.2: Successful unblock 

  • PB administrator/external App unblocks the account.

  • PB system triggers an event for ESPF.

  • ESPF EventSender delivers the event to Boomi

  • Boomi updates associated SIM via HLR/HSS REST API

    • sets active status

Use scenario #2.3: Successful termination 

  • PB administrator/external App terminates the account.

  • PB system sets SIM status to "Disposed"

  • PB system triggers an event for ESPF

  • ESPF EventSender delivers the event to Boomi

  • Boomi updates associated SIM via HLR/HSS REST API

    • sets inactive status
    • unassigns MSISDN
    • updates CS and EPS profile to default cs-barred and ps-barred

Use case #3: Product changes 

Primary Actor: PB administrator/external App

Supporting actors: PortaBilling system (PB), ESPF, Boomi  

Preconditions: 

  1. Use scenario #1.1 is successful

  2. Product X defines cs-prepaid and ps-1mbps

  3. Product Y does not define cs nor eps profiles

  4. Product Z defines cs-postpaid and ps-10mbps

  5. The end user is subscribed and uses mobile service according to the product X. 

Use scenario #3.1: X to Y

  • PB administrator changes the product from X to Y, the one which doesn’t define service profiles explicitly.

  • PB system triggers an event for ESPF.

  • ESPF EventSender delivers the event to Boomi

  • Boomi updates associated SIM via HLR/HSS REST API

    • updates CS and EPS profile to default cs-barred and ps-barred

Use scenario #3.2: Y to X

  • PB administrator changes the product from Y to X, the one which defines service profiles explicitly.

  • PB system triggers an event for ESPF.

  • ESPF EventSender delivers the event to Boomi

  • Boomi updates associated SIM via HLR/HSS REST API

    • updates CS and EPS profile to cs-prepaid and ps-1mbps

Use scenario #3.3: X to Z

  • PB administrator changes the product from X to Z, the one which defines service profiles explicitly with different access policy.

  • PB system triggers an event for ESPF.

  • ESPF EventSender delivers the event to Boomi

  • Boomi updates associated SIM via HLR/HSS REST API

    • updates CS and EPS profile to cs-postpaid and ps-10mbps

Use case #4: Mobile account identity changes 

Primary Actor: PB administrator/external App

Supporting actors: PortaBilling system (PB), ESPF, Boomi  

Preconditions: 

  1. Use scenario #1.1 is successful

Use scenario #4.1: New IMSI

  • PB administrator/external App changes the SIM card for the account.

  • PB system sets the old SIM status to "Disposed"
  • PB system sets the new SIM status to "In use" from either "Reserved" or "Available"
  • PB system triggers events for ESPF.

  • ESPF EventSender delivers events to Boomi

  • Boomi handles events by provisioning SIM data to HLR/HSS over REST API

    • sets inactive status for old IMSI
    • unassigns MSISDN for old IMSI
    • updates CS and EPS profile to default cs-barred and ps-barred for old IMSI
    • sets active status for new IMSI

    • updates MSISDN for new IMSI

    • updates CS and EPS profile for new IMSI

      • if effective service policy does not define CS profile explicitly, then default cs-barred is used

      • if effective service policy does not define EPS profile explicitly, then default ps-barred is used

Use scenario #4.2: New MSISDN

  • PB administrator/external App changes the MSISDN for the account.

  • PB system triggers an event for ESPF.

  • ESPF EventSender delivers events to Boomi

  • Boomi handles events by provisioning SIM data to HLR/HSS over REST API

    • updates MSISDN

Use case #5: Handling of common failures

Primary Actor: Boomi

Supporting actors: PortaBilling system (PB), ESPF 

Preconditions:  

  1. SIM cards are pre-provisioned with proper security in HLR/HSS

  2. SIM IMSIs are uploaded to the SIM inventory of PortaBilling.

  3. Products with mobile services are created in PortaBilling

  4. Service Policies managing CS and EPS profiles in HLR/HSS are created in PortaBilling

Use scenario #5.1, Failed provisioning in Boomi

  • PB systems produces the event for ESPF

  • ESPF EventSender delivers the event to Boomi

  • Boomi fails to provision SIM data to HLR/HSS over REST API

  • Multiple automatic retries are attempted in Boomi
  • A failed Sync job is stored as a dead letter in Boomi and kept for configurable amount of time, default 14 days
  • Data owners (aka data stewards) receive e-mail/rss notification from Boomi to follow up
    • they analyse the cause
    • they troubleshoot the cause
    • they re-try processing using Boomi UI tools

Use scenario #5.2, Failed ESPF

  • Out-of-scope, i.e. handled as it is now, e.g.
    • using ESPF cli tools
    • using ESPF UI tools

Non-functional requirements

N/A

Peculiarities

N/A

Performance / Clustering, Geo Redundancy/ Dual-Version, Porter

N/A