Input Flow

1. Overview

The Input Flow provisions a CPE from a provisioning request. It is the main flow of the Provision Portal. The Single device tab, the Multiple device tab, ProvisioningForDevice and ProvisioningForDevices start the Input Flow. The /provision/* REST endpoints also start the Input Flow. For the full list, see Flows and Entry Points.

provisioningStarter receives the request. It runs the Input Flow once for each CPE of the request. The Business Process Model and Notation (BPMN) process of the Input Flow is inputFlowV3 in inputFlowV3.bpmn. For the processing modes, see Batch Processing.

For one CPE, the Input Flow does these steps:

  1. Saves the request data to the provision database (provision DB).

  2. Finds the CPE in the ACS or creates the CPE. Updates the device info and the domain.

  3. Collects the objects, standalone services and parameters.

  4. Creates or updates the objects and sub-objects on the CPE.

  5. Sets the non-object parameters.

  6. Waits for the ACS tasks, reboots the CPE on request and writes the final status.

The options Delete previous, Current only, Reprovision, Secondary provision and Reboot change the path. See Common Options.

2. Flow Diagram

The numbers in the circles are status codes. For their meaning, see Status Codes Reference.

Input Flow page 1
Figure 1. Input Flow, page 1: provision DB update and CPE search in the ACS
Input Flow page 2
Figure 2. Input Flow, page 2: objects and standalone services
Input Flow page 3
Figure 3. Input Flow, page 3: new and existing objects, sub-objects
Input Flow page 4
Figure 4. Input Flow, page 4: non-object parameters, task results and reboot

3. Steps

3.1. Save the Request to the Provision DB

The flow reads the CPE identifier from the request XML. The MAC address comes first. If the request has no MAC address, the flow uses the serial number (SN).

  1. The flow searches the provision DB for the identifier.

  2. If the request has Delete previous, the flow deletes the existing records.

  3. The flow creates or updates the records for the SN or the MAC address.

Code Meaning

251, 151

MAC address, SN in the request XML

1500

No SN and no MAC address in the request XML. The flow ends.

266, 271

MAC address in the provision DB: yes, no

161, 166

SN in the provision DB: yes, no

276, 171

Previous records of the MAC address, SN deleted

176

Provision DB updated

1700

Database exception. The flow ends.

3.2. Find the CPE in the ACS

If the identifier is an SN, the flow checks the ACS for the CPE:

  • The ACS has the CPE: the flow continues.

  • The ACS does not have the CPE, and <createDevice> is true: the flow creates the CPE with FTCreateDevice.

  • The ACS does not have the CPE, and <createDevice> is false: the flow ends with status 196.

<createDevice> is a setting in Configuration.xml. After status 196, the data waits for the CPE. When the CPE connects, the ACS Event Flow applies the stored data.

If the identifier is a MAC address, the flow gets the SN with FTFindCPEByWANMAC. Then the flow adds the SN to the records of the MAC address. If the ACS does not know the MAC address, the flow ends with status 261. The data waits for the CPE.

For a CPE in the ACS, the flow then does these steps:

  1. FTGetDeviceInfo gets the OUI and the Product Class.

  2. If device info exists, FTUpdateDeviceInfo sends the device info.

  3. If the request has a domain, FTSetCPEDomain sets the domain.

  4. If the request has Delete previous, FTRemoveCPEProvisionData removes the previous provisioning data from the ACS.

With Current only, the device info comes from the request. Otherwise, the device info comes from the provision DB.

Code Meaning

206

Search for the CPE in the ACS

186, 191

SN in the ACS: yes, no

700, 7000

FTCreateDevice: success, failure. The call needs the OUI and the Product Class.

196

CPE not in the ACS. The data waits for the CPE. Final status for an SN.

286, 291

SN for the MAC address in the ACS: yes, no

261

CPE not in the ACS. The data waits for the CPE. Final status for a MAC address.

177, 1770

SN added to the records of the MAC address: success, failure

216, 2160

OUI and Product Class: received, FTGetDeviceInfo failure

440 to 443, 110, 112

Source of the device info: request XML or provision DB

108, 1080

FTUpdateDeviceInfo: success, failure

600

No domain in the request

601, 6010

FTSetCPEDomain: success, failure

201, 2010

FTRemoveCPEProvisionData: success, failure

3.3. Collect Objects and Standalone Services

The flow decides what to send. With Current only, the flow reads only the request XML. Without Current only, the flow reads the provision DB. The provision DB already contains the data of the request.

Item What the flow does

Standalone services

A standalone service is a service in the request without its own objects or parameter values. The flow sends the defaults of the service. The flow takes the TR-069 objects of the service from Objects.xml. The default parameters come from Params.xml in Set Non-Object Parameters.

Objects

The flow matches the objects and sub-objects of the request with Objects.xml.

Object related parameters

The flow matches the parameters of these objects with Objects.xml. The flow adds the default values from Objects.xml.

If the flow finds at least one object name, the flow continues with Create and Update Objects. Otherwise, the flow writes status 182 and continues with Set Non-Object Parameters.

Code Meaning

450 to 453, 169, 170

Standalone services in the request XML or the provision DB

214, 212

Standalone service in Objects.xml: yes, no

172, 1720

Object names for the standalone services: received, failure

460 to 463, 173, 174

Objects in the request XML or the provision DB

175, 1750

Objects matched with Objects.xml: success, mismatch

470 to 473, 178, 181

Object related parameters in the request XML or the provision DB

179, 1790

Object related parameters matched with Objects.xml: success, mismatch

183, 1830

Default parameters of the objects from Objects.xml: received, mismatch

182

No Objects.xml data. No objects to process.

3.4. Create and Update Objects

First, the flow checks the online status of the CPE. An offline CPE can get new objects. The tasks wait in the ACS until the CPE connects. An offline CPE cannot get an object with a specific instance. In this case, the flow ends with status 5007.

The flow processes the objects one by one. The instance of an object decides the action. See also Provisioning Objects.

Instance Action

0

The flow creates a new object with its parameters. The flow uses FTAddObject. If the CPE is online and the reprovision flag is not 2, the flow waits for the task result.

1 to 9

The flow sets one parameter of the instance with FTSetDeviceParameters. The result of this call shows if the instance exists. If the instance exists, the flow sets all parameters of the instance with FTSetDeviceParameters. If the instance does not exist, the flow creates the object with FTAddObject. With reprovision flag 2, the flow cannot process a specific instance. The flow ends with status 3070.

After the flow creates an object, the flow processes the sub-objects. FTGetDeviceParametersByTransID gets the instance number of the new parent object. The flow creates the sub-objects under this instance.

Code Meaning

221, 211, 5000

CPE online, CPE offline, online status unknown

5007

Specific instance for an offline CPE. The flow ends.

184, 1840

First object selection: success, failure

185

Instance 0

187, 1850

FTAddObject with parameters: success, failure

305

FTAddObject with reprovision flag 2. The flow does not wait.

180

FTAddObject for an offline CPE. The flow does not wait.

1880, 5008

Task still pending after the timeout, task status unknown

189, 1890

Object created, task failed or rejected

190

Instance 1 to 9

3070

Specific instance with reprovision flag 2. The flow ends.

192, 1900, 1930, 5009

Check of the instance with FTSetDeviceParameters, and its task

194, 195

Instance exists, instance may not exist

293, 2930, 2940, 5012, 295, 2950

Parameters of an existing instance

197, 1970, 1980, 5010, 199, 1990

New instance with FTAddObject

800 to 808, 8040, 8050, 8080

Sub-objects

204, 205

Next object selected, no objects left

3.5. Set Non-Object Parameters

The flow collects the parameters outside objects:

  • the default parameters of the standalone services, from Params.xml

  • the non-object parameters of the request

  • without Current only, the non-object parameters of the provision DB

The flow matches the non-object parameters with Params.xml. The flow also adds the default parameters of their services. One FTSetDeviceParameters call sends all these parameters.

If the flow has no parameters and handled no objects, the flow ends with status 248. In this case, the CPE got only the device info.

Code Meaning

480 to 483, 157, 158

Standalone services in the request XML or the provision DB

219, 213

Standalone service in Params.xml: yes, no

159, 1590

Default parameters of the standalone services: received, failure

490 to 493, 113, 114

Non-object parameters in the request XML or the provision DB

217, 2171

Parameters matched with Params.xml: success, mismatch

163, 1630

Services and default parameters matched: success, failure

231, 2310

FTSetDeviceParameters: success, failure

160

No parameter data for the CPE

320, 322

Objects handled: at least one, none

248

Only the device info sent. Final status.

3.6. Wait for Results, Reboot and Finish

Case Action Final status

Reprovision flag 2

The flow does not wait for task results. If the request has Reboot, the flow reboots the CPE with FTRPCInvoke.

314

CPE online

The flow waits for the parameter task. See Waiting for Task Results. If the request has Reboot, the flow then reboots the CPE.

246

CPE offline

The flow does not wait. If the request has Reboot, the flow queues the reboot. The ACS runs the tasks when the CPE connects.

247
Code Meaning

215, 2150

FTCPEStatus: success, failure

321, 319

Non-object parameters handled: at least one, none

2350, 5001

Parameter task still pending after the timeout, task status unknown

164, 2460

Parameters set, task failed or rejected

165, 1650, 168, 1680, 313, 3130

Reboot with FTRPCInvoke: success, failure

246

Provisioning of an online CPE complete. Final status.

247

Offline CPE. The data waits for the CPE. Final status.

314

Provisioning with reprovision flag 2 complete. Final status.