Every TR-069 network has two halves: the client code inside each router, modem or ONT, and the ACS server those devices call home to. The client gets most of the attention because it’s what vendors ship. The server is where the operational pain lives, because that’s what has to stay up when 100,000 devices reboot after a regional power cut.
This is an explainer on how an ACS works: the CWMP session, the connection request, the data model, and then the part most articles skip, which is sizing. It closes with how to choose between open-source, commercial and custom builds. If you want the wider picture of TR-069 in an ISP first, read our guide to TR-069 remote device management for ISPs. The ACS is the server half of that architecture.
What is an ACS server, or auto configuration server?
An ACS server (auto configuration server) is the management system that TR-069 devices connect to for configuration, monitoring, diagnostics and firmware updates. Devices open CWMP sessions to the ACS over HTTPS, and the ACS uses those sessions to read and change parameters in each device’s data model.
The Broadband Forum defines the protocol in TR-069, the CPE WAN Management Protocol. CWMP messages are SOAP 1.1 envelopes carried over HTTP 1.1, secured with TLS. The spec defines the RPCs a device must support and the RPCs the ACS must support. What it doesn’t define is how you build the server, store device state, or scale it. That’s left to you.
A production TR-069 ACS usually has four parts:
- The CWMP endpoint that devices talk to.
- A file server for firmware images and config files.
- A database holding device records, parameter values and task queues.
- A northbound API and UI for your OSS/BSS, helpdesk and NOC.
How a TR-069 ACS finds and provisions devices
Before anything else, the device has to know where the ACS is. The TR-069 spec allows three ways: a URL configured locally, a URL delivered by DHCP (option 43 or 125 for DHCPv4, option 17 for DHCPv6), or a factory default URL baked into the firmware. Most ISPs use DHCP or a factory default set by the CPE vendor under contract.
On first contact the device sends an Inform with the 0 BOOTSTRAP event. That’s the ACS’s cue to treat it as new: match it to a subscriber, push the service profile (WAN settings, Wi-Fi SSID and password, VoIP lines), check the firmware version and schedule an upgrade if needed. This is zero-touch provisioning, and it’s the first job an ACS does for every device it will ever manage. Our zero-touch provisioning guide covers the workflow in detail.
The subscriber match is where most provisioning designs succeed or fail. The Inform carries the device’s OUI, product class and serial number. You need a reliable way to connect that identity to an account, whether through pre-registration from the warehouse, a PPPoE username, or a line ID from the access network.
The steps of a CWMP session
Here’s what happens in a typical session, in order:
- The device opens an HTTPS connection to the ACS and sends an Inform. The Inform carries its identity, event codes (such as 1 BOOT, 2 PERIODIC, 4 VALUE CHANGE or 6 CONNECTION REQUEST) and a set of parameter values.
- The ACS replies with an InformResponse.
- The device sends any RPCs it has queued for the ACS, such as TransferComplete after a firmware download. When it’s done, it sends an empty HTTP POST.
- The ACS sends its RPCs one at a time: GetParameterValues, SetParameterValues, AddObject, DeleteObject, Download, Reboot and so on. The device answers each.
- When the ACS has nothing left to send, it replies with an empty response (HTTP 204) and the session ends.
As a flow, it looks like this:
CPE ACS | --- HTTPS POST: Inform ------------> | | <-- InformResponse ----------------- | | --- TransferComplete (if queued) --> | | <-- TransferCompleteResponse ------- | | --- empty POST --------------------> | | <-- GetParameterValues ------------- | | --- GetParameterValuesResponse ----> | | <-- SetParameterValues ------------- | | --- SetParameterValuesResponse ----> | | <-- 204 No Content (session ends) -- |
Two details matter for anyone building or running an ACS. The device, not the ACS, always opens the session. And it’s strictly request-response: one RPC at a time. A session that pushes 40 parameter changes and a firmware download involves many round trips, so latency between device and ACS matters more than raw bandwidth.
Connection requests: how the ACS reaches a device
If the device always initiates, how do you make a change right now, while a customer is on the phone? With a connection request.
The ACS sends an HTTP GET to the ConnectionRequestURL that the device reported in its Inform, authenticated with HTTP digest. The device doesn’t act on the GET itself. It simply opens a new session to the ACS with the 6 CONNECTION REQUEST event, and the ACS delivers its queued work inside that session.
This breaks when the device sits behind NAT, which is common with carrier-grade NAT on residential lines. The spec gives two workarounds: STUN (Annex G), where the device keeps a UDP binding open so the ACS can signal through the NAT, and XMPP (Annex K), where the device holds a persistent connection to an XMPP server that relays the request. If your ACS can’t reach a large share of the fleet on demand, your helpdesk will feel it long before your NOC does.
The data model an ACS works with
TR-069 moves parameters, but the meaning of those parameters lives in the data model. The Broadband Forum publishes them on its CWMP data models site. The current root model is Device:2 (TR-181), which has deprecated the older InternetGatewayDevice:1 root from TR-098. Service models such as VoiceService (TR-104) and STBService (TR-135) sit under Device.Services.
Parameters are dotted paths, like Device.WiFi.SSID.1.SSID or Device.ManagementServer.PeriodicInformInterval. The ACS can discover what a device supports with GetParameterNames and set notification attributes with SetParameterAttributes, so the device reports a value change without waiting to be polled.
In practice, you’ll run a mixed estate. Older gateways often still speak InternetGatewayDevice, newer ones speak Device:2, and every vendor has extensions under its own prefix. A lot of the real work in an ACS is the mapping layer that lets your helpdesk say “change the Wi-Fi password” without caring which of the three schemas that device uses.
Sizing an ACS server for your fleet
Sizing an ACS is mostly arithmetic. The numbers below are illustrations, not benchmarks. Plug in your own.
Periodic inform intervals
Every device calls in once per PeriodicInformInterval. For 150,000 devices, the average informs per second are:
- 24-hour interval: about 1.7 informs per second
- 1-hour interval: about 42 informs per second
- 15-minute interval: about 167 informs per second
- 5-minute interval: 500 informs per second
Shorter intervals give fresher data and cost you a lot of capacity. Our view: keep the periodic interval long, use value-change notifications for the few parameters you need quickly, and rely on connection requests for anything interactive.
Concurrent sessions
Concurrent sessions are roughly the arrival rate multiplied by average session length. At 42 informs a second and two seconds per session, you have around 84 sessions open at once. A session that runs a firmware check and a dozen parameter reads can take much longer, so measure your real session times before you size anything.
Inform storms
The average is not the problem. The peak is. After a power cut or a firmware push, thousands of devices send 1 BOOT informs within minutes. The spec’s session retry policy makes devices back off with growing wait intervals when the ACS fails to respond, which helps, but you should also spread periodic informs by setting PeriodicInformTime per device instead of letting the whole fleet align on the hour.
Database load and high availability
Every Inform writes something. Parameter values, event logs and task states add up fast, and the database is usually the first thing to fall over. Keep the hot path (current device state and pending tasks) separate from history and reporting. For availability, run several stateless CWMP front ends behind a load balancer, keep the file server on separate capacity so firmware downloads don’t starve sessions, and make sure a failed node doesn’t leave tasks half-applied.
Open-source, commercial or custom ACS
There are three routes, and each fits a different operator.
- Open-source ACS: a good fit for smaller ISPs and labs with in-house Node.js or Java skills. Watch out: you own security patches, scaling and vendor quirks.
- Commercial ACS: a good fit for operators who want a supported product and a vendor to call. Watch out for per-device licensing and limited control over the roadmap.
- Custom build: a good fit for operators with specific integration, reporting or data residency needs. Watch out for build time and the need for a team that knows CWMP in depth.
On the open-source side, GenieACS is the most active project. It’s AGPLv3-licensed, runs on Node.js with MongoDB, and splits into separate CWMP, northbound API, file server and UI services. The project recommends its stable 1.2 line for production, with 1.3 still in development, and offers commercial support. FreeACS, a Java and MySQL alternative under the MIT license, was archived on GitHub in September 2024 and is no longer maintained, so we wouldn’t start a new deployment on it. Check the AGPL terms with your legal team if you plan to modify GenieACS and offer it as a service.
Hosting is a separate decision. A cloud-hosted ACS is easier to scale for inform storms. An on-prem ACS keeps device and subscriber data inside your network, which some regulators and operators require. If you’re weighing that trade-off, our enterprise cloud migration guide covers the broader questions.
Here’s where our own experience fits. For SCOM Technologies, we built a TR-069 NMS with a full CWMP implementation and an Auto-Configuration Server for device provisioning and firmware management, plus SNMP-based reporting and a real-time monitoring dashboard. It manages 1.5 lakh+ (150,000+) ADSL, VDSL and ONT devices. Combining CWMP management and SNMP reporting in one operational view is the kind of requirement that pushes an operator toward a custom build rather than an off-the-shelf ACS.
Frequently asked questions
How does a TR-069 ACS work?
A TR-069 ACS waits for devices to connect. Each device opens an HTTPS session and sends an Inform with its identity and event codes. The ACS replies, then sends RPCs such as GetParameterValues, SetParameterValues or Download within the same session. To reach a device on demand, the ACS sends a connection request that asks the device to open a new session.
What is the difference between an ACS and a CPE?
The CPE (customer premises equipment) is the router, modem, ONT or set-top box at the subscriber’s site, running a TR-069 client. The ACS is the server in the operator’s network that manages those devices. The CPE always opens the CWMP session, and the ACS decides what to read, change or upgrade once the session is open.
Which port does a TR-069 ACS use?
CWMP runs over HTTP or HTTPS, so the ACS listens on whatever port its URL specifies, typically 443 when using HTTPS. Port 7547 is commonly used on the device side for connection requests, and some ACS products also use it for the CWMP endpoint. Use HTTPS with valid certificates in production rather than plain HTTP.
Is an open-source ACS good enough for an ISP?
For smaller fleets and labs, often yes. GenieACS is actively developed and its maintainers say it scales horizontally to hundreds of thousands of devices. The trade-off is that you own patching, scaling, monitoring and device-specific fixes. Larger operators usually need either commercial support or a team that knows CWMP and the chosen codebase well.
Should we choose a self-hosted or cloud ACS?
Choose cloud if elastic capacity for inform storms and lower infrastructure effort matter most. Choose self-hosted if regulation, data residency or internal policy requires subscriber and device data to stay in your network. Either way, the sizing questions are the same: inform rate, session length, database write load and how the system behaves when a node fails.
How does an ACS push firmware to a CPE?
The ACS sends a Download RPC with the firmware file’s URL, type and size. The CPE fetches the file, usually from a separate file server, installs it and reboots. In its next session it reports the result with a TransferComplete RPC, and the ACS confirms the new version from the Inform. Staged rollouts by model and region limit the damage from a bad image.
Where to start
If you’re choosing or rebuilding an ACS, start with your numbers: device count, planned inform interval, measured session length and the worst reboot storm you’ve seen. Those four figures size the system better than any vendor datasheet.
Our product engineering team built the TR-069 NMS behind the SCOM deployment. If you’d like help working through those numbers, ask us to size an ACS for your fleet. Send your device count and mix, and we’ll come back with a capacity and architecture outline.