IT Documentation - Network Operator & Infrastructure Owner v1.51 PDF

IT Documentation Network Operator & Infrastructure Owner Date: February 29, 2024 Content Content................................................................................................................................................................. 2 1. Introduction................................................................................................................................................ 6 1.1 Purpose............................................................................................................................................. 6 1.2 Limitations......................................................................................................................................... 6 1.3 Revision History................................................................................................................................. 6 1.4 Audience........................................................................................................................................... 9 1.5 References........................................................................................................................................ 9 1.6 Abbreviations & Concept................................................................................................................... 10 2. Integration Approach................................................................................................................................. 10 3. Integration Framework & Principles............................................................................................................. 11 4. Security & Authentication........................................................................................................................... 12 4.1 Server Certificates............................................................................................................................ 12 4.2 Registration..................................................................................................................................... 12 OpenNet API Registration......................................................................................................... 13 NO/IO Registration................................................................................................................... 13 4.3 OpenNet Integration Layer Authentication.......................................................................................... 13 1.2.1. Data Definition......................................................................................................................... 14 4.4 NO/IO Authentication....................................................................................................................... 15 4.5 Logging........................................................................................................................................... 16 5. Integration Layer Process........................................................................................................................... 16 6. Services & Communication.......................................................................................................................... 16 7. Address File.............................................................................................................................................. 17 Page 2 of 88 8. Structure & Handling of Work Orders within the OpenNet Solution............................................................... 18 8.1 Handling Order Changes................................................................................................................... 19 8.2 Handling Rescheduling..................................................................................................................... 19 8.3 Handling H1 & H3 Sold Together....................................................................................................... 19 9. Interaction/Sequence Diagram.................................................................................................................... 20 9.1 Network Capacity Handling............................................................................................................... 20 Capacity Check........................................................................................................................ 20 Capacity Check & Reservation................................................................................................... 24 Confirm Capacity Reservation.................................................................................................... 30 Cancel Capacity Reservation...................................................................................................... 32 Capacity Reservation Timeout................................................................................................... 33 10. Order fulfilment......................................................................................................................................... 34 10.1 Fulfilment requests....................................................................................................................... 34 Get Fulfilment Request............................................................................................................. 34 Update Fulfillment Request....................................................................................................... 38 10.2 Add Notes................................................................................................................................... 39 Data Definition......................................................................................................................... 40 10.3 Events......................................................................................................................................... 41 Create Event............................................................................................................................ 42 Get Next Event........................................................................................................................ 45 Update Event........................................................................................................................... 47 10.4 UDF API...................................................................................................................................... 48 Post UDF................................................................................................................................. 48 10.5 Combined Use of UDF's, Notes, Events & Fulfillment Requests......................................................... 48 11. Service Assurance...................................................................................................................................... 50 Page 3 of 88 11.1 Support Tools (OpenNetNO/IO)............................................................................................... 50 General Data Definition............................................................................................................. 51 Detailed Data Definition for task “getServiceStatus” version 1.0.................................................... 51 Detailed Data Definition for task “getServiceStatus_v2”............................................................... 53 11.2 Support Tools (NO/IOOpenNetNO/IO)................................................................................ 57 General Data Definition............................................................................................................. 57 11.3 Trouble Ticket.............................................................................................................................. 58 Get Trouble Ticket.................................................................................................................... 58 Update Trouble Ticket.............................................................................................................. 62 Get All Trouble Tickets Assigned To User.................................................................................... 64 Search for Open Trouble Tickets................................................................................................ 64 How to Use the Trouble Ticket System for serviceSubscriptionID Related Incidents........................ 67 11.4 Planned & Unplanned Outages...................................................................................................... 68 Create Outage......................................................................................................................... 69 Update Outage........................................................................................................................ 70 Upload Related Service Subscription ID’s.................................................................................... 71 Get Upload Status.................................................................................................................... 72 12. Timeslot Management................................................................................................................................ 73 12.1 Overview of Technician Calender................................................................................................... 73 12.2 Data Segregation......................................................................................................................... 74 12.3 Calendar Data.............................................................................................................................. 74 12.4 Timeslot Management Services...................................................................................................... 75 Get Timeslot Data.................................................................................................................... 75 Update Timeslot Data............................................................................................................... 77 Close Timeslots........................................................................................................................ 78 Page 4 of 88 Open Timeslots........................................................................................................................ 78 13. Exceptions................................................................................................................................................ 79 13.1 Standard Exceptions..................................................................................................................... 79 13.2 Example Bad Request................................................................................................................... 79 14. IO Charging file......................................................................................................................................... 79 14.1 File name and location.................................................................................................................. 79 14.2 File content specification............................................................................................................... 80 14.3 Sample line.................................................................................................................................. 80 14.4 List of transaction codes............................................................................................................... 80 14.5 Loading process and error handling............................................................................................... 81 15. Environments............................................................................................................................................ 81 16. Endpoint URL's.......................................................................................................................................... 81 16.1 Authentication API....................................................................................................................... 81 16.2 Other API's.................................................................................................................................. 81 17. API Rate limits and quota policies................................................................................................................ 86 18. sFTP access............................................................................................................................................... 87 18.1 Pre-Production............................................................................................................................. 87 18.2 Production................................................................................................................................... 87 19. Entity naming table.................................................................................................................................... 87 Page 5 of 88 1. Introduction 1.1 Purpose This document has the purpose of establishing a common understanding of how a Network Operator will interface with the OpenNet systems to perform provisioning, capacity check and afterwards confirm and reserve capacity in the network. Addtionally the Network Operator needs to handle Work Force Management and in-life service changes and service assurance processes. The aim is to provide the Network Operator with sufficient context and detail with regard to communication with OpenNets interfaces. It is envisaged that this high-level definition provides a sufficient architectural view with regard to the solution, approach and capabilities supported. The information herein will enable the Network Operator with an understanding as to how to interaction with OpenNet, and will occur and enable the necessary technical planning to develop systems/interfaces to consume OpenNet APIs for the operation of key business processes. The full and final description will be developed and controlled by OpenNet, as it is the owner of the OpenNet interface. 1.2 Limitations This document is to be considered as an API specification. For request examples see the OpenNet Connectivity packages. 1.3 Revision History Version Date Description 0.9 12.02.2018 First draft 0.91 09.03.2018 Updated the document 0.92 26.04.2018 Updated 0.93 29.05.2018 Added information mostly around fulfillment, events, notes. 0.94 04.06.2018 Added information about trouble ticket API 0.95 07.06.2018 Changed text from rescheduleAfter to rescheduleFrom in event and note definitions 0.96 09.06.2018 Added SUSPEND_SLA and RESUME_SLA to the defined trouble ticket tags. 0.97 18.06.2018 As agreed the codes for Fulfillment Request type has been modified to capital letters and underscores. Clarified information where needed, and added a little more information about the internal structure of the OpenNet system. 0.98 02.07.2018 Fixed wrong name and bad spelling "requestSeqenceNo" to "requestTypeSequenceNo" 0.99 04.07.2018 In Confirm Capacity request description, reference to networkOperatorDataField1-6 has been corrected to networkOperatorOut1-6. 1.00 30.07.2018 Added missing ] in the Get Trouble ticket JSON structure regarding notes array. 1.01 06.08.2018 Add note was wrongly stated to be a get. It should be a POST operation. With regard to events ORDFUL code should be ODRFUL instead. 1.12 16.10.2018 The document has a new format 1.13 19.10.2018 Added description of timeslot handling and management. 1.14 19.10.2018 Corrected trouble ticket API type field. Was “STANDARD” should be “STAN”. 1.15 29.10.2018 In capacityCheckAndReserve and confirmCapacity API requests for H2 the content of the UDF field “serviceProviderIn1” has been modified to match formatting used else where. For H2 the expected format of serviceProviderIn1 is now: "{"svlan":34, "poiID":"JDMSK78986546"}" 1.16 03.12.2018 Corrected spelling mistakes. “REOPENNED” has been corrected to “REOPENED”. 1.17 21.03.2019 Rewritten the Trouble Ticket chapter, to align with new features. Page 6 of 88 1.18 12.04.2019 Replaced old figures and sequence diagrams with new optimized and updated visualizations. Also corrected minor spelling mistakes. 1.19 13.10.2019 Updated H2 related info related to serviceProviderIn and serviceProviderOut UDF fields. Updated wording in “Handling H1 & H3 Sold Together” chapter, to match agreed and implemented functionality. Main change is appointmentDate or actionDate is visible on fulfillment requests for both H1 and H3 service. 1.20 17.12.2019 Improved documentation of “Support Tools”. See section 11.1 1.21 03.01.2020 Added documentation for GENUPD eventSubType Renamed document to “IT Documentation - Network Operator & Infrastructure Owner” Added Outage documentation 1.22 03.01.2020 Added endpoint information for Production, and also sFTP hostname+port for both Pre-Prod and Production. Modified wording in section 8. In section 9.1.1 Capacity Check & Reservation, the mapping between inputted C-VLAN’s and returned T-VLAN’s has been clarified. Removed section 15, 16 and 17 covering ITSM and roles and responsibility. The information was obsolete and is now covered in process documentation and/or joint test planer. Fixed minor wording errors through out the document. 1.23 16.01.2020 Added documentation for fulfillment API version 2. Only change is adding “contactEmail” property to WORK_ORDER_NO, WORK_ORDER_IO and WORK_ORDER_PROVISIONING fulfillment requests. Added documentation for contactEmail to trouble ticket API version 2.0. URI change for capacityReservationTimedOut API. Moved from version 1.0 to 2.0 URI change for addNote API. Moved from version 1.4 to 2.0. 1.24 17.02.2020 Added IO Charging file specification. (Section 14) Updated possible timeslot codes to include AM_PR_1, AM_PR_2, PM_PR_1, PM_PR_2, PM_PR_3 Updated description of adminState in Support Tools API. 1.25 27.02.2020 Renamed section 10 to “Order fulfilment” instead of “Fulfilment requests” and reorganized sub sections. Introduced description of new event feature, where events can flow from NO->IO or IO- >NO using two new event types “NOEVENT” and “IOEVENT”. This also means that the getNextEvent and updateEvent API’s are now introduced for NO/IO entities. 1.26 18.06.2020 Added section 19 Entity Naming Table. Specified that “null” can be returned in rx/tx value when calling support tools. 1.27 22.08-2020 Added section 18 – API Rate limits and quota policies 1.28 25.02.2021 Documentation updated to reflect default token expiery time being 5 minuttes instead of 30 minuttes. Page 7 of 88 In the sample events, “ has been changed to \” to reflect the needed escape charactors. 1.29 25.02.2021 Specified that IO’s are not allowed to remove a temporary reservation unless a success response is returned from OpenNet in section 9.1.5 Added http response 4xx and 5xx to data definition in 9.1.5 Added Main Product relevance column to 11.1.2 If no qosProfile is configured in returnValue.configuration.qosProfile, then it must be null or “”, updated in 11.1.2 1.30 26.02.2021 Updated Trouble Ticket chapter of this document to describe in more details the different parameters and also a new searchOpenTroubleTickets API. Added description of internal trouble ticket notes to get and update trouble ticket API description. 1.31 04.03.2021 Updated 11.1.2 – if no CVLANs are provisioned then an empty array [] or null is returned in returnValue.configuration.provisionedVlans[index].id 1.32 26.03.2021 Added mising appointment information in getTroubleTicket API for SAWA type trouble tickets. 1.33 06.04.2021 Corrected confirmCapacityReservation description in regard to H2 and expected value in serviceProviderIn1. Earlier the description described a requirement to pass S-VLAN, which was incorrect. 1.34 26.04.2021 Corrected “Table 1: Data items – Search for Open Trouble Tickets”: “Array of “OPEN” Trouble Ticket Id's which are related to the user”. It was previously “Array of Trouble Ticket Id’s assigned to the user”. 1.35 04.05.2021 Added entities to entity naming table 1.36 11.05.2021 Added documentation for new errorAfterInstallation property for GET Trouble Ticket API version 2.0 onwards. See section 11.2.1 for details 1.37 27-07-2021 Removed variants for H2 (BASIC, ENTERPRISE, ADVANCED) Updated requirements in regard to serviceProviderOut1 and serviceProviderOut3 properties in Capacity Check And Reserve API response in regard to H2. Note: As a minimum the serviceProviderOut1 field must be populated for H1, H2 and H3 services in the capacityCheckAndReserve response. For H2 also the transceiverSpeed in serviceProviderOut3 is expected to be returned as part of the capacityCheckAndReserve Response. Added description of new autoAcknowledge=false feature for Get Fulfillment Request API and related changes to Update Fulfillment Request API. 1.38 Not released Updated endpoint URI for Add Note API to version 3.0 1.39 31-08-2021 New version 3.0 of fulfillment request API described. This version change the order fulfillment requests are returned to a FIFO style queue, and also introduce a priority property in the fulfillment request collect response, which allow NO/IO to detect if the appointment/actionDate has related to the order, was scheduled using the priority=triue flag from SP side. Priority=true means that the order has been agreed between SP and IO to be fast tracked. 1.40 10.11.2021 Added information about relatedEntities record, now being available in the GET Trouble Ticket response. (Require use of API version 3.0) 1.41 Corrected Support Tools API response definitions, in regard to which values are relevant for which main products. 1.42 01.03.2022 Added scenario causing a No Capacity Available response from capacityCheck and capacityCheckAndReserve API’s. Scenario: If an ongoing order, which involves the initial installation of a fiberbox, is currently preventing placement of new orders until completion. Expected completion date is only an indication, as the order can be rescheduled or cancelled. Page 8 of 88 ”message”:”{\”reasonCode\”:3000,\”description\”:\”Ongoing installation order on address. Expected completion 2022-05-23\”}” 1.43 03.10.2022 Clarification added to “9.1.3 Confirm Capacity Reservation”, to explicitly describe the required functionality of the Confirm Capacity Reservation API. Please take note of this, as the functionality of the API is expected to be very limited, to avoid the need for manual error handling on orders. Section 14.3: Corrected wrong format definition for transaction effective date, in regard to IO Charging file records. From yyyy-MM-dd to yyyy_MM_dd. Added note under BARRING fulfillment request definition, specifying the expected behaviour if SP executes a change of options on a barred service. Clarified that installationID in Capacity Check API as well as requiredInstallationID in serviceProviderIn UDF for Capacity Check and Reserve API is only expected to hold values which has been made available to OpenNet via the Address file. For Capacity Check and Reserve, the NO can optionally accept values in requiredInstallationID which has been registered on the address by not yet uploaded to OpenNet. NO is NOT required to build this logic. Removed option to reopen a cancelled trouble ticket. Added documentation for getServiceStatus_v2 1.44 28.11.2022 Added documentation for Trouble Ticket type “NETW”=Network ticket to support OpenNet Process 6.6 Multi and POI error. See GET Trouble Ticket API response description. Reference to Swagger documentation removed. OpenNet instead point readers to the OpenNet Connectivity Packages for SP or NO/IO entities to see request examples. 1.45 30.11.2023 Corrected SAWA trouble-ticket subState “REOPENED_SCHEDULED” to “REOPN_SCHD”. REOPENED_SCHEDULED was never implemented due to character restrictions. 1.46 28.02.2023 Added description of ratelimit headers and http 429 – Too Many Requests response within section 17. Removed requirement for VOCES or FOCES client certificates. 1.47 24.04.2023 Added description of IO’s being able to call Support Tools API which was only available to SP’s earlier. This is to improve the support of IO and NO being two different companies. 1.48 14.08.2023 Added status query parameter to Trouble Ticket Search API, to allow API to return OPEN, CLOSED or ALL updated trouble tickets since a specific time. 1.49 01.09.2023 Fixed typo in documentation for Open and Close Timeslot API’s. The documentation mistakenly wrote workFieldsArea where it should say workFieldArea. Using workFieldsArea as property name would result in the property being ignored in the timeslot filtration. 1.50 Added NETW as possible enum value for the type query parameter in Trouble Ticket Search API. Fixed technologyCode on workorders 1.51 14.02.2024 Defines Support tools response in regard to ethernet port interface for speeds higher than 1 Gbps Moved the definition of reasonCode and description in Capacity Check and Capacity Check and Reserve to the OpenNet Appendix. 1.4 Audience People with insight in the IT solution and integration. 1.5 References Title Document Ref. Issue Dated Page 9 of 88 1.6 Abbreviations & Concept Abbreviation Explanations API Application Programming Interface CRM Customer Relation Management which relate to OpenNet Core backend system Infrastructure Owner Own and develop the physical network and sells access to the infrastructure via the OpenNet Entity Network Operator To deliver technical operations and incident handling, including 2nd level and 3rd level support as defined in potential outsourcing contract with OpenNet. Order An instruction received by the OpenNet Integration Layer from a Service Provider to provide, change or terminate one or more OpenNet packages. OpenNet Name of Wholesale OpenNet is going to deliver wholesale products to Service Providers. Has primary contact with Wholesale customers (Service Providers). OpenNet Integration Layer The system built and administered by OpenNet which surrounds and interacts with the Cerillion Core System, via APIs. Service Provider To deliver Services to end-customers on the network, providing full packages including any content, voice and other Value Added Services they may find appropriate. Has contact with the end-customers. 2. Integration Approach The overall integration approach (see Figure 1) decouples connectivity between OpenNets CRM Core System and the multiple entities that enable the operational activities necessary to deliver and support end-customer services. The key participants involved in OpenNets services include: Service Provider (SP) Network Operator (NO) Infrastructure Owner (IO) This multi-party model is underpinned and enabled by OpenNet, acting as both the conduit and integration between the entities. In no situation are the entities expected to have direct contact, rather this is enabled via the OpenNet Integration/System. The OpenNet CRM & Billing Core System is delivered by OpenNet selected vendor Cerillion. Cerillion additionally provides the Integration Framework to which the OpenNet participants interface, which means that the Network Operator should only communicate with OpenNet Integration Layer. Page 10 of 88 A Network Operator communicates with the OpenNet Integration Layer over the public IP address via TLS (see Security Overall Integration Architecture Service Provider Two ways commun ication Public internet OpenNet Integration Layer OpenNet CRM Core System OpenNet Integration Layer Two ways communication Public internet Network Infrastructure Operator Owner & Authentication section). Figure 1: Overall Integration Architecture 3. Integration Framework & Principles Using Open Source components to enable the Integration Framework that provides a secure, performant and highly available solution, combined with industry standard approaches for integration and enterprise application integration, OpenNet provides a single approach that enables the OpenNet participants to perform specific business functions relevant to the role/action performed in support of the end-to-end solution. Key principles for the framework include: Authentication through username & password or client credentials provide secure access over HTTPs Use RESTful interfaces for simple and lightweight payloads Provide single patterns for specific interaction All participants will consume integration services for get and put operations Interfaces will support synchronous and asynchronous using request/response pattern Manage all exceptions and error handling gracefully, providing the consumer sufficient information to understand the issue for resolution activities Capture application or system exceptions/errors to enable application management Page 11 of 88 Use industry standard monitoring to ensure queues, throughput and processing are logged to ensure SLA are supported Approach is to provide single services that enable specific business functions Exception responses to be dealt with gracefully All exceptions and errors to be logged 4. Security & Authentication OpenNet is going to use the same security model around the OpenNet Integration Layer and Core Systems, which means the same security model applies to the three APIs in the system. To recap these are: OpenNet API: Published through OpenNet Integration Layer and consumed by the Service Provider Network Operator API: Published by Network Operator and consumed by OpenNet Integration Layer Infrastructur Owner API: Published by Infrastructure Owner and consumed by OpenNet Integration Layer APIs are only available over HTTPs. Two-Factor Authentication (2FA) is enforced when clients are authenticated. The following factors are used: Username and password or client credentials. The username identifies a system user. The security is strengthened further by establishing IP-address whitelists for each API. The use of two-way TLS will ensure integrity and confidentiality of the exchanged information and provide a strong authentication of the Network Operator and Infrastructure Owner. The requirements above will assert a logical separation of Service Provider, Network Operator and Infrastructure Owner for access and data in the OpenNet application, effectively preventing a Service Provider, Network Operator and Infrastructure Owner from accessing any part of data belonging to (or pertaining to business conducted with) another Service Provider, Network Operator and Infrastructure Owner. The requirements stated above must be adhered to by Cerillion (WCBS) SP and any NO/IO operator. Operators may choose to address the requirements in a number of different ways. It is therefore for important that implementation details are both carefully documented and approved by OpenNet before any production data are exchanged. 4.1 Server Certificates The three APIs are published on HTTPs URL’s using TLS server certificates. All server certificates used must adhere to current best practices with respect to algorithms, key sizes etc. API exposed by the OpenNet Integration Layer uses server certificates issued by a CA operated by Cerillion. NO API and IO API is expected to use TLS certificates issued by a public CA. 4.2 Registration Before any communication can take place the required credentials must be established at the client systems. This process is described below for each API. Page 12 of 88 OpenNet API Registration New Service Providers are registered in the OpenNet Integration Layer, where OpenNet provides the following information to the Service Provider: URL of the OpenNet Integration Layer API Username and password for Service Provider system account CA certificate for Cerillion CA OpenNet provides the following information to Cerillion: Source IP address used by NO/IO NO/IO Registration NO/IO systems are also registered in the OpenNet Integration Layer, where NO/IO provides the following information to OpenNet: URL of the NO/IO API Username and password system account to be used in NO/IO CA certificate for used server CA (if not public) OpenNet provides the following information to NO/IO: Source IP address used by OpenNet Integration Layer VOCES certificate (issued to OpenNet) used by the OpenNet Integration Layer OpenNet provides the following information to Cerillion: VOCES certificate and private key for authenticating in NO/IO APIs (or equivalent installation credentials allowing Cerillion to issue VOCES certificate themselves). URL of the NO/IO API Username and password system accounts to be used in NO/IO CA certificate for used server CA (if not public) 4.3 OpenNet Integration Layer Authentication This section describes the inbound authentication communication when the Network Operator or Infrastructure Owner is going to access OpenNets Integration Layer. OpenNets Integration Layer has chosen to employ an OAuth2 model where one subsystem (KeyCloak) acts as IdP (issuer of OAuth2 tokens) and another subsystem (APIMan) acts as RP (consumer of OAuth2 tokens). An initial request presents username & password or client credentials causing KeyCloak to issue a temporary OAuth2 token. Subsequent API requests are authenticated exclusively by passing the OAuth2 token in an HTTP header. Below you can see the sequence diagram for interaction between the Network Operator or Infrastructure Owner. Page 13 of 88 SP/IO/NO Security Interaction Sequence OpenNet SP/IO/NO (KeyCloak & APIMan) POST/getToken(grant_type, username, password, client_id) response(Token, expiry, UID, etc.) POST/GET API-x(token, input parameters) Various actions to sub-systems Figure 2: Security Interaction Sequence The sequence diagram shows the following: 1. The Infrastructure Owner or Network Operator will call a login service with unique username/password. The login is a POST request where two operations will occur: ▪ TLS handshake ▪ OpenNet Integration Layer which include KeyCloak and APIMan will authenticate and return token if all credential validation rules pass. 2. The token, used in the header for service calls, will allow the Network Operator and Infrastructure Owner the ability to call the desired services (i.e. Service Availability). On the basis that a token is released and the consumer can call the service, all subsequent downstream calls and responses will be managed by OpenNet Integration Layer. 3. OpenNet Integration Layer returns the response to the Infrastructure Owner or Network Operator. Access tokens is signed and the keys are signed and stored and protected within the KeyCloak server. 1.2.1. Data Definition The following provides an overview of the data items expected to support the INPUT and RESPONSE payload. This data will be subject to change as design/development evolves through. Input - Data Item Description POST getToken SP will call login service with unique user/password, identifier and type of token required grant_type=xxxxx&client_id=xxxxx&username=xxxxx&password=xxxx grant_type Type of request. Available grant types are “password” and "refresh_token" client_id Used to identify the client. A client_id of “IL” will automatically create an OAuth Key in the system that is used for “password” authentication username The username of the user authenticating to the system password The plain text password the user authenticating to the system Response authResponse "access_token": "xxxx", "expires_in": 299, Page 14 of 88 "refresh_expires_in": 1799, "refresh_token": "xxxxx", "token_type": "bearer", "not-before-policy": 0, "session_state": "0fd84d0d-a111-49c2-be01-983561de12c1" access_token The OAuth 2.0 access token needed to authenticate for other methods. expires_in The length of time until access_token expires in seconds refresh_expires_in The length of time until refresh_token expires in seconds refresh_token The token needed to extend the access_token expiration timeout token_type The token type. Currently only “bearer” is supported not_before_policy Not used. Always set to 0 session_state A unique value that identifies the current user session Table 2: Data Definition The access token has the following characteristics: The token expire currently as default after 5 minutes Any token refresh (issue of new token) requires a new authentication The reference specification in the KeyCloak OAuth2 documentation is RFC6749 The token is validated by APIMan 4.4 NO/IO Authentication This section describes how OpenNet Integration Layer is authenticated when invoking NO/IO APIs. As previously stated the same overall security requirements are imposed on NO/IO APIs as on OpenNet API (2-factor authentication using username/password and VOCES). Instead of adopting an OAuth2 scheme as used by OpenNet Integration Layer it is possible that NO and IO will choose to implement a simpler authentication scheme. Options include: Authenticating every API request fully: o Username/password sent as HTTP header o Frontend terminates TLS, backend validates VOCES certificate o Preferred: Employ a dedicated (account-specific) API-key replacing username/password o Login-method invoked with username/password and TLS client cert returns sessionID ▪ SessionID authorized subsequent API-invocations ▪ SessionID expires after 5 minutes If no OAuth2/OpenID Connect capabilities are already established at NO/IO the methods above are considerably simpler to implement. NO and IO must in any case describe how the security requirements are satisfied and document details, including how VOCES certificate validation is performed. Page 15 of 88 4.5 Logging The operators (OpenNet, NO, IO) must ensure that the three APIs (OpenNets API, NO's API, IO's API) establish traffic logs. The traffic logs must include: Web Service Calls Service-to-Backend Audits Request/Response Interactions Error and Exceptions 5. Integration Layer Process The suggested proces for a Network Operator to interact with Wholesale through the Integration Layer require coordination which is described below: 1. Making sure the right resources are allocated 2. Technical onboarding of the Network Operator: 1. Firewalls, port opening, etc. 2. Security setup 3. An introductory workshop to include: 1. An overview of the OpenNet IT interface 2. Detailed examination of the OpenNet interface documentation 3. Introduction to the sequence diagrams 4. Input/output parameters 5. Error Codes and descriptions 4. Planning of test activities: 1. Create a testplan 2. Agree on testcases 3. Is test data available in the test environment 5. Agreement about support during the development project 6. OpenNet and Network Operator must agree on operational requirements (Incidents, Change, Major Incidents) and support with regard to the OpenNet IT interface A contact person in OpenNet which will assist and coordinate with the above. 6. Services & Communication The OpenNet Integration Layer provides all services via RESTful interfaces, delivered over HTTPs and sFTP enables processes that require significant data volume transfer (e.g. address file). Key consumable services include: Capability Process Type Purpose Address File sFTP A file which contains addresses with coverage which means the Service Provider can use these Address Files to collect, ingest and use as a part of their sales process. A dedicated secure FTP location accessible through Service Provider specific user/password credentials. The FTP site will primarily be used to collect daily Page 16 of 88 supply data files; address coverage, lead time definition etc. Capacity Issue_Service_Order REST The Network Operator provides a service to check /Order Capture and reserve capacity during the sale process. This feature provides the integration between the OpenNet solution and the network element. The feature includes check and reserve capacity, confirm capacity, cancel and time out capacity. Get Fulfillment Request Fulfillment REST This service allows NO/IO to get information about orders that have been placed by the SP. Update Fulfillment Request Fulfillment REST This service allows NO/IO to signal to OpenNet that the specified fulfillment reqest have been completed. Depending on type this can result in a number of different scenarios i.e. progress work to next part of an order, start billing, end billing. Create Event Fulfillment REST This service allows NO/IO to create events, that is used to notify SP of specific milestones or actions during order fulfillment. Add Note to order history Add order note REST This service allows NO/IO to add note to an order. The notes are used as order history, and provide a complete view of order status and history. Get Next Event N/A REST Usability by NO/IO is still pending Support Tools Service Assurance REST A service which allows the Service Provider with a direct interface to the network layer to retrieve technical data related to the service configuration. Trouble Ticket Service Assurance REST A service which allows the Service Providers to raise incident and service request tickets, subsequently routed to the appropriate resolver group. Planned & Unplanned Outages Service Assurance REST A service where information about planned and unplanned outages related to end customers can be submitted by NO’s and/or IO’s and fetched by SP’s. This API is NOT used for ITSM related to the OpenNet IT systems them self. 3rd Party Charging Billing sFTP Enables Network Operator to submit additional charges to wholesale that need to be applied to the Service Provider or additional work-costs incurred during the delivery of the service. Time Slot Management REST This service allows IO to manage technician capacity on a day to day basis. Table 3: Key Consumable Services Overview 7. Address File The OpenNet solution will enable large data volume transfer via sFTP and will be used in support of providing Service Providers with address data. The Infrastructure Owner should create and upload a file with an agreement amount of Danish addresses, with coverage, for the Service Provider to collect, ingest and use as part of the sales process. The exact datafields and datainformation is part of the document "Address File". The sFTP service enables OpenNet and the Service Provider to excange "address file" in a controlled maner. The Service Provider is responsible for accessing the sFTP and retrieving files which is showed in the figure below: Page 17 of 88 Address File Infrastructure sFTP Owner login and upload file Figure 3: Address File It needs to be agreed between OpenNet and the Infrastructure Owner at what time of the day the file will be generated and afterwards is available for the Service Provider. The Infrastructure Owner will be provided access to a dedicated sFTP location, created during the technical onboarding. The sFTP site will be accessed via username & password permissions. Any issues accessing the site or depositing files will be managed by support. 8. Structure & Handling of Work Orders within the OpenNet Solution When SP places an order to OpenNet, it will result in one or more work orders being created internally in the OpenNet system. These work orders are very simple in their structure, and hold only very little detail about the expected delivery process. OpenNet handles the orchistration only four simple jobsteps, i.e. a Confirm Capacity job step, a NO work job step, a IO work job step and a final technical provisioning job step. Each of theese job steps result in a fulfillment request being made available to the NO or IO, and they are expected to schedule the needed work in acordance with the delivery date and time information that are provided as part of the fulfillment requests. Page 18 of 88 The Steps of an OpenNet Work Order Begin Confirm Capacity CONFIRM_CAPACITY NO Work WORK_ORDER_NO IO WORK WORK_ORDER_IO Note: Only used when an appointment is booked Note: Both NO and IO work mus t be completed before progression to Technica lP rovisioning is Technical allowed WORK_ORDER_PROVISIONING Provisioning Complete Figure 4: The steps of an OpenNet work order 8.1 Handling Order Changes If an order is changed before it is fully completed, all job steps are reactivated. This means that the NO and IO will receive the fulfillment requests again, and should disregard previously received information. The salesOrderNo, serviceSubscriptionID and workOrderID will remain the same, enabling NO and IO to match the new information to the previously information received. A new requestUID is provided, and the old requestUID will no longer be useable. 8.2 Handling Rescheduling In case an appointment or action date is rescheduled, the job steps that currently have uncompleted fulfillment requests will be reactivated. This means there corosponding fulfillment request will be reissued with the new information. With the exception of requestUID other ID’s passed to NO/IO will remain the same, i.e. serviceSubscriptionID, workOrderID, salesOrderNo etc.. 8.3 Handling H1 & H3 Sold Together In case the SP orders both a H1 and H3 service on the same order, two separate capacityCheckAndReserve requests will be sent to the NO. The two capacityCheckAndReserve requests will hold the same basketID, but other properties e.g. serviceSubscriptionID, productCode and most optionCodes will be different in the two requests. In case one or both capacityCheckAndReserve requests fail, the complete order will fail in OpenNet and confirmCapacity requests for the two temporary reservations will not be sent to NO, unless the issue can be resolved by fixing data inside OpenNet and retry the capacityCheckAndReserve request. In case of a retry, the same basketID will be used. Page 19 of 88 Unless SP cancels the full order, thereby also sending cancelCapacity for successful reservations, it is expected that NO will trigger CapacityReservationTimeOut requests for any temporary reservation that times out. Minimum reservation time is 1 hour. In case both capacityCheckAndReserve request succeed, the order will move on in OpenNet where SP will schedule either an action date or appointment. Afterwards two separate work orders will be generated internally, and this will in turn generate multiple south bound fulfillment requests for NO and depending on the order IO. For fulfillment request of type WORK_ORDER_NO and WORK_ORDER_IO and WORK_ORDER_PROVISIONING the same preferedActionDate or appointmentDate and appointmentSlot will be passed for both services. NO/IO is expected to be able to pair the two WORK_ORDER_NO, two WORK_ORDER_IO and two WORK_ORDER_PROVISIONING fulfillment requests together where required using the salesOrderNo property. If any changes are done to an inflight order, or to an active service, it will always result in a new capacityCheckAndReserve for the specific serviceSubscriptionID. In these requests a new basketID for each change will be introduced, unless the request is a retry due to errors, and the original link between the H1 and H3 services, using the first basketID, is therefore no longer visible in the capacityCheckAndReserve requests. 9. Interaction/Sequence Diagram This section describes how different parts of the OpenNet Integration Layer performs functions and the order in which the interactions occur when a particular use case/capability is executed. The sequence diagram shows which message/method and primary parameters as unique keys as part for the request and the response interaction. 9.1 Network Capacity Handling The capacity service is used to first get a temporary reservation of the network capacity for later to confirm the reservation. The capacity will be temporary reserved for a defined period of time only, which is expected to be no less than an hour, it could be any time longer than this. When the reservation of the capacity reservation times out the Network Operator needs to inform OpenNet about the timeout. If an order is cancelled the reserved capacity also needs to be cancelled so the capacity can be released again. The Capacity service will have the following operations: capacityCheck (OpenNet => NO) capacityCheckAndReservation (OpenNet => NO) confirmCapacityReservation (OpenNet => NO) cancelCapacity (OpenNet => NO) CapacityReservationTimeOut (NO => OpenNet) The operation is described in details in the next section. All calls are expected to be idempotent which means that it will be the same result the capacity service returns. Capacity Check The Capacity Check gives the Service Provider the capability to request and get capacity information on a single address towards the Network Operator infrastructure. The response will only reply with capacity information about the end customers installations and will not reserve any capacity. The sequence diagram for capacity check is showed in the sequence diagram below: Page 20 of 88 Capacity Check OpenNet Network Operator capacityCheck(serviceProviderCode, infrastructureOwnerAddressUID, installationID) response(responseCode, errorDescription, installationID, leadTime, appointmentNeeded) Figure 5: Capacity Check 9.1.1.1 Data Definition The following provides a high-level view of the data items expected to support the INPUT and RESPONSE payload. This data will be subject to change as design/development evolves through. Input - Data Item Description serviceProviderCode Service Provider identifier infrastructureOwnerAddressUID Unique identifier of the specified address. technologyType Fiber, copper, coax productCode H1, H2, H3 optionCodes Multiple codes specifying speed, tv package and other product options. E.g.: Format SPEED100 For each entry for a specific product, parse the following information infrastructureOwnerCode InfrastructureOwnerCode E.g.: 4 character string (e.g. IO_E) installationID Unique identifier for the installation. This value can be empty string/null if no installation has been supplied at the end customer address. networkOperatorDataField1 Data stored for specified Installation id and product. (Provided by IO via supply data) , networkOperatorDataField2 Data stored for specified Installation id and product. (Provided by IO via supply data) networkOperatorDataField3 Data stored for specified Installation id and product. (Provided by IO via supply data) networkOperatorDataField4 Data stored for specified Installation id and product. (Provided by IO via supply data) networkOperatorDataField5 Data stored for specified Installation id and product. (Provided by IO via supply data) networkOperatorDataField6 Data stored for specified Installation id and product. (Provided by IO via supply data) Response responseCode 0: Success 1: No Available Capacity 2: Other Error message String specifying cause of error when present. Page 21 of 88 If responseCode is 1 this property will hold a JSON encoded string in the following format: ”{\”reasonCode\”:integer,\”description\”:\”text describing scenario\”}” The reasonCode is an integer defined by OpenNet for each relevant scenario. The description is also a fixed text defined by OpenNet. Note: For details on defined reason codes and descriptions please see the OpenNet Appendix. installationsID InstallationID on which the service will be delivered. If no installationID was supplied during the request, this Installation_id would have been generated by the NO. It is considered best practice to keep the installationID returned static per address/installation even if an installation does not yet exist on the address, as the SP will then see the same installation ID if they call the API multiple times, as well as well as when the SP submits an order later in the process. leadTime Lead time for NO to make capacity available. Lead time will be a number of calendar days appointmentNeeded "N": No need for IO technician appointment on delivery date. "Y": Need for IO technician appointment on delivery date. validCPEFeature H1: Gives information about the end customers installation and og how the installation can support the requested products primary regarding speed. For H1 this string is expected to hold the maximum supported speed of the installation after potential fiberbox change. E.g. "SPEED1000" H2 and H3: Return null or empty string “” Table 4: Data Definition The same data definition is described in the.json files in the table below. The files describe the structure when OpenNets Integration Layer is sending the files to the Network Operator. Description JSON Request { "serviceProviderCode": 20000001, "infrastructureOwnerAddressUID": "99999999-9999-9999-999999991235", "technologyType": "FIBRE", "productCode": "H1", "OptionCodes": [ "SPEED120" ], "supplyData": [ Page 22 of 88 { "infrastructureOwnerCode": "IO01", "installationID": "7777", "networkOperatorDataField1": "string1", "networkOperatorDataField2": "string2", "networkOperatorDataField3": "string3", "networkOperatorDataField4": "string4", "networkOperatorDataField5": "string5", "networkOperatorDataField6": "string6" }, { "infrastructureOwnerCode": "IO01", "installationID": "8888", "networkOperatorDataField1": "string1", "networkOperatorDataField2": "string2", "networkOperatorDataField3": "string3", "networkOperatorDataField4": "string4", "networkOperatorDataField5": "string5", "networkOperatorDataField6": "string6" } ] } Response { "responseCode": 0, "message": "", "installationID": "7777", "leadTime": 11, "appointmentNeeded": "Y", Page 23 of 88 "validCPEFeatures": "string", } Table 5: Data Definition in JSON format Capacity Check & Reservation The Capacity Check and Reservation service is used to check and reserve capacity during the sales process. The service is activated by the OpenNet Core System by the Integration Layer and will be communicated to the Network Operator for further processing. The sequence diagram for Check Capacity and Reservation is showed below: Capacity Check And Reservation OpenNet Network Operator capacityCheckAndReservation(serviceProviderCode, infrastructureOwnerAddressUID, installationID) response(responseCode, errorDescription, installationID, leadTime, appointmentNeeded) Figure 6: Capacity Check & Reservation 9.1.2.1 Data Definition The following provides a high-level view of the data items expected to support the INPUT and RESPONSE payload. This data will be subject to change as design/development evolves through. Input - Data Item Description serviceProviderCode Service Provider identifier serviceSubscriptionID Unique identifier of the main service for which capacity is reserved. This unique identifier is constant across order fulfillment process and stays the same, even during a possible option change before the original order has been fulfilled. E.g.: Format is 10 digits basketID A unique identifier of the order requested from the Service Provider. The unique identifier id is used to cancellation i relation to and/or work order(s) if reservation time runs out within NO. infrastructureOwner Unique identifier of the specified address AddressUID technologyType FIBRE, COAX, COPPER productCode H1, H2, H3 Page 24 of 88 optionCodes Multiple codes specifying speed, tv package and other product options. E.g.: Format Speed100 serviceProviderIn1 Theese fields are used to parse information of a more technical nature i.e. VLAN ID's, serviceProviderIn2 poiID etc. serviceProviderIn3 serviceProviderIn4 The below information is what should be expected by the Network Owner. serviceProviderIn5 serviceProviderIn6 Note: If a specific installationID is required to be used on the endcustomer address, the requiredInstallationID property needs to be provided. If no required installationID is provided, the network owner will select the most suitable installation to use in case multiple installations exist on the address. If the SP passed a requiredInstallationID which does not match any of the array elements passed in the supplyData array in the request, NO is expected to return an error. If the NO has opted to add the needed logic, which is not required by OpenNet, a success response can be returned if the required installationID is linked to the specific address but has not yet uploaded to OpenNet. H1 serviceProviderIn1 : “{\"cvlan\":[{\"id\":32,\"tagged\":true},{\"id\":33,\"tagged\":true},{\"id\":34,\"tagged \":true},{\"id\":35,\"tagged\":true},{\"id\":36,\"tagged\":true},{\"id\":37,\"tagged\":tr ue},{\"id\":38,\"tagged\":true},{\"id\":null,\"tagged\":false}]}” serviceProviderIn2 : null or ”{\"multicastCvlan\":{\"id\":35,\"tagged\":true}}” or ”{\"multicastCvlan\":{\"id\":null,\"tagged\":false}}” or ”{\"multicastCvlan\":{\"id\":null,\"tagged\":null}}” serviceProviderIn3 : null or ”{\”requiredInstallationID\”:\”BA9382XXX\”}” or ”{\”requiredInstallationID\”:null}” serviceProviderIn4-6 : null or ”” H2 serviceProviderIn1 : "{\”poiID\":\"JDMSK78986546\"}" serviceProviderIn2 : null or "{\"requiredInstallationID\": \"BCJD8234234\"}" or "{\"requiredInstallationID\": null}" serviceProviderIn3-6 : null or ”” H3 serviceProviderIn1 : null or ”{\”requiredInstallationID\”:\”BA9382XXX\”} or ”{\”requiredInstallationID\”:null} serviceProviderIn2-6 : null or ””serviceProviderIn2-6 : null or ”” For each entry in supply data for specific product, parse the following information infrastructureOwnerCode InfrastructureOwnerCode E.g.: 4 character string (e.g. IO_E) installationID Unique identifier for the installation. This value can be empty string/null if no installation has been supplied at the end customer address. networkOperatorDataField1 Data stored for specified Installation id and product. (Provided by IO via supply data) networkOperatorDataField2 Data stored for specified Installation id and product. (Provided by IO via supply data) networkOperatorDataField3 Data stored for specified Installation id and product. (Provided by IO via supply data) networkOperatorDataField4 Data stored for specified Installation id and product. (Provided by IO via supply data) networkOperatorDataField5 Data stored for specified Installation id and product. (Provided by IO via supply data) networkOperatorDataField6 Data stored for specified Installation id and product. (Provided by IO via supply data) Response responseCode 0: Success 1: No Available Capacity 2: Other Error message String specifying cause of error when present. Page 25 of 88 If responseCode is 1 this property will hold a JSON encoded string in the following format: ”{\”reasonCode\”:integer,\”description\”:\”text describing scenario\”}” The reasonCode is an integer defined by OpenNet for each relevant scenario. The description is also a fixed text defined by OpenNet. Note: For details on defined reason codes and descriptions please see the OpenNet Appendix. installationsID InstallationID on which the service will be delivered. If no installationID was supplied during the request, this Installation_id would have been generated by the NO. InstallationID would need to be stored on the service leadTime Lead time for NO to make capacity available. Lead time will be a number of calendar days appointmentNeeded "N": No need for IO technician appointment on delivery date. "Y": Need for IO technician appointment on delivery date. networkOperatorOut1 Information should be parsed to NO as part of fulfillment requests. networkOperatorOut2 Information should be parsed to NO as part of fulfillment requests. networkOperatorOut3 Information should be parsed to NO as part of fulfillment requests. networkOperatorOut4 Information should be parsed to NO as part of fulfillment requests. networkOperatorOut5 Information should be parsed to NO as part of fulfillment requests. networkOperatorOut6 Information should be parsed to NO as part of fulfillment requests. serviceProviderOut1 The technical provisioning data: serviceProviderOut2 serviceProviderOut3 H1 serviceProviderOut4 serviceProviderOut1 : “{\“port\“:\“ethPort1\“}“ serviceProviderOut5 serviceProviderOut2 : serviceProviderOut6 “{\"tvlan\":[{\"id\":4001},{\"id\":4002},{\"id\":4003},{\"id\":4004},{\"id\":4005},{\"id \":4006},{\"id\":4007},{\"id\":4008}]}” serviceProviderOut3 : ”{\”svlan\”:234,\”poiID\”:\”GFS789XXX\”}” serviceProviderOut4-6 : null or ”” H2 serviceProviderOut1 : ”{\”transceiverType\”:\”single\”}” or ”{\”transceiverType\”:\”dual\”}” serviceProviderOut2 : ”{\”svlan\”:234}” serviceProviderOut3 : ”{\”transceiverSpeed\”:\”1G\”}” or ”{\”transceiverSpeed\”:\”10G\”}” serviceProviderOut4-6 : null or ”” H3 serviceProviderOut1 : “{\“port\“:\“rfPort\“}“ serviceProviderOut2-6 : null or ”” Note: As a minimum the serviceProviderOut1 field must be populated for H1, H2 and H3 services in the capacityCheckAndReserve response. For H2 also the transceiverSpeed in serviceProviderOut3 is expected to be returned as part of the capacityCheckAndReserve Response. Other values are allowed not to be published until the actual order fulfillment process, but must be populated no later than the completion of the WORK_ORDER_NO fulfillment request. Maximum length of UDF field is 256 characters. The returned values for T-VLAN’s must one to one map to the inputted C-VLAN’s, i.e. first T-VLAN id will map to first C-VLAN id. Page 26 of 88 InfrastructureOwnerOut1 These fields will hold information needed by IO during order fulfillment. Information should be parsed to IO as part of fulfillment/provisioning messages. InfrastructureOwnerOut2 These fields will hold information needed by IO during order fulfillment. Information should be parsed to IO as part of fulfillment/provisioning messages. InfrastructureOwnerOut3 These fields will hold information needed by IO during order fulfillment. Information should be parsed to IO as part of fulfillment/provisioning messages. InfrastructureOwnerOut4 These fields will hold information needed by IO during order fulfillment. Information should be parsed to IO as part of fulfillment/provisioning messages. InfrastructureOwnerOut5 These fields will hold information needed by IO during order fulfillment. Information should be parsed to IO as part of fulfillment/provisioning messages. InfrastructureOwnerOut6 These fields will hold information needed by IO during order fulfillment. Information should be parsed to IO as part of fulfillment/provisioning messages. Table 5: Data Definition The same data definition is described in the.json files in the table below. The files describe the structure when OpenNets Integration Layer is sending the files to the Network Operator. Description JSON Request { "serviceProviderCode": 20000001, "serviceSubscriptionID": "570874", "basketID": 75646, "infrastructureOwnerAddressUID": "99999999-9999-9999-999999991235", "technologyType": "FIBRE", "productCode": "H1", "OptionCodes": [ "SPEED120", "SLASILVER" ], "serviceProviderIn1": "string1", "serviceProviderIn2": "string2", "serviceProviderIn3": "string3", "serviceProviderIn4": "string4", Page 27 of 88 "serviceProviderIn5": "string5", "serviceProviderIn6": "string6" "supplyData": [ { "infrastructureOwnerCode": "IO01", "installationID": "7777", "networkOperatorDataField1": "string1", "networkOperatorDataField2": "string2", "networkOperatorDataField3": "string3", "networkOperatorDataField4": "string4", "networkOperatorDataField5": "string5", "networkOperatorDataField6": "string6" }, { "infrastructureOwnerCode": "IO01", "installationID": "8888", "networkOperatorDataField1": "string1", "networkOperatorDataField2": "string2", "networkOperatorDataField3": "string3", "networkOperatorDataField4": "string4", "networkOperatorDataField5": "string5", "networkOperatorDataField6": "string6" } ] } Response { "responseCode": 0, Page 28 of 88 "message": "", "installationID": "7777", "leadTime": 11, "appointmentNeeded": "Y", "networkOperatorOut1": "string1", "networkOperatorOut2": "string2", "networkOperatorOut3": "string3", "networkOperatorOut4": "string4", "networkOperatorOut5": "string5", "networkOperatorOut6": "string6", "serviceProviderOut1": "string1", "serviceProviderOut2": "string2", "serviceProviderOut3": "string3", "serviceProviderOut4": "string4", "serviceProviderOut5": "string5", "serviceProviderOut6": "string6", "infrastructureOwnerOut1": "string1", "infrastructureOwnerOut2": "string2", "infrastructureOwnerOut3": "string3", "infrastructureOwnerOut4": "string4", "infrastructureOwnerOut5": "string5", "infrastructureOwnerOut6": "string6" } Table 6: Data Definition JSON format Page 29 of 88 Confirm Capacity Reservation Once an appointment has been scheduled the OpenNet solution will invoke a request to confirm a previously reserved capacity to ensure the service can be delivered/activated on the network. Using the serviceSubscriptionID the confirm capacity service will invoke a call to the Network Operator to confirm capacity reservation, using the same data items included in the original check/reservation request It is critical that the operation performed by this API is kept to a minimum, as returning an error will result in manual handling and potential order failure. The expected action performed by the API is to stop the temporary capacity reservation from timing out. Any product validation, and other actions that could fail the order in the first place, is expected to have been done in the Capacity Check and Reserve API it self, as there is a clear communication path back to the SP in that process. An error is only expected to be returned if the Network Operator systems, needed to process the API request, is down, or Network Operator and OpenNet systems has gotten out of sync due to an incident. The sequence diagram for confirm capacity reservation is showed below: Confirm Capacity Reservation OpenNet Network Operator confirmCapacityReservation(basketID, serviceSubscriptionID) response(responseCode, message) Figure 7: Confirm Capacity Reservation 9.1.3.1 Data Definition The following provides a high-level view of the data items expected to support her INPUT and RESPONSE payload. This data is will be subject to change as design/development evolves through. Input - Data Item Description serviceProviderCode Service Provider identifier serviceSubscriptionID Unique identifier of the main service for which capacity is reserved. This unique identifier is constant across order fulfillment process and stays the same, even during a possible option change before the original order has been fulfilled. E.g.: Format is 10 digits basketID A unique identifier of the order requested from the Service Provider. The unique identifier ID is used to cancellation i relation to and/or work order(s) if reservation time runs out within NO. infrastructureOwnerAd Unique identifier of the specified address. dressUID technologyType FIBRE, COAX, COPPER Page 30 of 88 productCode H1, H2, H3 optionCodes Multiple codes specifying speed, tv package and other product options. E.g.: Format SPEED100 serviceProviderIn1 Theese fields are used to parse information of a more technical nature i.e. VLAN ID's, poiID serviceProviderIn2 etc. serviceProviderIn3 serviceProviderIn4 The below information is what should be expected by the Network Owner. serviceProviderIn5 serviceProviderIn6 Note: If a specific installationID is required to be used on the end-customer address, the requiredInstallationID property needs to be provided. If no required installationID is provided, the network owner will select the most suitable installation to use in case multiple installations exist on the address. H1 serviceProviderIn1 : “{"cvlan":[{"id":32,"tagged":true},{"id":33,"tagged":true},{"id":34,"tagged":true} ,{"id":35,"tagged":true},{"id":36,"tagged":true},{"id":37,"tagged":true},{"id":38,"tagged":t rue},{"id":null,"tagged":false}]}” serviceProviderIn2 : null eller ”{"multicastCvlan":{"id":35,"tagged":true}}” eller ”{"multicastCvlan":{"id":null,"tagged":fals e}}” eller ”{"multicastCvlan":{"id":null,"tagged":null}}” serviceProviderIn3 : null or ”{”requiredInstallationID”:”BA9382XXX”}” or ”{”requiredInstallationID”:null}” serviceProviderIn4-6 : null or ”” H2 serviceProviderIn1 : "{"poiID":"JDMSK78986546"}" serviceProviderIn2 : null or "{"requiredInstallationID": "BCJD8234234"}" or "{"requiredInstallationID": "null"}" serviceProviderIn3-6 : null or ”” H3 serviceProviderIn1 : null or ”{”requiredInstallationID”:”BA9382XXX”} or ”{”requiredInstallationID”:”null”} serviceProviderIn2-6 : null or ”” infrastructureOwnerCo InfrastructureOwnerCode de E.g.: 4 character string (e.g. IO_E) installationID Unique identifier for the installation. This value can be empty string/null if no installation has been supplied at the end customer address. networkOperatorOut1 Pupulated by NO during capacityCheckAndReserve call. networkOperatorOut2 networkOperatorOut3 networkOperatorOut4 networkOperatorOut5 networkOperatorOut6 Response Page 31 of 88 responseCode 0: Success 1: No Capacity Available (Not used here) 2: Other Error message String specifying cause of error when present. Table 7: Data definition The same data definition is described in the.json files in the table below. The files describe the structure when OpenNets Integration Layer is sending the files to the Network Operator. Description JSON Request Response Table 8: Data definition.json Cancel Capacity Reservation When orders are cancelled (e.g. prior to activation) or services are ceased, network capacity must be released to ensure the Network Operator has an accurate view of the network (technical) use. Cancelling/Cease activities will subsequently cancel capacity use on the network. Using the serviceSubscriptionID only, the cancel capacity service will invoke a call to the Network Operator to release capacity. The sequence diagram for Cancel Capacity Reservation is showed below: Cancel Capacity Reservation OpenNet Network Operator cancelCapacityReservation(basketID, serviceSubscriptionID) response(responseCode, message) Figure 8: Cancel Capacity Reservation 9.1.4.1 Data Definition Input - Data Item Description serviceSubscriptionID Unique identifier of the main service for which capacity is reserved. This unique identifier is constant across order fulfillment process and remains the same, even during a possible option change before the original order has been fulfilled. Page 32 of 88 E.g.: Format is 10 digits basketID A unique identifier of the order requested from the Service Provider. The unique identifier ID is used for cancellation in relation to and/or work order(s) if reservation time runs out within NO. Response responseCode 0: Success 1: No Available Capacity 2: Other Error message String specifying cause of error when present. Table 9: Data Definition The same data definition is described in the.json files in the table below. The files describe the structure when OpenNets Integration Layer is sending the files to the Network Operator. Description JSON Request Response Table 9: Data Definition Capacity Reservation Timeout To perform cancel order in case the temporary capacity reservation times out. It’s only allowed to remove the temporary reservation if a success response is received from OpenNet – the infrastructure owner is required to hold the reservation in any case of an unsuccessfull response. The sequence diagram for time out regarding capacity reservation is showed below: Capacity Reservation Timedout Network Operator OpenNet capacityReservationTimedOut(basketID) response Figure 9: Capacity Reservation Timeout 9.1.5.1 Data Definition Input - Data Item Description basketID basketID received by NO as part of the Capacity Check And Reserve request. The unique identifier ID is used for cancellation in relation to and/or work order(s) if reservation time runs out within NO. Page 33 of 88 (Query parameter) Response http response 204 Basket and related work orders have been cancelled successfully in OpenNet. http response Basket and related work orders have not been cancelled. Do not release the 4xx/5xx temporary reservation. Table 10: Data definition 10. Order fulfilment 10.1 Fulfilment requests The Fulfillment Request service is used by NO/IO to collect fulfillment requests and after completion of the specified work at NO/IO, the service is then used to signal OpenNet that the task has been done. The service will have the following operations: getFulfillementRequest updateFulfillmentRequest The operations are described in more details in the next sections. Get Fulfilment Request Used by NO/IO to collect fulfillment requests from OpenNet. The sequence diagram for getFulfillmentRequest is showed below: IO/NO Get Fulfillment Request IO/NO OpenNet getFulfillmentRequest(types) response(fulfillment request data) Figure 10: Get Fulfillment Request 10.1.1.1 Data Definition Input - Data Item Description Page 34 of 88 autoAcknowledge Data type: Boolean (Optional) Default value is true if not specified, i.e. the returned fulfillment request is removed from the queue once fetched. If set to false, fulfillment request is not removed from the queue until NO/IO actively update the status of the specific fulfillment request. See “Update Fulfillment Request” for details on how to acknowledge a fulfillment request. requestType Array of request types to look for. Possible types are: WORK_ORDER_NO, WORK_ORDER_IO, WORK_ORDER_PROVISIONING, WORK_ORDER_TERMINATE, WORK_ORDER_CANCELLED_NO, WORK_ORDER_CANCELLED_IO, WORK_ORDER_CANCELLED_PROVISIONING, BARRING, UNBARRING. Function change from version 3 onwards: OpenNet system will search the internal database holding all fulfillment requests, for the oldest uncollected fulfillment request available to the calling entity. Filtration will ensure that only specified requestType’s are considered in the search, and the functional change is that they will be considered equal. In other words, the fulfillment request queue will follow a FIFO principle. Prior versions: OpenNet will try the return a fulfillment request of the first requestType specified. If no fulfillment requests of the first requestType is available, then OpenNet will move to the next specified requestType and search for a fulfillment request of that type. If no fulfillment request of the second request type is found, then OpenNet will move on to the third requestType and so on. Request example for a typical NO entity: { "requestType":[ "WORK_ORDER_NO", "WORK_ORDER_PROVISIONING", "WORK_ORDER_CANCELLED_NO", "WORK_ORDER_CANCELLED_PROVISIONING", "WORK_ORDER_TERMINATE", "BARRING", "UNBARRING" ] } Response Response (http Request was successful and a fulfillment request has been returned in the response body response code 200) requestType The actual type of request returned. Other data fields The actual data of the request. See response data content below. Response empty Desscription response http response code 204 No fulfillment requests of the specified types are available. Table 11: Data definition 10.1.1.2 GetFulfilmentRequest Response Definition Field name Description Included Included Included Included in Type 1 in Type 2 in Type 3 in Type 4 requestType Type can be used to route requests within receiving system. YES YES YES YES Possible values:

IT Documentation - Network Operator & Infrastructure Owner v1.51 PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue