End-to-End Flow : From Customer Order to Service Assurance

Beginner Friendly 15 min read Real Telecom Examples 5G Postpaid Focus
Overview Selling Order Capture Inventory Check Provisioning Assurance Billing Examples Questions

🎯 Learning Objective: Understand the complete end-to-end flow when a customer buys a 5G postpaid connection. Follow the journey from "Buy Now" click to activation, ongoing monitoring, and monthly billing. This topic ties OSS and BSS concepts together using a simple mobile subscription example.

The Customer's Journey - 5G Postpaid Connection

💰

1. Buy

Customer selects plan on website

📝

2. Order

BSS creates service order

⚙️

3. Activate

OSS configures 5G Core

📱

4. Use

Customer enjoys 5G service

📄

5. Bill

Monthly invoice generated

This is the journey of every mobile postpaid connection. OSS and BSS work together behind the scenes.

Phase 0: Selling – Where It All Begins

Simplified View: The customer clicks "Buy Now" on the website or in the app.

What Happens

  • Customer browses plans (e.g., "Unlimited 5G - ₹499/month")
  • Selects plan and enters details
  • Clicks "Buy Now"
  • BSS checks eligibility and creates an order

Key Point

  • Selling happens in BSS (CRM, Product Catalog)
  • Without this click, OSS never gets involved
  • Selling triggers everything
📱 EXAMPLE
User opens Jio/Airtel app → selects "₹499 5G Plan" → clicks "Buy Now" → enters address → completes payment → service activates in 10 minutes.

Phase 1: Order Capture (BSS)

Simplified View: BSS turns the customer's purchase into a formal order that OSS can understand.

  • BSS captures customer name, address, plan selected, payment method
  • BSS validates the order (Is plan available? Is address serviceable?)
  • BSS creates a Service Order - a standardized request for OSS
  • BSS sends the order to OSS via TMF641 API
Key API: TMF641

TMF641 is the standard Service Order API. It ensures any BSS can talk to any OSS using a common language.

Phase 2: Inventory Check (OSS)

Simplified View: OSS checks if the necessary items are available to fulfill the order.

What OSS Checks

  • SIM Card: Is there a physical SIM or eSIM profile available?
  • Phone Number (MSISDN): Is there a free number from the available pool?
  • Plan Features: Is 5G access available in the customer's area?
  • Network Capacity: Does the local tower have capacity for one more user?

Where They Are Managed

  • SIM & Number: HLR/UDM (Home Location Register)
  • Network Resources: TMF639 Resource Inventory (routers, ports, fiber, gNBs)
  • Plan Features: Product Catalog / PCF policies
Important Clarification: Inventory in Mobile Networks

In telecom OSS/BSS environments, different types of inventory are managed by different systems.

Network Resource Inventory systems (often integrated using TMF639 APIs) manage infrastructure resources such as: routers, switches, gNBs, ports, fiber links, transport equipment, and hardware assets.

Subscriber-related items such as: SIM cards, IMSIs, eSIM profiles, and phone numbers (MSISDNs) are commonly managed using specialized provisioning, subscriber management, and number management systems integrated with the OSS/BSS stack.

For a standard 5G postpaid activation, these availability checks are usually automated and completed within seconds.

📱 INVENTORY CHECK EXAMPLE
When a customer buys a 5G connection, the OSS/BSS ecosystem checks:

1. Is there an available phone number (MSISDN) in the selected telecom circle?
→ Checked using Number Management systems.

2. Is there an available SIM card or eSIM profile?
→ Checked using SIM inventory and provisioning systems.

3. Is the subscriber profile ready for activation in the 5G Core?
→ Provisioned in systems connected to UDM/Subscriber Management platforms.

4. Is the network operating normally in that area?
→ Verified through OSS monitoring and assurance systems.

Result: If all checks pass, the order moves automatically to provisioning and activation.

Phase 3: Provisioning & Activation (OSS)

Simplified View: OSS configures the 5G Core network to allow this customer's SIM to work.

1

Order Received

OSS gets order from BSS

2

Provisioning Engine

Creates subscriber profile

3

Activation Engine

Configures 5G Core elements

4

Service Active

Customer can use 5G

What gets configured in the 5G Core:

  • UDM (Unified Data Management): Stores the customer's profile - who they are, what plan they bought, and if they are allowed to use 5G.
  • AUSF (Authentication Server Function): Handles the "handshake" when the phone connects to the network.
  • PCF (Policy Control Function): Defines the rules - speed limit, data cap, priority, and whether 5G is allowed.
  • SMF (Session Management Function): Manages the data session when the customer uses the internet.
Important: OSS does NOT configure RAN or Transport directly

For a standard 5G postpaid connection, RAN (cell towers) and Transport (fiber backbone) are already built and shared by all users. The OSS only configures the Core Network. Once the Core allows the SIM, the phone connects automatically through existing towers.

📱 ACTIVATION STEPS
1. OSS creates profile in UDM → "User is allowed 5G with unlimited data"
2. OSS configures PCF policy → "Speed limit = 1Gbps, Video streaming allowed"
3. Customer inserts SIM → Phone and SIM authenticate through the 5G Core using AUSF
4. PCF sends policy to phone → "You can use 5G"
5. Customer uses 5G → Data flows through SMF
Result: Service becomes active without requiring dedicated tower configuration for that individual customer.
  • Service Inventory (TMF638): Creates a service record marking the subscription as "ACTIVE."
  • Post-provisioning validation: OSS may query the UDM to confirm the profile was created successfully.
  • Activation confirmed: OSS sends confirmation back to BSS via TMF641.

Phase 4: Service Assurance (OSS)

Simplified View: Once the customer is active, OSS monitors the network to ensure good experience.

  • Performance Monitoring: OSS tracks network KPIs - call drop rates, data speeds, latency
  • Fault Management: OSS receives alarms if towers or Core elements fail
  • SLA Monitoring: OSS checks if the service meets promised quality levels
  • Customer Impact: If a tower fails, OSS knows which customers are affected
  • Dashboards: NOC sees real-time network health; customers see their usage via apps
Key Point:

Most customers never see OSS dashboards. But when there is an outage, OSS helps NOC engineers fix it quickly. When network is slow, OSS helps identify the problem.

Phase 5: Billing (BSS)

Simplified View: At the end of the month, the customer receives a bill for their usage.

  • Core network tracks usage - data consumed, calls made, SMS sent
  • Usage records flow from Core → Mediation → BSS
  • Mediation normalizes the data (cleans and formats it)
  • BSS calculates the bill based on the plan and usage
  • Customer receives invoice via email or app
📄 BILLING EXAMPLE
User uses 45GB data in a month on his ₹499 unlimited plan → no extra charges (unlimited).
If he had a 10GB plan and used 12GB, BSS would add overage charges.
Core network generates usage records for data consumption, calls, and sessions. BSS applies the pricing rules.
Modern Telecom Trend

Traditional telecom systems relied heavily on batch mediation systems to process usage records. Modern cloud-native architectures increasingly use real-time event streaming platforms and APIs for faster charging, analytics, and customer notifications.

Real-World Scenarios

Scenario 1: New Customer Buys 5G Postpaid

A new customer switches to 5G postpaid plan online.

  • Sell: Customer selects "₹699 5G Plan" on website → clicks "Buy Now"
  • Order: BSS creates order → sends TMF641 to OSS
  • Inventory: OSS reserves SIM card and phone number
  • Provisioning: OSS creates profile in UDM, configures PCF policy
  • Assurance: OSS confirms SIM is active on network
  • Billing: Monthly invoice generated on same date each month

Scenario 2: Tower Outage Affects Customers

A 5G tower in Mumbai loses power.

  • Fault Detection: gNB sends "Power Failure" alarm to OSS via SNMP
  • Correlation: OSS correlates with other alarms from the area
  • Customer Impact: Inventory maps tower → affected customers (2,000 users)
  • Ticket Creation: NOC creates trouble ticket, dispatches field engineer
  • SLA Tracking: OSS tracks downtime duration for SLA credits
  • Result: Power restored in 2 hours. Affected customers may get bill credits if SLA breached.

Scenario 3: Network Congestion During Cricket Match

50,000 people at a stadium all using 5G simultaneously.

  • Performance Monitoring: OSS detects PRB utilization > 90% (high congestion)
  • Threshold Alert: TCA triggered → NOC notified
  • Automation: Orchestration may activate additional spectrum layers, optimize traffic policies, or rebalance network resources temporarily
  • Customer Experience: Video streaming continues without buffering
  • Result: Customers unaware of congestion. No complaints.

Complete Flow Map: Systems and APIs

💰

BSS (Sell)

CRM captures customer purchase

📦

BSS → OSS

TMF641 Service Order API

🔍

Inventory

TMF639 + SIM/Number Systems

⚙️

5G Core

UDM, AUSF, PCF, SMF

📊

Assurance

FMS, PM, Analytics Platforms

💰

BSS (Billing)

Usage → Mediation → Invoice

Key Terms You Must Know

Sell → Order → Activate
The three-step process for any service
TMF641
Service Order API - BSS to OSS handoff
UDM
Unified Data Management - stores subscriber profiles
PCF
Policy Control Function - defines speed and data rules
Provisioning
Creating subscriber profile in Core network
Activation
Making the service usable for the customer
Service Assurance
Monitoring network health and customer experience
Mediation
Cleaning usage data before billing

Common Questions

Q1. Walk me through the end-to-end flow when a customer buys a 5G postpaid connection.

Customer buys plan → BSS creates order (TMF641) → OSS checks inventory → OSS configures 5G Core (UDM, PCF) → SIM activates → OSS monitors service → BSS bills monthly.

Q2. Does OSS configure cell towers for every new customer?

No. Towers are shared infrastructure already configured. For a standard mobile activation, OSS mainly configures subscriber-related Core Network functions rather than individual towers or transport devices. The phone connects automatically through existing towers.

Q3. What is TMF641?

Standard Service Order API that BSS uses to send orders to OSS. It ensures any BSS can work with any OSS.

Q4. What happens when a tower fails?

OSS receives alarm → correlates with other alarms → identifies affected customers via inventory → creates ticket → dispatches field engineer. OSS tracks downtime for SLA credits.

Q5. How does billing know how much data I used?

Core network tracks every byte. Usage records go from Core → Mediation (cleaning) → BSS (rating and invoicing).

📌 Key Takeaways:

  • Selling triggers everything - Customer click creates order
  • OSS configures Core, not RAN/Transport - Towers are shared infrastructure
  • End-to-end flow: Sell → Order → Activate → Use → Bill
  • TMF641 is the standard API for BSS to OSS order handoff
  • 5G Core elements: UDM (profile), AUSF (auth), PCF (policy), SMF (session)
  • Assurance monitors network health and customer impact
  • Mediation cleans usage data before BSS billing