When a TR-069-capable device connects to the network for the first time, it obtains an IP address and initiates a connection session with ACS using an Inform Request remote procedure call (RPC) that contains event codes indicating the session purpose.
(InternetGateway)Device.ManangementServer.ManagementURLparameter. There are three ways that the device can obtain the ACS URL.
- It can be hard-coded into the device firmware by factory default.
- It can be locally configured on the device.
- The device can discover it.
Often technicians pre-configure devices before shipment to customer premises, or they load a local software installation tool for the broadband subscriber to use. For a device to discover the ACS URL, often the DHCP server that assigns it an IP address also provides the ACS URL through DHCP options or, in the case of DOCSIS devices, TLVs.
Discovering DOCSIS Cable Gateways
The CableLabs eRouter specification, standardized in 2011, defines how all vendor DOCSIS Cable Gateways are provisioned to communicate with an auto configuration server. The eRouter Initialization Mode TLV 202 conveys this information during provisioning.
Specifically the valid TLV options are:
TLV 202. The encodings in the eCM configuration file encapsulated in Type 202 are for exclusive use of the eRouter and these TLVs are transferred to the eRouter from the eCM in a vendor specific manner. The eRouter uses these TLVs for its initialization.
TLV 202 subtype 2 (202.2) TR69ManagementServer. This encoding specifies aspects of the TR-069 Management Server object used by the cable modem eRouter
TLV 202.2 subtype 1 (202.2.1) Enable CWMP. This encoding specifies the
Device.Management.Server.Enable CWMP Parameter as required from TR-181-i2a3. Value is 0:false, 1:true
TLV 202.2 subtype 2 (202.2.2) URL. This encoding specifies the
Device.ManagementServer.URL parameter from TR-181-i2a3
TLV 202.2 subtype 3 (202.2.3) Username. This encoding specifies the
Device.ManagementServer.Username parameter from TR-181-i2a3
TLV 202.2 subtype 4 (202.2.4) Password. This encoding specifies the
Device.ManagementServer.Password parameter from TR-181-i2a3
TLV 202.2 subtype 5 (202.2.5) ConnectionRequestUsername. This encoding specifies the
Device.ManagementServer.ConnectionRequestUsername parameter from TR-181-i2a3
TLV 202.2 subtype 6 (202.2.6) ConnectionRequestPassword. This encoding specifies the
Device.ManagementServer.ConnectionRequestPassword parameter from TR-181i2a3
TLV 202.2 subtype 7 (202.2.7) ACSOverride. If enabled, this encoding specifies the CPE MUST accept the ACS URL from the eCM configuration file even if the auto configuration server has overwritten the TLV 202 related values. If disabled, the CPE accepts the CM configuration file values only if the auto configuration server has not overwritten the ACS URL. Value is 0:false, 1:true
A device uses the ACS URL in order to initiate a CWMP session. The format of the ACS URL will differ based on the authentication method you use.
|Authentication Method||URL Format|
|CPE Authentication via LDAP||http://acs.example.com:7547/service/cwmpDigest|
LDAP_DEVICE_PASSWORD_ATTRIBUTEparameters. Refer to the ACS CLI Reference for information about configuring these parameters.
On the first contact with ACS, a device reports all its supported parameters, which can be an excessively large list. ACS defaults to this “all at once” discovery algorithm, as defined in the TR-069 protocol, and it works for the vast majority of devices.
Sometimes, a device is unable to handle the transfer of this list due to memory or CPU processor limitations. As a backup method, you can change the discovery algorithm to a batch discovery mode which enables you to split the number of parameters the device reports into batches.
When the device completes a successful discovery cycle it changes state and reports the status “Synchronized”. You can view the sync status for a device from the device summary in the GUI.
Devices have five possible states.
|Undiscovered||The service has a record for the device, but
the device has not run through a successful discovery cycle.
Note: A device record can be created in advance over the API. Devices that are pre-provisioned in this manner will never be assigned an Undiscovered status.
|Synchronized||The device completed a successful discovery cycle and has no pending operations.|
|Discovery Failed||The device could not be fully discovered by CWMP. Enough information was discovered in order to uniquely identify the device and create a record in the service.|
|Not Synchronized||The device has pending operations. The service performs pending operations during the next scheduled window.|
|Synchronize Failed||The device has failed operations that require user interaction. This can happen when value settings are not communicated properly or when a configuration send operation fails.|
Device records can be created using a zero-touch, self-install, provisioning model or a pre-provisioning model.
First Contact Device Records
When you use a zero-touch provisioning model, devices records are created on first contact with the service. In this model, new and unknown devices are sent to the walled garden device group until the device can be associated with a service and customer.
Pre-Provisioned Device Records
When you use a pre-provisioned model, you create device records before first contact with the service over the northbound API through SAC or a third-party application.
When integrated with SAC, a SAC-initiated API call requests ACS to create the device record. If the device record already exists in ACS, then SAC sends a request to update the device record.
ACS Connection Initiation
Devices always initiate communication sessions. However, ACS can request a device to start a session using the Connection Request mechanism. This mechanism relies on the device using a public IP address that can be contacted directly by the ACS.
When a TR-069 device is operating behind a NAT gateway in private IP space, ACS is unable to deliver a connection request because the device is not exposed to the Internet. To enable ACS to request session initiation, the TR-069 standard defines two methods for the traversal of connection requests over NAT.
The recommended NAT traversal technique is to use XMPP. Legacy devices and firmware, which implemented early support for TR-069, may not support the latest data model which defines XMPP objects. For these devices, ACS supports STUN as an alternative NAT traversal technique.
NAT Traversal Using XMPP
When using XMPP, ACS and the device are clients to an XMPP server which relays messages between the two. You can pre-provision a device with the XMPP server location for connection requests or, ACS can provision the XMPP credentials and location, on discovery or on periodic inform.
To use XMPP, your device must support XMPP according to Annex K of the TR-069 standard, Amendment 5.
NAT Traversal Using STUN
When a CPE is deployed to a customer by an operator, ACS determines which port it can use to communicate with devices operating in private IP space behind that gateway (for management purposes).
To register communications, the operator provisions the gateway device with the location of the STUN server in the network. The STUN server publishes the reachable IP address and ports for devices behind those gateways, in private IP space, to ACS. This is called a notification-based approach.
UDPConnectionRequest, otherwise, it uses the regular (TCP)