The workflow functionality of the Order fulfilment module allows the creation of the following types of tasks:
- Install
- Terminate
- Connection Incident
- Network Incident
- Telco Migrate
- Port Migrate
- ONT Install
InTask and OutTask
Gridsz uses the terms InTask and OutTask to distinguish the incoming and outgoing tasks.
An InTask is an order created by the active operator. This order is delivered via the GRIDSZ API and portal to a Contractor party. Depending on the type of InTask that is created, the task will be assigned to the party that is assigned by the passive operator to execute the work. An InTask can have a SLA agreement which is visible on the GUI. Each InTask has is own identical DHID number, connection ID and search code. These identical identification numbers are equivalent for the InTask and the OutTask.
An OutTask is a taskset created by Gridsz based on an InTask order as received by the active operator. The OutTask will appear in the portal and API of the receiving party. Every OutTask contains details that are needed for the contractor to execute the work and shows metadata of the order, like the Status of the included tasks, the SLA status, the create and last updated date, priority, and contact details of the customer if applicable.
Install
The Install taskset always contains a standard task of a Patch_Install for the PoP, and potentially an FTU_Construct or FTU_Reconstruct for in the end user’s home.
The type of FTU to be placed is a free text that is directly specified by the Operator. Gridsz assumes that the contractor is aware of the types of FTU that can be requested.
In certain situations, there’s already an FTU at the end user’s home, in which only a patch_install task will be assigned to the contractor. It is also possible that the provided FTU by the active operator is different from the current FTU at the end user’s home, in which an FTU_Reconstruct task will be assigned to the contractor.
For the installation of a connection, a patch is always required. The contractor is asked to place a patch between the specified passive end point and the specified active endpoint. Hereby the passive endpoint is filled by Gridsz, whereas the active operator will provide the active endpoint.
Depending on the PoP type, the active equipment can be a port on active equipment or a port on a patch panel.
Terminate
A Terminate TaskSet can only be created on addresses that have previously been successfully delivered via an Install TaskSet. As such, if an Active Operator creates a Terminate order on an address that is not connected, the Terminate order will be denied.
The Active Operator also has to give the Active Endpoint on a Terminate order, on which the address is currently connected, to ensure that the Contractor receives the most recent Active Endpoint to conduct his work.
Based on the default configuration of a Terminate TaskSet, only a PATCH_REMOVE OutTask will be created for the Contractors to execute. This means that there is no FTU related Task.
Connection Incident
A connection Incident means a single connection is down. In this case, the specified contractor gets assigned the incident ticket to investigate the problem, and solve it whereas possible. Connection incidents are always a Prio 4. With this task type, the contractor gets a request to resolve a single incident on a connection.
The contractor assigned can do research on the incident and resolve the problem. To resolve the incident the contractor has to provide a reason code to the task:
DLV-01: Issue found in Active Operator Domain
DLV-02: Issue found in Customer Domain
DLV-03: Issue found in Underground Passive Domain
DLV-04: Issue found in PoP Passive Domain
DLV-05: No issue found (after investigation ok)
DLV-99: other + clarification
Network Incident
A network incident concerns a fault that affects several single connections. This incident means one incident has impact on, at least, N connections. Where N can be different per Active Operator. Default value for N = 48. For example a complete PoP is down or a main cable of the backbone has been cut. With this task type, the contractor receives a request to resolve a network failure (this could also be a failure in the city ring).
The contractor assigned can do research on the incident and resolve the problem. To resolve the incident the contractor has to provide a reason code to the task:
DLV-01: Issue found in Active Operator Domain
DLV-02: Issue found in Customer Domain
DLV-03: Issue found in Underground Passive Domain
DLV-04: Issue found in PoP Passive Domain
DLV-05: No issue found (after investigation ok)
DLV-99: other + clarification
Telco Migrate
The Migrate task type is to migrate an end-user from one Active Operator to another, also known as a Telco Migrate.
The Migrate task is very similar to the patch install, yet there is an important difference. When inserting a patch, the contractor must assume that the specified passive position (ODF drawer and position) is still occupied by the donor operator’s patch. As such, the Task becomes removing the donor operator patch and installing the recipient operator patch as specified in the TaskSet.
Depending on whether it’s the same requested fiber, it will either be a PATCH_MIGRATE or a PATCH_INSTALL and a PATCH_REMOVE. Potentially, there can also be a FTU_RECONSTRUCT if the desired FTU is different from the current FTU at the address. Any other fiber in use will also be de-patched, resulting in a PATCH_REMOVE.
With a Telco migrate the donor Active Operator of the migrate always needs to be informed. Regardless of whether it’s a PATCH_MIGRATE or a separate PATCH_INSTALL and PATCH_REMOVE.
Before a Migration Task is accepted, it goes through a Clean order check. Within this process it will also specifically check Migrations requirements. As such, it will check whether the Passive port is in use. In case this check fails, the Migration order will be denied. Additionally, as with all types of Tasks, a Migration order will be denied if there’s already a Task active on the requested Address.
Furthermore, with all Migration cases the Wishdate should also be used as the Plan Date. This means that the Contractor needs to put the provided Wishdate on all POP related TASKS. An exception to this are addresses with two connected fibers, on which the non-donated fiber can be planned at a later stage if desired, yet will generally concur at the same time.
If present, the FTU_RECONSTRUCT can be executed from a different date than is provided in the Wishdate. Additionally, there is no hard requirement on whether the FTU_RECONSTRUCT has to be completed before or after the patch migrate.
In rare cases where the Fiber is migrated, but the PATCH_REMOVE on the no longer used Fiber failed, the Migration order is still considered successful. The failed PATCH_REMOVE will be seen as a separate incident.
| Title | User Story | Notes |
|---|---|---|
| Quick switch | The end-customer should be disconnected as soon as possible | All preparation out-tasks must be finished successfully beforehand |
| Execution date | The disconnect & reconnect must occur exactly at planned time | Wish date will be used as exact plan date |
| Only 1 fiber active | As an AO I want to have exclusive access to the HAS. After MIGRATE only my 1 fiber should be connected to the HAS | AO hires both fibers in the cable to the HAS. |
| No other tasks | If a MIGRATE is ordered and there is any other InTask active on the connection, the task is DENIED | Can be improved later to be lease coarse |
| AEE must change | WHEN an end-customer switches from his current SP to a new SP AND the new SP uses the AO AND that AO keeps using the same AEE for the connection THEN the AO should not send a TELCO_MIGRATE task AND if he AO does it anyway, g.Task must reject that erroneous TELCO_MIGRATE Task | AEE and previous AEE are not allowed to be the same. The AO could disconnect the end-customer because it will get a donor message from Task telling the connection is occupied |
Port Migrate
The PORT_MIGRATE TASK is to migrate a connection for an ISP to a different Active Equipment Endpoint port in the PoP. Within this migrate the Active Operator and Service Provider stay the same. The connected fiber is moved from one port to another, and or from one module to another. The ISP stays the same for a Port Migrate, so no indication of a migrate will be provided on forehand to the active ISP.
The PORT_MIGRATE is a TASK that request a change in the active PORT and or MODULE , of the Active AO where a new Patch needs to be created. The active endpoint details get updated by the AO when creating a PORT_MIGRATE task, by filling this information in the Active endpoint fields.
The new Port and or Module data will be updated to AC once the task is set to DELIVERD status.
ONT Install
The task type ONT_INSTALL is generated for a contractor to install an ONT into the house of an end user. There is no specific task type for activation of the ONT. Gridsz assumes that the Contractor is aware of the ONT type to be used. If there are further instructions required, these can be placed in the comment section by the AO/ISP.
The task type ONT install is an optional OutTask type for the Install order. When the ISP/AO creates a new Install task for a specific address, they can select the option to create a ONT_Install task in this order.
When an Install order is created, Gridsz will check the data in AC to prepare the correct outtask types. An install order always contains a Patch_install. If there is no FTU in place, an install Order will also create an FTU_construct.
When there is already a FTU in place but the “to be” FTU type is different from the current FTU type, the outtask set will contain an FTU_Replacement, instead of an FTU_construct.
To update the status of an ONT_INSTALL task the plandate is mandatory to be filled.
Schematically these are the two scenarios:
| Scenario | Actions |
| ONT_Install No |
New Install task will create
When no FTU in place, new Install task will create:
When there is a wrong FTU in place, new Install task will create
The Install task wil follow the normal status flow |
| ONT_Install Yes |
New Install task will create
When no FTU in place, new Install task will create:
When there is a wrong FTU in place, new Install task will create:
|