8 Mapping of procedures for management

8.0 Introduction

This clause contains all information on how to map management resource primitives from oneM2M TS-0004 [2] to the Remote Procedure Calls (RPCs) in BBF TR-069 [4].

8.1 Resource Type primitive mappings

8.1.0 Introduction

This clause contains all information on how to map Resource Type [2] to the Remote Procedure Calls (RPCs) in BBF TR-069 [4].

8.1.1 Alias-Based Addressing Mechanism

In order to utilize the Alias-Based Addressing Mechanism, the mechanism has to be supported by the ACS and CPE in order to map the M2M Service Layer identifier for the Resource instance to the CPE object instance. If the Alias-Based Addressing Mechanism feature is not supported by either the ACS or CPE, the CSE has to retain the mapping of the these M2M Resource instance identifiers.

8.1.2 Create primitive mapping

8.1.2.0 Introduction

The Create Request and Response primitives shall map to the AddObject RPC. The AddObject RPC is defined in BBF TR-069 [4] as a synchronous RPC and returns a successful response or one of the following fault codes in Table 8.1.2.0‑1.

Table 8.1.2.0‑1: AddObject Fault Code Mapping

8.1.2.1 M2M Service Layer Resource Instance Identifier mapping

When the Resource is a multi-instance Resource, the AddObject RPC should utilize the Alias-Based Addressing Mechanism as defined in Sectionclause 3.6.1 of BBF TR-069 [4] in order to use the Resource instance value of the URI.

8.1.3 Delete primitive mapping

8.1.3.1 Delete primitive mapping for deletion of Object Instances

The Delete Request and Response primitives that results in the deletion of a Resource shall map to the DeleteObject RPC. The DeleteObject RPC is defined in BBF TR-069 [4] as a synchronous RPC and returns a successful response or one of the following fault codes in Table 8.1.3.1‑1.

Table 8.1.3.1‑1: DeleteObject Fault Code Mapping

8.1.3.2 Delete primitive mapping for software un-install operation

The Delete Request and Response primitives that results in a software un-install operation (e.g. Resource [software]) shall use the ChangeDUState mechanism defined in BBF TR-069 [4]. The ChangeDUState mechanism is an asynchronous command that consists of the synchronous ChangeDUState RPC for the un-installation request and the asynchronous ChangeDUStateComplete RPC. The ChangeDUState RPC returns a successful response or one of the following fault codes in Table 8.1.3.2‑1. A successful response means that the CPE has accepted the ChangeDUState RPC.

Table 8.1.3.2‑1: ChangeDUState Fault Code Mapping

Once the CPE has attempted to change the state of the deployment unit, the CPE reports the result of the state change operation using the ChangeDUStateComplete RPC. The ChangeDUStateComplete RPC indicates a successful operation or one of the following fault codes in Table 8.1.3.2‑2.

Table 8.1.3.2‑2: ChangeDUStateComplete Fault Code Mapping

8.1.4 Update primitive mapping

8.1.4.1 Update primitive mapping for Parameter modifications

The Update Request and Response primitives that modifies the value of Resource attributes shall map to the SetParameterValues RPC. The SetParametersValue RPC is defined in BBF TR-069 [4] as a synchronous RPC and returns a successful response or one of the following fault codes in Table 8.1.4.1‑1.

Table 8.1.4.1‑1: SetParameterValues Fault Code Mapping

8.1.4.2 Update primitive mapping for upload file transfer operations

The Update Request and Response primitives that results in an upload file transfer operation (e.g. logStop attribute of the Resource [eventLog]) shall use the Upload mechanism defined in BBF TR-069 [4]. The Upload mechanism is an asynchronous command that consists of the synchronous Upload RPC for the Upload and the asynchronous TransferComplete RPC. The Upload RPC returns a successful response or one of the following fault codes in Table 8.1.4.2‑1. A successful response means that the CPE has accepted the Upload RPC.

Table 8.1.4.2‑1: Upload Fault Code Mapping

Once the CPE has attempted to upload the file, the CPE reports the result of the Upload operation using the TransferComplete RPC. The TransferComplete RPC indicates a successful operation or one of the following fault codes in Table 8.1.4.2‑2.

Table 8.1.4.2‑2: TransferComplete Fault Code Mapping

8.1.4.3 Update primitive mapping for download file transfer operations

The Update Request and Response primitives that results in a download file transfer operation (e.g. update attribute of Resource [firmware]) shall use the Download mechanism defined in BBF TR-069 [4]. The Download mechanism is an asynchronous command that consists of the synchronous Download RPC for the Download and the asynchronous TransferComplete RPC. The Download RPC returns a successful response or one of the following fault codes in Table 8.1.4.3‑1. A successful response means that the CPE has accepted the Download RPC.

Table 8.1.4.3‑1: Download Fault Code Mapping

Once the CPE has attempted to download the file, the CPE reports the result of the download operation using the TransferComplete RPC. The TransferComplete RPC indicates a successful operation or one of the following fault codes in Table 8.1.4.3‑2.

Table 8.1.4.3‑2: TransferComplete Fault Code Mapping

8.1.4.4 Update primitive mapping for reboot operation

The Update Request and Response primitives that results in a reboot operation (e.g. reboot attribute of Resource [reboot]) shall use the Reboot RPC defined in BBF TR-069 [4]. The Reboot RPC is asynchronous command. The Reboot RPC returns a successful response or one of the following fault codes in Table 8.1.4.4‑1.

Table 8.1.4.4‑1: Reboot Fault Code Mapping

8.1.4.5 Update primitive mapping for factory reset operation

The Update Request and Response primitives that results in a factory reset operation (e.g. factoryReset attribute of Resource [ reboot]) shall use the FactoryReset RPC defined in BBF TR-069 [4]. The FactoryReset RPC is an asynchronous command. The FactoryReset RPC returns a successful response or one of the following fault codes in Table 8.1.4.5‑1.

Table 8.1.4.5‑1: FactoryReset Fault Code Mapping

8.1.4.6 Update primitive mapping for software install operation

The Update Request and Response primitives that results in a software installation operation (e.g. install attribute of Resource [software]) shall use the ChangeDUState mechanism defined in BBF TR-069 [4]. The ChangeDUState mechanism is an asynchronous command that consists of the synchronous ChangeDUState RPC for the download and the asynchronous ChangeDUStateComplete RPC. The ChangeDUState RPC returns a successful response or one of the following fault codes in Table 8.1.4.6‑1. A successful response means that the CPE has accepted the ChangeDUState RPC.

Table 8.1.4.6‑1: ChangeDUState Fault Code Mapping

Once the CPE has attempted to change the state of the deployment unit, the CPE reports the result of the state change operation using the ChangeDUStateComplete RPC. The ChangeDUStateComplete RPC indicates a successful operation or one of the following fault codes in Table 8.1.4.6‑2.

Table 8.1.4.6‑2: ChangeDUStateComplete Fault Code Mapping

8.1.5 Retrieve primitive mapping

The Retrieve Request and Response primitives shall map to the GetParameterValues RPC. The GetParametersValue RPC is defined in BBF TR-069 [4] as a synchronous RPC and returns a successful response or one of the following fault codes in Table 8.1.5‑1.

Table 8.1.5‑1: GetParameterValues Fault Code Mapping

8.1.6 Notify primitive mapping

8.1.6.0 Introduction

The NotifyRequest and Response primitives permit notifications to AE or CSEs that have subscribed to a Resource.

While BBF TR-069 [4] has the capability to notify the subscribed ACS when an object's parameter has been modified, BBF TR-069 [4] does not have the capability for an ACS to be notified if any parameter within the object has been modified unless the ACS individually subscribes to all the parameters of the object.

As such the procedure for mapping the Notify Request and Response primitives for BBF TR-069 [4] is not possible unless the CSE subscribes to receive notification to all the parameters of an Object that are mapped to the Resource's attributes.

NOTE: In many implementations, subscribing to all the parameters of an Object that are mapped to the Resource can cause performance issues in the CPE as well as the CSE. As such using the attribute based subscription capabilities of BBF TR-069 [4] for subscription of Resources should be avoided when possible.

8.1.6.1 Procedure for subscribed Resource attributes.

When a

• BBF TR-069 [4] provides the capability to subscribe to changes of a specific attribute through the use of the SetParameterAttributes RPC using the "Active" value for the Notification parameter.
• BBF TR-069 [4] provides the capability to un-subscribe to changes of a specific attribute through the use of the SetParameterAttributes RPC using the "None" value for the Notification parameter.

The SetParametersAttributes RPC is defined in BBF TR-069 [4] as a synchronous RPC and returns a successful response or one of the following fault codes in Table 8.1.6.1‑1.

Table 8.1.6.1‑1: SetParameterAttributes Fault Code Mapping

8.1.6.2 Notification primitive mapping

Notify Request and Response primitives shall map to the BBF TR-069 notification mechanism. CPEs produce notifications for subscribed attributes using the BBF TR-069 Inform method, the Inform method has an argument Event that has as one of the EventCodes with the value "4 VALUE CHANGE" indicating that a subscribed parameter's value has changed. The parameter(s) that have changed are included ParameterList argument of the Inform method.

The ParameterList argument is list of name-value pairs; the name is parameter name and shall be mapped to the objectPath attribute of the Resource while the value is the most recent value of the parameter.

NOTE: BBF TR-069 CPEs do not report value changes of parameters that were modified by the ACS.

8.2

8.2.1 Update (Execute) primitive for the resource

8.2.1.0 Introduction

When the Update Request primitive for

The Hosting CSE performs command conversion of its [4] RPC procedures triggered is based on the value of the cmdType attribute of the resource defined in Table 8.2.1.0‑1. The CPE acceptance of the corresponding RPC procedures is indicated by returning a successful Response primitive to the initial Update Request.

The Fault Codes which may be returned by the CPE to the Hosting CSE are mapped onto execResult codes and stored in the corresponding clauses:8.2.1.1 to 8.2.1.7 inclusive:

Table 8.2.1.0‑1 Mapping of Execute primitives to BBF TR-069 RPC

8.2.1.1 Execute File Download

The download file transfer operation may use the Download mechanism defined in BBF TR-069 [4]. The Download mechanism is an asynchronous command which returns a successful response or one of the following fault codes mapped onto execResult values as detailed in Table 8.2.1.1‑1. A successful response to the Update primitive triggering the Execute procedure means that the CPE has accepted the Download RPC.

Table 8.2.1.1‑1: Download Fault Code Mapping

8.2.1.2 Execute File Upload Operations

The upload file transfer operation shall use the Upload mechanism defined in BBF TR-069 [4]. The Upload mechanism is an asynchronous command that consists of the synchronous Upload RPC for the Upload and the asynchronous TransferComplete RPC. The Upload RPC returns a successful response or one of the following fault codes mapped onto execResult values as detailed in Table 8.2.1.2‑1. A successful response to the Update primitive triggering the execute procedure means that the CPE has accepted the Upload RPC in Table 8.2.1.2‑1.

Table 8.2.1.2‑1: Upload Fault Code Mapping

8.2.1.3 Report Results using TransferComplete RPC

After a File Download or Upload has been attempted, the result of the operation is reported using the TransferComplete RPC. The TransferComplete RPC indicates a successful operation or one of the following fault codes mapped onto execResult values in Table 8.2.1.3‑2.

Table 8.2.1.3‑2: TransferComplete Fault Code Mapping

8.2.1.4 Execute Software Operations with ChangeDUState RPC

The software installation and uninstall operations shall use the ChangeDUState mechanism defined in BBF TR-069 [4]. The ChangeDUState mechanism is an asynchronous command that consists of the synchronous ChangeDUState RPC and returns a successful response or one of the fault codes mapped onto execResult values as detailed in Table 8.2.1.4.-1. A successful response to the Update primitive triggering the Execute procedure means that the CPE has accepted the ChangeDUState RPC.

Table 8.2.1.4‑1: ChangeDUState Fault Code Mapping

8.2.1.5 Report Results with ChangeDUStateComplete RPC

After software installation and uninstall operations using a ChangeDUState mechanism as defined in BBF TR-069 [4], the result of the state change operation is retrieved using the ChangeDUStateComplete RPC. The ChangeDUStateComplete RPC indicates a successful operation or one of the fault codes mapped onto execResult values as detailed in Table 8.2.1.5‑1.-1.

Table 8.2.1.5‑1: ChangeDUStateComplete Fault Code Mapping

8.2.1.6 Execute Reboot operation

The reboot operation shall use the Reboot RPC defined in BBF TR-069 [4]. The Reboot RPC is a synchronous command. A successful response to the Update primitive triggering the Execute procedure means that the CPE has accepted the Reboot RPC. The Reboot RPC returns a successful response or one of the fault codes mapped onto execResult values as detailed in Table 8.2.1.6‑1.

Table 8.2.1.6‑1: Reboot Fault Code Mapping

8.2.1.7 Execute Factory Reset operation

The factory reset operation shall use the FactoryReset RPC defined in BBF TR-069 [4]. The FactoryReset RPC is a synchronous command. A successful response to the Update primitive triggering the Execute procedure means that the CPE has accepted the FactoryReset RPC. The FactoryReset RPC returns a successful response or one of the fault codes mapped onto execResult values as detailed in Table 8.2.1.7‑1.

Table 8.2.1.7‑1: FactoryReset Fault Code Mapping

8.2.2 Delete resource primitive mapping

The Delete Request primitive for the [4] RPC commands for the corresponding sub-resources as follows:

• If there are no [4] RPCs.
• If there are [4] RPCs (e.g. File Upload and File Download RPCs), a BBF TR-069 [4] CancelTransfer RPC shall be initiated for each cancellable operation. Upon completion of all the cancellation operations, if any fault codes are returned by the CPE, an unsuccessful Response to the Delete primitive with status code "Delete mgmtCmd- execInstance cancellation error" is returned, and the Table 8.2.2‑1. If all cancellation operations are successful on the managed entity, a successful Response to the Delete primitive is returned and the resource is deleted.
• If there is at least one [4] RPCs (e.g. RPCs other than File Upload and File Download RPCs), the execStatus attribute of the specific

Table 8.2.2‑1: CancelTransfer Fault Code Mapping for Delete

8.2.3 Update (Cancel) primitive mapping

When the Update Request primitive for an

The hosting CSE determines whether the [4] RPCs are cancellable. Currently, only the BBF TR-069 File Upload and File Download RPCs are cancellable using the BBF TR-069 [4] CancelTransfer RPC:

• If the addressed sub-resource has an execStatus other than RUNNING, an un-successful Response to the Update primitive is returned with status code "Cancel execInstance - already complete".
• If the addressed [4] RPCs (e.g. File Upload and File Download RPCs), a BBF TR-069 [4] CancelTransfer RPC shall be initiated. For a successful CancelTransfer RPC the execStatus attribute of the specific Table 8.2.3‑1 and an unsuccessful Response is sent to the Update primitive with status code "Cancel execInstance - cancellation error".
• If the addressed [4] RPCs (e.g. RPCs other than File Upload and File Download RPCs), the execStatus attribute of the specific is changed to STATUS_NON_CANCELLABLE. An unsuccessful Response is sent to the Update primitive with status code "Cancel execInstance - not cancellable".

Table 8.2.3‑1: CancelTransfer Fault Code Mapping for Update (Cancel)

8.2.4 Delete primitive mapping

The Delete Request primitive for an [4] RPC commands for the corresponding sub-resources as follows:

• If the addressed [4] RPCs.
• If the addressed [4] RPCs (e.g. File Upload and File Download RPCs), a BBF TR-069 [4] CancelTransfer RPC shall be initiated. For a successful CancelTransfer RPC a successful response is sent to the Delete primitive and the sub-resource is deleted. For an unsuccessful CancelTransfer RPC the execStatus attribute is determined from the RPC fault codes as detailed in Table 8.2.4‑1 and an unsuccessful Response is sent to the Delete primitive with status code "Delete execInstance - cancellation failed".
• If the addressed [4] RPCs (e.g. RPCs other than File Upload and File Download RPCs), the execResult attribute is set to STATUS_NON_CANCELLABLE and an unsuccessful Response is sent to the Update primitive with status code "Delete execInstance - not cancellable".

Table 8.2.4‑1: CancelTransfer Fault Code Mapping for Delete

8.3 Resource [myCertFileCred] primitive mappings

8.3.1 Introduction

This clause contains information regarding the procedures for establishing a certificates presented by the managed entity in order for the peer to authenticate the managed entity.

8.3.2 Creation of Resource [myCertFileCred]

8.3.2.1 Introduction

The creation of a [myCertFileCred] resource requires the use of the BBF TR-069 Download RPC to establish the credential on the managed entity. Once the managed entity has obtained the credential, the Device.Security.Certificate.{i} instance's SUIDs parameter is set from the [myCertFileCred] attribute using the BBF TR-069 Set RPC.

8.3.2.2 Procedure for creation of Resource [myCertFileCred]

The Create Request and Response primitives for Resource [myCertFileCred] that results in a download file transfer shall use the Download mechanism defined in BBF TR-069 [4]. The Download mechanism is an asynchronous command that consists of the synchronous Download RPC for the Download and the asynchronous TransferComplete RPC. The Download RPC returns a successful response or one of the following fault codes in Table 8.3.2.2‑1. A successful response means that the CPE has accepted the Download RPC.

Table 8.3.2.2‑1: Download Fault Code Mapping

Once the CPE has attempted to download the file, the CPE reports the result of the download operation using the TransferComplete RPC. The TransferComplete RPC indicates a successful operation or one of the following fault codes in Table 8.3.2.2‑2.

Table 8.3.2.2‑2: TransferComplete Fault Code Mapping

Upon successful TransferComplete notification from the CPE, the newly created Device.Security.Certificate.{i} object instance shall be assigned the values of the SUIDs attribute using the procedure for updating parameters in clause 8.1.4.