Open APIs

Hello,

I have a question regarding the OpenAPI TMF645 Service Qualification API, which is part of the Pre-Ordering Management APIs. As I understand it, the Service Qualification API's goal is to assess service availability at the customer location.

In typical implementations, the TMFC009 Service Qualification Management component often utilizes other APIs such as the Service Catalog, Geographic Address Management, or Inventory to evaluate technical feasibility.

However, in the case I am working on, the service is more complex. It involves sending a technician to the customer's home, scheduling an appointment, and reserving specific equipment to perform measurements.

My question is: Is the Service Qualification Management component the right one to orchestrate this process? The workflow seems to be closer to a Service Order creation rather than a simple service qualification.

I would appreciate any insights or suggestions from the community on how to approach this scenario effectively.

Thank you in advance!

------------------------------
Vítor Fernández
OPTARE SOLUTIONS, S.A.
------------------------------

Hi,

TMF has a Work Order Management (TMFC061) component is responsible for setup and maintenance requests from initiation to completion at party's location.

TMFC009 will not orchestrate any activities that would "upgrade" the customer location to make it compatible with the requested CFS (CFSspec).

If you POST a request towards the TMF645 CHECK endpoint, you will get a response that has:

• Eligibility unavailability reason
• Alternate service proposal

 in the AlternateServiceProposal sub-resource, 645 provide the alternate service. It can be another service or it can be the CFS  that you requested but with a future date (alternateServiceAvailabilityDate).

What is not clear is how TMFC009 can calculate that alternateServiceAvailabilityDate, which will be the date your field technician is expected to upgrade the location's CPE in order to provide one technical solution (RFSspec) available to deliver the requested service (CFSspec).

what TMFC009 cannot do, I think, is to tell you what RFSspec is needed

Another approach is to POST a request towards the TMF645 QUERY endpoint. with Query, you only get what exist at the location. No qualification rules  are computed. It's the requester that has to contain all the logic to evaluate SQ and determine alternatives. Our BSS does this because it has its own SQ component and it works with the product catalogue and product configurator to identify what products are missing and can also automatically add the required product offers in the carts:

• tangible products like Gigabit fiber, PON, fiber CPE etc
• non tangible x hours of a field technician, engineer etc
• generic installation charges (software config is OSS, swapping cables, planning activities, construction company work etc)

then customer must accept our proposal (still a cart) which becomes an product order and then you can use TMFC003 to orchestrate all the dependent orders in the right sequence (first the work orders).

In general, I see more and more questions about how ODA component can work together. once to try to make them work together, we often see gaps. Service Qualification is an area that has many gaps as we have seen in a recent post on CFS determination)

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------

Thanks Matthieu for your detailed response. I understand the following key points:

• TMFC061 Work Order Management is responsible for handling installation and upgrade activities at the customer's location.

• TMFC009 Service Qualification Management is not intended to orchestrate activities or upgrades.

One approach we are considering is using TMFC009 to indicate that a Work Order is required, so that the BSS can initiate the corresponding request.

Thanks again for your insights!

------------------------------
Vítor Fernández
OPTARE SOLUTIONS, S.A.
------------------------------

Original Message:
Sent: Apr 25, 2025 06:29
From: Matthieu Hattab
Subject: TMF645 for Complex Long-Running Service Qualification Process

Hi,

TMF has a Work Order Management (TMFC061) component is responsible for setup and maintenance requests from initiation to completion at party's location.

TMFC009 will not orchestrate any activities that would "upgrade" the customer location to make it compatible with the requested CFS (CFSspec).

If you POST a request towards the TMF645 CHECK endpoint, you will get a response that has:

• Eligibility unavailability reason
• Alternate service proposal

 in the AlternateServiceProposal sub-resource, 645 provide the alternate service. It can be another service or it can be the CFS  that you requested but with a future date (alternateServiceAvailabilityDate).

What is not clear is how TMFC009 can calculate that alternateServiceAvailabilityDate, which will be the date your field technician is expected to upgrade the location's CPE in order to provide one technical solution (RFSspec) available to deliver the requested service (CFSspec).

what TMFC009 cannot do, I think, is to tell you what RFSspec is needed

Another approach is to POST a request towards the TMF645 QUERY endpoint. with Query, you only get what exist at the location. No qualification rules  are computed. It's the requester that has to contain all the logic to evaluate SQ and determine alternatives. Our BSS does this because it has its own SQ component and it works with the product catalogue and product configurator to identify what products are missing and can also automatically add the required product offers in the carts:

• tangible products like Gigabit fiber, PON, fiber CPE etc
• non tangible x hours of a field technician, engineer etc
• generic installation charges (software config is OSS, swapping cables, planning activities, construction company work etc)

then customer must accept our proposal (still a cart) which becomes an product order and then you can use TMFC003 to orchestrate all the dependent orders in the right sequence (first the work orders).

In general, I see more and more questions about how ODA component can work together. once to try to make them work together, we often see gaps. Service Qualification is an area that has many gaps as we have seen in a recent post on CFS determination)

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------

Hi,

I understand you questions. When I see TMF645 API, it's designed for instant response or for long running process, but TMFC009 is imho designed only for instant reply. So I also see the gap there.

I dont think, that call to TMFC061 WOM is sufficient, I think process is more complex and it's similiar to SOM (we have implemented it in the past as simlified service order). So question here is what component is responsible for this process (if not TMFC009) and how to triger it? And I suggest to check if TMF701 API suits you and implement call from TMFC009 to some newcomponent using this API which will handle SQM long running process specifications and also run process instances.

@Matthieu Hattab what is you opinion? Should we extend TMFC009 to also have dependency on TMF701 API?

Jan

------------------------------
Ján Krištof
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

Hello colleagues,

While I agree with Matthieu that TMFC009 – Service Qualification is not meant to "orchestrate any upgrade activities at the customer site", I'd like to add that in many B2B or complex access scenarios, service qualification requires orchestration of feasibility-related actions. These are often not service activation steps, but investigations to determine what can be offered, such as:

• Verifying line-of-sight to a microwave base station;
• Checking land ownership and maps for trenching fiber;
• Technical surveys or civil constraints for enterprise connectivity.

This probably goes beyond the intent of TMF645 (Service Qualification API) and TMFC009 (Service Qualification component), which are IMHO designed to evaluate availability based on known data.

The approach might be:

1. A Service Order (TMF641) is created for a Feasibility Survey.
2. Field work is coordinated using Work Order (TMF697) to assign and track technician activities.
3. Results are stored in the Service Inventory (TMF638), where a placeholder service instance can be in state feasibilityChecked, which si pre-defined by the API.
4. Service Qualification (TMF645) can then reference this inventory data to return accurate, context-sensitive results.

This flow avoids overloading the qualification APIs with orchestration logic, while keeping feasibility workflows consistent with the ODA principles (?).

Curious how others handle such site-dependent service qualification in OSS/BSS implementations.

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

Original Message:
Sent: Apr 28, 2025 05:24
From: Ján Krištof
Subject: TMF645 for Complex Long-Running Service Qualification Process

Hi,

I understand you questions. When I see TMF645 API, it's designed for instant response or for long running process, but TMFC009 is imho designed only for instant reply. So I also see the gap there.

I dont think, that call to TMFC061 WOM is sufficient, I think process is more complex and it's similiar to SOM (we have implemented it in the past as simlified service order). So question here is what component is responsible for this process (if not TMFC009) and how to triger it? And I suggest to check if TMF701 API suits you and implement call from TMFC009 to some newcomponent using this API which will handle SQM long running process specifications and also run process instances.

@Matthieu Hattab what is you opinion? Should we extend TMFC009 to also have dependency on TMF701 API?

Jan

------------------------------
Ján Krištof
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------