Open APIs

Expand all | Collapse all

TMF641 & TMF633 characteristic modelling

  • 1.  TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 13, 2021 12:34
    Hi All,

    Within our business there is a requirement for a client to specify the 'method' by which a service will be provisioned.

    This is mainly for a focus around fibre access services that are onwardly provisioned with supplier networks. Some of these methods might be: -
    • installation of a new line
    • switching ownership of a line from an existing CSP to ourselves
    • activation of an existing inactive line
    The understanding is that variable data accross service specifications is stored within characterisitcss. Each of the 'methods' above would have different data requirements as below: -
    633-method-layer-between-specification-and-characteristic


    What this is suggesting for us is that in the catalog model the follow relationships would be true (which conflicts with TMF): -
    • ServiceSpecification -> 'Method' --> ServiceCharacteristics.

    I'm reaching out here because it feels like to me that the problem of different provisioning methods driving different data requirements is very likely to have been faced into by others and some steer of how they achieved this would really help us.

    thanks in advance for any help

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------


  • 2.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 14, 2021 02:58
    Hello David

    Have you explored the option to dedicate a specific product and then a corresponding service to manage this installation option?
    It will allow you to keep your fiber service 'clean' from the installation process.
    This "installation choice"  service (and the corresponding) product will have a relationship to the fiber access. We can have for this service (and product) the characteristic to pick the choice.  And depending on this you trigger a  specific installation process.

    Hope it helps
    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 3.  RE: TMF641 & TMF633 characteristic modelling

    Posted Sep 14, 2021 07:18
    Hello

    A question rather than an answer

    Why isn't each method governed by either

    A service specification of its own?

    Or

    A set of characteristics in the service specification specific to the chosen downstream supplier?

    One point which might clarify things for you is what happens after such a service is provisioned and you want to switch supplier? Do you expect to

    Provision a new service and cease the old

    Or

    Alter the characteristics of the already provisioned service to reflect the new supplier.

    This is quite important not just with multiple suppliers but also when considering the different types of orders your customers might place with you to cover different scenarios such as migrating from "fiber to the node" to "fiber to the home" products. Are they provisioning a new service along side the old or over the old or modifying from one to the other?

    ------------------------------
    Derrick Evans
    ------------------------------



  • 4.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 14, 2021 07:42

    Hi @Ludovic Robert,

    thanks for getting back to me, really helpful thoughts, I've interpreted this as: -

    model-installmethod-attempt2
    • ​fibre access service specs per supplier in the catalog
    • a single 'installation method' specification in the catalog
    • 'dependent on' links between these mentions specs
    • single characterisitc in the 'installation method' spec to capture which method is needed.

    Couple of questions off the back of this
    • As we only have a single specification for the 'install method' how would we drive the behaviour of the client to send different groups of characteristics based on which method they picked in the special 'installation type' characteristics?
    • Given that this 'installation method' service wont actually be a service (its just a means to get a service installed) it doesnt feel right for it to be added to the service inventory? but that feels strange?


    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 5.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 14, 2021 08:07
    Hey @Derrick Evans,

    thanks for your reply and challenge, I have redrawn my attempt at a simple view of what we have so far modelled within our catalog to try and help show how each fibre supplier has its own installation methods which in of themself require different data (assumed characteristics) to be sent by the client.

    catalog-data

    Our thoughts were that a move of a service from one supplier to another would be a DELETE of the old and ADD of the new (or cease and provide in general teleco terms :-) ). Additional to this we saw that FTTN/FTTC and FTTH/FTTP were different services.

    It didnt feel like these instsallation methods were something that would be of interest some time post the service completing the provisioning  hence the reason we were trying to put this seperation in.

    does this bring it to light more?


    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 6.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 14, 2021 09:24
    David,

    I was more imagining something like this:


    Of course, we could imagine other approach but here my thought was to split the installation itself to the fiber but leverage  relationship (present in the service order) to tie them. With this approach, you could also 'sell' some installation offer (I've also illustrated them).

    Hope it helps,
    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 7.  RE: TMF641 & TMF633 characteristic modelling

    Posted Sep 14, 2021 10:50
    Hello @David Whitfield

    See where you are going with this and I get it. When you end up with the service you wanted, it doesn't matter what installation method got you there.​ Although I suspect you might find some of these characteristics still have a meaning after the service is provided.

    My experience is with Siebel where characteristics could be persisted against the resulting asset on an as needed basis so you only kept what you needed for ongoing support and maintenance.

    And I agree the different methods need different information (like migration keys or ids of services/lines to be transferred) and sometimes you want to identify a premises for the install of new stuff and other time a physical service or bearer on which to work to transfer or upgrade. Which by the way means this is more than about the characteristics when you come to compose an order. Moreover, the order action item type does not give you enough to know the scenario in play.

    I tend to agree with your notions of Add and Delete but in these various scenarios there is a complication where re-use of physical lines takes place.For example, adding an VDSL/FTTC service on a copper line where you have already provisioned ADSL tends to result in the removal of the ADSL service as a consequence anyway without an order. Whereas, in theory, adding an FTTP service alongside and ADSL copper service can leave the pre-existing copper service in place unless your supplier downstream just happens to have a rule that orchestrates its removal on the basis that the consumer really only wants one broadband service and wants the transfer to be managed seemlessly.

    I don't have a great answer here but I think where Ludovic is going suggests the most likely beneficial approach.

    in the absence of changes to the APIs and the underlying models to separate out characteristics as a template across various sets of specifications, if you want to re-use a limited set of characteristics and model them across multiple service specifications then it seems the answer is somehow to model them as separate but related things which can then be added to the order as a supplementary thing.

    This is not unheard of as a similar technique can be used to specify other value-added things such as whether a third party installer is to provide CPE or come along and provide a demo of the service to the customer.

    The only other way I can see it is to put up with the repetition of characteristics across multiple varients of the specifications for each installation method or include all the characteristics in the one specification and have an horrendous set of rules to validate the various combinations.

    Where I worked last we had one service specification for the to be provided service with all the various characteristics in for the different methods. The customer then had to know which characteristics to supply at order time based on where they were starting from and where they wanted to get to. Not an easy thing to manage.









    ------------------------------
    Derrick Evans
    ------------------------------



  • 8.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 15, 2021 06:39

    Hi @Ludovic Robert, thanks for going into this detail, this is really helpful! (a picture always helps i find!)

    Whilst i do you follow you thinking here i'd question that if we were to model the 'Method' as a characteristic of a single service spec created for the installation then how would we drive the onward dependency of the other characteristics?

    i.e. 'newLine' requires the client to pass CharacterisitcA and CharacteristicB

    'siwtch' requires the client to pass CharacteristicC and CharacteristicD​


    Would be really helpful to get your thoughts on this

    thanks

    Dave


    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 9.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 15, 2021 07:27

    thanks again @Derrick Evans.

    ​"The only other way I can see it is to put up with the repetition of characteristics across multiple varients of the specifications for each installation method or include all the characteristics in the one specification and have an horrendous set of rules to validate the various combinations."

    Where as i could see that TMF model would allow this i fully agree with you that should the framework be used in this way its so loose that IMO a client has no hope of 'getting it right'  therefore we steered well clear of that :-). It really goes against the idea of a self documenting platfrom and whilst i know that not everything lives in swagger docs but if the combination of them and the catalog setup can provide this in a way that is clearly understandible for a client on what they need to do then this is a far better approach. Once we start to open up word docs or wiki pages to explain the complexity of the backend logic its fraught with human error.

    really great to get this feedback so thanks for spending the time on it, I agree that ludovics suggestion seems like a good approach. My only reservation is that if these are 'fake' services (the installation service) then I dont see how the 641 API can honour the contract and return an id for the installation service as it doesnt really feel like something that would make it into the inventory at all, any thoughts?



    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 10.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 15, 2021 02:06
    Hi all,

    It is always tempting for a service provider to only consider the "networkService" in the modeling. That is in the end the reason of existance for the service provider. It is however beneficial to clearly define the other services that are provided in the process. That typically includes fieldOperationsService (installation, CPE configuration), portingService (switching ownerships), shippingService (ship a CPE to the customer), entitlementServices (maintenance, repair).
    The SID document on product made a start at defining these at the product level but never went into the details.

    In principle your network service is supported by a number of resources (fiber, ONT, CPE), that must have a lifecycleStatus "operating". The other services all define methods to change aspects of these resources to get them into an operating state.

    The extra information you require for the fieldOperationsService, portingService, ShippingService, entitlementService are captured in the respective service entities in the inventory. They will be terminated by the time the networkService is active and probably only have historic value.

    The separation of these services also give you a better understanding about monetization opportunities. the CSP can always decide to charge for such a service or at least make a consious decision to offer them for free and adjust the marketing message to make this clear to the customer.

    Regards

    ------------------------------
    Koen Peeters
    Ciminko Luxembourg
    ------------------------------



  • 11.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 21, 2021 05:06

    hey @Koen Peeters,

    thanks as always for your response. Definately see that there could be something in 'inventrifying' those more 'state change' based services which get us from a place of not having a network service to having one.

    Could you point me at the SID document that made a start on this for Product? I'm still learning how to navigate the TMF docs :-)​



    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 12.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 15, 2021 07:10
    Hello David,
    If I have to manage this, in order to split the characteristic between the Fiber Service and the Installation Service, I will ask myself: Do I care about this characteristic in one month from now when the service will be live and running?
    If yes, the characteristic should be defined for the Fiber service.
    If no, the characteristic should be defined for the Installation service.

    So no problem for me to have the Characteristic A on the fiber  and the characteristic B - C - D on the installation.

    I want to get my inventory as clean as I can with only relevant information.
    If for some reason I have to go back to the installation characteristic pattern, then I will look to the order.

    Hope it helps
    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 13.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted 28 days ago
    Hi All,

    I have more basic question on this discussion. Are we saying that modelling the installation methods as Services is our modelling best practice? We would also need to see the source of these characteristics that we are mapping on the "Method Services". Who decides that what are the values of these characteristics. Do these characteristics naturally reside on the RFS or Resources? If so, the best place to model them would be the subjects where they naturally reside (CFS, RFS or Resources), instead of creating "fake" services to place them.

    I think the business requirement here is to pass the right parameters to the Workforce Management System so that it can do the installation. One way to implement is to derive the right Work Order (TMF697) parameters from the characteristics that are placed on the real Services. This will be a transformation that needs to be done by "Calculate Work Order" function and may not require us to model them separately in the Service Catalog

    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 14.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 15, 2021 07:40
    yes agree with you @Ludovic Robert installation specific characteristics that are irellevant later can be added to the 'dummy' installation service. This was in mind already. I think that keeping the inventory clean is definately at the front of my mind.

    However my thoughts were that i cant have a single installation service because this would mean that i would have to associate every possible characteristic relevant to every kind of installation to it and then have backend logic to determin if the correct ones were passed. If i have an installation service spec per install type then this allows me to link the relevant characteristics to the specific installation type which means better informed clients. Would you agree?

    One final question on the 'requires' link​ for these specifications.

    In 633 i concieve this as being modeled as a 'ServiceSpecRelationship'
    In 641 i wondered whether this was one of two and didnt really understand the difference between them?...

    serviceOrderItem

    A list of service order items (ServiceOrderItem [*]). A list of order items embedded to this order item.

    serviceOrderItemRelationship

    A list of service order item relationships (ServiceOrderItemRelationship [*]). A list of order items related to this order item.



    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 15.  RE: TMF641 & TMF633 characteristic modelling

    Posted Sep 15, 2021 09:59
    @David Whitfield
    Very happy to have the conversation.

    Agree that supplementary Word and Excel documents to explain rulesets is a pain.
    Explicit statements of how an installation ​should be executed along with the appropriate characteristics definitely helps here.

    There does then remain the question as to whether the client organisation knows which installation services are then available to achieve what they want and this might spill over into qualification (especially where not all downstream suppliers have the same geographic coverage).

    On the matter of "if these are 'fake' services (the installation service) then I dont see how the 641 API can honour the contract and return an id for the installation service as it doesnt really feel like something that would make it into the inventory at all"

    I am showing my ignorance of the API spec here. But (!) I am not sure that an installation service having an ID means it ends up in inventory. I agree the spec implies that an ID is required for the service associated with the service order item but I am wondering whether that is to deal with the notion of linking service order items to services together with bundling related services etc. during the execution of the order as much as anything else.

    It seems to me that in general (not just your case) not everything someone orders will end up with a tangible physical asset with an ID in the inventory. But that just means the ID remains in the order and never makes it to the inventory.

    One example is a "self-install" consumer-grade broadband service where one has the option to add something value-added as part of a bundle (that is an associated but separate and optional second service for selected propositions). An example often quoted is to pay extra for a field tech to come out and move or install some wiring to correctly position the network termination point, install the CPE,  and perhaps set up the customer's WiFi and demonstrate the features of the service. I choose this example because

    The main service results in a working broadband service with associated RFS and an ID in inventory.
    The optional installation service is definitely linked to the main service and its sole rationale is to enhance the main service but usually will not end up in inventory alongside the main service.
    In catalogue and order terms, the optional installation service could be only loosely related to the "main" service as any old access service and not care whether it is xDSL or "fibre to the home" or even "Ethernet in the first mile" and therefore is available to be bundled with many types of connectivity services at order time.
    You could also have more than one flavour of the installation service for various types of customer (home, SME, corporate) or contracted supplier which might have different characteristics to add value in different ways.

    Such an installation service is definitely something I have seen people do and I believe has by comparison with what you want to achieve many of the broad properties I think you might be seeking.




    ------------------------------
    Derrick Evans
    ------------------------------



  • 16.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 16, 2021 07:07
    @Ludovic Robert any chance i could get your view on these points, would be really helpful.

    I think its my second question on the relationship vs embedded pieces im quite confused on?​

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 17.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 17, 2021 08:57
    Hello David

    "Embedded"  service order item did not have any semantic. So it could be used only for service bundled - which personally I never used in my company - but @Kamal Maghsoudlou could perhaps provide additional comment.

    ​serviceOrderItemRelationship has a mandatory semantic (relationshipType) and based on these you can trigger specific delivery process. We use it in my company...when service A requires B, then we trigger delivery of B first and then once completed we trigger delivery of A.

    Thanks
    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 18.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 17, 2021 12:12
    thanks @Ludovic Robert sounds like the relationship is the way to go.

    Is there somewhere that these relationship and relationship roles are ​documented or at least the base ones with their semantics which can be extended if necessary?

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 19.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 20, 2021 03:24
    Hello David
    I do not think we had defined them in the API - we're just provided illustration.
    There are some examples in ODA project, in particular in document ig1228 which feature some UC with catalog illustration. But you'll probably not find the semantic.
    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 20.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 23, 2021 06:41
    Hi @Ludovic Robert, thanks for the pointer, I realy found that document (especially the diagrams very useful as they describe pretty much the 'desired customer services' we have in our scenario (clearly the 'installation' i have spoken about would be something additional).

    Whilst the 'applies on' link makes absolute sense to me (semantics seem clear) we are implementing the service layer and when i look into the service order api and i have the usecase where i want to submit an order as below with the 3  line items i dont know how to specify the link?

    If i assumed: -
    • Line 1 - fiber access
    • Line 2 - connectivity ('applies on' 1)
    • Line 3 - tv channels ('applies on' 2)

    In 641 (v4.1.0) I looked at : -
    • 'ServiceOrderItem' resource has an array of 'ServiceOrderItemRelationship' which might be an option. However when i look at the POST (create service order) guidance it says that if i include a 'serviceOrderItem.serviceOrderItemRelationship.orderItem' then the 'serviceOrderId is mandatory. This isnt really any good because i am POSTing the service order and therefore do not when creating the request have a serviceOrderId to populate?
    • I looked at the 'ServiceRefOrValue' resource which in this case would be passing by value as i am requesting the creation of all 3 services in the same order.
      • I cannot POST a 'ServiceRelationship' within the service object for Line 2 referencing the service within line 1 as i dont have an inventory id for it?
      • I cannot POST a 'ServiceOrderItem' within the service object for Line 2 referencing the order line item 1 because the 'serviceOrderId' is mandatory and i dont have an id yet (i am only just constructing the order)
      • supportingService field within the service object is described as a bundling link of CFS to RFS (which this isnt) and either way if i did also create another service in here it couldnt be a ref (i dont have an id for the service thats going to be created by line 1) and i cant really pass a duplicate of the service contained in line 1.

    As i say the diagram is really useful and makes complete sense just a bit lost on how to actually get the relationships described into the API calls?

    ig1228-uc003
    ​​

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 21.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 22, 2021 14:50
    Hi David,

    The starting point for these state changes are found in  GB922 Product Domain Business Entities Information Framework (SID) Suite R21.0.0 2.2.7

    This section descibes different types of productSpecifications. Except for the networkProductSpec (linked to a networkServiceSpec) it describes a number of other products. One of these products is the FieldOperationProductSpec, from the description you can conclude that it is a service that creates a state change for the Resources that will be used by the NetworkService.

    A further modeling for these statechanges can be found in GB922 Common Domain Business Entities Information Framework (SID) Suite R21.0.0 2.6 Project ABE.

    This ABE describes project and generic concepts on activities and workorder.
    Particularly 2.6.12 provides some insight in how activities perform state changes and 2.6.17 on workorder provide further usefull information.
    I will be working on an architecture for fieldOperations in the coming months and expect this will result in some kind of fieldOperations blade similarly to the SCRUM blade example in 2.6.20.

    It is all not yet in a plug and play state ready to give to a developer, but it helps architects by giving structured patterns to start working with.

    Regards



    ------------------------------
    Koen Peeters
    Ciminko Luxembourg
    ------------------------------



  • 22.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 23, 2021 11:24
    David,
    I quickly took a look on the swagger here  and the serviceOrderId is (hopefully) not mandatory. Could you please check on your side because the pattern you explained is the correct one....item could have relationship to other items by just referring item id without need to refer service order id if we are within the same service order.

    Hope it helps
    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 23.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 24, 2021 11:44

    thanks @Ludovic Robert, you're correct the swagger doesnt say that the service order id is mandatory, its the user guide i'd understood was defining this as part of the 'additional rules' for 'create service order'

    fromtmf641guide

    ​If i look at the swagger the serviceOrderItem.serviceOrderItemRelationship defines the 'orderItem' property as a ServiceOrderItemRef. Within that object it mentions that a field called 'id' is required but there is no field in that object called id?

            "ServiceOrderItemRef": {
                "type": "object",
                "properties": {
                    "itemId": {
                        "type": "string",
                        "description": "Identifier of the line item"
                    },
                    "serviceOrderHref": {
                        "type": "string",
                        "format": "uri",
                        "description": "Link to the order to which this item belongs to"
                    },
                    "serviceOrderId": {
                        "type": "string",
                        "description": "Identifier of the order that this item belongs to"
                    },
                    "@baseType": {
                        "type": "string",
                        "description": "When sub-classing, this defines the super-class"
                    },
                    "@schemaLocation": {
                        "type": "string",
                        "format": "uri",
                        "description": "A URI to a JSON-Schema file that defines additional attributes and relationships"
                    },
                    "@type": {
                        "type": "string",
                        "description": "When sub-classing, this defines the sub-class Extensible name"
                    },
                    "@referredType": {
                        "type": "string",
                        "description": "The actual type of the target instance when needed for disambiguation."
                    }
                },
                "required": [
                    "id"
                ]
            }


    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 24.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted 29 days ago
    Hello
    Got it.
    We need to fix the user guide. I will raise a jira. Hopefully the swagger is correct.
    Thanks for the catch.

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------