CWMP

CWMP Transaction Sessions

What is a transaction session?

TR-069 defines a transaction session as a sequence of Remote Procedure Calls (RPCs), both requests and responses. A transaction session is completed when both parties (CPE and ACS) have no messages left to send.

The CPE has an important role:

l         All transaction sessions are established by the CPE.

l         The CPE maintains a TCP connection (persistent HTTP connection) for the duration of the session.

l         The CPE is also responsible for closing a transaction session.

Session establishment

All transaction sessions are established by the CPE, by sending an Inform RPC to the ACS.

We distinguish two types of transaction sessions:

­ CPE initiated sessions:

­ Asynchronous ACS initiated sessions: the CPE establishes a transaction session to the ACS after receipt of a Connection Request from the ACS.

 

A CPE MUST call the Inform method to initiate a transaction sequence whenever a session with an ACSis established.  The Inform RPC contains the Inform event argument, to indicate the cause(s) of the transaction session establishment.

RPC :Reboot

When the CPE receives a Reboot RPC from the ACS, following steps are executed:

1 The ongoing transaction session is finalized. This means that all outstanding requests are sent and all responses are received. After finalization, the ongoing transaction session is closed.

2 The CommandKey argument of the Reboot message must be remembered across the reboot via either

l         Writing it to the memory prozone. This is a memory protected zone that is not reinitialized after a “warm” reboot.

l         Writing it to the configuration file (user.ini).

3  A “warm” reboot is triggered.

4  After reboot, an Inform message is sent. The Event argument contains:

l          EventCode: “1 BOOT”, “M Reboot” and possibly other EventCodes.

l          CommandKey: the value of the CommandKey argument of the Reboot message is sent as

CommandKey for the EventCode “M Reboot”.

Response: This method response has no arguments.

Session re-establishment

In some cases, the TCP connection is closed before the transaction session is completed. For example, the session is interrupted by the ACS. If necessary, the CPE re-establishes the TCP connection to the ACS.

In this case, the Inform RPC contains:

­ Inform event: if the session is re-established because of a pending TransferComplete RPC to be sent to the ACS, the Inform event is “7 TRANSFER COMPLETE”. In other cases, the Inform message contains the undelivered Inform events from the interrupted session.

­ Cookie: the Inform message includes the transaction Cookie (if received from the ACS during the transaction session) as HTTP header field.

Factory reset

The FactoryReset RPC resets the CPE to its factory default state. When a problem occurs and the cause is not found, a reset to (pre-provisioned) ISP defaults via the FactoryReset RPC triggers the zero-provisioning use case. Although some user configuration might be lost, a reset to factory defaults guarantees auto-configuration and service activation as described in the “Zero-provisioning” use case.

When the CPE receives a FactoryReset RPC from the ACS, following steps are executed:

1 The ongoing transaction session is finalized. This means that all outstanding requests are sent and all responses are received. After finalization, the ongoing transaction session is closed.

2 A reset to factory defaults is triggered.

l         The user configuration file (user.ini) is deleted.

l          A configuration load is performed: in absence of the user configuration file, the service provider defaults (ISP.def) are loaded. In absence of these service provider defaults, factory defaults are loaded.

This method response has no arguments.

 

Download

The Download RPC may be used by an ACS to cause the CPE to download a specified file from the designated location.

When the CPE receives a Download RPC from the ACS, following steps are executed:

1 A DownloadResponse RPC is sent with Status argument set to 1 (the download is not yet completed).

2 The ongoing transaction session is closed.

3 Whether or not steps are executed before the file transfer, depends on the FileType argument of the Download RPC. For more information, see “3.1 Firmware Upgrade” on page 32 and “3.2 Configuration Update” on page 41.E-DOC-CTC-20071119-0003 v1.0

4 File transfer is initiated: a HTTP GET message is sent by the CPE to the file server.

5 File transfer is completed (or an error occurred).

6 A new transaction session to send the TransferComplete RPC is established after loading the downloaded configuration file or firmware image. The exact steps depend on the FileType argument of the Download RPC. For more information, see “3.1 Firmware Upgrade” on page 32 and “3.2 Configuration Update” on page 41.

 

Bootstrapped

This variable indicates the BOOTSTRAP event state.

If this event state is set to yes, the first Inform RPC sent to the ACS includes the Bootstrap event. On receiving an InformResponse, this event is considered delivered and the event state is set to no.

This variable is set to yes if the ACS URL is reconfigured.

 

 

 

IP Ping Diagnostics Test

 

passive notification

active notification