3 min read
Watch our training on connection request basics and XMPP connection requests in our TR-069 training series.
Though one of the fundamental principles of CWMP (TR-069) is that the CPE endpoint is always the one to initiate a connection, Autoconfiguration Servers (ACS) can use the TR-069 Connection Request feature to stimulate a CPE to begin a session. This is often used when the ACS must contact the CPE immediately, such as when configuring the device for a new service after it has already been bootstrapped by the system.
When CWMP was originally designed, it focused on devices acting as gateways into the customer premises - commonly refered to as home gateways. Because these devices were directly addressable on the Internet, it was easy to deliver TR-069 Connection Requests to the device by having the device expose an accessable URL for the ACS to make such requests. The basic Connection Request is done via the HTTP GET method to the URL specified by the CPE (this URL is required to be sent in every Inform message to the ACS, so that the ACS always knows what the current URL is). When successful, the device initiates a CWMP session with the 6 CONNECTION REQUEST event in the Inform method’s event list.
As more devices became manageable by TR-069, however, devices that sat behind the gateway that was likely using Network Address Translation (NAT) could not simply expose a directly addressable URL without the CPE setting up a complex port mapping. Since this was undesirable, Annex G of TR-069 specified a way to use STUN (Session Traversal Utilities for NAT) protocols to allow the devices to accept HTTP GET requests through the gateway.
STUN is not the best solution, however. For starters, it is UDP based, and the ACS cannot guarantee that its CRs have arrived. As newer protocols appeared, the Broadband Forum TR-069 developers looked towards a messaging bus solution using the eXtensible Messaging and Presence Protocol (XMPP) to allow Connection Requests to occur. This is now defined in Annex K of TR-069 Amendment 5.
To use this feature, a CPE must support the XMPPBasic:1 and XMPPConnReq:1 profiles from the CWMP data model. The ACS makes a connection to an XMPP Server, and configures the CPE via TR-069 to use this XMPP Server for its Connection Requests. The CPE then establishes a secure connection to the agreed upon XMPP server. From then on, the ACS can communicate a Connection Request via the XMPP Server to the Jabber ID of the CPE. This Connection Request is simply an XMPP IQ Stanza containing a Connection Request message to its XMPP Server specifying the “to” address that matches the CPE where the Connection Request needs to be sent and a “from” address that matches one of the allowed Jabber IDs.
When this is complete, the CPE is stimulated to initiate a CWMP session with the ACS as usual via HTTP. Since the ACS is communicating the Connection Request via XMPP, there’s no reason to worry about Network Address Translation.
Even if a device supports XMPP Connection Requests, HTTP Connection Requests are still required by TR-069. Luckily, you can easily test this feature in CDRouter, which includes the XMPP feature in the TR-069 add-on. After configuring CDRouter for XMPP connection requests, CDRouter will use its own XMPP server to allow its ACS simulator to connect and to communicate with a CPE that supports XMPP Connection Requests. Since this is automated, you can build it into your existing TR-069 testing runs to ensure that your device correctly implements XMPP CRs and can reliably perform all of its TR-069 functions with this feature enabled, and test the traditional HTTP connection request as well.
