Open APIs

 View Only

  • 1.  TMF OpenAPI for network service design and assign

    Posted Jun 24, 2019 08:55
    Hello,

    I'm trying to indentify the right TMF OpenAPI to be exposed by network inventory system to request the design of some network service (e.g. an FTTH service for a residential customer). The design would also imply the reservation of any resources needed to fulfill the requested service.

    Such interface should be consumed by an order management system aiming to receive the list of resources (e.g. ONT, OLT, etc.) to be activated and configured on the network.

    Thanks in advance for your support.

    Regards,
    Pasquale Rechichi

    ------------------------------
    Pasquale Rechichi
    Ericsson Inc.
    ------------------------------


  • 2.  RE: TMF OpenAPI for network service design and assign

    Posted Jun 26, 2019 02:24
    Hi
    See https://projects.tmforum.org/wiki/display/API/Open+API+Table for the full list of published Open APIs.

    For your use case, it could be a combination of Service Qualification (TMF 645), which would be called after the end customer has selected the product in the sales process, and then Service Order (TMF 641), which would be called after the product order has been submitted.
    Note the following:
    • This assumes that your Product Order layer is capable of decomposing a product into candidate services. If this is not the case, then the Product Order layer will not be able to invoke these Service-level APIs. There have been various discussions on this in the forum, see some of the links below.
    • Service Qualification is stateless, in the sense that it does not actually reserve stuff in the network, it only verifies that service can be provided (at the time of invocation - things might change if significant time elapses until actual order submission)
    @Ludovic Robert may have additional insights on this topic.
    Hope it helps.​

    Discussions on product=>service decomposition:


    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 3.  RE: TMF OpenAPI for network service design and assign

    Posted Jun 27, 2019 11:38
    Hi,
    in addition to the use of Service Qualification API (TMF 645), that for sure can be used to determine the general feasibility of the service delivery at a specified location, when it comes to the service design and resource reservation, I would propose to use also the Resource Inventory Management API (TMF639) and in particular the resource state "Planning" and its sub-state "Designed".
    Indeed, the Service Order Management system, handling an order received from the Service Order API (TMF641), could post a TMF639 CREATE RESOURCE request with lifecycleSate = Proposed (or Feasibility Checked) to the Resource Inventory system that in turn could automatically proceed with the resources allocation transiting finally the status to "Designed". The transition is notified back to the the Order Manager which can fetch the details of the allocated resources still through the TMF639 and subsequently request other transitions of the status to Ordered, etc..
    Does it make sense? Comments welcome.

    Best regards,
    Dino

    ------------------------------
    Dino Pellegrini
    Solution Architect OSS Orchestration
    Ericsson Inc.
    ------------------------------



  • 4.  RE: TMF OpenAPI for network service design and assign

    Posted Jun 28, 2019 11:29
    Hi Dino, Pasquale,

    you both are clearly describing the need for a not yet existant ResourceQualification API.

    This API should handle both planning tasks and resource reservation tasks.
    This API can obviously use TMF 639 to store the result of this activity in an Resource Inventory, but in many cases It will also use engagedParty related tasks & APIs (check feasibility with suppliers, building permission, ...) as part of the process flow.

    It always stays a balancing act for a service provider to decide how much planning tasks you want to do before sales (Resource Qualification), potentially involving costs not covered by later sales and after sales (Resource Ordering) with risks of rejections after the order was accepted, resulting in bad customer experience.

    Regards


    ------Original Message------

    Hi,
    in addition to the use of Service Qualification API (TMF 645), that for sure can be used to determine the general feasibility of the service delivery at a specified location, when it comes to the service design and resource reservation, I would propose to use also the Resource Inventory Management API (TMF639) and in particular the resource state "Planning" and its sub-state "Designed".
    Indeed, the Service Order Management system, handling an order received from the Service Order API (TMF641), could post a TMF639 CREATE RESOURCE request with lifecycleSate = Proposed (or Feasibility Checked) to the Resource Inventory system that in turn could automatically proceed with the resources allocation transiting finally the status to "Designed". The transition is notified back to the the Order Manager which can fetch the details of the allocated resources still through the TMF639 and subsequently request other transitions of the status to Ordered, etc..
    Does it make sense? Comments welcome.

    Best regards,
    Dino

    ------------------------------
    Dino Pellegrini
    Solution Architect OSS Orchestration
    Ericsson Inc.
    ------------------------------


Related Content