Open APIs

Hi TMForum community,

While working with TMF645, there were some conceptual questions raised by my team.

For Check Service Qualification request for some services (e.g. data/voice), the viability logic must consider the current available access infrastructure (meaning the ONU/ONT that end-user currently has) or should the logic consider all possible network expansion (e.g. adding new NAPs/CTO/ONU/ONT) to reply the viability request?

For example, lets say that CSQ has service qualification item for a new voice service. However the customer existing ONU/ONT does not have resources to provide this service (maybe customer already has all voice ports used). The PON network could support however installing a second ONU/ONT to provide this service.

Conceptually, should CSQ return:
1) qualificationResult = Unqualified => because the existing ONU/ONT does not have resources (e.g. voice ports available) to provide the service
2) qualificationResult = Qualified => because CSP can install a new ONU/ONT and with that, provide the required service

Thanks and Br,

------------------------------
Juliano Sugavara
Nokia
------------------------------

Hello Juliano

Regarding your question, I will consider additional factors:

• You have also to consider the date - indeed the requester could specify an expectedActivationDate - so regarding your UC, if I ask for tomorrow probably the qualification will be unqualified but it is for 10 days from today it could be qualified. 
• You can also specify more precisely the qualification result: additionally to qualified/unqualified you add a conditionalQualified and leverage eligibilityUnavailabilityReason to explain the condition and/or providing an alternate with an availability date.

Hope it helps,

Ludovic

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

Hi Juliano,

Interesting question.

I have the impression that - as a service operator - you want to give the answer 'Qualified but...' because it's feasible, however with impact / work to do.

We use today towards BSS the values/status's OK (qualified), OKBUT, NOK (unqualified).It would indeed be interesting to have a standard approach to indicate this OKBUT.

As Ludovic indicates, two different paths for this.

1) OR conditionallyQualified - this looks closer to our "OKBUT"

2) OR via alternate construction

To me it sounds like this is maybe  not really an alternate because there's only one way, via the existing access to do it, but both - I agree with Ludovic's view - approaches are acceptable.

In both cases we need a standard way to indicate the later "fully qualified date" +  the reason and/or the work to do / impact + maybe  even also a way of estimatedWork or estimatedCost to achieve this.

Anyway, I think it would be good to standardize a bit this response of "OKBUT" rainy day use case.

greetz

Peter 

------------------------------
Peter Broucke
Proximus SA
------------------------------

Hi,

from my past experience and this is not about TMF645, a customer are qualified or they're not.
when you're not qualified, you may want to provide a reason as well as a potential and automatic resolution.
I'm gonna use the term "TSQ" (Technical Service Qualification") as the name of the component that exposes TMF645 (or other TSQ API)
TMF645 is great if incorporated in a bigger value chain managed by an overal process. It's not just about giving a status, it's about giving valuable and actionable intel for the customer. Below are 2 real-life implementation of how a TSQ API can be used.

Example 1: valuable intel

1. I, a customer, currently have internet over copper.
2. I browse the product catalogue and see the fiber internet product offerings.
3. Before the product offerings are displayed, the TSQ component is called (via TMF645) in pre-pick mode (i.e. before I pick the product and add it to the shopping cart)
4. for each fiber internet product offerings, TSQ message tells me:
   "There is no fiber at my adress"
5. that's the unhelpful approach. But you can integrate your TSQ component with your "project management" component that manage Fiber installation project in your country. and then you can get much better information for your customer:
   "We are planning to install Fiber in your region (post code, place...) the current status is "Installation in progress" and we plan to complete the works in September 2022

From there, your implementation can do what it wants: create a sales opportunity for future follow up, create a future-date order etc

Example 2: actionable intel

1. steps 1 to 3 as above
2. for each fiber internet product offerings, TSQ message tells customer: "it's ok but I will need an "fiber installation" and a new "home gateway", both options will be added automatically to the shoppping cart, should I click "add to cart" button to pick that offer.
3. I click the add to cart button
4. Fiber installation and home gateway are now in the shopping cart
5. when I run the TSQ component on my cart (this time, it's in post-pick mode), TMF645 will return a OK message, because the TSQ has seen that the correct fiber home gateway and fiber connection (via installation) are present in the cart.
6. This means TSQ should not only check the services or resources in the Production ODA block but also products in the product inventory as well as what's in the current shopping cart (and possibly in current open orders!)

There is lots of logic that can be implemented in the TSQ component, but not in the API itself.

------------------------------
Matthieu Hattab
Altibox AS
------------------------------

Original Message:
Sent: Apr 15, 2022 04:59
From: Peter Broucke
Subject: TMF645 - Check Service Qualification - qualificationResult

Hi Juliano,

Interesting question.

I have the impression that - as a service operator - you want to give the answer 'Qualified but...' because it's feasible, however with impact / work to do.

We use today towards BSS the values/status's OK (qualified), OKBUT, NOK (unqualified).It would indeed be interesting to have a standard approach to indicate this OKBUT.

As Ludovic indicates, two different paths for this.

1) OR conditionallyQualified - this looks closer to our "OKBUT"

2) OR via alternate construction

To me it sounds like this is maybe  not really an alternate because there's only one way, via the existing access to do it, but both - I agree with Ludovic's view - approaches are acceptable.

In both cases we need a standard way to indicate the later "fully qualified date" +  the reason and/or the work to do / impact + maybe  even also a way of estimatedWork or estimatedCost to achieve this.

Anyway, I think it would be good to standardize a bit this response of "OKBUT" rainy day use case.

greetz

Peter 

------------------------------
Peter Broucke
Proximus SA
------------------------------