CDS API Exposure Function
CDS-AEF is a provisioning engine that gives the rest of the Slicce estate — and, where authorized, external consumers — a single point of access to the data an operator provisions once and reuses everywhere: fraud and roaming blacklists, call-screening lists, VPN dialing plans, emergency-number tables, IMEI and number-replacement rules. Every domain is backed by the same underlying data store, so a subscriber list provisioned through CDS-AEF is immediately the same list another AF or AEF reads — no separate copy to keep in sync.
Features & Benefits
One provisioning surface across many domains
Call screening subscriber lists, VPN Kosher dialing rules and groups, emergency-call URN and area tables, and IMEI change and number-replacement rules are all provisioned through the same REST API pattern — full CRUD, bulk CSV upload, and where relevant a rule-simulator endpoint. Fraud and roaming blacklist provisioning reads and writes the same underlying store today through the legacy SOAP interface.
A shared data store, not a data copy
Every domain CDS-AEF provisions is read directly by the AFs and AEFs that need it — for example, UPP-AF reads subscriber packages, blacklist countries and MCC/MNC tables straight from the same store CDS-AEF writes to. Provision once, and every consumer of that data sees the same state immediately.
Published to the operator's API framework
CDS-AEF registers and publishes its APIs to the CAPIF Core Function, so provisioning capability can be onboarded and authorized for consumption beyond the AFs and AEFs on the same network, under the same authorization and logging framework as the rest of the exposure function family.
Legacy and modern interfaces side by side
Subscriber and VPN-customer administration, built earliest, remains available over a SOAP interface for the systems already integrated against it, while every domain added since is REST first — so existing integrations keep working while new ones use the current interface.
One shared data store behind every AF and AEF
Provisioning and data access, entirely inside the operator domain
Deployed as the shared provisioning and data-access layer behind the operator's own AFs and AEFs, CDS-AEF centralizes writes and reads for blacklists, call screening, VPN dialing rules, emergency numbers and subscriber/number-replacement data, backed by a single MongoDB store.
This mode suits an operator consolidating provisioning across multiple network functions that previously each held their own copy of the same reference data.
Expose provisioning APIs to a 3rd party domain with the CAPIF CF
CDS-AEF CAPIF mode, provisioning APIs with 3rd Party Exposure
Where an operator lets a partner or managed-service provider maintain its own subset of provisioning data — a corporate VPN's dialing plan, or its own call-screening list — CDS-AEF publishes the relevant service APIs to the CAPIF Core Function, which onboards the API invoker, applies the negotiated security method and routes authorized requests to the exposure function.
Technical specifications
Blacklist & Fraud Provisioning
Slicce internal (SOAP)
Call Screening (PCL)
Slicce internal
VPN Kosher Dialing
Slicce internal
Emergency Call (URN/Area)
Slicce internal
IMEI / Number Replacement
Slicce internal
Subscriber / VPN Customer Admin
Slicce internal (SOAP)
CAPIF
3GPP TS 29.222
Transport
HTTP, JSON (REST)
SOAP/XML (legacy)
Data Store
MongoDB (TCP)
Architecture
3GPP TS 29.222 (CAPIF) onboarding — Slicce-internal shared provisioning layer, no dedicated architecture document
Ask us for the swagger file...
Contact us