Definition
BSS (Business Support System) is a support system for telecom operators aimed at customers and business, covering billing, settlement, customer management, orders, product management, Reseller channels, etc. BSS works together with OSS (Operational Support System) to form the core IT of operators; through RESTful API integration with ICMP, it provides capabilities such as card management, billing, and settlement.
Core Functions
Typical BSS functions include: Billing——CDR processing, Rate Card pricing, Cross-Border Billing, Unified Invoice; Settlement——Multi-Currency Settlement, Reconciliation, Commission; Customer Management——CRM, customer master data, contracts; Order——order acceptance, provisioning, Activation; Product and data plan——product catalog, data plan configuration, Quota. ICMP, as a connection management platform, needs to interface with the operator's BSS to obtain CDR, usage, billing, etc.
Relationship with OSS
BSS is oriented toward "business and customers," while OSS is oriented toward "network and operations." BSS handles billing, customers, orders; OSS handles network configuration, faults, performance. ICMP may interface with both BSS (billing, orders) and OSS (network status, diagnostics). Both are integrated via RESTful API, message queues, etc., forming end-to-end support capabilities.
Integration in ICMP
SimtoLink ICMP integration with carrier BSS: obtain CDR and usage data; synchronize activation, suspension, termination, and other statuses; Reconciliation for accounting and settlement. The platform itself also has BSS-type capabilities (billing, customer, orders) and can operate independently or collaboratively with carrier BSS.
Customer-side billing objects a business support system holds
A business support system handles customers, contracts, products, and accounts, not base stations and links. After an international connectivity order arrives, it has to recognize the customer master data, the chosen product and price, the settlement currency, and which subscriptions that order should create. When rating, it consumes usage records, applies the rate card, and rolls the result into an invoice and a settlement. Channel rebates, multi-currency conversion, and reconciliation differences also sit on this business chain, not in network alarms.
The connectivity platform may hold some of that capability itself, or it may keep only connection state and leave accounting to the operator’s business system. Either way, there cannot be two customer numbers that do not refer to each other. The SIM identifier and order number on the platform, and the subscription number and account number in the business system, need an explicit mapping. Without that mapping, usage can be calculated and still have no contract to post against.
Master data that must match when reconciling with the connectivity platform
Invoices match only when both sides use the same key master data for the same object. Customer number, SIM identifier, product code, rate version, currency, billing-period start and end, and time zone must all translate into one another. An order marked complete only means the purchase was accepted commercially. A successful network-side enablement means the subscription can generate usage. Both states must be written back, and neither may overwrite the other. Rate versions must be distinguished by effective time. Keeping only “the current price” makes a historical period get rerated at the new price.
Before usage enters the business system, agree how duplicates and late records are handled. The same detail record delivered twice is rated once. A late detail record should enter an adjustment to the original period, not quietly fall into the month when it arrived. Fields tied to the detail record, such as visited network, access point, and country, must be kept through to invoicing, so it is possible to explain why the same SIM has different prices in different countries. If the connectivity platform hands the business system only aggregated traffic, a dispute cannot return to a single session.
Drift when order status and billing status each follow their own path
If the order says complete and billing is still pending, the device is already using the network and charges appear only next month. The customer reads that as under-billing. The reverse is also possible: billing has started, the order was cancelled, and a SIM in the warehouse is still generating a monthly fee. If each side keeps its own state and they compare only a daily total, a single-SIM difference is hidden by the grand total. Another drift is duplicated customer master data. The same company has two accounts in the business system, the SIM hangs on account A, and the invoice is sent to account B.
Inconsistent product codes put the wrong plan on the wrong SIM. The platform sells a “local data package,” the business system rates a “roaming data package,” and the reconciliation gap leans steadily to one side. An empty currency field may default to the operator’s home currency, while the customer contract states settlement in another currency, and the conversion dispute starts there. To repair it, first choose which side is authoritative for customer, product, and billing period, then fill in the mapping, rather than editing the amount on one invoice by hand. Failed state write-backs must be replayable. Keep business state separate from network state on the operations support side, so a link alarm is not used to explain an invoice.
Which side is master has to be decided field by field. One system should not own the whole record. The customer’s legal name and settlement account follow the business support system. The SIM’s on-network state follows the network receipt the connectivity platform received. The price follows the rate version both sides confirmed. If a sync job overwrites one side with a full copy of the other, it can push a just-enabled state back to pending, or write an obsolete cancelled price back onto the platform. Incremental sync needs a version or an update time. A late old message is discarded, not applied over the newer state. On reconciliation day, freeze the window for changing this master data, so customer numbers are not edited while the invoice is being produced. During the freeze, allow only a correction of an identifier already confirmed as wrong, and keep a separate correction record. Do not change price or account in the same pass.