CDRouter USP Test Summaries (Full)

    Test Procedure:

    1. Allow the Controller to send a Get message to the Agent.
    2. Allow the Controller and Agent to establish an E2E Session
       Context with the payload security established in the test
       setup.
    3. Allow the Agent to send a GetResp or Error message to the
       Controller within the E2e Session Context.
    4. Allow the Controller to process the GetResp or Error
       message.
    5. Repeat steps 1, 3, and 4.

    Test Metrics:

    1. The Agent and Controller are able to establish an E2E Session
       Context.
    2. The Get messages and GetResp messages are sent and received
       within the E2E Session Context.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a Get message to the Agent.
    2. Allow the Controller and Agent to establish an E2E Session
       Context with the payload security established in the test
       setup.
    3. Allow the Agent to send a GetResp or Error message to the
       Controller within the E2e Session Context.
    4. Allow the Controller to process the GetResp or Error
       message.
    5. Interrupt the connection, or cause the Controller to wait more
       than 5 seconds.
    6. Repeat steps 1, 3, and 4.

    Test Metrics:

    1. The Agent and Controller are able to establish an E2E Session
       Context.
    2. The E2E Session Context expires after 5 seconds.
    3. The E2E Session Context is re-established after expiration.
    4. The Get messages and GetResp messages are sent and received
       within the E2E Session Context.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure :

    1. Allow the Controller to send a Get message to the Agent.
    2. Allow the Agent to send a GetResp or Error message to the
       Controller outside of an E2E Session Context.
    3. Allow the Controller to process the GetResp or Error
       message.

    Test Metrics:

    1. Integrity at the MTP layer is successfully established.
    2. The Get messages and GetResp or Error messages can be sent
       and received without an E2E Session Context.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send an Add message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: ADD
    }
    body {
        request {
            add {
                allow_partial: true
                create_objs {
                    obj_path: "<Object selected in test setup>"
                    param_settings {
                        param: "<Valid Parameter selected in test setup>"
                        value: "<Valid Value>"
                        required: false
                    }


                    obj_path: "<Object selected in test setup>"
                    param_settings {
                        param: "<Invalid Parameter>"
                        value: "<Any Value>"
                        required: true
                    }
                }
            }
        }
    }

    2. Allow the Agent to send an AddResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the Add message and creates the Object
       instances in its Instantiated Data Model.

    2. The Controller understands the AddResp and is able to learn
       the created Object(s) unique keys.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send an Add message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: ADD
    }
    body {
        request {
            add {
                allow_partial: false
                create_objs {
                    obj_path: "<Object selected in test setup>"
                    param_settings {
                        param: "<Valid Parameter selected in test setup>"
                        value: "<Valid Value>"
                        required: false
                    }
                    obj_path: "<Object selected in test setup>"
                    param_settings {
                        param: "<Invalid Parameter>"
                        value: "<Any Value>"
                        required: true
                    }
                }
            }
        }
    }

    2. Allow the Agent to send an Error message to the Controller.

    Test Metrics:

    1. The Agent rejects the Add message and sends an Error message.
    2. The Controller understands the Error and is able to learn which
       Objects and Parameters caused the Error.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a Set message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: SET
    }
    body {
        request {
            set {
                allow_partial: true
                update_objs {
                    obj_path: "<Object selected in test setup>"
                    param_settings {
                        param: "<Valid Parameter selected in test setup>"
                        value: "<Valid Value>"
                        required: false
                    }

                    obj_path: "<Object selected in test setup>"
                    param_settings {
                        param: "<Invalid Parameter>"
                        value: "<Any Value>"
                        required: true
                    }
                }
            }
        }
    }

    2. Allow the Agent to send a SetResp message to the
       Controller.

    Test Metrics:

    1. The Agent understand the Set message and updates the Object
       parameters in its Instantiated Data Model.
    2. The Controller understands and processes the SetResp
       message.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a Set message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: SET
    }
    body {
        request {
            set {
                allow_partial: false
                update_objs {
                    obj_path: "<Object selected in test setup>"
                    param_settings {
                        param: "<Valid Parameter selected in test setup>"
                        value: "<Valid Value>"
                        required: false
                    }

                    obj_path: "<Object selected in test setup>"
                    param_settings {
                        param: "<Invalid Parameter>"
                        value: "<Any Value>"
                        required: true
                    }
                }
            }
        }
    }

    2. Allow the Agent to send an SetResp message to the
       Controller.

    Test Metrics:

    1. The Agent rejects the Set message and sends an Error message.
    2. The Controller understands the Error and is able to learn which
       Parameters caused the Error.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a Set message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: SET
    }
    body {
        request {
            set {
                allow_partial: <any value>
                update_objs {
                    obj_path: "<Valid Search Expression Using the Parameter selected in test setup>"
                    param_settings {
                        param: "<Valid Parameter selected in test setup>"
                        value: "<Valid Value>"
                        required: <any value>
                    }
                }
            }
        }
    }

    2. Allow the Agent to send an SetResp message to the
       Controller.

    Test Metrics:

    1. The Agent understand the Set message and updates, in its
       Instantiated Data Model, the parameter of each Object matched
       in the given Search Expression.
    2. The Controller understands and processes the SetResp.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a Delete message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: DELETE
    }
    body {
        request {
            delete {
                allow_partial: true
                obj_paths:
                "<Deletable Object selected in test setup>"
                "<Non-Deletable Object selected in test setup>"
            }
        }
    }

    2. Allow the Agent to send a DeleteResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the Delete message and removes the Object
       instance from its Instantiated Data Model.
    2. The Controller understands and processes the DeleteResp.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a Delete message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: DELETE
    }
    body {
        request {
            delete {
                allow_partial: true
                obj_paths:
                "<Deletable Object selected in test setup>"
                "<Non-Deletable Object selected in test setup>"
            }
        }
    }

    2. Allow the Agent to send an Error message to the Controller.

    Test Metrics:

    1. The Agent rejects the Delete message and sends an Error
       message.
    2. The Controller understands and processes the Error message and
       understands which Objects caused the error.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a Get message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: GET
    }
    body {
        request {
            get {
                param_paths: "<First Parameter Path selected in test setup>"
                param_paths: "<Second Parameter Path selected in test setup>"
            }
        }
    }

    2. Allow the Agent to send a GetResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the Get message and sends a GetResp
       containing the requested parameters.
    2. The Controller understands and processes the Get message, and
       is able to learn the values of the requested parameters.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a Get message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: GET
    }
    body {
        request {
            get {
                param_paths: "<First Object Path selected in test setup>"
                param_paths: "<Second Object Path selected in test setup>"
            }
        }
    }

    2. Allow the Agent to send a GetResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the Get message and sends a GetResp
       containing the parameters and values of the requested Objects.
    2. The Controller understands and processes the Get message, and
       is able to learn the values of the parameters in the requested
       Objects.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a Get message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: GET
    }
    body {
        request {
            get {
                param_paths: "<Parameter Path selected in test setup>"
                param_paths: "<Object Path selected in test setup>"
            }
        }
    }

    2. Allow the Agent to send a GetResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the Get message and sends a GetResp
       containing the value of the requested Parameter and the
       parameters and values of the requested Object.

    2. The Controller understands and processes the Get message, and
       is able to learn the values of the parameters requested.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a Get message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: GET
    }
    body {
        request {
            get {
                param_paths: "<Search Path selected in test setup>"
            }
        }
    }

    2. Allow the Agent to send a GetResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the Get message and sends a GetResp
       containing the parameters and values of the Object(s) matched
       by the Search Expression.
    2. The Controller understands and processes the Get message, and
       is able to learn the values of the parameters requested.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    1. Allow the Controller to send a Get message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: GET
    }
    body {
        request {
            get {
                param_paths: "<Valid Parameter Path selected in test setup>"
                param_paths: "<Valid but non-existent Parameter Path selected in test setup>"
                param_paths: Device.InvalidPath.
            }
        }
    }

    2. Allow the Agent to send a GetResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the Get message and sends a GetResp
       containing the value of the requested valid Parameter, and
       error conditions explaining the failure to retrieve the other
       paths.
    2. The Controller understands and processes the Get message, is
       able to learn the values of the parameters requested, and
       process the paths that were in error.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a GetInstances message to the
       Agent with the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: GET_INSTANCES
    }
    body {
        request {
            GetInstances {
                obj_paths : <Object selected in test setup>
                bool first_level_only : false
            }
        }
    }

    2. Allow the Agent to send a GetInstancesResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the GetInstances message and sends a
       GetInstancesResp containing the Instance Identifiers and
       unique keys of Object Instances in the Agent's Instantiated
       Data Model from the specified Object and all multi-instance
       child objects.
    2. The Controller understands and processes the GetInstances
       message, and is able to learn the Instance Identifiers and
       unique keys.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a GetInstances message to the
       Agent with the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: GET_INSTANCES
    }
    body {
        request {
            GetInstances {
                obj_paths : <Object selected in test setup>
                bool first_level_only : true
            }
        }
    }

    2. Allow the Agent to send a GetInstancesResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the GetInstances message and sends a
       GetInstancesResp containing the Instance Identifiers and
       unique keys of Object Instances in the Agent's Instantiated
       Data Model, with no information about child objects.
    2. The Controller understands and processes the GetInstances
       message, and is able to learn the Instance Identifiers and
       unique keys.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a GetSupportedDM message to the
       Agent with the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: GET_SUPPORTED_DM
    }
    body {
        request {
            GetSupportedDM {
                obj_paths {
                    obj_path : Device.
                }
                first_level_only : false
                return_commands : false
                return_events : false
                return_params : false
            }
        }
    }

    2. Allow the Agent to send a GetSupportedDMResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the GetSupportedDM message and sends a
       GetSupportedDMResp containing the Objects that it supports
       in its Supported Data Model.
    2. The Controller understands and processes the GetSupportedDM
       message, and is able learn the supported Objects.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a GetSupportedDM message to the
       Agent with the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: GET_SUPPORTED_DM
    }
    body {
        request {
            GetSupportedDM {
                obj_paths {
                    obj_path : <Object selected in test setup>
                }
                first_level_only : true
                return_commands : true
                return_events : true
                return_params : true
            }
        }
    }

    2. Allow the Agent to send a GetSupportedDMResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the GetSupportedDM message and sends a
       GetSupportedDMResp containing the supported Object and its
       parameters, commands, and events.
    2. The Controller understands and processes the GetSupportedDM
       message, and is able learn the information about the supported
       Object.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    1. Allow the Controller to send a GetSupportedDM message to the
       Agent with the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: GET_SUPPORTED_DM
    }
    body {
        request {
            GetSupportedDM {
                obj_paths {
                    obj_path : Device.
                }
                first_level_only : false
                return_commands : true
                return_events : true
                return_params : true
            }
        }
    }

    2. Allow the Agent to send a GetSupportedDMResp message to the
       Controller.

    Test Metrics:

    1. The Agent understands the GetSupportedDM message and sends a
       GetSupportedDMResp containing its entire Supported Data
       Model.
    2. The Controller understands and processes the GetSupportedDM
       message, and is able learn the Agent's entire Supported Data
       Model.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Purpose:

    The purpose of this test is to demonstrate that the Controller can
    subscribe to a notification on the Agent using the
    Device.LocalAgent.Subscription.{i} table.

    Test Steps:

    1. Allow the Controller to send an Add message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: ADD
    }
    body {
        request {
            add {
                allow_partial: false
                create_objs {
                    obj_path: "Device.LocalAgent.Subscription."
                    param_settings {

                        {
                            param: "Enable"
                            value: "true"
                            required: true
                        }
                        {
                            param: "Recipient"
                            value: "Device.LocalAgent.Controller.<instance number of participating Controller>"
                            required: true
                        }
                        {
                            param: "ID"
                            value: "<subscription ID determined by the Controller>"
                            required: true
                        }
                        {
                            param: "NotifType"
                            value: "ValueChange"
                            required: true
                        }
                        {
                            param: "ReferenceList"
                            value: "<parameter selected during test setup>"
                            required: true
                        }
                    }
                }
            }
        }
    }

    2. Allow the Agent to send an AddResp message, and allow the
       Controller to process the response and learn the instance
       number of the created Subscription object.
    3. Alter the value of the parameter chosen during test setup.
    4. Allow the Agent to send a Notify message to the Controller with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: NOTIFY
    }
    body {
        request {
            notify {
                subscription_id: "<subscription_id>"
                send_resp: true
                value_change {
                    param_path: "<parameter selected during test setup>"
                    param_value: "<new value of the parameter selected during test setup>"
                }
            }
        }
    }

    5. Allow the Controller to process the Request and send a
       NotifyResp message to the Agent.

    Test Metrics:

    1. The Controller is able to subscribe to the ValueChange event on
       the Agent.
    2. The Controller is able to learn about the changed value of the
       parameter.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Purpose:

    The purpose of this test is to demonstrate that the Controller can
    disable a notification on the Agent by disabling the associated
    object in the Device.LocalAgent.Subscription. table.

    Test Procedure:

    1. Allow the Controller to send a Set message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: SET
    }
    body {
        request {
            set {
                allow_partial: false
                update_objs {
                    obj_path: "Device.LocalAgent.Subscription.<instance identifier of subscription object>."
                    param_settings {
                        param: "Enable"
                        value: "false"
                        required: true
                    }
                }
            }
        }
    }

    2. Allow the Agent to send a SetResp to the Controller.
    3. Alter the value of the parameter chosen during test setup of
       the test Subscription Creation Using ValueChange.

    Test Metrics:

    1. The Controller is able to disable the Subscription object on
       the Agent.
    2. No Notify message is sent when the parameter is altered.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Purpose:

    The purpose of this test is to demonstrate that the Controller can
    disable a notification on the Agent by deleting the associated
    object in the Device.LocalAgent.Subscription. table.

    Test Setup:

    1. Allow the Controller to send a Delete message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: DELETE
    }
    body {
        request {
            delete {
                allow_partial: false
                obj_paths {
                    "Device.LocalAgent.Subscription.<instance identifier of subscription object>."
                }
            }
        }
    }

    2. Allow the Agent to send a DeleteResp to the Controller.
    3. Alter the value of the parameter chosen during test setup of
       the test Subscription Creation Using ValueChange.

    Test Metrics:

    1. The Controller is able to delete the Subscription object on the
       Agent.
    2. No Notify message is sent when the parameter is altered.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Purpose:

    The purpose of this test is to demonstrate that the Controller can
    enable Notification for the creation of new object instances of a
    given object.

    Test Steps:

    1. Allow the Controller to send an Add message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: ADD
    }
    body {
        request {
            add {
                allow_partial: false
                create_objs {
                    obj_path: "Device.LocalAgent.Subscription."
                    param_settings {

                        {
                            param: "Enable"
                            value: "true"
                            required: true
                        }
                        {
                            param: "Recipient"
                            value: "Device.LocalAgent.Controller.<instance number of participating Controller>"
                            required: true
                        }
                        {
                            param: "ID"
                            value: "<subscription ID determined by the Controller>"
                            required: true
                        }
                        {
                            param: "NotifType"
                            value: "ObjectCreation"
                            required: true
                        }
                        {
                            param: "ReferenceList"
                            value: "<object selected during test setup>"
                            required: true
                        }
                    }
                }
            }
        }
    }

    2. Allow the Agent to send an AddResp to the Controller.
    3. Initiate the creation of an instance of the Object selected
       during test setup.
    4. Allow the Agent to send a Notify message to the Controller with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: NOTIFY
    }
    body {
        request {
            notify {
                subscription_id: "<subscription_id>"
                send_resp: true
                obj_creation {
                    obj_path: "<path to created object using instance number addressing>"
                    unqiue keys {
                        key: <one of one or more unique keys>
                        value: <value of the unique key>
                    }
                }
            }
        }
    }

    5. Allow the Controller to send a NotifyResp message to the
       Agent.

    Test Metrics:

    1. The Controller is able to subscribe to the ObjectCreation event
       on the Agent.
    2. The Controller is able to learn about the new Object Instance.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Purpose:

    The purpose of this test is to demonstrate that the Controller can
    enable Notification for the removal or expiration of new object
    instances of a given object.

    Test Steps:

    1. Allow the Controller to send an Add message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: ADD
    }
    body {
        request {
            add {
                allow_partial: false
                create_objs {
                    obj_path: "Device.LocalAgent.Subscription."
                    param_settings {

                        {
                            param: "Enable"
                            value: "true"
                            required: true
                        }
                        {
                            param: "Recipient"
                            value: "Device.LocalAgent.Controller.<instance number of participating Controller>"
                            required: true
                        }
                        {
                            param: "ID"
                            value: "<subscription ID determined by the Controller>"
                            required: true
                        }
                        {
                            param: "NotifType"
                            value: "ObjectDeletion"
                            required: true
                        }
                        {
                            param: "ReferenceList"
                            value: "<object selected during test setup>"
                            required: true
                        }
                    }
                }
            }
        }
    }

    2. Allow the Agent to send an AddResp to the Controller.
    3. Initiate the removal of an instance of the Object selected
       during test setup.
    4. Allow the Agent to send a Notify message to the Controller with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: NOTIFY
    }
    body {
        request {
            notify {
                subscription_id: "<subscription_id>"
                send_resp: true
                obj_deletion {
                    obj_path: "<path to deleted object using instance number addressing>"
                }
            }
        }
    }

    5. Allow the Controller to send a NotifyResp message to the
       Agent.

    Test Metrics:

    1. The Controller is able to subscribe to the ObjectDeletion event
       on the Agent.
    2. The Controller is able to learn about the removed Object
       Instance.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Purpose:

    The purpose of this test is to demonstrate that the Controller can
    receive an OnBoardRequest notification when triggered on the Agent
    via the SendOnBoardRequest() Operation.

    Test Procedure:

    1. Allow the Controller to send an Operate message to the Agent
       with the following minimum structure:

    Operate Request:
    header {
        msg_id: "<msg_id>"
        msg_type: OPERATE
    }
    body {
        request {
            operate {
                command: "Device.LocalAgent.Controller.<instance identifier of participating controller>.SendOnBoardRequest()"
                command_key: "onboard_command_key"
            }
        }
    }

    Note:

    The use of send_resp has been omitted here, as it is not the focus
    of the test case.  If the participants wish to have the Operate
    request confirmed by the Agent they are free to do so by setting
    send_resp to true, in which case, the Agent will send an
    OperateResp to the Controller.

    2. Allow the Agent to send a Notify message to the Controller with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: NOTIFY
    }
    body {
        request {
            notify {
                subscription_id: "<subscription_id>"
                send_resp: true
                on_board_req {
                    oui: "<oui of the Agent>"
                    product_class: "<product class string, if any>"
                    serial_number: "<serial number of the Agent, if any>"
                    agent_supported_protocol_version: "1.0"
                }
            }
        }
    }

    3. Allow the Controller to send a NotifyResp to the Agent.

    Test Metrics:

    1. The Controller is able to trigger an OnBoardRequest event on
       the Agent.
    2. The Controller receives and understands the OnBoardRequest
       event.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Purpose:

    The purpose of this test is to demonstrate that the Controller and
    Agent can recover from a lost notification when the NotifRetry
    parameter in the Subscription object is set to true.

    Test Procedure:

    1. Allow the Controller to send an Add message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: ADD
    }
    body {
        request {
            add {
                allow_partial: false
                create_objs {
                    obj_path: "Device.LocalAgent.Subscription."
                    param_settings {

                        {
                            param: "Enable"
                            value: "true"
                            required: true
                        }
                        {
                            param: "Recipient"
                            value: "Device.LocalAgent.Controller.<instance number of participating Controller>"
                            required: true
                        }
                        {
                            param: "ID"
                            value: "<subscription ID determined by the Controller>"
                            required: true
                        }
                        {
                            param: "NotifType"
                            value: "ValueChange"
                            required: true
                        }
                        {
                            param: "ReferenceList"
                            value: "<parameter selected during test setup>"
                            required: true
                        }
                        {
                            param: "NotifRetry"
                            value: "true"
                            required: true
                        }
                    }
                }
            }
        }
    }

    2. Allow the Agent to send an AddResp message, and allow the
       Controller to process the response and learn the instance
       number of the created Subscription object.
    3. Alter the value of the parameter chosen during test setup.
    4. Allow the Agent to send a Notify message to the Controller with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: NOTIFY
    }
    body {
        request {
            notify {
                subscription_id: "<subscription_id>"
                send_resp: true
                value_change {
                    param_path: "<parameter selected during test setup>"
                    param_value: "<new value of the parameter selected during test setup>"
                }
            }
        }
    }

    5. Prevent the delivery of the NotifyResp from the Controller
       by either causing it to not be emitted, or by interrupting the
       connection between the Controller and the Agent.
    6. Allow the Agent to engage in the Notification Retry algorithm
       using the default values for 30 seconds.
    7. Allow the Controller to successfully send a NotifyResp to
       the Agent.

    Test Metrics:

    1. The Agent retries the Notify message in accordance with the
       retry algorithm specified in the "Responses to Notifications
       and Notification Retry" section of TR-369.
    2. The Controller receives the Notification after it has been
       retried.
    3. The Agent stops sending the Notify message after it has been
       acknowledged.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Purpose:

    The purpose of this test is to demonstrate that the Controller can
    set a Subscription to expire using the TimeToLive parameter in the
    Subscription object.

    Test Procedure:

    1. Allow the Controller to send an Add message to the Agent with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: ADD
    }
    body {
        request {
            add {
                allow_partial: false
                create_objs {
                    obj_path: "Device.LocalAgent.Subscription."
                    param_settings {

                        {
                            param: "Enable"
                            value: "true"
                            required: true
                        }
                        {
                            param: "Recipient"
                            value: "Device.LocalAgent.Controller.<instance number of participating Controller>"
                            required: true
                        }
                        {
                            param: "ID"
                            value: "<subscription ID determined by the Controller>"
                            required: true
                        }
                        {
                            param: "NotifType"
                            value: "ValueChange"
                            required: true
                        }
                        {
                            param: "ReferenceList"
                            value: "<parameter selected during test setup>"
                            required: true
                        }
                        {
                            param: "TimeToLive"
                            value: "60"
                            required: true
                        }
                    }
                }
            }
        }
    }

    2. Allow the Agent to send an AddResp message, and allow the
       Controller to process the response and learn the instance
       number of the created Subscription object.
    3. Within 30 seconds, alter the value of the parameter chosen
       during test setup.
    4. Allow the Agent to send a Notify message to the Controller with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: NOTIFY
    }
    body {
        request {
            notify {
                subscription_id: "<subscription_id>"
                send_resp: true
                value_change {
                    param_path: "<parameter selected during test setup>"
                    param_value: "<new value of the parameter selected during test setup>"
                }
            }
        }
    }

    5. Allow the Controller to process the Request and send a
       NotifyResp message to the Agent.
    6. Allow the TimeToLive time to expire (60 seconds).
    7. Alter the value of the parameter chosen during test setup.
    8. Allow the Controller to send a GetInstances message to the
       Agent with the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: GET_INSTANCES
    }
    body {
        request {
            GetInstances {
                obj_paths : "Device.LocalAgent.Subscription."
                bool first_level_only : true
            }
        }
    }

    9. Allow the Agent to send a GetInstancesResp to the
       Controller.

    Test Metrics:

    1. No Notify message is sent after the TimeToLive has expired.
    2. The Subscription Object Instance has been removed from the
       Agent's Instantiated Data Model.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Purpose:

    The purpose of this test is to exercise the Controller and Agent
    abilities to handle synchronous operations initiated using the
    Operate message. The Device.Boot! event is exercised in the
    process.

    Test Steps:

    1. If there are no entries in the
       Device.LocalAgent.Controller.<instance id of
       controller>.BootParameter. table: a. Allow the Controller to
       send an Add message to the Agent with the following minimum
       structure:

    header {
        msg_id: "<msg_id>"
        msg_type: ADD
    }
    body {
        request {
            add {
                allow_partial: false
                create_objs {
                    obj_path: "Device.LocalAgent.Controller.<instance id of participating controller>.BootParameter."
                    param_settings {
                        {
                            param: "Enable"
                            value: "true"
                            required: true
                        }
                        {
                            param: "ParameterName"
                            value: "Device.DeviceInfo.SoftwareVersion"
                            required: true
                        }
                    }
                }
            }
        }
    }

       b. Allow the Agent to send an AddResp message to the
       Controller.

    2. If the Controller does not currently have a subscription to the
       Device.LocalAgent.Boot! event on the Agent: i. Allow the
       Controller to send an Add message to the Agent with the
       following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: ADD
    }
    body {
        request {
            add {
                allow_partial: false
                create_objs {
                    obj_path: "Device.LocalAgent.Subscription."
                    param_settings {

                        {
                            param: "Enable"
                            value: "true"
                            required: true
                        }
                        {
                            param: "Recipient"
                            value: "Device.LocalAgent.Controller.<instance number of participating Controller>"
                            required: true
                        }
                        {
                            param: "ID"
                            value: "boot-1"
                            required: true
                        }
                        {
                            param: "NotifType"
                            value: "Event"
                            required: true
                        }
                        {
                            param: "ReferenceList"
                            value: "Device.Boot!"
                            required: true
                        }
                    }
                }
            }
        }
    }

    3. Allow the Controller to send an Operate message to the Agent
       with the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: OPERATE
    }
    body {
        request {
            operate {
                command: "Device.Reboot()"
                command_key: "reboot_command_key"
                send_resp: true
            }
        }
    }

    4. Allow the Agent to send an OperateResp to the Controller.
    5. Allow the Agent to restart.
    6. Allow the Agent to send a Notify message to the Controller with
       the following minimum structure :

    header {
        msg_id: "<msg_id>"
        msg_type: NOTIFY
    }
    body {
        request {
            notify {
                subscription_id: "<subscription id>"
                send_resp: true
                event {
                    obj_path: "Device.LocalAgent."
                    event_name: "Boot!"
                    params {
                        {
                            key: "Cause"
                            value: "RemoteReboot"}
                        {
                            key: "CommandKey"
                            value: "reboot_command_key"}
                        {
                            key: "ParameterMap"
                            value: "{"Device.DeviceInfo.SoftwareVersion":"<software version>"}"
                        }
                    }
                }
            }
        }
    }

    7. Allow the Controller to send a NotifyResp message to the
       Agent.

    Test Metrics:

    1. The Controller is able to initiate the Reboot operation on the
       Agent.
    2. The Agent reboots.
    3. The Controller receives and process the Boot! event from the
       Agent.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Purpose:

    The purpose of this test is to exercise the Controller and Agent
    abilities to handle asynchronous operations initiated using the
    Operate message. The ability of the Controller to do a managed
    firmware upgrade through the Agent is exercised in the process.

    Test Procedure:

    1. If the Controller does not currently have a subscription to the
       Device.LocalAgent.TransferComplete! event assigned in the
       Agent, allow the Controller to send an Add message to the Agent
       with the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: ADD
    }
    body {
        request {
            add {
                allow_partial: false
                create_objs {
                    obj_path: "Device.LocalAgent.Subscription."
                    param_settings {

                        {
                            param: "Enable"
                            value: "true"
                            required: true
                        }
                        {
                            param: "Recipient"
                            value: "Device.LocalAgent.Controller.<instance number of participating Controller>"
                            required: true
                        }
                        {
                            param: "ID"
                            value: "<subscription ID determined by the Controller>"
                            required: true
                        }
                        {
                            param: "NotifType"
                            value: "Event"
                            required: true
                        }
                        {
                            param: "ReferenceList"
                            value: "Device.LocalAgent.TransferComplete!"
                            required: true
                        }
                    }
                }
            }
        }
    }

    2. Allow the Agent to send an AddResp message to the
       Controller.
    3. Allow the Controller to send an Operate message to the Agent
       with the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: OPERATE
    }
    body {
        request {
            operate {
                command: "Device.DeviceInfo.Firmware.<instance id of non-active firmware bank>.Download()"
                command_key: "download_command_key"
                send_resp: true
                input_args {
                    {
                        key: "URL"
                        value: "<URL of the firmware determined in test setup>"}
                    {
                        key: "Username"
                        value: ""}
                    {
                        key: "Password"
                        value: ""}
                }
            }
        }
    }

    4. Allow the Agent to create an instance of the
       Device.LocalAgent.Request. object.
    5. Allow the Agent to send an OperateResp with the following
       minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: OPERATE_RESP
    }
    body {
        request {
            operate_resp {
                operation_results {
                    executed_command: "Device.DeviceInfo.Firmware.<instance number of the Firmware object>.Download()"
                    req_object_path: "Device.LocalAgent.Request.<instance number of the Request object>."
                }
            }
        }
    }

    6. Allow the system modeled by the Agent to download the file.
    7. Allow the Agent to send a Notify message to the Controller with
       the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: NOTIFY
    }
    body {
        request {
            notify {
                subscription_id: "<subscription id>"
                send_resp: true
                event {
                    obj_path: "Device.LocalAgent."
                    event_name: "TransferComplete!"
                    params {
                        {
                            key: "Cause"
                            value: "Device.DeviceInfo.Firmware.<instance number of the Firmware object>.Download()"}
                        {
                            key: "CommandKey"
                            value: "download_command_key"}
                        {
                            key: "Requestor"
                            value: "<Endpoint ID of the Controller>"}
                        {
                            key: "TransferType"
                            value: "Download"}
                        {
                            key: "Affected"
                            value: "Device.DeviceInfo.Firmware.<instance number of the Firmware object>."}
                        {
                            key: "TransferURL"
                            value: "<URL of the firmware determined in test setup>"}
                        {
                            key: "StartTime"
                            value: "<time the download was started>"}
                        {
                            key: "CompleteTime"
                            value: "<time the download was completed>"}
                    }
                }
            }
        }
    }

    8. Allow the Controller to send a NotifyResp to the Agent.
    9. Allow the Controller to send an Operate message to the Agent
       with the following minimum structure:

    header {
        msg_id: "<msg_id>"
        msg_type: OPERATE
    }
    body {
        request {
            operate {
                command: "Device.DeviceInfo.Firmware.<instance id of non-active firmware bank>.Activate()"
                command_key: "activate_command_key"
                send_resp: true
            }
        }
    }

    10. Allow the Agent to send an OperateResp message to the
        Controller.
    11. Allow the Agent to create an instance of the
        Device.LocalAgent.Request. object.
    12. Allow the Agent to complete the firmware activation.

    Test Metrics:

    1. The Controller is able to manipulate the Agent to download the
       new firmware.
    2. The Controller is able to activate the new firmware on the
       Agent.


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ParameterPerRow CSV
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ObjectHierarchy JSON
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ParameterPerRow CSV
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ObjectHierarchy JSON
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ParameterPerColumn CSV
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using NameValuePair JSON
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ParameterPerColumn CSV
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using NameValuePair JSON
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ParameterPerRow CSV
    step 2. Ensure the EUT sends a POST to the HTTPS host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ObjectHierarchy JSON
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ParameterPerRow CSV
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ObjectHierarchy JSON
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ParameterPerColumn CSV
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using NameValuePair JSON
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ParameterPerColumn CSV
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using NameValuePair JSON
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ParameterPerRow CSV, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ObjectHierarchy JSON, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ParameterPerRow CSV, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ObjectHierarchy JSON, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ParameterPerColumn CSV, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using NameValuePair JSON, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using ParameterPerColumn CSV, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP
            using POSTs and encode the data using NameValuePair JSON, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ParameterPerRow CSV, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ObjectHierarchy JSON, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ParameterPerRow CSV, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ObjectHierarchy JSON, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ParameterPerColumn CSV, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using NameValuePair JSON, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using ParameterPerColumn CSV, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS
            using POSTs and encode the data using NameValuePair JSON, and URI parameters
    step 2. Ensure the EUT sends a POST to the HTTP host using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via USP
            usings and encode the data using ParameterPerRow CSV
    step 2. Ensure the EUT sends a Push! event using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via USP
            usings and encode the data using ObjectHierarchy JSON
    step 2. Ensure the EUT sends a Push! event using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via USP
            usings and encode the data using ParameterPerRow CSV
    step 2. Ensure the EUT sends a Push! event using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via USP
            usings and encode the data using ObjectHierarchy JSON
    step 2. Ensure the EUT sends a Push! event using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via USP
            usings and encode the data using ParameterPerColumn CSV
    step 2. Ensure the EUT sends a Push! event using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via USP
            usings and encode the data using NameValuePair JSON
    step 2. Ensure the EUT sends a Push! event using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via USP
            usings and encode the data using ParameterPerColumn CSV
    step 2. Ensure the EUT sends a Push! event using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via USP
            usings and encode the data using NameValuePair JSON
    step 2. Ensure the EUT sends a Push! event using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTT
             and encode the data using ParameterPerRow CSV
    step 2. Ensure the EUT sends a PUBLISH to the MQTT broker using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTT
            and encode the data using ObjectHierarchy JSON
    step 2. Ensure the EUT sends a PUBLISH to the MQTT broker using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTT
            and encode the data using ParameterPerRow CSV
    step 2. Ensure the EUT sends a PUBLISH to the MQTT broker using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTT
            and encode the data using ObjectHierarchy JSON
    step 2. Ensure the EUT sends a PUBLISH to the MQTT broker using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTT
            and encode the data using ParameterPerColumn CSV
    step 2. Ensure the EUT sends a PUBLISH to the MQTT broker using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTT
            and encode the data using NameValuePair JSON
    step 2. Ensure the EUT sends a PUBLISH to the MQTT broker using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTT
            and encode the data using ParameterPerColumn CSV
    step 2. Ensure the EUT sends a PUBLISH to the MQTT broker using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTT
            and encode the data using NameValuePair JSON
    step 2. Ensure the EUT sends a PUBLISH to the MQTT broker using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTTS
             and encode the data using ParameterPerRow CSV
    step 2. Ensure the EUT sends a PUBLISH to the MQTTS broker using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTTS
            and encode the data using ObjectHierarchy JSON
    step 2. Ensure the EUT sends a PUBLISH to the MQTTS broker using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTTS
            and encode the data using ParameterPerRow CSV
    step 2. Ensure the EUT sends a PUBLISH to the MQTTS broker using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTTS
            and encode the data using ObjectHierarchy JSON
    step 2. Ensure the EUT sends a PUBLISH to the MQTTS broker using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTTS
            and encode the data using ParameterPerColumn CSV
    step 2. Ensure the EUT sends a PUBLISH to the MQTTS broker using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTTS
            and encode the data using NameValuePair JSON
    step 2. Ensure the EUT sends a PUBLISH to the MQTTS broker using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTTS
            and encode the data using ParameterPerColumn CSV
    step 2. Ensure the EUT sends a PUBLISH to the MQTTS broker using CSV encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTTS
            and encode the data using NameValuePair JSON
    step 2. Ensure the EUT sends a PUBLISH to the MQTTS broker using JSON encoding


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP with JSON encoding
    step 2. Send an Operate message to the EUT for the ForceCollection() operation
    step 3. Ensure the EUT sends a POST to the HTTP host


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTP with CSV encoding
    step 2. Send an Operate message to the EUT for the ForceCollection() operation
    step 3. Ensure the EUT sends a POST to the HTTP host


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS with JSON encoding
    step 2. Send an Operate message to the EUT for the ForceCollection() operation
    step 3. Ensure the EUT sends a POST to the HTTPS host


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via HTTPS with CSV encoding
    step 2. Send an Operate message to the EUT for the ForceCollection() operation
    step 3. Ensure the EUT sends a POST to the HTTPS host


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via USP with JSON encoding
    step 2. Send an Operate message to the EUT for the ForceCollection() operation
    step 3. Ensure the EUT sends a POST to the USP host


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via USP with CSV encoding
    step 2. Send an Operate message to the EUT for the ForceCollection() operation
    step 3. Ensure the EUT sends a POST to the USP host


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTT with JSON encoding
    step 2. Send an Operate message to the EUT for the ForceCollection() operation
    step 3. Ensure the EUT sends a POST to the MQTT host


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTT with CSV encoding
    step 2. Send an Operate message to the EUT for the ForceCollection() operation
    step 3. Ensure the EUT sends a POST to the MQTT host


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTTS with JSON encoding
    step 2. Send an Operate message to the EUT for the ForceCollection() operation
    step 3. Ensure the EUT sends a POST to the MQTTS host


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    Test Procedure:

    step 1. Configure the EUT to perform regular bulk data transfers via MQTTS with CSV encoding
    step 2. Send an Operate message to the EUT for the ForceCollection() operation
    step 3. Ensure the EUT sends a POST to the MQTTS host


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

    step 1. Find the list of all defined USP scenarios
    step 2. If the testvar cwmpScenarioSingleMode is set to yes, run the next scenario.
            Otherwise, run all the scenarios.

    NOTE: For more help on USP scenarios, please visit the CDRouter USP
    user guide section on USP scenarios.

    Purpose:

    The purpose of this test is to validate that the EUT properly handles an Add
    message when the allow_partial element is set to false, and all required
    parameters to be set upon Object Creation succeed.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles an Add
    message when the allow_partial element is set to true, and all required
    parameters to be set upon Object Creation succeed.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles an Add
    message when the allow_partial element is set to false, and at least one
    required parameter fails, and only a single object is set.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles an Add
    message when the allow_partial element is set to false, and a single invalid
    object is set.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles an Add
    message when the allow_partial element is set to false, multiple objects are
    attempted, and all required parameters to be set upon Object Creation
    succeed.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles an Add
    message when the allow_partial element is set to false, multiple objects are
    attempted, and one of the objects is invalid.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles an Add
    message when the allow_partial element is set to false, and at least one
    required parameter fails in one of multiple objects.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles an Add
    message when the allow_partial element is set to true, and at least one
    required parameter fails (with an invalid value) in a single object.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles an Add
    message when the allow_partial element is set to true, and at least one
    required parameter fails in one of multiple objects.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles an Add
    message when the Controller uses unique key addressing.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles a Set
    message when the allow_partial element is set to false, and all required
    parameters to be updated succeed.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles a Set
    message when the allow_partial element is set to true, and all required
    parameters to be updated succeed.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles a Set
    message when the allow_partial element is set to false, and all required
    parameters to be updated succeed.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles a Set
    message when the allow_partial element is set to false, and a required
    parameter fails.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles a Set
    message when the allow_partial element is set to false, and required
    parameters in one of multiple objects fail.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles a Set
    message when the allow_partial element is set to true, and a required
    parameter on one of multiple objects fails.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles a Set
    message when the allow_partial element is set to true, and one of multiple
    non-required parameters fail.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles a Set
    message when the Controller uses unique key addressing.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles a Set
    message when the Controller uses a wildcard search path and the requested
    updates succeed.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles a Set
    message when the Controller uses a wildcard search path, allow_partial
    element is set to false, and required parameters in multiple objects fail.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/

    Purpose:

    The purpose of this test is to validate that the EUT properly handles a Set
    message when the Controller uses a wildcard search path, the allow_partial
    element is set to true, and a required parameter on multiple objects fails.


    References:

    BBF TP-469 Issue 1 Amendment 2 "Conformance Test Plan for USP Agents"

    https://usp-compliance.broadband-forum.org/