This is a very valid requirement which is not just needed for Service Qualification, but also for Service Ordering, where there is a need to group related services together, so that downstream fulfillment system can recognise them as a group and process accordingly.
Consider a scenario where someone has to order these services together on a given location. In such case also, we need to group them together so that downstream system would know which internet needs to be provisioned with which Access. This scenario would be more common in B2B connectivity Services where there are multiple EVCs and UNIs needs to be provisioned at a given location.
Consider a scenario where an Enterprise what to order dedicated E-LAN services for their Finance and Operations teams, both of which share same locations. In that case, we will have multiple EVCs and Multiple UNIs in a single Order. The need here is to group relevant UNIs with their corresponding EVC so that the fulfillment system understand that they need to be handled together.
I think we should have something called a Service Group that can be used to group multiple CFSs together so that provisioning systems can have enough information to handle them together. The same concept can be used in Service Qualification API as well to return the Service Groups wherever needed.
------------------------------
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 12, 2021 02:17
From: Jonathan Goldberg
Subject: TM645 query Service Qualification - How to cluster services in the response per technology?
Hi Peter
So nice to be back in contact with you after 20 years or so !
As you correctly state, a qualification item relates to a specific Service (or a Product in the corresponding offer qualification API).
The idea of clustering is an interesting one, but changing cardinality from 1 to 1:* would be a breaking change.
You can of course extend your implementation of the API to add characteristics (or indeed strongly-typed attributes).
@Ludovic Robert as the API owner might have additional thoughts, as also @Johanne Mayer our NaaS expert.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Sep 10, 2021 04:21
From: Peter Broucke
Subject: TM645 query Service Qualification - How to cluster services in the response per technology?
Hi,
We are analyzing the implementation of a strict TMF645 Service Qualification version for the query operation.
We want in the output/response the possibility to list all the different services & their characteristics but this per available technology at the requested location.
Therefore the required output needs to be able to host the following structure of information for us (example):
item 1 > this reflects the preferred cluster of services
CFS Access
Technology = FIBER GPON
CFS TV
MaxNoOfStreams =
MaxVideoQuality =
CFS Voice
MaxNoOfChannels =
CFS Internet
MaxDownStream =
item 2 > 2nd option for cluster of services
CFS Access
Technology = VDSL2
CFS TV
MaxNoOfStreams =
MaxVideoQuality =
CFS Voice
MaxNoOfChannels =
CFS Internet
MaxDownStream =
item 3 >
CFS Access
Technology = 4G
CFS TV
MaxNoOfStreams =
MaxVideoQuality =
CFS Voice
MaxNoOfChannels =
CFS Internet
MaxDownStream =
The technology influences / limits certain service characteristics. The set of possible services is to be seen as a cluster linked to the selected/possible techology.
The current TMF645 specification doesn't allow us to cluster the possible answers as indicated above because the cardinality from ServiceQualificationItem to ServiceValueOrRef is limited to 1.
Is there an option to review this & change this cardinality?
Do you propose / see another way to handle this?
We also need to provide the requester a way to show the preference of technology. Currently we would add a number of characteristics on the ServiceQualificationItem, including such 'Priority' (or 'Weight') - could this be foreseen? Any alternative proposal for this requirement?
kind regards,
Peter
------------------------------
Peter Broucke
Proximus
------------------------------