Thanks, that makes perfect sense.
We're seeing exactly that balance, using sync checks for standard slice types and exploring async for more complex scenarios where real-time validation is needed.
Original Message:
Sent: Jun 11, 2025 03:14
From: Peter Eksteen
Subject: TMF645 checkAvailability in 5G Slicing – Catalog vs Real-Time Feasibility?
Hi Juan,
You have it correct. The decision about whether it should be synchronous (checkServiceQualification) vs asynchronous (queryServiceQualification) is determined largely by the complexity, and deciding which is also determined by how 'near-real-time' you need a response.
Obviously from CPQ/Product Order Management you might want synchronous in order to give an immediate response to the CSR or customer, whereas in other scenarios asynchronous might be needed because the process to qualify is complex.
Of course you will probably run into situations where you need a rapid response, but the qualification takes time - in those cases you will need to engineer out solutions that either pre-qualify, or change the process on the front-end to accommodate a long-running qualification process.
Good luck!
------------------------------
Peter Eksteen
Senior Advisor, Product Line Management
CIENA Blue Planet
Original Message:
Sent: Jun 10, 2025 12:20
From: Juan Casanovas
Subject: TMF645 checkAvailability in 5G Slicing – Catalog vs Real-Time Feasibility?
Hi Peter,
Thanks for the thoughtful explanation, I found it very insightful.
Today, I had a recent discussion with some members of our internal team (@Peter Bruun) , and we double-checked this against the TMF645 specification and TMFS014 (5G Slice Management Use Case). We came across the following understanding, which I believe is perfectly aligned with your comment:
Operation names in TMF645, defines two operations:
- checkServiceQualification
- This operation initiates a qualification request.
- It can be used in:
- Synchronous mode (200 OK): when feasibility is based on static data like product models, catalog entries, coverage rules, or business policies.
- Asynchronous mode (202 Accepted): when the check involves real-time feasibility, such as querying OSS/BSS systems, resource inventories, or domain-specific orchestrators (e.g., NSMF/NSSMF in 5G slicing).
- queryServiceQualification
- This is a GET to /serviceQualification/{id}
- It is used to retrieve the result of a previously submitted (typically asynchronous) request.
- It does not initiate a new feasibility check.
We believe now that the split between synchronous and asynchronous mode should be based on the depth and data source of the feasibility (as long as semantics remain consistent between both):
- High-level feasibility (e.g., product model, service templates, location eligibility) → synchronous checkServiceQualification
- Low-level, real-time feasibility (e.g., cross-domain slice orchestration, current resource availability) → asynchronous checkServiceQualification, with result retrieved via queryServiceQualification
We believe that this model maps well to slicing workflows in TMFS014. In fact, section 4.4 highlights that feasibility may require cross-domain validation (e.g., RAN, Core, Transport), which clearly justifies the need for low-level runtime evaluation.
Any comment :D?
Thanks again!
------------------------------
Juan Casanovas
Hewlett Packard Enterprise
Original Message:
Sent: Jun 10, 2025 07:21
From: Peter Eksteen
Subject: TMF645 checkAvailability in 5G Slicing – Catalog vs Real-Time Feasibility?
Hi Juan,
As is almost always the case - the answer to you Catalog vs Real Time feasibility is YES.
We see scenarios where you do simple catalog feasibility (can I configure the product with these parameters) where the the catalog provides sufficient information to make those decisions - although these may also involve inventory/geography checks.
We also see scenarios where more extensive service feasibility / qualification needs to be done. These can range from checking design options for the service, to far more complex scenarios where you might schedule a site visit before you can tell the customer the order is possible.
The simpler scenario is almost certainly a checkServiceQualification use case, where as the more complex ones are typically queryServiceQualification.
I see TMF645 being invoked from a variety of systems too.
It is not uncommon for CPQ to call TMF645 - especially in consumer, simpler service scenarios, although even in complex Enterprise services calls to TMF645 may be required.
As to when Service Order Management systems may call TMF645 - that is certainly possible if the CSP starts the service lifecycle very early (common in cases where there is really no choice BUT to deliver the service) - and might take the service through a created->feasibility checked->designed->active lifecycle in SOM. In these scenarios SOM can make use of TMF645 calls (often more than 1) to determine the feasibility of the service components for the service.
When we apply these to the 5G space - to your questions on static, policy, coverage etc. we can see that there are a multitude of decisions to be taken about order capture and order fulfilment that will guide you towards one approach or the other (synchronous checkServiceQualification vs asynchronous queryServiceQualification) in each scenario.
Hope that helps
------------------------------
Peter Eksteen
Senior Advisor, Product Line Management
CIENA Blue Planet
Original Message:
Sent: Jun 09, 2025 07:06
From: Juan Casanovas
Subject: TMF645 checkAvailability in 5G Slicing – Catalog vs Real-Time Feasibility?
Hi API experts,
I'm bringing into this space a topic originally discussed in the TM Forum Community that received helpful input and touched on key architectural decisions involving TMF645 (Service Qualification API), specifically in the context of 5G Network Slicing.
The question is when using the checkAvailability operation in TMF645 for 5G slicing:
- Is checkAvailability intended to perform real-time, low-level feasibility checks (e.g., RAN/Core domain resource evaluation via NSMF/NSSMF), or is it generally meant for high-level catalog/policy-based eligibility assessments?
- > _"It may be necessary for the Quantitative and Qualitative analysis algorithm to cross-check the slice profile corresponding to the core slice subnet with the slice profile for the RAN and Transport domain."_ in the (Section 4.4)
- which I think it might imply dynamic low-level runtime validation via NSMF → NSSMF.
- If it is intended for low-level feasibility:
- Should the response be synchronous and catalog-driven, relying on static service type, policy rules, or coverage data (e.g., "URLLC is generally supported in Zone A")? Or is it acceptable (or even expected) for the same API call to trigger asynchronous, low-level feasibility checks via NSMF/NSSMF and resource-level status?
- Use synchronous (200 OK) when the qualification is fast and catalog-based.
- Use asynchronous (202 Accepted) when real-time OSS/domain orchestration is required.
- Is it architecturally sound for TMF645 to behave differently (sync vs async) depending on backend complexity, as long as semantics remain consistent?
BTW Interestingly, TMFS014 shows TMF641 invoked before feasibility, supporting an intent-based ordering pattern where TMF645 (or equivalent) may be called during order processing.
I'd love input from the API community on how best guide this dual-mode use of TMF645 in slicing contexts, or whether it suggests a need for clearer separation of responsibilities.
Thanks in advance!
------------------------------
Juan Casanovas
Hewlett Packard Enterprise
------------------------------