T-Mobile ACS 2.0 Platform

ACS 2.0 is an operations interface for administering Customer Premises Equipment connected to an Auto-Configuration Server. The product brings fleet visibility, individual device diagnostics, provisioning, logs and reporting into one operational workspace.

Telecom operations teams need to understand the state of thousands of connected devices, investigate individual device behaviour and carry out remote actions without losing operational traceability.

The system problem

A device management platform has to serve two scales at the same time: the fleet and the individual device. Operators need a quick overview, but they also need deep access to radio status, network interfaces, data models, provisioning actions and raw session history.

The design therefore has to make highly technical information navigable without hiding the detail required for operational work.

Designing for operational complexity

The core UX challenge was not a single screen. It was creating a coherent system across monitoring, diagnostics, remote configuration, troubleshooting and reporting while keeping navigation and interaction patterns predictable.

A task-based information architecture

The navigation mirrors the operator journey: begin with system health, find a device, inspect it, diagnose the network or data model, execute a provisioning action, then review logs or reports.

From navigation to task-level destinations

Reading the existing UI as a system reveals a clear hierarchy: authentication opens the ACS workspace, seven operational domains organise the primary navigation, and each domain contains the views and actions operators use to monitor, diagnose, provision and administer connected devices.

Common operator navigation paths

From architecture to interaction

Before applying the T-Mobile visual language, the wireframe stage focused on whether the operational structure worked: how quickly users could scan network health, find a device, keep selected-device context visible, move between diagnostics and provisioning, and reveal deeper technical detail only when needed. The emphasis was on hierarchy, navigation, table density, progressive disclosure and repeatable interaction patterns rather than colour or brand styling. This carousel can later show how those structural decisions evolved across dashboard, fleet, device detail, data model and provisioning flows.

How the system is made usable?

The interface keeps the technical depth of ACS operations but gives it a consistent structure. The design can be read as four deliberate moves that reduce cognitive load without removing expert-level detail.

The opening dashboard gives operators a fast read on the network before they move into a device-level task. It brings total and online device counts together with CPE session duration, rate and latency, plus active-device and network-usage views. This turns the first screen into an operational health check, reducing the need to begin with raw device tables or individual records.

The device list acts as the operational index for every CPE known to the ACS, including active, inactive, online, in-session and banned states. Operators can search, sort and page through serial number, IMEI, MSISDN, firmware, registration status, IP, last-connected time and scope, then open the device profile or perform controlled actions such as blacklist, unregister or batch unregister. Colour-coded states make fleet scanning faster.

The selected device becomes a structured workspace rather than one long technical record. Expandable sections organise Main Information, LTE Status, Wi-Fi Radio Status, Data Usage, IMS Status and Connected Hosts, while the header keeps identity and context visible. Detailed fields range from serial, IMEI, MAC, software and hardware versions to last IP, uptime, LTE signal values, SIM and IMS status, Wi-Fi activity and connected-host information.

Location and topology views connect technical device data to physical and network context. The cell-tower screen places the selected device and connected towers on a map, exposes current connection state and shows brief radio and device details such as CGI, RSRP/RSRQ and battery level. A companion Devices on Network view separates Ethernet, Wi-Fi 2.4 GHz and Wi-Fi 5 GHz clients, showing connected, disconnected and previously seen endpoints and their usage.

Rather than flattening the TR-069 data model into one table, the UI lets operators browse from the root through nested objects and parameters. Names, values, types, attributes, notification and access information, and last-updated data remain attached to the hierarchy, with search and manipulation tools for read-only and read/write parameters. The workspace also exposes AddObject and DeleteObject actions, giving expert users controlled access to the underlying CPE model.

Manual provisioning turns low-level TR-069 RPC work into a guided operation-building flow. Operators select one or more RPC methods in Device Operation Request, add them to the request, then define the relevant Action Settings, including parameter names, data types and values, before execution. The separation between request composition and settings makes actions such as GetParameterValues, SetParameterValues, AddObject and DeleteObject easier to review before they are sent to the selected device.

Completed or cancelled requests move from the pending queue into Logs, where Operations, Sessions, Calls and Reports provide different levels of evidence. Operation history shows ID, action count, status and timestamps, with expandable RPC detail, parameter or object context, fault codes and fault strings. Session logs expose session IDs, log levels and request counts with downloadable message detail, while call records add peer, duration and connection timing for deeper troubleshooting.

Reports turn selected-device data into a durable operational snapshot. Operators can generate a report with confirmation, search and expand report entries, refresh or remove report history, then export structured device information in formats including XLS, TXT and CSV. The report can combine identity, software and hardware versions, connectivity, SIM and LTE status, and signal information, supporting offline analysis and handover beyond the live ACS session.

Beyond the core device journey, ACS supports four operational flows that complete the management lifecycle: queuing device actions, managing transfer files, inspecting CWMP session evidence and administering user access. These screens reuse the same selected-device context, tables, detail reveals and confirmation patterns so operators can move between execution, audit and administration without learning a separate interaction model.

Pending operations

Review outstanding device requests by ID, action count and creation time, search the queue, expand operation details, start a new request or cancel pending work with confirmation. Once a request is completed or cancelled, its history moves to Logs / Operations.

File management

Manage the files used by device-transfer operations, including firmware entries and device-specific files. Operators can add files with type, URL, target name, credentials, size and description, while product and server-default entries remain protected from device-level editing or removal.

Session logs

Inspect individual CWMP sessions by session ID, log level and request count, then open the session to review timestamped ACS and CPE exchanges. Detailed session logs can be expanded and downloaded to support protocol-level investigation.

User management

Use Server Access to find platform users and review their name, roles, expiration and scope. Password changes are handled in a dedicated form that requires the current password and confirmation of the new password, keeping account administration separate from device operations.

Interaction patterns that keep the system coherent

Across very different technical tasks, the interface reuses a consistent set of patterns so operators do not have to relearn the product on every page.

What the product enables

The available project documentation focuses on requirements and product behaviour rather than measured KPI results. The strongest evidence of value is therefore the operational capability the system brings together in one place.

Where I would take the product next

A modern iteration could keep the depth of the operational model while improving accessibility, prioritisation and support for recurring operator tasks.