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
------------------------------
Original Message:
Sent: Oct 13, 2021 16:44
From: David Whitfield
Subject: TMF641 & TMF633 characteristic modelling
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
Original Message:
Sent: Oct 07, 2021 17:16
From: David Whitfield
Subject: TMF641 & TMF633 characteristic modelling
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
Original Message:
Sent: Oct 07, 2021 05:00
From: Koen Peeters
Subject: TMF641 & TMF633 characteristic modelling
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
Original Message:
Sent: Oct 06, 2021 09:54
From: Kinshuk Kulshreshtha
Subject: TMF641 & TMF633 characteristic modelling
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.
Original Message:
Sent: Oct 01, 2021 17:21
From: Dave Milham
Subject: TMF641 & TMF633 characteristic modelling
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
Original Message:
Sent: Oct 01, 2021 09:36
From: David Whitfield
Subject: TMF641 & TMF633 characteristic modelling
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
Original Message:
Sent: Oct 01, 2021 05:55
From: Dave Milham
Subject: TMF641 & TMF633 characteristic modelling
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
Original Message:
Sent: Sep 29, 2021 08:36
From: David Whitfield
Subject: TMF641 & TMF633 characteristic modelling
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
Original Message:
Sent: Sep 28, 2021 01:53
From: Kinshuk Kulshreshtha
Subject: TMF641 & TMF633 characteristic modelling
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.
Original Message:
Sent: Sep 15, 2021 07:26
From: David Whitfield
Subject: TMF641 & TMF633 characteristic modelling
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
Original Message:
Sent: Sep 14, 2021 10:49
From: Derrick Evans
Subject: TMF641 & TMF633 characteristic modelling
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
Original Message:
Sent: Sep 14, 2021 08:07
From: David Whitfield
Subject: TMF641 & TMF633 characteristic modelling
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.
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
Original Message:
Sent: Sep 14, 2021 07:17
From: Derrick Evans
Subject: TMF641 & TMF633 characteristic modelling
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
Original Message:
Sent: Sep 13, 2021 12:33
From: David Whitfield
Subject: TMF641 & TMF633 characteristic modelling
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: -
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
------------------------------