Open APIs

 View Only
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

    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
    ------------------------------



  • 4.  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
    ------------------------------



  • 5.  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
    ------------------------------



  • 6.  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
    ------------------------------



  • 7.  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
    ------------------------------



  • 8.  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
    ------------------------------



  • 9.  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
    ------------------------------



  • 10.  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
    ------------------------------



  • 11.  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
    ------------------------------



  • 12.  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
    ------------------------------



  • 13.  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
    ------------------------------



  • 14.  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
    ------------------------------



  • 15.  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
    ------------------------------



  • 16.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 27, 2021 05:07
    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
    ------------------------------



  • 17.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 27, 2021 06:04
    No problem @Ludovic Robert, thank you for all your help on this! happy to make a contribution.

    Quite keen on keeping up to date on the ideas evolution of especially these 3 ​API's as they're things we're using and have some requirements for :-)

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



  • 18.  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
    ------------------------------



  • 19.  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
    ------------------------------



  • 20.  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
    ------------------------------



  • 21.  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
    ------------------------------



  • 22.  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
    ------------------------------



  • 23.  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
    ------------------------------



  • 24.  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
    ------------------------------



  • 25.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 28, 2021 01:53
    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.
    ------------------------------



  • 26.  RE: TMF641 & TMF633 characteristic modelling

    Posted Sep 29, 2021 08:17
    Hello
    Fair question but in my opinion "installation methods" are real and not "fake" services. It is just they are not network related services.

    In the organisation I last worked for they had a whole portfolio of "Field Services" which related to things a field technician could do for a customer whilst at the premises. The notion was to upsell the work of the field tech and derive more revenue from a particular customer site visit.

    These "Field Services" were priced as optional addons to the basic visit and install. You could not order them as standalone things but if the field technician was visiting to install or repair broadband, telephony or Ethernet one could optionally order additional equipment to be installed or internal wiring to be put in etc.


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



  • 27.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 29, 2021 08:36
    Hi @Kinshuk Kulshreshtha,

    In our use case we do not have a workforce mangaement system as this will be work carried out by a supplier (its their WFM) and is therefore something they would essentially capture on a non-TMF equivilent of Product Order Management. I think your assumption here is that each operator manages the resources that will complete the work? If this were always the case then the business requirement you suggest could be correct but i dont think that's the case.

    To your point "Who decides that what are the values of these characteristics". Then i think that depends on the service we are modelling but ultimately they would be modelled in the catalog and be appropriate to the service being requested. i.e. characterisitics of a new line installation with one access network provider vs another access network provider are unlikely to be the same.

    In our world its correct that during the customer journey the digital experience layer has understood the fibre and connectiivty services that the customer has available to them. Decisions there will determine if they wish to have a new line installed or have an existing line switched over from their current CSP (as two examples). Its therefore correct for the business layer to request that this method service (new line installation)  ​is fulfilled (my understanding of open API is this is always modelled as CFS as this is something that the customer has asked for). There is no point in a service layer guessing this from discovering various parameters/characterisitcs.

    I must admit before having my eyes opened to such an approach i considered these things to be 'fake' services however i've now changed my view on this. I dont think its correct to say they are fake. This is a service we are providing (just like having some kind of inhome configuration might be another) and therefore these services (albeit being in a 'finished' state post the order) are no less of something that has been provided. I think @Koen Peeters made a really good point on the monitization (or potential) that this would provide.
    ​​

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



  • 28.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 30, 2021 01:47

    Hi David,

    Actually my point was mainly on the abstractions and encapsulation around the constructs. I very well understand that we will always have the case where we need multiple operators and engagement between them to provision a service. This is typical of complex B2B connectivity services where one CSP own one portion of the network and other CSP own other portion. It is also common to have a small regional provider own the last mile for broadband and relay on wholesale CSP for the backhaul. But even in those cases, we should be able to define clean constructs with abstractions around PS, CFS, RFS and Resources and use them as the anchor to interface between the operators at the delivery layer. 

    Based on what you mentioned above, it seems that your commercial layer itself is calculating the delivery details and the commercial layer is directly requesting the delivery layer by providing the required parameters. In this case, you are not decomposing the Product Order into a Service Order and not creating the Service Inventory decompositions in form of CFS, RFS and Resources, but directly identifying the method details right into the commercial layer.  Is that correct?

    These "Services" that we are creating are more close to "Field Services" with examples like Installation Service which is an activity needs to be done to provision a "Customer Service". In my view, this is different from the Customer Facing and Resource Facing Services that are defined in SID and I am not sure if there is a recommendation in TMF to use  Service construct to encapsulate the metadata for Workforce Management in the Service Catalog.

    Koen Peeters, Are you proposing that we should use the "Service" construct to create the catalog model for fieldOperations as well? Currently, when we talk about services in TMF context, we only talk about CFS and RFS. Are we moving in a direction to introduce something called FFS (Field operations Facing Services) as well?



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

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



  • 29.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 01, 2021 09:33
    Hi @Kinshuk Kulshreshtha, thanks for your thoughts.

    Correct our equivilent of the core Commerce Management domain within ODA along with the digital experience over​ the top gives the options to the product/customer (depending on channel.... think B2B2x where partner businesses want the ability to determin the fulfilment option). If something is considered something that a customer wants (I want a new fibre access vs i want to reuse the one i have) im interested why this is not considered a customer facing service? I'd thought that this was? The equivilent of a product order is decomposed into a service order  and service order management will populate service inventory.

    As i have illuded to in my prior post (and @Derrick Evans mentioned previously) each of this customer facing installation options would require different data based on which supplier the installation was performed with and the type of installation being performed​​. Our take is that this is data required on the order as this will eventually be decomposed into a supplier order which requires this data for it to be placed. How else would you see this data being correlated back with the service order?

    I can see that your preference is towards workforce management, I see two challenges with this...
    1. How do you start off small with ODA and open API if you need to implement all these at once (we dont have WFM)
    2. We dont see the case for WFM as we dont have installation engineers.

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



  • 30.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 01, 2021 10:50
    Hi Kinshuk,

    I have not found a TMF related document that proposes to use "service" for fieldOperations, but at the same time I don't find any official proposal on how it should be modeled. The below is therefore my personal interpretation.

    I am currently trying to dive bit deeper in this subject and my current vision for fieldOperations Products is that it is realised as a Project rather than a service.
    There is currently no defined OpenAPI for Projects but it is described in the SID (GB922_Common).


    The catalog model for projects is defined in the same SID model:

    1. ProjectSpec
    2. WBSElementSpec
    3. ActivitySpec
    4. ProjectResource

    The ProjectResource is a link to the Resource being installed or can also have references to tools or consumables.
    I hope this is helpful information.

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



  • 31.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 01, 2021 15:52
    Hi Kinshunk,

    In IG1233 Product & Service Modelling Best Practices – Conforming to ODA v2.0.0, chapter 4.1.4. Model, page 16 following is stated:
    "Though many SID diagrams show CFSS and RFSS layer providing a technical solution using technical resources, it is important to recognize that a Service can also be offered using people, process resources. These are called Managed Services in the diagram. The Production system that creates and offers a Technical service may be different from the system that offers a managed service. "


    If I understand it correct, those "Managed Services" can be modelled via Product Specification and related Customer Facing Service Specifications.

    ------------------------------
    Alen Ruvic
    SES Astra S.A.
    ------------------------------



  • 32.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 01, 2021 05:56
    David  indirectly related d to this are a couple of documents for the e2eODA transformation guide team which look at modelling in a B2B context

    IG1233 Product & Service Modelling Best Practices – Conforming to ODA v2.0.0
    This has an Orange email example whcih is based on bring in services form a thirds party  as a Product this is about modelling form Product Specs -> CFS- RFS to third party products

    IG1264 Best Practice: Secure Customer Control of CSP Services v1.0.0
    Which use he same model but adds the security piece - inspired by reselling ZOOM but uses same p/S/R  model as IG1233

    Strikes me however there might be a case for adding examples based on your third party workforce needs as that is a pretty common requirment and can require link customer facing Appointments with a third party's appointments.

    ------------------------------
    Dave Milham
    TM Forum, Chief Architect
    ------------------------------



  • 33.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 01, 2021 09:37
    thanks @Dave Milham for the pointers i'll take a look at the links.

    You're quite right that some of the complexity we're working through is trying to apply the TMF646 to multiple appointment books which are not our own. It appears that the appointing api doesnt quite give us what we need and certain functions (Create a timeslot) are not something we control.

    How would we go about getting some examples ​added for the 3rd party workforce piece?

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



  • 34.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 01, 2021 17:22
    Appointments in A B2B context are really difficult. My experience comes form BT Wholesale and regulated interconnect . In these cases the consumer of the Appointment Service needs to be able to lock in the person scheduled for the appointment which isn't something you see in the majority of retail situations. Note Derick Evans who commented earlier is an expert in this area and has the  scars .

    ------------------------------
    Dave Milham
    TM Forum, Chief Architect
    ------------------------------



  • 35.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 06, 2021 09:54
    Hi Koen Peeters,

    It is interesting ​to understand your views on Field Operations. I really like that you are not using Services for Field Operations because they are inherently different from CFS and RFSs. I agree that Project is the right entity to be used here and not Service. That was the primary reason why I raised the concern on mapping the installation method related information on the Service Entity.

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

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



  • 36.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 07, 2021 05:00
    Hi Kinshuk,

    The fieldOperations are indeed very different from the classic CFS / RFS.
    A project effectively provides the right structure for a flexible catalog driven approach. In the end a fieldOperations product should reflect a number of activities that consume, use or produce projectResources.
    The goal of the project will be to produce the supportingResources for a Service.

    The catalog for fieldServices will start by creating activitySpec e.g.:
    • Patch distribution cable to PON
    • Install drop cable
    • install ONT
    • Install CPE

    These activites are grouped into WBSelementSpec:
    • Customer premise work
    • PON streetcabinet work
    And these WBS Elements are organised into to projectSpec:
    • Individual Home GPON connection

    The projectSpec is than linked to a fieldOperationsProductSpec.

    On the instantiation of the fieldOperationsProduct, A project will be started and WorkOrders can be issues for each WBSElement. This allows for multiple workOrders for each fieldOperationsProduct. In the above example that would be one for the work at the Streetcabinet work and one for the work at the customer premise.
    Intrestingly all the cost planning and cost allocation capabilities of the project can help for any operator that wants to have detailed IFRS compliant cost tracking. A mapping to CFS/RFS would never be able to achieve that this easily.

    Best Regards

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



  • 37.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 07, 2021 17:17

    Hi @Koen Peeters, this is a really interesting view point, is the concept therefore that you would have a ​project catalog?

    I guess that whilst the above sounds really good this isn't something that is in the toolbox right now and isn't something I can adopt currently within inflight work.

    I was hoping to get some practical advice based on my above constraints

    1. we don't have a workforce management system (we don't have a workforce installing fibre)
    2. We don't have an appointment book to allocate engineers. this is multiple appointment books each specific to the fibre installer.
    3. We're starting off small with only the 641/633/638 apis

    All that there is is a supplier order for fibre connection and that connection will be performed differently based on what data we send in it. 
    ultimately the customer is in control of what connection they wish to take.

    i.e. They maybe wish to have a new line installed even though one is already present

    maybe they desire the inactive connection point in the living room to be connected (not the one in the kitchen)

    Maybe they wish to switch their current active port with another provider

    maybe they wish to install a new gpon connection and have their current copper connection cease orchestrated. 

    I was looking for a way to fit all of these complex different journeys which are determined during the digital lead to order systems to fit smoothly into product and then ultimately service order creation. 

    Could either of you suggest an approach?


    it felt with the suggestions made earlier the idea of having 'installation specifications' would allow a clean way of defining the different data requirements between these different options. Then defining the links between these and the 'actual services' would ensure that a 'fibre acces' would have a 'install fibre & disconnect copper' installation service linked (installedUsing) but say a 'dsl access' would not.



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



  • 38.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 13, 2021 16:44
    Hi @Kinshuk Kulshreshtha and @Koen Peeters do you have any help on my above constraints.

    In addition to the above points on the kind of connection that the customer desires my understanding on how to get that information to them would be via ServiceQualificationManagement. However the example in the doc just really shows asking for 4K TV via a characteristic and receiving an alternate offering with a HD characteristic.

    In this fibre access case there is need to supply back the experience layer with information it never knew (like available port references at the address or legacy copper line references for a managed migration). Not really sure how this would be achieved?​​

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



  • 39.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 14, 2021 05:10
    Hi David,

    I agree with you that a serviceQualificationManagement for an access service can become quite complex.

    Most service providers nowadays have hybrid environments with partially copper based and partially fiber based infrastructure. On top of that they might be interfacing with a number of alternative local loop providers.

    A serviceQualificationmanagement should hide these complexities.

    The first hurdle to take is to unique identify the address of the premisses. Let's assume that we have passed this hurdle and that we can use a unique id to identify the premise using the place array, than we still have a number of different use cases.

    1. Access service by address
    The experience layer should in this case create a request like this:

    {
      "@type": "CheckServiceQualification",
      "serviceQualificationItem": [
        {
          "id": "1",
          "serviceCategory": {
              "name": "accessServices"
           },
           "service": {
              "place": {
                  "id": "123e4567-e89b-12d3-a456-426614174000"
            }
          }
        }
      ]
    }

    This should return a list of alternate access services available without touching the existing services.

    2. Upgrade/downgrade existing service
    In this case the experience layer should issue a request like this:

    {
    "@type": "CheckServiceQualification",
      "serviceQualificationItem": [
        {
          "id": "1",
          "service": {
            "id": "123e4567-e89b-12d3-a456-426614174000"
          }
        }
      ]
    }

    This should return a list of alternate services that take into account the existing service.
    The id of the existing service is previously determined by lookup. If the the existing services uses legacy copper lines the

    The results can have a complex structure to help determine the different scenarios.
    If the alternate services use the same supportingResource (port, copperline), the service can probably be accomplished by remote activation.
    If the alternate services use new supportingResources, the lifecycleStatus of these resources can be used to determine the complexity of the work. Resources in "planning" state will require a project with associated workorders to get the resource in a "operating" state.





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



  • 40.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 15, 2021 02:25
    Hi David,
    As you said, Service Qualification can have varying level of complexity depending on the context. For a DSL Service, Service Qualification can be as simple as checking the availability of ADSL or VDSL port on the DSLAM. But for Carrier Ethernet E-LAN Service it will be quite complex and require Orchestration of its own. I think depending on the context and complexity, the interface and processing of TMF 645 needs to be adjusted.  Qualification of complex multipoint connectivity Services may require creation of a Project and field engineers to check some feasibility on ground manually to see if it will be possible to dig the cable for connecting to an Enterprise customer site.

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

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



  • 41.  RE: TMF641 & TMF633 characteristic modelling

    Posted Oct 18, 2021 10:55
    Hello All
    In terms of qualification APIs I think it would be useful to make a distinction between things which can be checked via lookups to inventory records and other systems of record versus things requiring surveys. 

    For Ethernet access services one can usually tell quite easily whether a loc fibre enabled point of presence has capacity and or whether premises are already served with fibre.

    If new duct and cable needs to be provided then a site survey is possibly required.

    One could then offer that as a service which can be ordered separately.

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



  • 42.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Oct 19, 2021 01:14
    Hi Derrick,

    Thats exactly my point.

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

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



  • 43.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 25, 2022 07:55
    Edited by David Whitfield Sep 26, 2022 07:00

    Hey @Koen Peeters,

    I have been reflecting back on this post today whilst looking deeper into service qualification and also modelling of service specifications​ in the catalog I've discussed separately on another thread.

    I think that there we discussed that for example a specification might be 'fibre access' and a candidate might 'fibre access basic' (I.e. downstream characteristic with value 50MB)

    if this is the case then I pondered why, rather than returning 'alternate service proposals' entities, the qualification api doesn't return alternative service candidates which essentially give that extra layer of 'configuration' of a specification. 


    I suppose to a more general point even though the check qualification resource line items contain a service then this is really just a link to the inventory rather than creation anything in the inventory?!


    thanks 

    dave



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



  • 44.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted Sep 29, 2022 10:28
    Hi David,

    I agree that the serviceCandidate is currently missing from the TMF645 entities. I think indeed this should be added in the next release to allow this extra level of configuration.

    The the service contained in the line items can be used in two different modes.
    • When the id is used and the service exists, it can be used to provide alternatives for an existing service.
    • When there is no id the service doesn't have to exist in the inventory. In that case the service entity is a container to capture the filter constraints of the request: e.g. place, supportingResource, ... and to return the available serviceSpecifications or serviceCandidates.


    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------



  • 45.  RE: TMF641 & TMF633 characteristic modelling

    TM Forum Member
    Posted May 04, 2023 12:03

    HI @Koen Peeters  and team,

    I'm wondering if there is an work in flight at TMF to resolve this problem as it seems to me that only returning service specifications isn't sufficient. I guess depending on how a business decides to structure its service specifications returning only these could be quite insufficient.

    In the case i'd highlighted if you do have a specification for fibre access it might well cover a lot of different scenarios 

    At the location specified by the request
    - What company could provide the last mile or presence of existing infrastructure
    - What bandwidths are available
    - complexity of install
    - installation notes

    All of this is 'real data' for a potential service and not something that would be stored against a specification so not really clear on how the current API structure would work.

    On the flip side given that there could be many variations that would be available for a gives specification (bandwidths etc) the payload in the response could become large and non performant.

    I was therefore interested if anyone had faced this problem and therefore had some experience on how to solve it? To be clear my business is not a last mile provider and therefore these are supplier businesses of which there might be a lot of disparate options geographically.

    thanks for any help with this

    Dave



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