Reviewers (PMD-3361):

Oleg Shevtsov 09 Dec 2025
Andrii Kravchenko 05 Dec 2025
Oleksandr Zakharchenko 05 Dec 2025
Oleksandr Zaluhovskyi 13 Feb 2026
Stanislav Sevriuk 12 Feb 2026
Vaclav Balcar 06 Feb 2026
Mike Kidik 17 Feb 2026
Anastasiia Holota as part of DOCS-7100 16 Feb 2026

User Story

As a Mobile Network Operator (MNO) or Mobile Virtual Network Operator (MVNO) I want support of multi-IMSI eSIM profiles within PortaBilling in order to:

get world-wide coverage for their SIM product without negotiations and interconnect with each and every operator abroad
introduce competitive roaming offerings with up to 10 IMSI embedded into eSIM profile
enable integrations for provisioning, streamline product management, and enhance the end-user experience for frequent travelers.

As an end-user (and frequent traveler), I want seamless connectivity across countries using one plan and balance, so that my service just works wherever I go, with no need to change the SIM card in each country.

Example of use

A truck driver frequently travels on the Munich-Andorra la Vella route. Their mobile operator (a German MNO) offers a "EU Neighbour - Andorra" bundle that includes service in EU and Andorra. The eSIM profile for this bundle contains the MNO's own IMSI for use in Germany and an IMSI (from an IMSI Sponsor in Andorra) for use in Andorra, optimizing roaming costs and service quality.
A private transfer service driver travels weekly between Munich (Germany) and Montenegro. They would benefit from a "Balkan Traveller" bundle, which includes an eSIM with the German MNO's IMSI and sponsored IMSIs with optimal cost for use in Montenegro ensuring seamless service across borders.
A sales representative frequently visits trade shows world-wide. They would sign-up for regional or global bundles with world-wide coverage. The eSIM profile for this bundle contains the MNO's own IMSI for use in Germany and a dynamic sponsored IMSI which is chosen, replaced & provisioned automatically as the subscriber arrives to Japan or United States.

Business model

MNO, MVNO

Technology

Each eSIM profile is identified by ICCID and may have single or multiple (2+) embedded IMSIs. MNO/MVNO often embed more than one IMSI into profile to optimize roaming costs - the first IMSI is typically owned by the operator, the other IMSIs in the profile - given by IMSI sponsors (The party which owns MCC/MNC range for the IMSI, with the right to authorize MNO to use the IMSI e.g. "Partner W"). In addition, eSIM profile contains applet with rules to pick the best IMSI for available networks. Therefore, switching between IMSIs is automatically done by device and no end user action is required.

The overall solution assumes integration and orchestration between several platforms:

PortaBilling B/OSS: For subscriber management, product catalog, billing, charging, and SIM inventory.
Nordic SM-DP+: For eSIM profile generation and management.
Home HSS/PCRF: For MNOs/full MVNOs to manage subscriber authentication and policy control.
MVNE Platform: For light MVNOs to manage IMSI activation and service control.
sFTP Interface: For secure file transfer between the operator and the SM-DP+.

Current Solution

Currently, different use cases for multi-IMSI profiles are handled via a number of workarounds below. This approach has limitations, particularly in product-to-eSIM, IMSI-to-sponsor-rates, IMSI-to-eSIM mappings, automation, and scalability.

Inventory Data Store

We map multiple IMSIs and containing eSIM record to existing PortaBilling data objects. This involves creating separate SIM inventory records for the primary (eSIM) and secondary (IMSI) identities, linked by a custom "Profile ICCID" field.

Least Cost Roaming

To implement #2.5 (find a best/cheapest IMSI for data use in roaming network), separate IMSI Sponsor Tariffs are loaded as PortaBilling Customer Tariffs and all grouped under single special Product which is used for optimal IMSI lookup for given MCC in three stages:

looking for the tariffs of the product which give best rates matching MCC of the connecting network (Rate/search_rate_list gives i_tariff and rates to order)
get_tariff_info to get IMSI Sponsor ID, stored in tariff description
finally another lookup in SIM inventory against custom fields: Type (IMSI), Lifecycle (Pool), IMSI Sponsor (ID from previous step)

Multiple Charging IDs

Another challenge is Username for Gy/Ro/Mediation - it may have really different forms:

<IMSI>@imsi
<MSISDN>@msisdn

In multi-IMSI scenarios, multiple Usernames are required which also complicates implementation of Onboarding and Self-Care apps. Therefore, a special Boomi workflow is implemented to sync beneficiary accounts on eSIM profile assignment and dynamic sponsored IMSI swap.

Stakeholders and their benefits

Benefit/Stakeholders	More Comfort	Increased Efficiency	Saves Time	Tighter Control	Replaces Human
CSP		✓	✓	✓
Network operations /Support of CSP	✓	✓	✓	✓	✓
End user	✓

The CSP owner will get optimised roaming costs and reduced operational expenditure (OPEX) on manual provisioning tasks. Moreover, the CSP owner may avoid unnecessary negotiations and interconnect with every MNO abroad to get immediate worldwide coverage of their SIM product.

Use Cases

Introduction

The following use cases are separated to demonstrate two distinct operational models for Multi-IMSI support, representing the spectrum from predictable regional coverage to agile global connectivity. While the technical capabilities (such as OTA swapping) can technically be cross-applied, we have grouped them into these two archetypes to illustrate specific integration workflows and business logic.

1. Local MNO / Full MVNO (The "Static" Model) This scenario reflects an operator with their own core network infrastructure (Home HSS/PCRF) and established, stable roaming agreements (e.g., specific neighboring countries).

Core Mechanism: Pre-loaded Profiles. Multiple IMSIs are embedded into the eSIM during generation based on specific product bundles.
Business Focus: Leveraging the operator's own network in the home country, and IMSI from a sponsor in roaming. Most of MVNOs do not have agreements with all possible MNOs around the world, that's why they have to use the IMSI of a bigger operator for roaming.
Expected Profile Structure: up to 10 static IMSIs in single profile to cover visiting networks abroad with forecasted roaming costs. Each IMSI Sponsor from the profile shall give them certain MCCMNC coverage with a price per MCCMNC and GB. Profile applet will prefer optimal IMSI based on static rules.

2. Global Light MVNO (The "Dynamic" Model) This scenario represents an agile operator (often on an MVNE platform) aiming for worldwide coverage with aggressive cost optimization.

Core Mechanism: Over-The-Air (OTA) IMSI Swapping. The system maintains a "Pool" of sponsored IMSIs. As the subscriber travels, PortaBilling orchestrates the real-time replacement of IMSIs inside the active eSIM to ensure the most cost-effective connectivity.
Business Focus: Flexibility and integration capabilities. This demonstrates how PortaBilling interacts with external SM-DP+ or OTA vendors (like Nordic or Workz/Trasna) to dynamically manage IMSI resources based on location and cost.
Expected Profile Structure: up-to three IMSIs per profile: own for home network and direct roaming agreements, static sponsored IMSI with world-wide coverage to keep the user online and dynamic one to optimize costs against static sponsored IMSI.

Use case #1: Local MNO / Full MVNO (The "Static" Model)

Roles: PortaBilling (PB), PB Administrator (Admin), Onboarding App, Self-Care App, End User, Home HSS/PCRF, Nordic SM-DP+, Provisioning System

Preconditions:

Local MNO/MVNO in Germany (MCC = 262) has a roaming agreement with "Partner X", an IMSI Sponsor and MNO in Andorra (MCC = 213) with MNC 77 and 78
- A batch of 1000 IMSIs has been negotiated with "Partner X".
- "Partner X" shall charge Local MNO/MVNO for IMSI usage:
Country MCC MNC Price per GB
Andorra 213 77 1.01
Andorra 213 78 1.01
- - The above rates are uploaded to "Partner X - Data" tariff in PortaBilling service catalog
- "Partner X" core network is configured to route network registrations and other control plane traffic of those IMSIs to the mobile core network of Local MNO/MVNO (3gpp interfaces based on diameter and SIP)
Local MNO/MVNO in Germany has a roaming agreement with "Partner Y", an IMSI Sponsor and MNO in Andorra with MNC 55 who has its own direct roaming agreements with operators in Montenegro, Albania and Kosovo.
- A batch of 10000 IMSIs has been negotiated with "Partner Y".
- "Partner Y" shall charge Local MNO/MVNO for IMSI usage:
Country MCC MNC Price per GB
Andorra 213 55 1.1
Montenegro 297 01 0.41
Albania 276 03 0.3
Kosovo 221 01 0.6
- - The above rates are uploaded to "Partner Y - Data" tariff in PortaBilling service catalog
- "Partner Y" core network is configured to route network registrations and other control plane traffic of those IMSIs to the mobile core network of Local MNO/MVNO (3gpp interfaces based on diameter and SIP)
An sFTP interface is established with Nordic SM-DP+ for eSIM profile generation.
Gy/Ro interfaces are configured between PortaBilling and Local MNO/MVNO core network for real-time credit control.
- Possible AVPs for identifying user & connected (home/roaming) network
  - AVPs for user identity
    Subscription-Id
    User-Name
  - AVPs for user location
    Service-Information → PS-Information → 3GPP-User-Location-Info (Gy/Ro), holds CGI of subscriber, starting with roaming MCCMNC
    Service-Information → PS-Information → 3GPP-SGSN-MCC-MNC (Gy)
    Service-Information → IMS-Information → IMS-Visited-Network-Identifier (Ro), e.g. 'ims.mnc099.mcc460.3gppnetwork.org'
  - AVPs for IMSI sponsor identity
    Origin-Host
  We assume there's a reliable AVP for each category
- IMSI translation affects billing and provisioning setup
  Some IMSI Sponsors map their IMSIs 1:1 to the IMSIs of Local MNO/MVNO and setup translation in their Gy/Ro proxies.
  This simplifies provisioning and billing setup for the subscriber:
  - no need to create secondary account for billing id
  - no need to provision secondary IMSI to Home HSS/PCRF
  In this case, user identity AVP shall never expose sponsored IMSI over Gy/Ro. We can assume that sponsored IMSI is used based on different value for IMSI sponsor identity AVP.
  
  However, in general case, it's possible that multi-IMSI eSIM profile shall contain a mix of sponsored IMSIs from different sponsors, some do translation, some don't (i.e. we need to create secondary account for billing id and provision that IMSI to Home HSS)
The following Bundles are defined in PortaBilling service catalog:
- "EU Neighbour - Andorra 30-Day Pass" as renewable PortaBilling Bundle with
  - 100GB netaccess allowance for
    - E212-262-01 (home network)
    - E212-213-77
    - E212-213-78
    - other EU member codes
  - 2000 voice minutes allowance
    - in home/roaming networks
      - E212-262-01 (home network)
      - E212-213-77
      - E212-213-78
      - other EU member codes
    - incoming from anywhere
    - outgoing to destination group
      - +49 (Germany)
      - +376 (Andorra)
      - other EU member codes
- "EU Neighbour - Andorra 7-Day Pass" as renewable PortaBilling Bundle with
  - 10GB netaccess allowance for
    - E212-262-01 (home network)
    - E212-213-77
    - E212-213-78
    - other EU member codes
  - 200 voice minutes allowance
    - in home/roaming networks
      - E212-262-01 (home network)
      - E212-213-77
      - E212-213-78
      - other EU member codes
    - incoming from anywhere
    - outgoing to destination group
      - +49 (Germany)
      - +376 (Andorra)
      - other EU member codes
- "Balkan Traveller 10-Day Pass" as renewable PortaBilling Bundle with
  - 50GB netaccess allowance for
    - E212-262-01 (home network)
    - E212-297-01 (Montenegro)
    - E212-276-03 (Albania)
    - E212-221-01 (Kosovo)
    - other EU member codes
  - 1000 voice minutes allowance
    - in home/roaming networks
      - E212-262-01 (home network)
      - E212-297-01 (Montenegro)
      - E212-276-03 (Albania)
      - E212-221-01 (Kosovo)
      - other EU member codes
    - incoming from anywhere
    - outgoing to destination group
      - +49 (Germany)
      - +382 (Montenegro)
      - +355 (Albania)
      - +383 (Kosovo)
      - other EU member codes
- All bundles have grace period 60 days

Use scenario #1.1: eSIM profile generation for Product Offerings

PortaBilling administrator loads 1000 IMSIs into batch "1000-Own-2025-12-23" and associates IMSIs with their IMSI Sponsor - "Own"
PortaBilling administrator loads 1000 IMSIs into batch "1000-X-2025-12-23"and associates IMSIs with their IMSI Sponsor - "Partner X"
PortaBilling administrator defines the new eSIM profile pool "Own+X for EU Neighbour - Andorra"
- Available for use with Products
  - "EU Neighbour - Andorra 30-Day Pass"
  - "EU Neighbour - Andorra 7-Day Pass"
PortaBilling administrator triggers eSIM profile generation:
- Admin selects the pool "Own+X for EU Neighbour - Andorra" to include generated profiles into
- Admin defines quantity of IMSI per profile - exactly two IMSI per profile.
  - The other options were:
    - exactly one IMSI per profile
    - exactly three IMSI per profile
    - ...
    - exactly ten IMSI per profile
- Admin selects IMSI batch "1000-Own-2025-12-23" to pickup IMSIs for position (index) 1
- Admin selects IMSI batch "1000-X-2025-12-23" to pickup IMSIs for position (index) 2
- Admin selects to automatically produce rules for IMSI and MNC selection per country (MCC) based on
  - Products the pool "Own+X for EU Neighbour - Andorra" is available for use with
    - limited scope of product-covered E212-MCC-MNC rate codes
  - Least cost of data service
    - prefer IMSI with lower price for MCC MNC
  - Profit guarantee
    - registrations of IMSI1 and IMSI2 to certain MCC MNC should not be allowed due to too high or suboptimal cost
- Admin selects to generate 1000 profiles
PortaBilling integration prepares and transmits a specially formatted file to the Nordic SM-DP+ via the sFTP interface. The file includes:
- 1000 rows of <ICCID>/<IMSI1>/<IMSI2>
- rules for IMSI and MNC selection per country (MCC), e.g. since IMSI2 sponsored by "Partner X"
  - 262 01 IMSI1 (high preference for home network)
  - 213 77 IMSI2 (high preference)
  - 213 78 IMSI2 (med preference)
The SM-DP+ generates the eSIM profiles, each containing a primary IMSI, a sponsored IMSI, and an applet with rules for IMSI and MNC selection in allowed countries (i.e. per MCC).
Two output sFTP files containing profile data are processed by PortaBilling integration:
- An output file "Perso" is automatically loaded to Nordic profile inventory so that eSIM profiles could be ordered and downloaded by Onboarding app
- An output file "Standard" particularly contains generated Ki, OPc PINs, PUKs - the data is automatically extracted, transformed and loaded into the eSIM pool "Own+X for EU Neighbour - Andorra" of PortaBilling SIM inventory so that eSIM profiles could be assigned to PortaBilling account by Onboarding app and accessed by Provisioning System app (see #1.2)
.
Similarly, PortaBilling Admin defines and generates 10000 profiles in eSIM profile pool "Own+Y for Balkan Traveller"
- Available for use with Products
  - "Balkan Traveller 10-Day Pass"

Use scenario #1.2: Onboarding

End User (Truck Driver): Opens the Onboarding App and browses available plans for travel between Germany and Andorra. The app lists all suitable bundles, particularly the "EU Neighbour - Andorra 30-Day Pass" bundle.
- Since products are linked to pools of available eSIM profiles, the app may apply different business rules when stock is depleted.
The end user selects and pays for the "EU Neighbour - Andorra 30-Day Pass" bundle.
A subscriber account is created in PortaBilling, the service bundle is applied, and a multi-IMSI eSIM profile from the eSIM pool "Own+X for EU Neighbour - Andorra" is assigned to the account.
An eSIM activation code (QR code) is delivered to the end user by Onboarding app
Upon successful installation of the eSIM profile by the end user, the account and service bundle is activated (or was activated at the time of purchase).
PortaBilling notifies Provisioning System (e.g. NSPS connector)
Provisioning System app (e.g. NSPS connector) / Admin can get the following information about Profile ICCID 8949 1026 2010 0000 1234 5, eSIM from the pool "Own+X for EU Neighbour - Andorra":
- Profile ICCID: 8949 1026 2010 0000 1234 5
- PIN1: 1111
- PUK1: 11111111
- PIN2: 2222
- PUK2: 22222222
- Transport key label: MNO.PROD.SM.TRK.AES
- Ki: D07F9224CB230F5EDE645CA0D98C9CDB (encrypted by transport key)
- OPc: F94DEB6986F99DEC02374C58E1B1547D (encrypted by transport key)
- IMSIs
  - IMSI 1
    - IMSI: 26201 9XXXXXXXX
    - Sponsor: "Own"
  - IMSI 2
    - IMSI: 21377 9XXXXXXXX
    - Sponsor: "Partner X"
Provisioning System (e.g. NSPS connector) checks internal configuration per Sponsor:
- creates IMSI 1 (own) with their Ki/OPc secrets, encrypted with transport key in the Home HSS for an MNO/full MVNO.
- skips creation of IMSI 2 (sponsored by "Partner X", assuming there's IMSI translation of 21377 9XXXXXXXX → 26201 9XXXXXXXX)
The user is now ready to enjoy the offering

Use scenario #1.3: Usage & Charging

Following #1.2
The end user is in Germany, MCC 262. The device uses the MVNO own IMSI (from eSIM profile) for all services (Voice, Text, Data).
Own IMSI is registered in home network 262-01
Usage is authorized in real-time against the user's bundle in PortaBilling, based on home network code 262-01 (supplied via Gy/Ro attribute) and incoming/outgoing call destination (supplied in Ro attribute)
The end user travels to Andorra, MCC 213. The applet on the eSIM automatically switches the active IMSI to the "Partner X" IMSI.
"Partner X" IMSI is registered in visited network 213-77.
Data Usage is authorized and charged in real-time via Gy against the same bundle in PortaBilling, using roaming rate code E212-213-77
xDRs are created in PortaBilling associated with "Partner X", real-time based on "Partner X - Data" tariff, using rate code E212-213-77

Use scenario #1.4: Fair usage

The "EU Neighbour - Andorra 30-Day Pass" bundle includes a Fair Usage Policy (FUP) threshold (e.g., 50GB of high-speed data).
The end user consumes 50GB of data while in both countries.
Upon hitting the threshold, PortaBilling ESPF produces an event for Provisioning System to change service profile for all IMSIs associated with the eSIM profile.
- Provisioning System updates the subscriber profile for own IMSI in Home PCRF to apply a new policy (e.g., reduced QoS, throttled speed).
- Provisioning System updates the subscriber profile for "Partner X" IMSI via special API endpoint, provided by "Partner X".
On bundle renewal, PortaBilling ESPF produces an event for Provisioning System to change service profile back to "normal" for all IMSIs associated with the eSIM profile.
- Provisioning System updates the subscriber profile for own IMSI in Home PCRF to apply a new policy (e.g., normal QoS, unlimited speed).
- Provisioning System updates the subscriber profile for "Partner X" IMSI via special API endpoint, provided by "Partner X".

Use scenario #1.5: eSIM Stock levels

Following #1.2
Admin accesses a "IMSI Sponsor View" dashboard or report in PortaBilling that shows the current stock levels of available multi-IMSI eSIM profiles using different IMSI sponsors, e.g.
- 999 profiles using IMSI sponsored by "Partner X"
- 10000 profiles using IMSI sponsored by "Partner Y"
Admin accesses a "Product View" dashboard or report in PortaBilling that shows the current stock levels of available multi-IMSI eSIM profiles for different products, e.g.
- 999 profiles suitable for "EU Neighbour - Andorra 7-Day Pass"
- 999 profiles suitable for "EU Neighbour - Andorra 30-Day Pass"
- 10000 profiles suitable for "Balkan Traveller 10-Day Pass"
As subscribers purchase bundles, the respective eSIM stock is depleted.
PortaBilling provides alerts or notifications when stock levels fall below a predefined threshold, allowing the manager to initiate a new profile generation batch (#1.1) in a timely manner.

Use scenario #1.6: Product Offerings & eSIM Profile Pools

A month later, as an outcome of eSIM Stock monitoring, PortaBilling administrator faces high demand on "EU Neighbour - Andorra 30-Day Pass" product.
PortaBilling administrator started negotiations with IMSI sponsor "Partner X" for pool "Own+X for EU Neighbour - Andorra"
PortaBilling administrator started negotiations with a new IMSI sponsor "Partner A" since they can provide better QoS and pricing in Andorra
Another month later, "Partner X" provided 1000 IMSIs
PortaBilling administrator refills the pool "Own+X for EU Neighbour - Andorra" (#1.1)
3 month later, "Partner A" provided 10000 IMSIs with better QoS, SLA and cost pricing
PortaBilling administrator creates the pool "Own+A for EU Neighbour - Andorra" (#1.1)
PortaBilling administrator manually adjusts available eSIM pools for "EU Neighbour - Andorra 30-Day Pass" product
Current List New List
"Own+X for EU Neighbour - Andorra" (high priority)

"Own+A for EU Neighbour - Andorra" (high priority)
"Own+X for EU Neighbour - Andorra" (low priority)

Use scenario #1.7: Bundle change

Following #1.3 or #1.6
The end user would like to benefit from another bundle offer "EU Neighbour - Andorra 7-Day Pass"
Since the offer is implemented with the same eSIM profile pool "Own+X for EU Neighbour - Andorra", the bundle is replaced and activated in PortaBilling by Self-Care App
A month later, the end user intends to subscribe to "Balkan Traveller 10-Day Pass"
Self-Care App validates if new offering is available for current subscriber setup:
- new offer is implemented with the eSIM profile pool "Own+Y for Balkan Traveller" while current offer "EU Neighbour - Andorra 7-Day Pass" is implemented with the pool "Own+X for EU Neighbour - Andorra"
- hence current eSIM profile is not suitable for "Balkan Traveller 10-Day Pass"
Self-Care App suggest the user to replace current eSIM with a new suitable eSIM, i.e. partially go through onboarding as per #1.2
eSIM swap causes PortaBilling to produce ESPF events for Provisioning System (e.g. NSPS connector)
Provisioning System (e.g. NSPS connector) checks internal configuration per Sponsor:
- removes previous own IMSI 1 in the Home HSS for an MNO/full MVNO.
- skips actions for previous IMSI 2 (Partner X, no provisioning due to IMSI translation)
- creates new IMSI1 (own) and IMSI2 (Partner Y, no IMSI translation) in the Home HSS for an MNO/full MVNO.
The user is now ready to enjoy new offering

Use scenario #1.8: Bundle grace period of inactivity

The end user did not renew the bundle they are currently on
On March 1, Bundle becomes inactive, in grace period (started 60 days)
- current eSIM profile is kept active and assigned to the subscriber for a bundle grace period
- end user is encouraged to resume via notifications during grace period
On April 30, after grace period is over and no resume, the account is terminated

Use scenario #1.9: Account closure

The subscriber account in PortaBilling is terminated by Admin or automation scenario (#1.8)
The eSIM profile status is updated to "Disposed" in the PortaBilling inventory.
PortaBilling triggers an event for Provisioning System
Provisioning System:
- Removes all (according to sponsor configuration) IMSIs associated with the eSIM profile from the Home HSS.

Use scenario #1.10: Recycling

Before April 30, PortaBilling administrator defines IMSI Hold period per MCC (as per assignments guidelines regulated per country)
- 262 - 365 days
- 213 - 180 days
Before April 30, PortaBilling administrator enables recycling for disposed eSIMs for eSIM pool "Own+X for EU Neighbour - Andorra"
Before April 30, PortaBilling administrator enables recycling for disposed IMSIs for IMSI batches "1000-Own-2025-12-23" and "1000-X-2025-12-23"
Following account closure (#1.9) on April 30, or alternatively, eSIM swap (#1.7)
After April 30, Disposed eSIM with Profile ICCID 8949 1026 2010 0000 1234 5 can not be reused by any user
On April 30, IMSIs from Profile ICCID 8949 1026 2010 0000 1234 5 started their hold period
- IMSI 1 (own, MCC = 262) started 365 days of hold
  - recall: IMSI 1 belongs to IMSI batch "1000-Own-2025-12-23"
- IMSI 2 (sponsor X, MCC = 213) started 180 days of hold
  - recall: IMSI 2 belongs to IMSI batch "1000-X-2025-12-23"
After hold period of 180 days is over IMSI 2 becomes available for eSIM generation (#1.1) as per enabled recycling for the containing IMSI batch
PortaBilling administrator or automation workflow can kick-off eSIM generation to refill stock of eSIM profile pools
After hold period of 365 days is over IMSI 1 becomes available for eSIM generation (#1.1) as per enabled recycling for the containing IMSI batch
PortaBilling administrator or automation workflow can kick-off eSIM generation to refill stock of eSIM profile pools

Use scenario #1.11: End of Life

Alternatively, PortaBilling administrator cancels a batch "1000-X-2025-12-23" with IMSI sponsor "Partner X"
Before April 30, PortaBilling administrator disables recycling, enables "end-of-life" for unused IMSIs for IMSI batch "1000-X-2025-12-23"
Following account closure (#1.9) on April 30, or alternatively, eSIM swap (#1.7)
On April 30, IMSIs from Profile ICCID 8949 1026 2010 0000 1234 5 started their hold period
- IMSI 1 (own, MCC = 262) started 365 days of hold
- IMSI 2 (sponsor X, MCC = 213) started 180 days of hold
After hold period of 180 days is over IMSI 2 gets "end-of-life" state as per enabled "end-of-life" for the containing IMSI batch
IMSI 2 is NOT available for recycling
PortaBilling administrator or automation workflow can clean up the IMSI 2 from the batch and notify sponsor X
After hold period of 365 days is over IMSI 1 becomes available for eSIM generation (#1.1) as per enabled recycling for the containing IMSI batch
PortaBilling administrator or automation workflow can kick-off eSIM generation to refill stock of eSIM profile pools
After all IMSIs from the batch "1000-X-2025-12-23" got their final "end-of-life" state, administrator is able to remove the IMSI batch from PortaBilling

Use scenario #1.12: History Audit

Admin needs to investigate who used the IMSI 26201... on a specific date and time in the past.
Admin uses an audit trail feature in PortaBilling to query the assignment history of that specific IMSI.
The system returns a historical record showing which account and end user was assigned the eSIM profile containing that IMSI during the specified time frame, even if the IMSI has since been recycled and reassigned.

Use case #2: Global Light MVNO (The "Dynamic" Model)

Roles: eSIM Profile Manager, Product Manager, PortaBilling (PB), Onboarding App, Self-Care App, End User, MVNE Platform, Nordic SM-DP+, Provisioning System.