Open APIs

 View Only
  • 1.  TMF645 - Check Service Qualification - Multiple Services & Relations

    TM Forum Member
    Posted Mar 31, 2022 10:20
    Edited by Marlon Almazan Mar 31, 2022 12:44
    Hi all,

    I am looking into some scenarios for Check Service Qualification.
    In a specific use-case, we might have a scenario where the CSP wants to check qualification for a "combo" of services, for instance:
    • Scenario 1: Service1+Service2 where
      • Service1 = Voice service
      • Service2 = Data service
    • Scenario 2: Service1+Service2 where
      • Service1 = Data service (e.g. 500Mbps)
      • Service2 = Data service (e.g. 200Mbps)

    While the API v4.0.1 does seem to support multiple item entries inside "serviceQualificationItem", it does not have examples or comment how these might be handled during the qualification logic... for example, the server processing the request might understand that maybe for "Scenario 2", it can provide "Service 1" and it can provide "Service 2" since there resources for each of them... but maybe not possible to provide BOTH of them simultaneously since there are no resources available for providing the two data services (maybe the end user associated port interface is able to provide only 250Mbps of bandwitdh).

    I wonder if some relationship parameter could indicate if the items inside serviceQualificationItem could indicate if the evaluation must be an "AND" condition (where both items are required to be evaluated as simultaneous service) or a "OR" condition (where CSP is interested in determining qualification for each of them, but not both at the same time... end-user wants a 500Mbps service OR 200Mbps service).

    Really appreciate the experts opinion on this!

    Thanks and Br,

    Juliano Sugavara
    OSS Architect

  • 2.  RE: TMF645 - Check Service Qualification - Multiple Services & Relations

    TM Forum Member
    Posted Apr 01, 2022 09:32
    Hello Juliano

    For my perspective it is the itemRelationship (or serviceRelationship) that allow you to build the 'combo'. If you want to qualify several interconnect service you should have some relationship within them.
    In your case perhaps you have a third item for a mobile access and both Data and voice service relates to this mobile access?

    If you pass a CheckServiceQualification with
    CheckServiceQualificationItem1 - Mobile Access id=65xxxxx
    CheckServiceQualificationItem2 - Data service - itemRelationship : Requires #1
    CheckServiceQualificationItem3 - Voice service - itemRelationship : Requires #1

    Your back end could 'undersand' the grouping and the fact that you want both the voice & date on mobile access 65xxxx

    Hope it helps


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

  • 3.  RE: TMF645 - Check Service Qualification - Multiple Services & Relations

    TM Forum Member
    Posted Oct 27, 2023 07:36

    Hi All,

    I have a related question on this subject which is similar to the above but a slightly different. In the example above i understand it to be looking for additional services over the top of a service existing in the inventory.

    In our Case we have the following scenarios: -

    Fibre Access Services

    Data (broadband etc)


    There can be any combination of these but this is about providing the availability for a particular address and not based on anything currently in the inventory. So i was trying to understand if the question to service qualification is 'tell me what i can have at this address'. Here the client does not have a specific ask so will not want to pre-populate multiple line items in the checkservicequalification request so how that would be most appropriately modelled in the checkservicequalification response? we could essentially have...

    Request - here's my address

    Response - 

    1. Broadband Option 1 (Broadband Basic Specification) Depends on Fibre Access Basic OR Copper Access specification
    2. Broadband Option 2 (Broadband Basic Specification) Depends on Fibre Access Basic OR Copper Access specification
    3. Broadband Option 3 (Broadband Standard Specification) Depends on Fibre Access Standard
    4. VOIP Standalone (depends on nothing)
    5. Landline VOIP depends on (1 or 2)

    We actually have a lot more combinations than this but it just gives a flavour of how this becomes quite expansive and I cant really see how this link of one specification to another is meant to fit in so the caller knows that if they order a service with a broadband specification they would need to also order a service with a fibre access service (for example)

    I did consider that the response could have 'lots' of serviceQualificationItem added to the response to model all of the 'top level' CFS options but then looking inside this I considered that the: - 

    1. CheckServiceQualificationItem.service.relatedEntity felt like too generic and this wasn't the place for the other specifications to be modelled
    2. CheckServiceQualificationItem.service.serviceRelationship this is linking to things already in the inventory and there is nothing in the inventory at this point
    3. CheckServiceQualificationItem.service.supportingService this looked like the best option however its description suggests its to link CFS to RFS and this isnt the case in this situation as its CFS --> CFS.

    My concern here was also that within the supportingService containers across all of the top level qualification items  for example the Fibre Access Basic would be repeated many times even though it would essentially be the same information.

    Hope someone might have had a similar challenge or has some thoughts on how this is best modelled



    David Whitfield
    TalkTalk Group