CDRouter TR-069 Test Summaries (Full)

    6.1.1.1 Purpose

    The purpose of this test is to validate that a CPE can establish an authenticated HTTP
    session with the ACS using basic authentication.  This test should be performed only if
    the ACS uses or can be configured to use basic authentication.

    6.1.1.2 Procedure

      1. If necessary, configure the ACS to use basic HTTP authentication.
      2. The CPE is stimulated to initiate an HTTP session with the ACS. Possible
         methods involve various TR-069 specific mechanisms, or stimulating the CPE
         directly if such a mechanism exists through a non-standard interface.
      3. The ACS issues a "401 Unauthorized" HTTP challenge and HTTP authentication
         proceeds normally.

    6.1.1.3 Success Metric

      1. The CPE and ACS are able to successfully establish an authenticated HTTP
         session.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    6.1.2.1 Purpose

    The purpose of this test is to validate that a CPE can establish an authenticated HTTP
    session with the ACS using digest authentication.  This test should be performed only if
    the ACS uses or can be configured to use digest authentication.

    6.1.2.2 Procedure

      1. If necessary, configure the ACS to use digest HTTP authentication.
      2. The CPE is stimulated to initiate an HTTP session with the ACS. Possible
         methods involve various TR-069 specific mechanisms, or stimulating the CPE
         directly if such a mechanism exists through a non-standard interface.
      3. The ACS issues a "401 Unauthorized" HTTP challenge and HTTP authentication
         proceeds normally.

    6.1.2.3 Success Metric

      1. The CPE and ACS are able to successfully establish an authenticated HTTP
         session.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    6.1.3.1 Purpose

    The purpose of this test is to validate that a CPE and ACS can successfully interact using
    cookies across multiple CWMP sessions.

    6.1.3.2 Procedure

      1. The ACS is configured to use CWMP session cookies if it does not use them by
         default.  Any mode of CPE authentication by the ACS can be used in this test.
      2. The CPE is stimulated to initiate a new CWMP session with the ACS using any of
         the mechanisms outlined in Test 5 - CWMP Session Initiation. The CPE
         establishes a TCP connection and sends an HTTP request with Inform message.
         The CPE messages to the ACS do not contain any session cookies.
      3. During HTTP authentication stage or as part of the InformResponse RPC, the
         ACS sets an HTTP cookie in HTTP response.
      4. After the cookie has been set, the CPE resends the cookie in all subsequent HTTP
         requests within the same CWMP session, including any final empty posts used to
         indicate session termination.
      5. The ACS and CPE successfully terminate the CWMP session.
      6. Repeat steps 2-5.  The CPE does not return the cookie from the previous session
         in its messages with the ACS.

    6.1.3.3 Success Metric

      1. The CPE and ACS are able to successfully use session cookies across multiple
         CWMP sessions.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    6.1.4.1 Purpose

    The purpose of this test is to validate that the ACS can establish an authenticated HTTP
    session with a CPE.

    6.1.4.2 Procedure

      1. The ACS is stimulated to initiate an HTTP session with the CPE. Possible
         methods involve various TR-069 specific mechanisms, or stimulating the ACS
         directly if such a mechanism exists through a non-standard interface.
      2. The CPE issues a "401 Unauthorized" HTTP challenge and HTTP authentication
         proceeds normally.

    6.1.4.3 Success Metric

      1. The ACS and CPE are able to successfully establish an authenticated HTTP
         session.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    6.2.1.1 Purpose

    The purpose of this test is to validate that the ACS and CPE can interact over SSL, using
    server certificate authentication for the ACS and basic authentication for the CPE.  This
    test should be performed only if the ACS uses or can be configured to use basic
    authentication.

    6.2.1.2 Procedure

      1. Enable SSL on both ACS and CPE.
      2. If necessary, configure the ACS to use basic HTTP authentication.
      3. The CPE is stimulated to initiate an SSL session with the ACS. Possible methods
         include various TR-069 specific mechanisms, or stimulating the CPE directly if
         such a mechanism exists through a non-standard interface.
      4. The CPE sends a request to the ACS and receives a valid response at either the
         HTTP or CWMP layer.

    Note that because the traffic between the device and server is encrypted, inspection of the
    traffic via a protocol analyzer will not be possible.

    6.2.1.3 Success Metric

      1. The CPE and ACS are able to successfully establish an SSL session and pass data
         over an encrypted link.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    6.2.2.1 Purpose

    The purpose of this test is to validate that the ACS and CPE can interact over SSL, using
    server certificate authentication for the ACS and digest authentication for the CPE.  This
    test should be performed only if the ACS uses or can be configured to use digest
    authentication.

    6.2.2.2 Procedure

      1. Enable SSL on both ACS and CPE.
      2. If necessary, configure the ACS to use digest  HTTP authentication.
      3. The CPE is stimulated to initiate an SSL session with the ACS. Possible methods
         include various TR-069 specific mechanisms, or stimulating the CPE directly if
         such a mechanism exists through a non-standard interface.
      4. The CPE sends a request to the ACS and receives a valid response at either the
         HTTP or CWMP layer.

    Note that because the traffic between the device and server is encrypted, inspection of the
    traffic via a protocol analyzer will not be possible.

    6.2.2.3 Success Metric

      1. The CPE and ACS are able to successfully establish an SSL session and pass data
         over an encrypted link.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    6.2.3.1 Purpose

    The purpose of this test is to validate that the ACS and CPE can interact over SSL, using
    server certificate authentication for the ACS and client certificate authentication for the
    CPE.

    6.2.3.2 Procedure

      1. Enable SSL on both ACS and CPE.
      2. Configure the ACS to request client certificates from the CPE.
      3. The CPE is stimulated to initiate an SSL session with the ACS. Possible methods
         include various TR-069 specific mechanisms, or stimulating the CPE directly if
         such a mechanism exists through a non-standard interface.
      4. The CPE sends a request to the ACS and receives a valid response at either the
         HTTP or CWMP layer.

    Note that because the traffic between the device and server is encrypted, inspection of the
    traffic via a protocol analyzer will not be possible.

    6.2.3.3 Success Metric

      1. The CPE and ACS are able to successfully establish an SSL session and pass data
         over an encrypted link.

    NOTE: During the SSL session establishment, the ACS will request a client
    certificate from the CPE. The certificate that is returned is not
    validated against a specific CA. However, if a certificate is not returned
    by the CPE the test will fail.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    6.2.4.1 Purpose

    The purpose of this test is to ensure that the CWMP system properly handles sessions that
    are initiated with invalid cerificate information.

    6.2.4.2 Procedure

      1. Prior to testing, ensure ACS side certificates are signed with the ACS hostname
         rather than IP address.
      2. Enable SSL on both ACS and CPE.
      3. Configure the CPE to use an ACS URL containing the ACS IP address instead of
         its hostname.

         NOTE: CDRouter will actually change the ACS certificate instead of reconfiguring
         the CPE. If the CPE is reconfigured, the CDRouter ACS will not be able to change
         the configuration back without manual intervention.

         NOTE: If the default certificates provided with CDRouter are not used for this
         test, the CPE must have also have QA Cafe's root CA installed prior to running
         this test. If the QA Cafe root CA is not installed, the CPE may reject the
         certificate due to an unknown CA error, as opposed to actually validating the
         common name on the certificate.

      4. The CPE is stimulated to initiate an SSL session with the ACS. Possible methods
         include various TR-069 specific mechanisms, or stimulating the CPE directly if
         such a mechanism exists though a non-standard interface.

         NOTE: CDRouter will us a ConnectionRequestURL attempt to request a new CWMP session.

      5. Allow the ACS to present its certificate.
      6. Allow the CPE to reject the invalid certificate.

    6.2.4.3 Success Metric

      1. The CPE and ACS do not establish a connection with invalid certificates.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    6.3.1.1 Purpose

    The purpose of this test is to validate that a LAN-based CPE can use DHCP
    vendor options to exchange information with an IGD. This test is specific
    to CPEs and IGDs that implement TR-111 Part 1.

    This test is intended to verify that a CPE and an IGD support TR-111 Part 1
    DHCP requirements. Successful completion of this test does not require that
    the CPE and IGD implement full support for TR-111 Part 1, but it does
    require that they implement the DHCP Vendor Options requirements from
    TR-111 Section 1.2.5.

    6.3.1.2 Procedure

      1. The CPE includes DHCP vendor options (as described in TR-111 Section
         1.2.5) in a DHCPDISCOVER, DHCPREQUEST or DHCPINFORM request.
      2. The IGD receives and parses the DHCP request and returns a
         DHCPOFFER or DHCPACK response (as appropriate) that includes DHCP
         vendor options (as described in TR-111 Section 1.2.5).
      3. The CPE receives and parses the DHCP response

    6.3.1.3 Success Metric

      1. The CPE is able to communicate DHCP Vendor options to the IGD
      2. The IGD is able to communicate DHCP vendor options to the CPE


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    6.4.1.1 Purpose

    The purpose of this test is to validate that a LAN-based CPE can use STUN to detect the
    presence of a NAT-enabled IGD, to determine the IGDs WAN IP address, and to
    maintain an active UDP NAT binding in the IGD. This test is specific to CPEs and
    ACSes that implement TR-111 Part 2.

    This test is intended to verify that a CPE and an ACS support TR-111 Part 2 STUN
    requirements. Successful completion of this test does not require that the CPE and ACS
    implement full support for TR-111 Part 2, but it does require that they implement its
    STUN-related requirements.

    6.4.1.2 Procedure

      1. The CPE configures and enables STUN, and starts sending STUN Binding
         Request messages to the ACS's STUN server (address and port to be agreed with
         the ACS vendor).
      2. The ACS's STUN server receives and responds to these messages.
      3. The CPE's STUN client discovers the NAT device (i.e. the IGD), and maintains
         an open NAT binding through which the ACS can send unsolicited packets.
      4. The ACS discovers the public IP address and port associated with this open NAT
         binding (this is done via STUN, via an alernative TR-111 Part 2 mechanism, or
         directly by the CPE vendor).
      5. The ACS sends a UDP message to this public IP address and port.

    6.4.1.3 Success Metric

      1. The CPE is able to discover the NAT device, and the public IP address and port of
         the open CPE binding.
      2. The ACS is able to discover the public IP address and port of the open NAT
         binding.
      3. The ACS is able to send a UDP message to the public IP address and port of the
         open NAT binding (and its arrival on the LAN is verified using Ethereal or
         equivalent).


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.1.1.1 Purpose

    The purpose of this test is to enable vendors to verify session establishment and basic
    interoperability of the CPE and ACS Inform handshake, which is the basis of all other
    interactions.

    An ACS may need to perform some special work on first contact with a given CPE, in
    which case the Inform may need to include the "0 BOOTSTRAP" event code.

    7.1.1.2 Procedure

    1. The CPE is stimulated to send an Inform to the ACS (see the above note
    concerning the "0 BOOTSTRAP" event code).  Possible methods include setting
    a periodic inform interval in some fashion, changing a parameter that requires
    forced active notification, or stimulating the CPE directly if such a capability
    exists through a non-standard interface.
    2. Upon successful receipt of the Inform message, the ACS sends an
    InformResponse message to the CPE.
    3. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
    successfully terminates the session with the ACS.

    7.1.1.3 Success Metric

    1. The CPE and ACS are able to successfully establish a CWMP session with each
    other.
    2. The CPE and ACS are able to successfully terminate the CWMP session.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.2.1.1 Purpose

    Building upon the successful ability to exchange a basic CPE-initiated Inform message,
    this test examines the ability of the ACS to initiate interaction with the device by making
    a Connection Request.

    7.2.1.2 Procedure

    1. The ACS issues an HTTP GET to the ConnectionRequest URL specified by the
    CPE in the Inform message in Test 5 - CWMP Session Initiation.
    2. The CPE then initiates a CWMP session with the ACS by sending an Inform
    message.
    3. The ACS sends an InformResponse message to the CPE.
    4. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
    successfully terminates the session with the ACS.

    7.2.1.3 Success Metric

    1. The ACS and CPE are able to successfully establish a CWMP session.
    2. The ACS and CPE are able to successfully terminate the CWMP session.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.2.2.1 Purpose

    Building upon the successful ability to exchange a basic CPE-initiated Inform message,
    this test examines the ability of the ACS to initiate interaction with the device by making
    a Connection Request.

    7.2.2.2 Procedure

    1. The ACS issues a UDP HTTP GET (as specified in TR-111 Section 2.2.2.3) to
    the UDPConnectionRequestAddress (address and port) that the ACS will
    already have discovered (TR-111 Section 2.2.2.2).
    2. The CPE then initiates a CWMP session with the ACS by sending an Inform
    message.
    3. The ACS sends an InformResponse message to the CPE.
    4. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
    successfully terminates the session with the ACS.

    7.2.1.3 Success Metric

    1. The ACS and CPE are able to successfully establish a CWMP session.
    2. The ACS and CPE are able to successfully terminate the CWMP session.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.3.1.1 Purpose

    This test validates that the ACS is able to discover the RPC methods supported by the
    CPE.

    7.3.1.2 Procedure

    1. Initiate a transaction session between the ACS and CPE through a successful
    Inform exchange.
    2. The ACS issues the GetRPCMethods RPC.
    3. The CPE sends a GetRPCMethodsResponse message to the ACS.

    7.3.1.3 Success Metric

    1. The CPE is able to communicate its supported RPC methods to the ACS.
    2. The ACS is able to learn the CPE's supported RPC methods.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.3.2.1 Purpose

    This test validates that the CPE is able to discover the RPC methods supported by the
    ACS.

    Note that CPE support for invoking GetRPCMethods on the ACS is optional. ACS ability
    to respond to the RPC is required.

    7.3.2.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The CPE issues the GetRPCMethods RPC.
      3. The ACS sends a GetRPCMethodsResponse message to the CPE.

    7.3.2.3 Success Metric

      1. The ACS is able to communicate its supported RPC methods to the CPE.
      2. The CPE is able to learn the supported RPC methods of the ACS.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.4.1.1 Purpose

    The purpose of this test is to validate that a firmware download can be successfully
    executed when the ACS permits the download to take place in the current CWMP
    session.

    7.4.1.2 Procedure

       1. Initiate a transaction session between the ACS and CPE through a successful
          Inform exchange.
       2. The ACS issues the Download RPC, specifying values for the URL of the
          download server and no delay.
       3. The CPE performs the download.  It may:
          a. Perform and apply the download immediately during the current session
             and respond with a Status=0.
          b. Respond with a Status=1, which indicates that the download will be
             completed later.
       4. If the CPE responds with a status of 1, it may either finish the download during
          that same session or require a new CWMP session (either because it initiates a
          new connection to perform the upgrade or because it requires a reboot to fully
          apply the firmware upgrade).
       5. If the CPE is able to finish the download during the same CWMP session
          a. The CPE sends the TransferComplete RPC in the same session once the
             download has finished.
          b. The ACS sends a TransferCompleteResponse message to the CPE.
       6. If the CPE requires a new CWMP session in order to complete or report
          completion of the firmware download
          a. It terminates cleanly the existing session with the ACS.
          b. It downloads the firmware and reboots if required.
          c. It then establishes an HTTP session with the ACS.
          d. It sends an Inform message to the ACS with the '7 TRANSFER
             COMPLETE' event code.
          e. The ACS responds with an InformResponse message.
          f. The CPE sends a TransferComplete RPC.
          g. The ACS sends a TransferCompleteResponse message.
      7.  When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
          successfully terminates the session with the ACS.
      8.  Subsequent interrogation indicates that the CPE's firmware does indeed match the
          new, downloaded version.

    7.4.1.3 Success Metric

      1. The ACS is able to have the CPE download new firmware.
      2. The CPE is able to download and apply the new firmware.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.4.2.1 Purpose

    The purpose of this test is to test the ability of the CPE to download firmware when not
    permitted to perform the download in the current CWMP session.

    7.4.2.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues the Download RPC, specifying values for the URL and a non-
         zero delay.
      3. The CPE responds with a status value of 1, indicating that the download has not
         yet been completed.
      4. The CPE waits for the indicated period of time.
      5. The CPE then initiates a new session for the purpose of performing the download.
      6. The CPE downloads and applies the firmware.  It may need to reboot in order to
         apply the firmware.
      7. After successful download and application of the file, the CPE initiates a new
         transaction session with the ACS in which the Inform contains the '7
         TRANSFER COMPLETE' event code.
      8. The CPE issues the TransferComplete method during that new session.
      9. The ACS responds with a TransferCompleteResponse message.
      10. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
          successfully terminates the session with the ACS.
      11. Subsequent interrogation indicates that the CPE's firmware does indeed match the
          new, downloaded version.

    7.4.2.3 Success Metric

      1. The ACS successfully has the CPE download new firmware.
      2. The CPE successfully downloads and applies new firmware.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.4.3.1 Purpose

    The purpose of this test is to validate that a firmware download can be successfully
    executed when the ACS permits the download to take place in the current CWMP session
    using SSL.

    7.4.3.2 Procedure

      1. Configure the CPE to enable SSL; if the ACS is acting as the fileserver, enable
         SSL on the ACS.
      2. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      3. The ACS issues the Download RPC, specifying HTTPS values for the URL of the
         download server and no delay.
      4. The CPE performs the download.  It may:
        a. Perform and apply the download immediately during the current session
           and respond with a Status=0.
        b. Respond with a Status=1, which indicates that the download will be
           completed later.
      5. If the CPE responds with a status of 1, it may either finish the download during
         that same session or require a new CWMP session (either because it initiates a
         new connection to perform the upgrade or because it requires a reboot to fully
         apply the firmware upgrade).
      6. If the CPE is able to finish the download during the same CWMP session
        c. The CPE sends the TransferComplete RPC in the same session once the
           download has finished.
        d. The ACS sends a TransferCompleteResponse message to the CPE.
      7. If the CPE requires a new CWMP session in order to complete or report
         completion of the firmware download
        e. It terminates cleanly the existing session with the ACS.
        f. It downloads the firmware and reboots if required.
        g. It then establishes an HTTP session with the ACS.
        h. It sends an Inform message to the ACS with the '7 TRANSFER
           COMPLETE' event code.
        i. The ACS responds with an InformResponse message.
        j. The CPE sends a TransferComplete RPC.
        k. The ACS sends a TransferCompleteResponse message.
        8. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
           successfully terminates the session with the ACS.
        9. Subsequent interrogation indicates that the CPE's firmware does indeed match the
           new, downloaded version.

    7.4.3.3 Success Metric

      1. The ACS is able to have the CPE download new firmware over an encrypted link.
      2. The CPE is able to download and apply the new firmware over and encrypted
         link.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.4.4.1 Purpose

    The purpose of this test is to test the ability of the CPE to download firmware over an
    encrypted link when not permitted to perform the download in the current CWMP
    session.

    7.4.4.2 Procedure

      1. Configure the CPE to enable SSL.
      2. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      3. The ACS issues the Download RPC, specifying HTTPS values for the URL and a
         non-zero delay.
      4. The CPE responds with a status value of 1, indicating that the download has not
         yet been completed.
      5. The CPE waits for the indicated period of time.
      6. The CPE then initiates a new session for the purpose of performing the download.
      7. The CPE downloads and applies the firmware.  It may need to reboot in order to
         apply the firmware.
      8. After successful download and application of the file, the CPE initiates a new
         transaction session with the ACS in which the Inform contains the '7
         TRANSFER COMPLETE' event code.
      9. The CPE issues the TransferComplete method during that new session.
      10. The ACS responds with a TransferCompleteResponse message.
      11. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
          successfully terminates the session with the ACS.
      12. Subsequent interrogation indicates that the CPE's firmware does indeed match the
          new, downloaded version.

    7.4.4.3 Success Metric

      3. The ACS successfully has the CPE download new firmware over an encrypted
         link.
      4. The CPE successfully downloads and applies new firmware over an encrypted
         link.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.4.5.1 Purpose

    The purpose of this test is to exercise CWMP behavior in the event that a downloaded
    firmware image is not a valid image. It should be noted that prior to testing, the ACS and
    CPE testers will need to negotiate a file type to use.

    7.4.5.2 Procedure

       1. Prepare a firmware upgrade file that is invalid for the CPE.
       2. Initiate a transaction session between the ACS and CPE through a successful
          Inform exchange.
       3. The ACS issues the Download RPC, specifying values for the URL of the
          download server and no delay.
       4. Follow steps 3 through 6 of 7.4.1.2. Allow the CPE to include an appropriate
          fault code in the TransferComplete RPC.
       5. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
          successfully terminates the session with the ACS.

    7.4.5.3 Success Metric

      1. The CPE is able to send a fault code indicating an invalid firmware image.
      2. The ACS successfully handles the error.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.4.6.1 Purpose

    The purpose of this test is to exercise the CWMP systems ability to perform a download
    on a vendor configuration file. It should be noted that prior to testing, the ACS and CPE
    testers will need to negotiate the file type to use.

    7.4.6.2 Procedure

       1. Initiate a transaction session between the ACS and CPE through a successful
          Inform exchange.
       2. The ACS issues the Download RPC, specifying values for the URL of the
          download server and no delay.
       3. Follow steps 3 through 6 of 7.4.1.2
       4. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
          successfully terminates the session with the ACS.

    7.4.6.3 Success Metric

      1. The CPE is able to download the configuration file and convey its presence to the
         ACS
      2. The ACS successfully learns of the configuation file presence.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.4.7.1 Purpose

    The purpose of this test is to exercise the CWMP systems ability to perform a firmware
    download when DelaySeconds >> 0 and  the CPE reboots before the download is
    attempted.

    7.4.7.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues the Download RPC, specifying values for the URL of the
         download server and a delay of greater than 3 minutes.
      3. Follow steps 3-4 of 7.4.2.2.
      4. While the CPE waits to initiate the download, physically reboot the CPE.

         (NOTE: CDRouter will issue a RebootRPC instead of requiring a physical reboot.)

      5. Interrogate the CPE after it has rebooted. The download will not have completed
         and the CPE firmware image remains the initial version.
      6. Follow steps 5 through 9 of 7.4.2.2.
      7. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
         successfully terminates the session with the ACS.
      8. Subsequent interrogation indicates that the CPE's firmware does indeed match the
         new, downloaded version.

    7.4.7.3 Success Metric

      1. The ACS successfully has the CPE download new firmware.
      2. The CPE successfully downloads and applies new firmware.

    Note: If the LAN client is configured to use wireless there is an extra step to
          reconnect the LAN client to the wireless at the end of the test.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.5.1.1 Purpose

    This purpose of this test is to validate the ability of the CPE to respond for a simple
    complete path request of a variable's name.

    7.5.1.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a GetParameterNames RPC specifying the following complete
         path.

      IGD
      InternetGatewayDevice.DeviceInfo.Manufacturer

      Device
      Device.DeviceInfo.Manufacturer

      3. The CPE issues a GetParameterNamesResponse message containing the name
         requested by the ACS.

    7.5.1.3 Success Metric

      1. The CPE is able to communicate the requested parameter's name to the ACS.
      2. The ACS is able to receive the request parameter's name from the CPE.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.5.2.1 Purpose

    This test validates the ability of the ACS to retrieve information about the next level of
    the CPE's data hierarchy using the GetParameterNames RPC.

    7.5.2.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a GetParameterNames RPC specifying the following partial path
         and with the NextLevel Boolean argument set to True.

      IGD
      InternetGatewayDevice.DeviceInfo.

      Device
      Device.DeviceInfo.

      3. The ACS receives a GetParameterNamesResponse message from the CPE that
         contains the next level objects and parameters.

    7.5.2.3 Success Metric

      1. The CPE is able to communicate its next level data hierarchy to the ACS.
      2. The ACS is able to learn the device's next level data hierarchy.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.5.3.1 Purpose

    This test validates the ability of the ACS to retrieve information about the CPE's data
    hierarchy at all levels using the GetParameterNames RPC.

    7.5.3.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.

      2. The ACS issues a GetParameterNames RPC specifying the following partial path
         and with the NextLevel Boolean argument set to False.

      IGD
      InternetGatewayDevice.Layer3Forwarding.

      VoIP
      InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.

      STB
      InternetGatewayDevice.Services.STBService.1.Capabilities.VideoDecoder.

      Device 2.x
      Device.Ethernet

      3. The CPE issues a GetParameterNamesResponse message containing the full path
         name of all parameters whose name begins with the string specified in the request.

    7.5.3.3 Success Metric

      1. The CPE is able to communicate its data hierarchy at all levels below the
         specified partial path.
      2. The ACS is able to learn about the data hierarchy at all levels below the specified
         partial path.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.5.4.1 Purpose

    This test validates the ability for the CPE to identify an invalid path and for the ACS to
    handle the resulting error.

    7.5.4.2 Procedure

       1. Initiate a transaction session between the ACS and CPE through a successful
          Inform exchange.
       2. The ACS issues a GetParameterNames RPC specifying the following invalid
          complete path.

      IGD
      InvalidParameterPath

      Device
      InvalidParameterPath

      3. The CPE issues a GetParameterNamesResponse message containing a 9005
         (Invalid Parameter Name) fault code.
      4. The ACS may either issue another GetParameterValues RPC to the CPE with a
         correct parameter path specified, or may allow the CPE to terminate the session.

    7.5.4.3 Success Metric

      1. The CPE is able to communicate the fault information to the ACS.
      2. The ACS receives the fault and handles the error.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.5.5.1 Purpose

    This test validates the ability of the ACS to retrieve information about the CPE's entire
    data hierarchy using the GetParameterNames RPC. Note that the 9004 (Resources
    Exceeded) fault is never returned by GetParameterNames.

    7.5.5.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a GetParameterNames RPC specifying the root of the naming
         hierarchy and with the NextLevel Boolean argument set to False.

      IGD
      InternetGatewayDevice. or Device.

      VoIP
      InternetGatewayDevice. or Device.

      STB
      InternetGatewayDevice. or Device.

      3. The CPE issues a GetParameterNamesResponse message containing the full path
         name of all parameters in the CPE's data model.

    7.5.5.3 Success Metric

      1. The CPE is able to communicate its entire data hierarchy.
      2. The ACS is able to learn about the entire data hierarchy.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.6.1.1 Purpose

    The purpose of this test is to verify that the CPE provides configuration information in
    response to a simple, complete path request.

    7.6.1.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a GetParameterValues RPC to the CPE specifying the following
         complete path.

    IGD
    InternetGatewayDevice.ManagementServer.ConnectionRequestUsername

    VoIP
    InternetGatewayDevice.ManagementServer.ConnectionRequestUsername

    STB
    InternetGatewayDevice.ManagementServer.ConnectionRequestUsername

      3. The CPE responds with a GetParameterValues response message containing the
         name and value for the requested parameter.

    7.6.1.3 Success Metric

      1. The CPE is able to communicate the state of the requested variable
      2. The ACS is able learn the state of the request variable.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.6.2.1 Purpose

    The purpose of this test is to validate that a CPE can successfully receive and respond to
    a request for the values of multiple variables from different places within the device
    hierarchy.

    7.6.2.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a GetParameterValues RPC specifying the following complete
         paths to multiple variables from various branches of the device hierarchy to the
         CPE.

    IGD
    InternetGatewayDevice.DeviceInfo.SoftwareVersion
    InternetGatewayDevice.Layer3Forwarding.ForwardNumberOfEntries
    InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.ExternalIPAddress

    VoIP
    InternetGatewayDevice.DeviceInfo.SoftwareVersion
    InternetGatewayDevice.Services.VoiceService.1.VoiceProfileNumberOfEntries
    InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.Enable

    STB
    InternetGatewayDevice.DeviceInfo.SoftwareVersion
    InternetGatewayDevice.Services.STBService.1.Components.VideoOutputNumberOfEntries
    InternetGatewayDevice.Services.STBService.1.Components.VideoDecoder.1.Status

    Device 2.x
    Device.DeviceInfo.SoftwareVersion
    Device.Ethernet.Interface.1.MaxBitRate
    Device.ManagementServer.URL

      3. The CPE responds with a GetParameterValuesResponse message containing the
         ParameterList of names and their values.

    7.6.2.3 Success Metric

      1. The CPE is able to communicate its state as requested to the ACS
      2. The ACS is able to learn the requested CPE state.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.6.3.1 Purpose

    The purpose of this test is to validate that the CPE can respond to a request for
    configuration that is made using a partial path name.

    7.6.3.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a GetParameterValues RPC to the CPE specifying the following
         partial path.

    IGD
    InternetGatewayDevice.ManagementServer.

    VoIP
    InternetGatewayDevice.ManagementServer.

    STB
    InternetGatewayDevice.ManagementServer.

      3. The CPE sends a GetParameterValuesResponse message containing a list of all
         the parameters in the branch of the hierarchy with the same prefix as the argument
         along with their values, within the given device's resource limits.

    7.6.3.3 Success Metric

      1. The CPE is able to communicate its state as requested to the ACS.
      2. The ACS is able to learn the requested state of the CPE.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.6.4.1 Purpose

    The purpose of this test is to validate that the CPE can respond to a request for
    configuration that is made using a mixture of complete and partial path names.

    7.6.4.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a GetParameterValues RPC to the CPE specifying the following
         complete and partial paths.

    IGD
    InternetGatewayDevice.ManagementServer.URL
    InternetGatewayDevice.DeviceInfo.

    Device
    Device.ManagementServer.URL
    Device.DeviceInfo.

      3. The CPE sends a GetParameterValuesResponse message containing a list of all
         the requested parameters along with their values, within the given device's
         resource limits.

    7.6.4.3 Success Metric

      1. The CPE is able to communicate its state as requested to the ACS.
      2. The ACS is able to learn the requested state of the CPE.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.6.5.1 Purpose

    The purpose of this test is to validate that both parties can handle a request that is likely
    to strain the resource capabilities of the device.  In this test the ACS issues a request for
    the entire object model, which is likely to result in a 9004 (Resources Exceeded) fault, or
    if the CPE can handle responding to the request, an extremely large message for the ACS
    to parse.

    7.6.5.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a GetParameterValues RPC to the CPE specifying the following
         partial path.

    IGD
    InternetGatewayDevice.

    VoIP
    InternetGatewayDevice. or Device.

    STB
    InternetGatewayDevice. or Device.

      3. If the CPE is capable of responding with a ParameterList of its entire object
         model, it responds with a GetParameterValuesResponse message containing a list
         of all the requested parameters along with their values, within the given device's
         resource limits.
      4. If the CPE cannot respond with its entire object model,
         a. It issues a 9004 (Resources Exceeded) fault.
         b. The ACS may either issue another GetParameterValues RPC to the CPE
            with a smaller portion of the object model specified, or may allow the CPE
            to terminate the session.

    7.6.5.3 Success Metric

      1. The CPE either communicates its entire state to the ACS or it communicates its
         error condition.
      2. The ACS successfully learns the entire state of the device or handles the error.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.7.1.1 Purpose

    The purpose of this test is to validate that the ACS can modify a single variable.

    7.7.1.2 Procedure

    The CPE may either be able to apply the requested changes immediately or it may need
    to reboot in order to apply the change.

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a SetParameterValues RPC to the CPE setting the following
         parameter to any valid value that is different from its current value.

    IGD
    InternetGatewayDevice.ManagementServer.PeriodicInformEnable

    VoIP
    InternetGatewayDevice.ManagementServer.PeriodicInformEnable

    STB
    InternetGatewayDevice.ManagementServer.PeriodicInformEnable

      3. The CPE validates that it can change the value of the parameter as requested.
      4. If the CPE is able to apply the value change immediately, it responds with a
         SetParameterValuesResponse message in which Status=0 to the ACS.
      5. If the CPE requires a reboot or other action to apply the change
         a. It responds with a SetParameterValuesResponse message in which
            Status=1 to the ACS.
         b. It terminates the session with the ACS.
         c. It applies the changes and reboots if necessary.
         d. It then initiates an HTTP session and a CWMP session with the ACS by
            sending an Inform.
         e. The ACS sends an Inform response.
      6. When the CPE is later interrogated, the value of the variable reflects the new
         value specified in the SetParameterValues RPC.

    7.7.1.3 Success Metric

      1. The ACS is able to modify the state of the specified variable in the CPE.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.7.2.1 Purpose

    The purpose of this test is to validate that the ACS can make configuration modifications
    to multiple parameters.

    7.7.2.2 Procedure

    As with the previous test, the CPE may either be able to apply the requested changes
    immediately or it may need to reboot in order to apply the change.

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a SetParameterValues RPC to the CPE setting the following
         parameters to any valid values different from their current ones.

    IGD
    InternetGatewayDevice.ManagementServer.UpgradesManaged
    InternetGatewayDevice.LANDevice.1.LANHostConfigManagement.DomainName
    InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.Name

    Device
    Device.ManagementServer.UpgradesManaged
    Device.DeviceInfo.ProvisioningCode
    Device.Ethernet.Interface.1.DuplexMode
    Device.IP.Interface.1.Enable

    VoIP
    InternetGatewayDevice.ManagementServer.UpgradesManaged
    InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Enable
    InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.URI

    STB
    InternetGatewayDevice.ManagementServer.UpgradesManaged
    InternetGatewayDevice.Services.STBService.1.AVPlayers.PreferredAudioLanguage
    InternetGatewayDevice.Services.STBService.1.PreferredSubtitlingLanguage

      3. The CPE validates that it can change the values of the parameters as requested
      4. If the CPE is able to apply the value changes immediately, it responds with a
         SetParameterValuesResponse message in which Status=0 to the ACS.
      5. If the CPE requires a reboot or other action to apply the changes
         a. It responds with a SetParameterValuesResponse message in which
            Status=1 to the ACS.
         b. It terminates the session with the ACS.
         c. It applies the changes and reboots if required.
         d. It then initiates an HTTP session and a CWMP session with the ACS by
            sending an Inform.
         e. The ACS sends an Inform response.
      6. When the CPE is later interrogated, the value of the variables reflects the new
         values specified in the SetParameterValues RPC.

    7.7.2.3 Success Metric

      1. The ACS is able to successfully modify the CPE's state.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.7.3.1 Purpose

    The purpose of this test is to validate that the CPE can detect an invalid parameter
    modification request and that the ACS can handle the resulting fault response.

    7.7.3.2 Procedure

    As with the previous test, the CPE may either be able to apply the requested changes
    immediately or it may need to reboot in order to apply the change.

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a SetParameterValues RPC to the CPE attempting to set the
         following non-writeable, non-primitive or non-existent parameters.

    IGD
    InternetGatewayDevice.DeviceInfo.Manufacturer
    InternetGatewayDevice.LANDevice.1.LANEthernetInterfaceConfig.1
    InternetGatewayDevice.WANDevice.1.NonExistent

    VoIP
    InternetGatewayDevice.DeviceInfo.Manufacturer
    InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1
    InternetGatewayDevice.Services.VoiceService.1.Capabilities.NonExistent

    STB
    InternetGatewayDevice.DeviceInfo.Manufacturer
    InternetGatewayDevice.Services.STBService.1.Capabilities
    InternetGatewayDevice.Services.STBService.1.Applications.NonExistent

      3. The CPE detects the invalid parameters and generates a fault response with a
         primary fault code of 9003 (Invalid Arguments) and an appropriate
         SetParameterValuesFault structure for each parameter that is in error.
      4. The ACS may either issue another SetParameterValues RPC to the CPE with
         correct parameters specified, or may allow the CPE to terminate the session.

    7.7.3.3 Success Metric

      1. The CPE is able to communicate the fault information to the ACS.
      2. The ACS receives the fault and handles the error.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.8.1.1 Purpose

    The purpose of this test is to validate that the ACS can add new instances of multi-
    instance objects.  Note that for voice devices, although CWMP requires the ability to add
    objects, the creatable objects as defined in [5] may not be widespread in implementations.
    If this is the case, voice devices should skip this test.

    7.8.1.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues an AddObject command with the following path name.

    IGD
    InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.PortMapping.
    Device.NAT.PortMapping. (Device 2.x)

    VoIP
    InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.

    STB
    n/a

      3. The CPE validates that it can add the object as requested.
      4. If the CPE is able to create the object immediately, it does so and responds with
         an AddObjectResponse message with the instance number in which Status=0 to
         the ACS.
      5. If the CPE requires a reboot or other action to apply the changes
         a. It responds with an AddObjectRresponse message with the instance
            number of the new object in which Status=1 to the ACS.
         b. It terminates the session with the ACS.
         c. It creates the object and reboots if required.
         d. The CPE then initiates an HTTP session and a CWMP session with the
            ACS by sending an Inform.
         e. The ACS sends an Inform response.
      6. Later interrogation of the CPE indicates that the new object exists in the object
         model with the specified instance number and expected default values.

    7.8.1.3 Success Metric

      1. The CPE is able to successfully create a new object in its data hierarchy and
         communicate the new object's instance number to the ACS.
      2. The ACS is able to successfully learn the new instance number of the created
         object.

    7.9.1.1 Purpose

    The purpose of this test is to validate that the ACS can delete instances of multi-instance
    objects.  Note that for voice devices, although CWMP requires the ability to delete
    objects, the deletable objects as defined in [5] may not be widespread in implementations.
    If this is the case, voice devices should skip this test.

    7.9.1.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a DeleteObject command to the CPE with the path of the object
         to be deleted.

      Note that this object can be the one created in the previous test, or it can be another
      object whose instance number is known by the ACS.

      3. The CPE validates that it can delete the object as requested.
      4. If the CPE is able to delete the object immediately, it does so and responds with a
         DeleteObjectResponse in which Status=0 to the ACS.
      5. If the CPE requires a reboot or other action to apply the changes
        a. It responds with a DeleteObjectResponse in which Status=1 to the ACS.
        b. It terminates the session with the ACS.
        c. It deletes the object and reboots if required
        d. It then initiates an HTTP session and a CWMP session with the ACS by
           sending an Inform.
        e. The ACS sends an Inform response.
      6. Later interrogation of the CPE indicates that the object no longer exists in the data
          hierarchy.

    7.9.1.3 Success Metric

      1. The ACS is able to successfully delete the requested object from the CPE's data
         hierarchy


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.10.1.1 Purpose

    The purpose of this test is to verify that the ACS can reboot the CPE.

    7.10.1.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a
         successful Inform exchange.
      2. The ACS issues a Reboot RPC.
      3. The CPE responds with a RebootResponse message.
      4. The CPE reboots and then sends an Inform to the ACS with the 'M Reboot'
         event code and command key.

    7.10.1.3 Success Metric

      1. The CPE reboots.
      2. The CPE successfully initiates a post-reboot session with the ACS.

    Note: If a wireless LAN client is used during this test, the client will be
    disassociated before calling the Reboot RPC and restarted at the end of the
    test.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.11.1.1 Purpose

    The purpose of this test is to validate that the ACS can retrieve the current value of a
    parameter's attributes.

    7.11.1.2 Procedure

       1. Initiate a transaction session between the ACS and CPE through a successful
          Inform exchange.
       2. The ACS issues a GetParameterAttributes RPC to the CPE.

    IGD
    InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.PortMappingNumberOfEntries

    or

    Device.NAT.PortMappingNumberOfEntries (Device 2.x)

    VoIP
    InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Enable

    STB
    InternetGatewayDevice.Services.STBService.1.AVStreams.ActiveAVStreams

      3. The CPE responds with a GetParameterAttributesResponse containing the
         parameter and the value of the Notification and AccessList attributes.

    7.11.1.3 Success Metric

      1. The CPE is able to communicate its variable attributes to the ACS.
      2. The ACS is able to learn the CPE's variable attributes.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.11.2.1 Purpose

    The purpose of this test is to validate that the ACS can retrieve the current values of
    multiple parameters attributes.

    7.11.2.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a GetParameterAttributes RPC to the CPE, specifying the
         following complete paths to multiple variables.

    IGD
    InternetGatewayDevice.LANDevice.1.WLANConfiguration.1.TotalAssociations
    InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.PortMappingNumberOfEntries

    or

    Device.Ethernet.Interface.1.Enable (Device 2.x)
    Device.DeviceInfo.SoftwareVersion (Device 2.x)

    VoIP
    InternetGatewayDevice.VoiceService.1.VoiceProfile.1.Enable
    InternetGatewayDevice.VoiceService.1.VoiceProfile.1.Line.1.Enable

    STB
    InternetGatewayDevice.Services.STBService.1.AVStreams.ActiveAVStreams
    InternetGatewayDevice.Services.STBService.1.AVStreams.AVStreamNumberOfEntries

      3. The CPE responds with a GetParameterAttributesResponse containing the
         parameters and the values of their Notification and AccessList attributes.

    7.11.2.3 Success Metric

      1. The CPE is able to communicate its variable attributes to the ACS.
      2. The ACS is able to learn the CPE's variable attributes.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.11.3.1 Purpose

    The purpose of this test is to validate that the ACS can retrieve the current values of the
    attributes of all parameters within the object identified by a partial path.

    7.11.3.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a GetParameterAttributes RPC to the CPE, specifying the
         following partial path.

    IGD
    InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.

    or

    Device.Ethernet.Link.1. (Device 2.x)

    VoIP
    InternetGatewayDevice.VoiceService.1.VoiceProfile.1.Line.1.

    STB
    InternetGatewayDevice.Services.STBService.1.AVStreams.

      3. The CPE responds with a GetParameterAttributesResponse containing the
          parameters and the values of their Notification and AccessList attributes.

    7.11.3.3 Success Metric

      1. The CPE is able to communicate its variable attributes to the ACS.
      2. The ACS is able to learn the CPE's variable attributes.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.11.4.1 Purpose

    The purpose of this test is to validate that the ACS can retrieve the current values of the
    attributes of a mixture of parameters specified via complete paths and of parameters
    within an object identified by a partial path.

    7.11.4.2  Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a GetParameterAttributes RPC to the CPE, specifying the
         following complete and partial paths.

    IGD
    InternetGatewayDevice.LANDevice.1.WLANConfiguration.1.TotalAssociations
    InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.

    or

    Device.Ethernet.Interface.1.Enable (Device 2.x)
    Device.Ethernet.Link.1. (Device 2.x)

    VoIP
    InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Enable
    InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.

    STB
    InternetGatewayDevice.Services.STBService.1.AVStreams.ActiveAVStreams
    InternetGatewayDevice.Services.STBService.1.Capabilities.VideoDecoder.

      3. The CPE responds with a GetParameterAttributesResponse containing the
         parameters and the values of their Notification and AccessList attributes.

    7.11.4.3  Success Metric

      1. The CPE is able to communicate its variable attributes to the ACS.
      2. The ACS is able to learn the CPE's variable attributes.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.12.2.1    Purpose

    The purpose of this test is to validate that the ACS can modify Passive Notification
    related attributes on parameters.

    7.12.2.2    Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a SetParameterAttributes RPC to enable passive notifications for
         a particular parameter.

    IGD
    InternetGatewayDevice.DeviceInfo.UpTime

    VoIP
    Device.DeviceInfo.UpTime

    STB
    Device.DeviceInfo.UpTime

      3. The CPE responds with a SetParameterAttributes response.
      4. Through some local mechanism the value of the parameter is changed on the
         CPE.
      5. Through some mechanism, the CPE is stimulated to initiate a session and send an
         Inform to the ACS with the parameter and its current value in the Inform
         Parameter List.
      6. The ACS sends an Inform response.

    7.12.2.3    Success Metric

      1. The ACS is able to enable Passive Notification on the requested variable.
      2. The CPE is able to communicate changes to the variable's state to the ACS.
      3. The ACS is able to learn the variable's state when it changes.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.12.3.1    Purpose

    The purpose of this test is to validate that the ACS can modify Passive Notification
    related attributes on all parameters within the object identified by a partial path.

    7.12.3.2    Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a SetParameterAttributes RPC to enable passive notifications for
         the following partial path.

    IGD
    InternetGatewayDevice.DeviceInfo.

    VoIP
    Device.DeviceInfo.

    STB
    Device.DeviceInfo.

      3. The CPE responds with a SetParameterAttributes response.
      4. Through some local mechanism the values of one or more parameters within the
         object identified by the partial path are changed on the CPE.
      5. Through some mechanism, the CPE is stimulated to initiate a session and send an
         Inform to the ACS with the modified parameters and their current values in the
         Inform Parameter List.
      6. The ACS sends an Inform response.

    7.12.3.3    Success Metric

      1. The ACS is able to enable Passive Notification on the requested object.
      2. The CPE is able to communicate changes to the object's state to the ACS.
      3. The ACS is able to learn the object's state when it changes.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.12.4.1    Purpose

    The purpose of this test is to validate that the ACS can modify Passive Notification
    related attributes on parameters specified via complete paths and on parameters within
    the object identified by a partial path.

    7.12.4.2    Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues a SetParameterAttributes RPC to enable passive notifications for
         the following complete and partial paths.

    IGD
    InternetGatewayDevice.DeviceInfo.UpTime
    InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.PortMapping.

    or

    Device.DeviceInfo.UpTime (Device 2.x)
    Device.Ethernet.Link.1. (Device 2.x)

    VoIP
    InternetGatewayDevice.DeviceInfo.UpTime
    InternetGatewayDevice.VoiceService.1.VoiceProfile.1.Line.1.

    STB
    InternetGatewayDevice.DeviceInfo.UpTime
    InternetGatewayDevice.Services.STBService.1.AVStreams.

      3. The CPE responds with a SetParameterAttributes response.
      4. Through some local mechanism the values of one or more parameters within the
         variable and object identified by the complete and partial paths are changed on the
         CPE.
      5. Through some mechanism, the CPE is stimulated to initiate a session and send an
         Inform to the ACS with the modified parameters and their current values in the
         Inform Parameter List.
      6. The ACS sends an Inform response.

    7.12.4.3    Success Metric

      1. The ACS is able to enable Passive Notification on the requested parameter and
         object.
      2. The CPE is able to communicate changes to the parameter's and object's state to
         the ACS.
      3. The ACS is able to learn the parameter's and object's state when they change.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.12.5.1    Purpose

    The purpose of this test is to validate that the ACS can disable Notifications on
    parameters.

    7.12.5.2    Procedure

      1. Through some mechanism, preferably by just having executed the previous
         Passive Notifications test, the CPE ensures that passive notifications are enabled
         for the parameter in the table below.
      2. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      3. The ACS issues a SetParameterAttributes RPC to disable notifications for a
         particular parameter.

    IGD
    InternetGatewayDevice.DeviceInfo.UpTime

    VoIP
    Device.DeviceInfo.UpTime

    STB
    Device.DeviceInfo.UpTime

      4. The CPE responds with a SetParameterAttributes response.
      5. Through some local mechanism the value of the parameter is changed on the
         CPE.
      6. Through some mechanism, the CPE is stimulated to initiate a session and send an
         Inform to the ACS. This Inform should not include this parameter and its current
         value in the Inform Parameter List.
      7. The ACS sends an Inform response.

    7.12.5.3    Success Metric

      1. The ACS is able to disable Passive Notification on the requested variable.
      2. The CPE does not communicate this variable's state, even though its value has
         changed, to the ACS when it next contacts it.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.13.1.1 Purpose

    The purpose of this test is to validate that a file can be successfully upload
    when the ACS permits the upload to take place in the current CWMP session.

    7.13.1.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange.
      2. The ACS issues the Upload RPC, specifying values for the URL of the upload
         server and no delay.
      3. The CPE performs the upload.  It may:
         a. Perform and apply the upload immediately during the current session
            and respond with a Status=0.
         b. Respond with a Status=1, which indicates that the upload will be
            completed later.
      4. If the CPE responds with a status of 1, it may either finish the upload
         during that same session or require a new CWMP session.
      5. If the CPE is able to finish the upload during the same CWMP session
         a. The CPE sends the TransferComplete RPC in the same session once the
            upload has finished.
         b. The ACS sends a TransferCompleteResponse message to the CPE.
      6. If the CPE requires a new CWMP session in order to complete or report
         completion of the file upload
         a. It terminates cleanly the existing session with the ACS.
         b. It uploads the file.
         c. It then establishes an HTTP session with the ACS.
         d. It sends an Inform message to the ACS with the "7 TRANSFER COMPLETE" event code.
         e. The ACS responds with an InformResponse message.
         f. The CPE sends a TransferComplete RPC.
         g. The ACS sends a TransferCompleteResponse message.
      7. When the conditions outlined in Section 3.1 of TR-069 have been met, the
         CPE successfully terminates the session with the ACS.
      8. Subsequent interrogation of the file server indicates that the file has
         indeed been successfully uploaded.

    7.13.1.3 Success Metric
      1. The ACS is able to have the CPE upload the file.
      2. The CPE is able to upload the file to the file server.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.13.2.1 Purpose

    The purpose of this test is to test the ability of the CPE to upload a file
    when not permitted to perform the upload in the current CWMP session.

    7.13.2.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a
         successful Inform exchange.
      2. The ACS issues the Upload RPC, specifying values for the URL and
         a non-zero delay.
      3. The CPE responds with a status value of 1, indicating that the
         upload has not yet been completed.
      4. The CPE waits for the indicated period of time.
      5. The CPE then initiates a new session for the purpose of performing
         the upload.
      6. The CPE uploads the file to the fileserver.
      7. After successful upload, the CPE initiates a new transaction session
         with the ACS in which the Inform contains the "7 TRANSFER COMPLETE"
         event code.
      8. The CPE issues the TransferComplete method during that new session.
      9. The ACS responds with a TransferCompleteResponse message.
      10. When the conditions outlined in Section 3.1 of TR-069 have been met,
          the CPE successfully terminates the session with the ACS.
      11. Subsequent interrogation of the file server indicates that the file
          has indeed been successfully uploaded.

    7.13.2.3Success Metric

      1. The ACS is able to have the CPE upload the file.
      2. The CPE is able to upload the file to the file server.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.13.3.1 Purpose

    The purpose of this test is to validate that an upload can be successfully
    executed when the ACS permits the upload to take place in the current
    CWMP session using SSL.

    7.13.3.2 Procedure

      1. Configure the CPE to enable SSL; if the ACS is acting as the fileserver,
         enable SSL on the ACS.
      2. Initiate a transaction session between the ACS and CPE through a
         successful Inform exchange.
      3. The ACS issues the Upload RPC, specifying HTTPS values for the URL of
         the server to which to upload the file and no delay.
      4. The CPE performs the upload.  It may:
         a. Perform the upload immediately during the current session and
            respond with a Status=0.
         b. Respond with a Status=1, which indicates that the upload will be
            completed later.
      5. If the CPE responds with a status of 1, it may either finish the upload
         during that same session or require a new CWMP session.
      6. If the CPE is able to finish the upload during the same CWMP session
         a. The CPE sends the TransferComplete RPC in the same session once the
            upload has finished.
         b. The ACS sends a TransferCompleteResponse message to the CPE.
      7. If the CPE requires a new CWMP session in order to complete the upload
         a. It terminates cleanly the existing session with the ACS.
         b. It uploads the file.
         c. It then establishes an HTTP session with the ACS.
         d. It sends an Inform message to the ACS with the "7 TRANSFER COMPLETE"
            event code.
         e. The ACS responds with an InformResponse message.
         f. The CPE sends a TransferComplete RPC.
         g. The ACS sends a TransferCompleteResponse message.
      8. When the conditions outlined in Section 3.1 of TR-069 have been met,
         the CPE successfully terminates the session with the ACS.
      9. Subsequent interrogation of the file server indicates that the file has
         indeed been successfully uploaded.

    7.13.3.3 Success Metric

      1. The ACS is able to have the CPE upload the file over an encrypted link.
      2. The CPE is able to upload the file to the file server over an encrypted
         link.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    7.13.4.1 Purpose

    The purpose of this test is to test the ability of the CPE to upload a file
    over an encrypted link when not permitted to perform the upload in the
    current CWMP session.

    7.13.4.2 Procedure

      1. Configure the CPE to enable SSL.
      2. Initiate a transaction session between the ACS and CPE through a
         successful Inform exchange.
      3. The ACS issues the Upload RPC, specifying HTTPS values for the URL
         and a non-zero delay.
      4. The CPE responds with a status value of 1, indicating that the
         upload has not yet been completed.
      5. The CPE waits for the indicated period of time.
      6. The CPE then initiates a new session for the purpose of performing the upload.
      7. The CPE uploads the file.
      8. After successful upload of the file, the CPE initiates a new transaction
         session with the ACS in which the Inform contains the "7 TRANSFER COMPLETE"
         event code.
      9. The CPE issues the TransferComplete method during that new session.
      10. The ACS responds with a TransferCompleteResponse message.
      11. When the conditions outlined in Section 3.1 of TR-069 have been met, the
          CPE successfully terminates the session with the ACS.
      12. Subsequent interrogation of the file server indicates that the file has
          indeed been successfully uploaded.

    7.13.4.3 Success Metric

      1. The ACS is able to have the CPE upload the file over an encrypted link.
      2. The CPE is able to upload the file to the file server over an encrypted link.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    8.1.1.1     Purpose

    The purpose of this test is to validate that the ACS can find and modify the state of a
    particular port mapping entry.  Note that this test is IGD specific; voice devices should
    not attempt this test.

    This test assumes that there is at least one port mapping in the CPE's data model (and
    preferably a more fully populated port mapping table to better simulate a real world
    situation).

    The pre-existing port mapping should map TCP traffic on external port 80 to internal port
    80 (the same port) on a LAN PC, e.g. 192.168.1.1 (of course, the actual LAN PC address
    depends on the IGD's DHCP server configuration).

    The port mapping should be changed to refer to a different LAN IP address. This
    simulates the action that an ACS port mapping management application would have to
    take if a LAN host acquired a new IP address.

    8.1.1.2     Procedure

      1. The ACS and CPE initiate a transaction session.
      2. The ACS locates the port mapping of interest.
      3. The ACS takes the necessary steps to modify the port mapping of interest.
      4. The ACS and CPE successfully terminate the transaction session.

    8.1.1.3     Success Metric

      1. The ACS and CPE are able to initiate a transaction session.
      2. The ACS is able to locate the port mapping of interest in the CPE's data
         hierarchy.
      3. The ACS is able to modify the CPE's port mapping state.
      4. The CPE and ACS are able to conclude the transaction session successfully.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    8.2.1.1     Purpose

    The purpose of this test is to validate that the ACS can configure the CPE's wireless
    connection. Note that this test is IGD specific; voice devices should not attempt this test.

    When this test is complete the device should be in the following state:
      1. Wireless interface is enabled.
      2. SSID = Plugfest.
      3. Device is operating in Infrastructure mode.
      4. Device is using Channel 11.
      5. WEP Encryption is enabled.
      6. The WEP key has been configured to a value specified by the ACS.

    8.2.1.2     Procedure

      1. The CPE and the ACS initiate a transaction session.
      2. The ACS modifies the CPE data model as required to put the CPE in the state
         specified above.
      3. The CPE and ACS successfully close the transaction session.

    8.2.1.3     Success Metric

      1. The ACS and CPE are able to initiate a transaction session.
      2. The ACS is able to change the configuration such that the device is in the new
         requested state.
      3. The CPE and ACS are able to terminate the transaction session successfully.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    Test 20 WAN Connection Creation

    8.3.1.1     Purpose

    The purpose of this test is to verify that a complete WAN connection stack can be built
    up by the ACS. This test creates a WANConnectionDevice, WANIPConnection object and
    PortMapping entry via ACS. Note that this test is IGD specific; voice devices should
    not attempt this test.

    When this test is complete the device should have the following state:

      1. The device has an additional, enabled PVC with an EoA link type and VPI/VCI of 0/42
      2. The new PVC has one enabled, routed DHCP WAN connection across it.
      3. This new connection has NAT enabled.
      4. The new NAT table contains a port mapping entry.

    8.3.1.2     Procedure

      1. The CPE and ACS initiate a transaction session.
      2. The ACS adds objects to the CPE's data heirarchy and modifies device state such
         that the device is in the state described above.
      3. The CPE and ACS close the transaction session successfully.

    8.3.1.3     Success Metric

      1. The ACS and CPE are able to initiate a transaction session.
      2. The ACS is able to change the CPE's configuration such that it matches the state
         specified above.
      3. The CPE is able to terminate the session with the ACS.

    Test 21 WAN Connection Deletion

    8.4.1.1     Purpose

    The purpose of this test is to verify that the ACS can delete an entire WAN
    connection stack, including the WANConnectionDevice, the WANIPConnection and
    WANDSLLinkConfig objects, and any state associated with the connection.

    This test assumes that the CPE has configured a WANConnectionDevice with
    appropriate WANDSLLinkConfig and WANIPCOnnection objects. This connection is in
    addition to the one required for basic connectivity to the ACS. If the CPE does hot have
    an additional WANConnectionDevice, it can create once using the procedure
    outlined in 8.3 Test 19 - WAN Connection Creation.

    8.4.1.2     Procedure

      1. The CPE and ACS initiate a transaction session.
      2. The ACS located the WAN Connection of interest.
      3. The ACS takes the necessary steps to delete the secondary WAN Connection.
      4. The CPE and the ACS terminate the transaction session successfully.

    8.4.1.3     Success Metric

      1. The ACS and CPE are able to initiate a transaction session.
      2. The ACS is able to locate a WAN Connection of interst in the CPE's data
         hierarchy.
      3. The ACS is able to modify the CPE's state such that it no longer has a secondary
         WAN connection.
      4. The CPE and ACS are able to terminate the transaction session successfully.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    8.5.1.1     Purpose

    The purpose of this test is to validate that the ACS can configure parameters for the CPE
    to provision a line and initiate a SIP Register message. Note that this test is Voice device
    specific; IGDs should not attempt this test.

    When this test is complete the device should be in the following state:
      1. The proxy server's IP address equals that of the ACS, its port is equal to 5060,
         and its transport is UDP.
      2. The SIP Registration server, the user agent domain, and the SIP outbound proxy
         are empty.
      3. The user agent port is equal to 5060 and the user agent transport is UDP.
      4. The SIP registration period is 65 seconds.
      5. The voice line is enabled and
        a. The SIP username is test and the password is "password"
        b. The SIP user agent's URI is "user@<IP-address-of-ACS>"

        NOTE: QA Cafe has made a few small changes to steps 5a and 5b above. For
        step 5a a unique username is generated to ensure that old credentials
        are not used by the DUT. In addition, the URI in step 5b has also been
        modified to include the scheme identifier and omit the domain. As a
        result, the URI that is configured by the ACS is "sip:unique_user". The
        CPE should automatically append an "@" character and its IP address to
        this URI value according to TR-104.

    8.5.1.2     Procedure

      1. The ACS and CPE initiate a transaction session.
      2. The ACS locates variables of interest in the CPE's data heirarchy
      3. The ACS modifies the CPE's state such that it matches the device state described
         above.
      4. The ACS and CPE successfully terminate the transaction session.

    8.5.1.3     Success Metric

      1. The ACS and CPE are able to initiate a transaction session.
      2. The ACS is able to locate the object of interest in the CPE's data hierarchy.
      3. The ACS is able to change the configuration such that the device is in the state
         specified above.
      4. The CPE and ACS are able to terminate the transaction session successfully.
      5. A SIP register message is sent by the CPE (this can be verified using Ethereal,
         or equivalent; noSIP proxy server is needed).


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    8.6.1.1     Purpose

    The purpose of this test is to validate that the ACS can configure parameters for the CPE
    to initiate an IP Ping test, request that the test be performed, and collect the results.
    When this test is complete the device should have the following values in Internet-
    GatewayDevice.IPPingDiagnostics:

      1. DiagnosticState = Complete.
      2. Interface is in the proper format to represent the correct WANIPConnection
         pointer.
      3. Host is the IP address of the Router or the ACS (from the test environment).
      4. NumberOfRepetitions = 2
      5. Timeout = 17000
      6. DataBlockSize = 42
      7. DSCP = 0
      8. Other parameters are equal to the reported values of these parameters.

    8.6.1.2     Procedure

      1. The ACS and CPE initiate a transaction session.
      2. The ACS modifies the CPE state such that it matches the device state described
         above.
      3. The CPE executes the IPPing diagnostic test.
      4. The ACS reads the results of the diagnostic test.
      5. The ACS and CPE successfully terminate the transaction session.

    8.6.1.3     Success Metric

      1. The ACS and CPE are able to initiate a transaction session when requested by the
         ACS.
      2. The ACS is able to locate the object of interest in the CPE's data hierarchy.
      3. The ACS is able to change the configuration such that the device is in the new
         requested state specified above and initiate a diagnostic test.
      4. The CPE is able to execute a diagnostic test of sending two ICMP ping messages.
      5. The CPE is able to communicate the results of the ping test to the ACS.
      6. The CPE and ACS are able to terminate the transaction session successfully.

    If the CPE does not support DSCP configuration, the testvar acsSupportsDSCP may be
    set to no. In this case, the CDRouter ACS will not attempt to configure the DSCP
    parameter when configuring the Ping session.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    8.6.2.1     Purpose

    The purpose of this test is to validate that the ACS can configure parameters for the CPE
    to initiate an DSL Diagnostic test, request that the test be performed, and collect the
    results.

    When this test is complete. yje device informs the ACS by sending the Inform message
    and the ACS is able to retrieve the diagnostic results.

    This test should be run only on those CPE that indicate support of DSLDiagnostics
    Profile.

    At the end of the tests, the device has the following values in
    InternetGatewayDevice.WANDevice.{i}.WANDSLDiagnostics:

      1. DiagnosticState = Complete.
      2. ACTPSDds has an appropriate value as calculated for the Downstream actual
         power spectral density.
      3. ACTPSDus has an appropriate value as calculated for the Upstream actual power
         spectral density.
      4. ACTATPds has an appropriate value as calculated for the Downstream actual
         aggregate transmitter power.
      5. ACTATPus has an appropriate value as calculated for the Upstream actual aggregate
         transmitter power.
      6. HLINSCds has an appropriate value as calculated for the Downstream linear
         representation scale.
      7. HLINSCup has an appropriate value as calculated for the Upstream linear
         representation scale.
      8. QLNpsds has an appropriate value as calculated for the Downstream linear channel
         characteristics per subcarrier, as a Comma-separated list of integers. Each
         successive pair of integers represents the real and imaginary parts of each
         complex value. Maximum number of complex pairs is 256 for ADSL and
         ADSL2, 512 for ADSL2+.
      9. SNRpsds has an appropriate value as calculated for the Downstream SNR per
         subcarrier, as a Comma-separated list of integers. Maximum number of elements
         is 256 for ADSL and ADSL2, 512 for ADSL2+.
      10. BITSpsds has an appropriate value as calculated for the Downstream bit allocation
          per subcarrier, as a Comma-separated list of integers. Maximum number of elements
          is 256 for ADSL and ADSL2, 512 for ADSL2+.
      11. GAINpsds has an appropriate value as calculated for the Downstream gain
          allocation per subcarrier, as a Comma-separated list of integers. Maximum
          number of elements is 256 for ADSL and ADSL2, 512 for ADSL2+.

    8.6.2.2     Procedure

      1. The ACS and CPE initiate a transaction session.
      2. The ACS sends the set the
         InternetGatewayDevice.WANDevice.{i}.WANDSLDiagnostics.DiagnosticState
         = Requested. The CPE sets this parameters and returns the status = 1 to ACS.
      3. The CPE terminates the transaction session with ACS and executes the tests
         automatically. CPE may be required to change to DELT mode to execute the test
         and return to normal model once it is done.
      4. Once the test is complete. the CPE again initiates the session with ACS and
         includes the event "8 DIAGNOSTICS COMPLETE".
      5. The ACS reads the results of the diagnostic test using GetParameterValues RPC.
      6. The ACS and CPE successfully terminate the transaction session after ACS is
         done.

    8.6.2.3     Success Metric

      1. The ACS and CPE are able to initiate a transaction session when requested by the
         ACS.
      2. The ACS is able to locate the object of interest in the CPE's data hierarchy,
         change the appropriate parameter.
      3. CPE is able to execute the required test and inform ACS about the result. In case
         the CPE is not able to execute the test, it is able to inform the ACS of its
         Diagnostics State indiciating the error condition.

    NOTE:

    By default, CDRouter will allow 600 seconds (10 minutes) for the DSL Diagnostic
    test to complete. This value can be configured using the testvar
    dslDiagnosticTestDuration.

    testvar dslDiagnosticTestDuration 600


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    8.7.1.1 Purpose

    The purpose of this test is to validate that the information exchanged by a CPE and IGD
    in Test 3 - DHCP Vendor Option Test is correctly made available in the CPE's
    GatewayInfo object and the IGD's ManageableDevice table, and that the changes are
    correctly notified to the ACS. Note that this test is TR-111 specific.

    8.7.1.2 Procedure

      1. The CPE and IGD ensure (probably via some local interface) that neither is
         aware of the other's existence (this may result in notifications to the ACS).
      2. The CPE and the IGD engage in a DHCP exchange in which each learns the identity
         of the other and adds this identity to their data model, posting notifications
         to the ACS as appropriate.
      3. The ACS learns from the CPE of its new IGD, and from the IGD of its new CPE.
      4. The ACS reads the Gateway Identity from the CPE, and the Device Identity from
         the IGD, and validates that they match.

    8.7.1.3 Success Metric

      1. The IGD is able to to learn the identity of the CPE.
      2. The CPE is able to learn the identity of the IGD.
      3. The ACS is able to learn and validate the identities of the CPE and IGD.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    8.8.1.1     Purpose

    The purpose of this test is to validate that the CPE and ACS can perform a series of TR-
    069 operations over multiple sessions.  It was observed during the first TR-069 Plugfest
    that it was common for CPE vendors to reboot their devices prior to each test case.
    Rebooting the CPE clears substantial state and thus represents an unrealistic test case.

    This test will repeat several of the TR-069 Protocol Tests using a periodic inform interval
    on the CPE.  If the CPE minimum periodic inform interval is too long for purposes of
    interoperability testing time allotted, the ACS may initiate a connection request to initiate
    each session.

    This test should be performed only for CPE that are capable of completing Test 5, Test 9
    and Test 10 without rebooting.

    8.8.1.2     Procedure

      1. Configure the CPE to use its minimum periodic inform interval.
      2. Repeat Test 5 - CWMP Session Initiation using any supported client/server
         authentication mechanism.
      3. Wait for next periodic inform, or have ACS initiate Connection Request.
      4. Repeat Test 9 - Get Parameter Names without rebooting the CPE.
      5. Wait for next periodic inform, or have ACS initiate Connection Request.
      6. Repeat Test 10 - Get Parameter Values without rebooting the CPE.

    8.8.1.3     Success Metric

      1. The CPE and ACS are able to successfully establish and terminate CWMP
         sessions with each other.
      2. The CPE and ACS are able to complete each test case (Test 5, Test 9, and Test
         10).


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    8.9.1.1     Purpose

    The purpose of this test is to show that the ACS and CPE system can maintain a
    persistent session across multiple TCP connections.

    8.9.1.2     Procedure

      1. Initiate a transaction session between the ACS and CPE through a successful
         Inform exchange
      2. The CPE sends an empty post or a CWMP request to the ACS.
      3. The ACS terminates the TCP connection through the use of the HTTP
         Connection:close header.
      4. The ACS and CPE establish a new TCP connection.
      5. The ACS and CPE successfully continue the CWMP session on the new TCP
         connection.
      6. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
         successfully terminates the session with the ACS.

    8.9.1.3     Success Metric

      1. The ACS and CPE are able to maintain a persistent session across multiple TCP
         connections.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    8.10.1.1    Purpose

    The purpose of this test is to show that the ACS and CPE can recover from an HTTP
    error during a CWMP session.

    8.10.1.2    Procedure

      1. The ACS and CPE successfully initiate a transaction session.
      2. The CPE sends an empty post or a CWMP request to the ACS.
      3. The ACS responds with an HTTP error, e.g. 400 (Bad Request).
      4. The CPE terminates the session unsuccessfully.
      5. The CPE retries the session in accordance with the session retry policy.
      6. The ACS and CPE successfully initiate a transaction session.
      7. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
         successfully terminates the session with the ACS.

    8.10.1.3    Success Metric

      1. The ACS and CPE successfully handle the HTTP error condition.
      2. The CPE and ACS are able to successfully establish and terminate a subsequent
         CWMP session.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    8.10.2.1    Purpose

    The purpose of this test is to show that the ACS and CPE can handle a CWMP fault
    during CWMP session initiation (this is a special case).

    8.10.2.2    Procedure

      1. The CPE initiates a CWMP session with the ACS by sending an Inform message.
      2. The ACS responds with a CWMP fault other than 8005 (Retry Request), e.g. 8001
         (Request Denied).
      3. The CPE terminates the session unsuccessfully.
      4. The CPE retries the session in accordance with the session retry policy.
      5. The ACS and CPE successfully initiate a transaction session.
      6. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
         successfully terminates the session with the ACS.

    8.10.2.3    Success Metric

      1. The ACS and CPE successfully handle the CWMP fault during session initiation.
      2. The CPE and ACS are able to successfully establish and terminate a subsequent
         CWMP session.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    8.11.1.1 Purpose

    The purpose of this test is to validate that the CPE can announce, via the top-level
    DeviceSummary parameter, which device profiles and profile versions it supports, and
    that the ACS can successfully parse the value of the DeviceSummary parameter.

    8.11.1.2 Procedure

      1. The ACS and CPE initiate a transaction session.
      2. The ACS extracts the value of the DeviceSummary parameter from the Inform
         message.
      3. The ACS parses the value of the DeviceSummary parameter.

    8.11.1.3 Success Metric

       1. The CPE is able to announce its top-level capabilities via the DeviceSummary
          parameter.
       2. The ACS is able to read and parse the CPE's top-level capabilities as announced
          via its DeviceSummary parameter.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    10.1.1.1 Purpose

    The purpose of this test is to validate that a Deployment Unit can be successfully
    installed when the ACS only specifies the UUID and URL.  In this test case, the ACS
    relies upon the CPE to determine which Execution Environment the Deployment Unit
    should be installed on.

    10.1.1.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a
         successful Inform exchange.
      2. The ACS issues the ChangeDUState RPC with a single Install operation
         that specifies values for the UUID and URL.
      3. The CPE responds, indicating that the request is accepted and that
         the Install will be attempted after the CWMP Session has completed.
      4. When the conditions outlined in Section 3.1 of TR-069 have been met,
         the CPE successfully terminates the session with the ACS.
      5. The CPE then initiates a new session to the file server contained
         within the URL for the purpose of retrieving the Deployment Unit.
      6. The CPE retrieves and installs the Deployment Unit, determining for
         itself which Execution Environment to use.
      7. After successful retrieval and installation of the Deployment Unit,
         the CPE initiates a new CWMP session with the ACS in which the
         Inform contains the “11 DU STATE CHANGE COMPLETE” event code.
      8. The CPE issues the DUStateChangeComplete message during that new session.
      9. The ACS responds with a DUStateChangeCompleteResponse message.
      10. When the conditions outlined in Section 3.1 of TR-069 have been met,
          the CPE successfully terminates the session with the ACS.
      11. Subsequent interrogation indicates that the CPE’s
         .SoftwareModules.DeploymentUnit.{i} table does indeed include a new
         Deployment Unit that has the same UUID and URL specified within the
         Install operation of the ChangeDUState RPC.

    10.1.1.3 Success Metric

      1. The ACS is able to have the CPE retrieve and install a new Deployment Unit.
      2. The CPE is able to retrieve and install the new Deployment Unit.

    NOTE: The path to the DeploymentUnit file and related UUID can be specified
    using:

    testvar tr69DUInstallImage /home/lab/du.img
    testvar tr69DUInstallUUID 12-23-34-23
    testvar tr69DUChangeTimeout 600


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    10.1.2.1 Purpose

    The purpose of this test is to validate that a Deployment Unit can be
    successfully installed when the ACS specifies the UUID, URL, and Execution
    Environment Reference. In this test case, the ACS tells the CPE which
    Execution Environment the Deployment Unit should be installed on.

    10.1.2.2 Procedure

    1.  Initiate a transaction session between the ACS and CPE through a
        successful Inform exchange.
    2.  The ACS issues the ChangeDUState RPC with a single Install operation that
        specifies values for the UUID, URL, and an Execution Environment Reference
        for an Execution Environment that exists in the data model and is appropriate
        for the type of Deployment Unit being installed.
    3.  The CPE responds, indicating that the request is accepted and that the Install
        will be attempted after the CWMP Session has completed.
    4.  When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
        successfully terminates the session with the ACS.
    5.  The CPE then initiates a new session to the file server contained within the
        URL for the purpose of retrieving the Deployment Unit.
    6.  The CPE retrieves and installs the Deployment Unit, using the Execution Environment
        that was included in the ChangeDUState RPC.
    7.  After successful retrieval and installation of the Deployment Unit, the CPE initiates
        a new CWMP session with the ACS in which the Inform contains the “11 APP ACTION COMPLETE”
        event code.
    8.  The CPE issues the DUStateChangeComplete message during that new session.
    9.  The ACS responds with a DUStateChangeCompleteResponse message.
    10. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE successfully
        terminates the session with the ACS.
    11. Subsequent interrogation indicates that the CPE’s .SoftwareModules.DeploymentUnit.{i} table
        does indeed include a new Deployment Unit that has the same UUID and URL specified within
        the Install operation of the ChangeDUState RPC.

    10.1.2.3 Success Metric

    1. The ACS is able to have the CPE retrieve and install a new Deployment Unit.
    2. The CPE is able to retrieve and install the new Deployment Unit.

    NOTE: The path to the DeploymentUnit file and related UUID can be specified
    using:

    testvar tr69DUInstallImage /home/lab/du.img
    testvar tr69DUInstallUUID 12-23-34-23
    testvar tr69DUChangeTimeout 600
    testvar tr69DUChangeExecEnvRef openwrt


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    10.1.3.1 Purpose

    The purpose of this test is to validate that a Deployment Unit can be
    successfully updated when the ACS only specifies the UUID. In this
    test case, the ACS relies upon the CPE to discover the URL that was
    used to install the Deployment Unit identified by the supplied UUID and
    update it with the Deployment Unit found at the discovered URL
    (the URL may have been altered by a previous Update operation, like in
     Test 10.1.5).

    10.1.3.2 Procedure

    1.  Initiate a transaction session between the ACS and CPE through a successful
        Inform exchange.
    2.  The ACS issues the ChangeDUState RPC with a single Update operation that
        specifies a value for the UUID.
    3.  The CPE responds, indicating that the request is accepted and that the Update
        will be attempted after the CWMP Session has completed.
    4.  When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
        successfully terminates the session with the ACS.
    5.  The CPE finds the Deployment Unit by searching on the UUID provided in the Update
        operation and then discovers the URL used at installation (or last update, see Test 10.1.5).
    6.  The CPE then initiates a new session to the file server contained within the
        discovered URL for the purpose of retrieving the Deployment Unit.
    7.  The CPE retrieves the Deployment Unit and applies the updates to the existing
        Deployment Unit.
    8.  After successful retrieval and application of the Deployment Unit updates, the CPE
        initiates a new CWMP session with the ACS in which the Inform contains the
        “11 APP ACTION COMPLETE” event code.
    9.  The CPE issues the DUStateChangeComplete message during that new session.
    10. The ACS responds with a DUStateChangeCompleteResponse message.
    11. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE successfully
        terminates the session with the ACS.
    12. Subsequent interrogation indicates that the CPE’s .SoftwareModules.DeploymentUnit.{i}
        table does indeed include an updated Deployment Unit that has the same UUID as specified
        within the Update operation of the ChangeDUState RPC.

    10.1.3.3 Success Metric

    1. The ACS is able to have the CPE retrieve and update an existing Deployment Unit.
    2. The CPE is able to retrieve the Deployment Unit and apply the updates to the
       existing Deployment Unit.

    NOTE: The UUID of the DU can be specified using:

    testvar tr69DUInstallUUID 12-23-34-23

    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    10.1.4.1 Purpose

    The purpose of this test is to validate that a Deployment Unit can be
    successfully updated when the ACS only specifies the URL. In this
    test case, the ACS relies upon the CPE to discover the Deployment Unit
    that last used the URL for an installation and then update it with the
    Deployment Unit found at the specified URL (the URL may have been
    altered by a previous Update operation, like in Test 10.1.5).

    10.1.4.2 Procedure

    1.  Initiate a transaction session between the ACS and CPE through a
        successful Inform exchange.
    2.  The ACS issues the ChangeDUState RPC with a single Update operation
        that specifies a value for the URL.
    3.  The CPE responds, indicating that the request is accepted and that
        the Update will be attempted after the CWMP Session has completed.
    4.  When the conditions outlined in Section 3.1 of TR-069 have been met,
        the CPE successfully terminates the session with the ACS.
    5.  The CPE identifies the Deployment Unit by searching for one that has
        used the specified URL during its last update or installation.
    6.  The CPE then initiates a new session to the file server contained within
        the URL for the purpose of retrieving the Deployment Unit.
    7.  The CPE retrieves the Deployment Unit and applies the updates to the
        existing Deployment Unit.
    8.  After successful retrieval and application of the Deployment Unit updates,
        the CPE initiates a new CWMP session with the ACS in which the Inform contains
        the “11 APP ACTION COMPLETE” event code.
    9.  The CPE issues the DUStateChangeComplete message during that new session.
    10. The ACS responds with a DUStateChangeCompleteResponse message.
    11. When the conditions outlined in Section 3.1 of TR-069 have been met, the
        CPE successfully terminates the session with the ACS.
    12. Subsequent interrogation indicates that the CPE’s .SoftwareModules.DeploymentUnit.{i}
        table does indeed include an updated Deployment Unit that has the same URL as specified
        within the Update operation of the ChangeDUState RPC.

    10.1.4.3 Success Metrics

    1. The ACS is able to have the CPE retrieve and update an existing Deployment Unit.
    2. The CPE is able to retrieve the Deployment Unit and apply the updates to the
       existing Deployment Unit.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    10.1.5.1 Purpose

    The purpose of this test is to validate that a Deployment Unit can be successfully
    updated when the ACS specifies both a UUID and a URL. In this test case, the ACS
    is instructing the CPE to identify the Deployment Unit to be updated by the
    specified UUID and then to retrieve the update from the specified URL. In the
    process of updating the Deployment Unit he CPE should also update the URL field that
    is associated with that Deployment Unit.

    10.1.5.2 Procedure

    1.  Initiate a transaction session between the ACS and CPE through a successful
        Inform exchange.
    2.  The ACS issues the ChangeDUState RPC with a single Update operation that
        specifies values for the UUID and URL.
    3.  The CPE responds, indicating that the request is accepted and that the Update
        will be attempted after the CWMP Session has completed.
    4.  When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
        successfully terminates the session with the ACS.
    5.  The CPE finds the Deployment Unit by searching on the UUID provided in the Update.
    6.  The CPE then initiates a new session to the file server contained within the
        URL for the purpose of retrieving the Deployment Unit.
    7.  The CPE retrieves the Deployment Unit and applies the updates to the existing
        Deployment Unit.
    8.  The CPE updates the URL of the updated Deployment Unit to the one specified within
        the Update operation of the ChangeDUState RPC.
    9.  After successful retrieval and application of the Deployment Unit updates, the CPE
        initiates a new CWMP session with the ACS in which the Inform contains the
        “11 APP ACTION COMPLETE” event code.
    10. The CPE issues the DUStateChangeComplete message during that new session.
    11. The ACS responds with a DUStateChangeCompleteResponse message.
    12. When the conditions outlined in Section 3.1 of TR-069 have been met, the CPE
        successfully terminates the session with the ACS.
    13. Subsequent interrogation indicates that the CPE’s .SoftwareModules.DeploymentUnit.{i}
        table does indeed include an updated Deployment Unit that has the same UUID as specified
        within the Update operation of the ChangeDUState RPC.

    10.1.5.3 Success Metric

    1. The ACS is able to have the CPE retrieve and update an existing Deployment Unit.
    2. The CPE is able to retrieve the Deployment Unit, apply the updates to the
       existing Deployment Unit, and update the Deployment Unit’s URL.

    NOTE: The UUID of the DU can be specified using:

    testvar tr69DUInstallUUID 12-23-34-23


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    10.1.6.1 Purpose

    The purpose of this test is to validate that a Deployment Unit can be
    successfully uninstalled.

    10.1.6.2 Procedure

      1. Initiate a transaction session between the ACS and CPE through a
         successful Inform exchange.
      2. The ACS issues the ChangeDUState RPC with a single Uninstall
         operation that specifies a value for the UUID.
      3. The CPE responds, indicating that the request is accepted
         and that the Uninstall will be attempted after the CWMP Session has completed.
      4. When the conditions outlined in Section 3.1 of TR-069 have been
         met, the CPE successfully terminates the session with the ACS.
      5. After the uninstall of the Deployment Unit succeeds, the CPE
         initiates a new CWMP session with the ACS in which the Inform
         contains the “11 DU STATE CHANGE COMPLETE” event code. (NOTE: The
         timing on the removal of the resources is implementation specific
         and should happen before the Inform, but could happen after the
         Inform)
      6. The CPE issues the DUStateChangeComplete message during that
         new session.
      7. The ACS responds with a DUStateChangeCompleteResponse message.
      8. When the conditions outlined in Section 3.1 of TR-069 have
         been met, the CPE successfully terminates the session with the ACS.
      9. Subsequent interrogation indicates that the CPE’s
         .SoftwareModules.DeploymentUnit.{i} table does indeed not include
         the uninstalled Deployment Unit.  (NOTE: The timing on the removal
         of the resources is implementation specific and should happen before
         this step, but if it has not happened before this step then the
         Deployment Unit must have a Status parameter with a value of
         “Uninstalled”)

    10.1.6.3 Success Metric

      1. The ACS is able to have the CPE uninstall an existing Deployment Unit.
      2. The CPE is able to uninstall and remove an existing Deployment Unit.

    NOTE: The UUID of the DU can be specified using:

    testvar tr69DUInstallUUID 12-23-34-23

    This test will attempt to unistall the DU that is installed during test
    case od128_test_35.1


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Wait for new Inform from CPE
    step 3. Verify Inform contains required parameters
    step 4. For IGD 1.x, verify ExternalIPAddress of the default WAN interface
            is correct.

    Note that this test verifies the Inform requirements for CWMP 1.0 as
    defined in Broadband Forum TR-069 for IGD 1.x devices. The required
    Inform parameters for CWMP 1.1, defined in TR-069 Amendment 2, have
    been moved to TR-098 Amendment 2 Section 2.4.1. CWMP 1.1 specifies
    one additional required parameter as compared to CWMP 1.0
    InternetGatewayDevice.DeviceSummary.

    For newer IGD devices using the Device 2.0 data model, the required
    parameters are defined in TR-181 issue 2's data model with the forceInform
    attribute set to yes.

    NOTE: IGD devices based on 2.x are not required to include a WAN IP
    address.


    References:

    BBF CWMP Data Model InternetGatewayDevice:1.14 Root Data Model "TR-098 Issue 1 Amendment 8"

    https://cwmp-data-models.broadband-forum.org/tr-098-1-8-0.html

    BBF CWMP Data Model Device:1.14 Root Data Model "TR-181 Issue 1 Amendment 7"

    https://cwmp-data-models.broadband-forum.org/tr-181-1-7-0.html

    BBF CWMP Data Model Device:2.14 Root Data Model "TR-181 Issue 2 Amendment 14 Corrigendum 1"

    https://cwmp-data-models.broadband-forum.org/tr-181-2-14-1-cwmp.html

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Send GetParameterValues RPC using empty string
    step 3. Verify GetParameterValuesResponse or 9004 Soap Fault


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.2: GetParameterValues

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Send GetParameterNames RPC using empty string
    step 3. Verify GetParameterNamesResponse


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.3: GetParameterNames

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Send GetParameterAttributes RPC using empty string
    step 3. Verify GetParameterAttributesResponses or 9004 Soap Fault


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.5: GetParameterAttributes

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Send GetParameterNames RPC using empty string and nextLevel equal
            true
    step 3. Verify GetParameterNamesResponse returns the root object for the
            data model ending with a dot (either 'InternetGatewayDevice.' or
            'Device.').

    NOTE: A GetParameterNames with an empty string indicates the top of the
    name hierarchy. A GetParameterNames with a NextLevel value of true should
    return the root device or InternetGatewayDevice.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.3: GetParameterNames

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Send AddObject for new portmapping with ParameterKey value
    step 3. Verify AddObjectResponse is received
    step 4. Send GetParameterValues to read ParameterKey value
    step 5. Verify ParameterKey has new value
    step 6. Delete the port mapping using DeleteObject


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.6: AddObject

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Add new portmapping using AddObject
    step 3. Send DeleteObject for new portmapping with ParameterKey value
    step 4. Verify DeleteObjectResponse is received
    step 5. Send GetParameterValues to read ParameterKey value
    step 6. Verify ParameterKey has new value


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.7: DeleteObject

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Send SetParameterValues on InternetGatewayDevice.ManagementServer.UpgradesManaged
            and use new value for ParameterKey
    step 3. Verify SetParameterValuesResponse
    step 4. Send GetParameterValues to read ParameterKey value
    step 5. Verify ParameterKey has new value


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.1: SetParameterValues

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Send GetParameterValues to read ParameterKey value
    step 3. Send AddObject with bad instance and new ParameterKey value
    step 4. Verify AddObject fails with SOAP Fault
    step 5. Send GetParameterValues to read ParameterKey value
    step 6. Verify ParameterKey has not changed


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.6: AddObject

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Send GetParameterValues to read ParameterKey value
    step 3. Send DeleteObject with bad instance and new ParameterKey value
    step 4. Verify DeleteObject fails with SOAP Fault
    step 5. Send GetParameterValues to read ParameterKey value
    step 6. Verify ParameterKey has not changed


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.7: DeleteObject

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Send GetParameterValues to read ParameterKey value
    step 3. Send SetParameterValues on InternetGatewayDevice.ManagementServer.NoSuchPath
            and use new value for ParameterKey
    step 4. Verify SetParameterValues fails with SOAP Fault
    step 5. Send GetParameterValues to read ParameterKey value
    step 6. Verify ParameterKey has not changes


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.1: SetParameterValues

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Send a SetParameterValues on ManagementServer.NoSuchPath1,
            ManagementServer.NoSuchPath2 and PeriodicInformInterval
    step 3. Verify SetParameterValues fails with SOAP Fault
    step 4. Verify there is an error code for both invalid parameters

    Note: The testvar tr69MinPeriodicInform can be used to configure the value
    of the PeriodicInformInterval that is used for this test. This testvar
    should be set to a value supported by the DUT.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.1: SetParameterValues

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    Step 1. Send a SetParameterValues to the CPE using invalid arguments
    Step 2. Verify the CPE responds with a 9003 FaultCode
    Step 3. Send a SetParameterValues to the CPE using an invalid parameter type
    Step 4. Verify the CPE responds with a 9006 FaultCode
    Step 5. Send a SetParameterValues to the CPE with an invalid value
    Step 6. Verify the CPE responds with a 9007 FaultCode
    Step 7. Send a SetParameterValues to the CPE writing to a read-only
            parameter
    Step 8. Verify the CPE responds with a 9008 FaultCode


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.5.1: CPE Fault Codes

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Create a new IP host on the WAN side
    step 2. Initiate a new CWMP connection using Connection Request URL from the
            new host
    step 3. Verify the ACS receives a CONNECTION REQUEST event

    The CPE MUST accept Connection Request notifications coming from a source
    other than the ACS itself, provided the entity issuing the Connection Request
    has the correct authentication parameters for the target CPE.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.2.2: ACS Connection Initiation

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL from the
            new host
    step 2. Issue a 302 HTTP response and redirect to a new ACS server
    step 3. Verify the CPE establishes a new CWMP session with the new server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP response
    codes, which an ACS MAY use for redirection of a CPE. If the CPE is redirected
    in this way, the redirected address MUST apply only to the current session.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL from the
            new host
    step 2. Issue a 307 HTTP response and redirect to a new ACS server
    step 3. Verify the CPE establishes a new CWMP session with the new server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP response
    codes, which an ACS MAY use for redirection of a CPE. If the CPE is redirected
    in this way, the redirected address MUST apply only to the current session.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL from the
            new host
    step 2. Issue a 302 HTTP response and redirect to a new ACS server
    step 3. Configure new ACS server to issue a 302 redirect to the original
            server
    step 4. Verify the CPE establishes a new CWMP session with the original
            server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP
    response codes, which an ACS MAY use for redirection of a CPE. If the CPE is
    redirected in this way, the redirected address MUST apply only to the
    current session.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL from the
            new host
    step 2. Issue a 307 HTTP response and redirect to a new ACS server
    step 3. Configure new ACS server to issue a 307 redirect to the original
            server
    step 4. Verify the CPE establishes a new CWMP session with the new server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP
    response codes, which an ACS MAY use for redirection of a CPE. If the CPE is
    redirected in this way, the redirected address MUST apply only to the
    current session.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL from the
            new host
    step 2. Issue a 302 HTTP response and redirect to a new ACS server on port 7547
    step 3. Verify the CPE establishes a new CWMP session with the new server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP response
    codes, which an ACS MAY use for redirection of a CPE. If the CPE is redirected
    in this way, the redirected address MUST apply only to the current session.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL from the
            new host
    step 2. Issue a 307 HTTP response and redirect to a new ACS server at port 7547
    step 3. Verify the CPE establishes a new CWMP session with the new server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP response
    codes, which an ACS MAY use for redirection of a CPE. If the CPE is redirected
    in this way, the redirected address MUST apply only to the current session.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL from the
            new host
    step 2. Issue a 302 HTTP response and redirect to a new ACS server with a HTTPS URL
    step 3. Verify the CPE establishes a new CWMP session with the new server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP response
    codes, which an ACS MAY use for redirection of a CPE. If the CPE is redirected
    in this way, the redirected address MUST apply only to the current session.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL from the 
            new host
    step 2. Issue a 307 HTTP response and redirect to a new ACS server with a HTTPS URL
    step 3. Verify the CPE establishes a new CWMP session with the new server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP response
    codes, which an ACS MAY use for redirection of a CPE. If the CPE is redirected
    in this way, the redirected address MUST apply only to the current session.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Turn off the setting of the Path for any Set-Cookie or Set-Cookie2
    step 2. Run test OD128 Test 1 Part 3

    NOTE: This is a repeat of OD-128 Test case 1 part 3 to verify cookies when
    no 'Path' option is used in the Set-Cookie or Set-Cookie2. The Path
    parameter is not required in a Set-Cookie or Set-Cookie2, but some
    implementations have trouble if the HTTP server does not explicitly set the
    Path.


    References:

    Broadband Forum OD-128 "Test Plan for TR-069 Plugfests, Rev 4"

    step 1. Initiate a new CWMP connection using Connection Request URL from the
            new host
    step 2. Issue a 301 HTTP response and redirect to a new ACS server
    step 3. Verify the CPE establishes a new CWMP session with the new server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP response
    codes, which an ACS MAY use for redirection of a CPE. If the CPE is redirected
    in this way, the redirected address MUST apply only to the current session.
    A CPE MAY also support the 301 (Moved Permanently) HTTP status
    code for redirection.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL from the
            new host
    step 2. Issue a 301 HTTP response and redirect to a new ACS server
    step 3. Configure new ACS server to issue a 301 redirect to the original
            server
    step 4. Verify the CPE establishes a new CWMP session with the new server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP response
    codes, which an ACS MAY use for redirection of a CPE. If the CPE is redirected
    in this way, the redirected address MUST apply only to the current session.
    A CPE MAY also support the 301 (Moved Permanently) HTTP status
    code for redirection.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL from the
            new host
    step 2. Issue a 301 HTTP response and redirect to a new ACS server at port 7547
    step 3. Verify the CPE establishes a new CWMP session with the new server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP response
    codes, which an ACS MAY use for redirection of a CPE. If the CPE is redirected
    in this way, the redirected address MUST apply only to the current session.
    A CPE MAY also support the 301 (Moved Permanently) HTTP status
    code for redirection.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Initiate a new CWMP connection using Connection Request URL from the new host
    step 2. Issue a 301 HTTP response and redirect to a new ACS server with a HTTPS URL
    step 3. Verify the CPE establishes a new CWMP session with the new server

    NOTE: A CPE MUST support 302 (Found) and 307 (Temporary Redirect) HTTP response
    codes, which an ACS MAY use for redirection of a CPE. If the CPE is redirected
    in this way, the redirected address MUST apply only to the current session.
    A CPE MAY also support the 301 (Moved Permanently) HTTP status
    code for redirection.


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section 3.4.2: Sessions

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Create new TCP port mapping on default WAN interface using wildcard
            for remoteHost
    step 2. Verify inbound TCP connection can be created from WAN using port
            mapping
    step 3. Create a 2nd inbound TCP connection from the WAN to verify port
            mapping
    step 4. Delete the port mapping using DeleteObject
    step 5. Verify TCP traffic from WAN can no longer use the port mapping

    NOTE: The following testvars can be used to configure the amount of time to
    wait before verifying whether a change made to the port mapping has actually
    taken effect:

    tr69PortMapCreationDelay (default: 0 seconds)
    tr69PortMapDeletionDelay (default: 15 seconds)


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4"

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf

    step 1. Create a new WAN endpoint using an IP from the free network range
    step 2. Create new TCP port mapping on the default WAN interface using the
            specific IP address of the new host created in step 1 for the
            remoteHost parameter in the port mapping entry
    step 3. Verify that the port mapping created in step 2 works by initiating
            an inbound TCP connection to the configured port
    step 4. Verify that inbound TCP connections from other hosts are not
            allowed if they try to use the port mapping configured in step 2
    step 5. Delete the port mapping using the DeleteObject RPC
    step 6. Verify that the port mapping is no longer active by initiating an
            inbound TCP connection to the configured port

    NOTE: The following testvars can be used to configure the amount of time to
    wait before verifying whether a change made to the port mapping has actually
    taken effect:

    tr69PortMapCreationDelay (default: 0 seconds)
    tr69PortMapDeletionDelay (default: 15 seconds)


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4"

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf