Definition
OSS (Operations Support System) is a support system for telecom operators oriented towards network and operations, covering network management, device management, fault management, performance monitoring, configuration management, etc. OSS works together with BSS (Business Support System) to form the core of operators' IT; through RESTful API and ICMP integration, it enables the interfacing of network status, diagnostics, configuration, and other capabilities.
Core Functions
Typical OSS functions include: Network Management — network topology, configuration, alarms; Fault Management — fault tickets, root cause analysis, handling closure; Performance Monitoring — KPI collection, performance reports, SLA monitoring; Configuration Management — network device configuration, APN distribution, PLMN Selection policy; Resource Management — spectrum, network elements, SIM resources. ICMP's Card Diagnostics card diagnostics, connection status queries, etc., may rely on interfaces provided by OSS or the operator.
Relationship with BSS
BSS is business and customer-oriented (billing, orders, customers), OSS is network and operations-oriented (network status, faults, configuration). ICMP interfaces with BSS to obtain CDR, billing; interfaces with OSS to obtain network attachment status, signal quality, and fault information. Both collaborate to support ICMP's SIM management, diagnostics, and operational capabilities.
Integration in ICMP
SimtoLink ICMP interface with operator OSS: obtain SIM connection status, Card Diagnostics diagnostic data; deliver APN, Roaming Policy and other configurations; receive network alarms and fault notifications. The platform encapsulates OSS capabilities via RESTful API, providing a unified interface to customers.
Network-Side Facts and Business-Side Facts
An operations support system stores how the network is configured, whether it is in alarm now, and how performance samples change. It answers whether a device is attached, whether a policy has reached the network element, and which step a fault ticket is stuck on. A business support system answers who bought what, how CDRs are priced, and whether an invoice has been issued. The connectivity platform sits between them: it queries the operations side or sends network-related actions, and it takes billable usage from the business side. Calling both interfaces “the carrier interface” is fine. Mixing the fields is not. A failed attach is a network fact. A charge of zero may only mean the CDR has not arrived.
Integrate only after listing the network facts the platform truly needs, such as current attach, the latest rejection reason, and whether a policy is in effect, then confirming that the operations side can query by SIM identity and how fresh the result is. Not every carrier opens a full operations support system to the customer. Sometimes only a wrapped status API is offered. After wrapping, still keep whether this is live status or the latest sample. If an alarm must be pushed to the customer, use event subscription, and state whether a further event is pushed when the alarm clears. What usage analytics observes is consumption already collected. It does not stand in for current attach on the operations side.
Using a CDR in Place of Attach Status
A common error is to see no CDR today and conclude the device is offline. The device may be online and sending almost no data, and CDRs can also arrive late. The reverse is also wrong: a CDR already priced does not mean the device is attached at this moment, because a CDR describes a past stretch of usage. Another error is to treat a successful configuration on the operations side as proof the business is provisioned. The network element may have accepted the access point name while the account still cannot be used because of an unpaid balance or a product that is not yet effective.
If the two sides each invent their own alarm identity, one fault becomes two tickets, and clearing one side leaves the other still showing unrestored. When integrating an operations support system, store the other party’s alarm number, the SIM identity, and the sample time, and state which sample the status follows. Network facts judge the connection. Business facts judge the charge. Keep both. Do not overwrite one with the other.
When the sample time is older than the agreed window, the screen should say the status has expired. It should not keep showing the previous “attached.” Automatic actions after expiry, such as suspending or resuming on that basis, should stop, and wait for a person to confirm or for a new sample. A configuration push should store the request number and the network-element receipt. If the receipt is lost, query by request number. Do not blindly send the same parameters again, or a policy that has just taken effect may be changed back.
An alarm needs both a raise record and a clear record. Receiving only the raise leaves the platform showing the fault as open after recovery. Looking only at the clear, with no match to the original alarm number, treats the clear of an old fault as a new recovery. Repeated alarms from the same network element should fold into the one that has not yet cleared, so the on-call shift does not receive dozens of identical notices. After folding, still keep the count and the time of the latest one, so it is possible to tell a fault that persists from one that flickers.
Configuration push and status query use different freshness. After a query result expires, it can only say “unknown.” It cannot keep being treated as online. A push is marked effective only when a receipt arrives, or when a later query shows the network element has adopted the new configuration. A receipt timeout is marked unknown and closed by a later query. Do not automatically send the opposite configuration while the result is unknown. The request number runs through submit, receipt, and query, so support can say whether a given access point or policy actually took effect.
Performance samples from the operations side are samples. They are not a live guarantee for every SIM. A sample can judge the coverage trend of a whole batch of devices. One sample point is not enough to decide that a single SIM has recovered. Whether a single SIM has recovered follows that SIM’s later attach, or usage on the business side. Put the operations sample, the CDR, and the platform status on three timelines side by side, so the oldest of the three is not used to deny the newest.