Open APIs

 View Only
  • 1.  TMF645 - query based on existing service

    TM Forum Member
    Posted Mar 03, 2022 05:29
    Collegues,

    I have one usecase to solve, and I would appreciate your advice. We have usecase, when in QueryServiceQualification there is  "place" not defined as installation address, but "place" is defined by parameter of existing service at given place/location. For example, phone number of fix line, ServicePoindID which represent endpoint at customer location. (Get qualification based on exact service is much more precise in some case (line speed upgrade) and it's also convinient for consumer of TMF645) Question is, how to create such request (searchCriteria).

    Option 1 - use "place", use role, @type to distinquish for place defined by service parameters
    Option 2 - use "service" parameters and related objects (my worries here are, that this will act as filter and in response I will have only the same service as was defined in searchCriteria)​
    Option 3 - do you see other ways how to do it?

    Thanks

    Jan

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


  • 2.  RE: TMF645 - query based on existing service

    TM Forum Member
    Posted Mar 04, 2022 12:07
    Hello Ján 
    Humm not easy. 
    For me your intend is to provide a 'where' and to do that you provide an indirect information. So I will stick to place use and I will probably opt for your first option with a 'specific' @type like 'resourceLocation'.
    Hope it helps

    Ludovic​

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



  • 3.  RE: TMF645 - query based on existing service

    Posted Mar 05, 2022 12:59
    Hello,
    I would tend to agree with Ludovic.

    This usecase is quite common where people trust the records of a customers phone number more than having an alignment of the geographic address between customer and CSP.

    Postal addresses can change or a customer may have a different view of  their address as opposed to what is recorded (due to change of use of premises or reorganisation of post codes).
    Also when people are ordering services for a premises they are moving to, a phone number might be more reliable than their knowledge of their soon to be new address.

    However, with the growth of VoIP services, associations of phone numbers with locations is becoming something which will be less reliable.

    So what is the API actually specified to support in this case?
    I have read the specification a few times and some of the descriptions are a bit obscure.

    From past experience I see the following usecases.

    1) Provide some form of geographic location as a statement of the place for the intended installation and query what can be installed there or check whether a particular service can be installed.
    2) Provide the identity of an existing service and query what upgrades or replacements are available or whether a particular upgrade can be done to that service.
    3) Provide the identity of an existing service as a proxy for a geographic location (like a working telephone number that also happens to be in the proposed installation location) and then ask what can be provided in the same building (a second line or something unconnected at all with the serviced referenced) alongside that service as an addition.
    4) Provide identity of an existing service as a proxy for a network termination point, copper line or physical fibre and ask what other services can sit on that physical infrastructure alongside the services already provided (like install VDSL/ADSL on a copper pair identified by its working phone number).

    The important thing is to make sure the correct roles associated with the correct attributes   so one does not mistake install new infrastructure for upgrade/extend existing infrastructure etc.

    I think that is  perhaps a worthwhile thing to make explicit in the specification at some time in the  future.

    ------------------------------
    Derrick Evans
    ------------------------------



  • 4.  RE: TMF645 - query based on existing service

    TM Forum Member
    Posted Mar 07, 2022 03:32
    Hello Derrick
    This is 4 valuables UCs and it would make sense to have payload examples for each one. Some time ago we discussed internally to the API team to be able to let the community (or the team) to provided JSON examples to showcase how UC could be managed by the TMF open API. Probably a good idea to reopen this discussion and TMF645 is a good candidate as we have a lot of question from the community.
    Thanks

    Ludovic

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



  • 5.  RE: TMF645 - query based on existing service

    TM Forum Member
    Posted Mar 07, 2022 09:24
    Hi Ludovic,

    thanks for reply. I'm just wondering. At the end of the process, there is geographic address and service qualification based on it, but there is also other part which I mentioned briefly but it's very relevant. @Derrick Evans described it very well in his post. When customer provides service parameter, we know, that there is existing infrastructure and at first we look how we can upgrade it and in second step we get address from inventory and do qualification based on it. These two outcomes are combined and provided to consumer.​

    So, address definition is important, but also definition of existing service is also important as much. Does this change your mind how do you recommend to implement this usecase? I'm OK with option 1 but my toughts are mixed. I'm just asking. I want to implement it how it was intended.

    Jan

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



  • 6.  RE: TMF645 - query based on existing service

    TM Forum Member
    Posted Mar 07, 2022 09:43
    Hi all,

    the existing API actually permits referencing existing services. I added some sniplets of references to existing services that I have used:

    for services that use the same infrastructure (e.g. copper pair) for adding services (e.g. VDSL on pair with analogue phone service or IPTV on existing internet)
    "service": {
       "serviceRelationship" {
           "serviceRelationshipType": "reliesOn",
           "service": {
               "supportingResource": {
                   "name": "+352456378942",
                   "@ReferedType": "PhoneNumber",
                   "@Type": "ResourceRef"
               }
           }
       }
    }​

    Or for services that use other infrastructure in the same location where the service reference is only used to identify the place.

    "service": {
       "serviceRelationship" {
           "serviceRelationshipType": "collocatedWith",
           "service": {
               "supportingResource": {
                   "name": "+352456378942",
                   "@ReferedType": "PhoneNumber",
                   "@Type": "ResourceRef"
               }
           }
       }
    }​​


    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------



  • 7.  RE: TMF645 - query based on existing service

    TM Forum Member
    Posted Mar 08, 2022 01:51
    Hi Koen,

    thank you very much for sharing. Very helpful.

    Jan

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



  • 8.  RE: TMF645 - query based on existing service

    TM Forum Member
    Posted Mar 08, 2022 02:22
    Hi,
    Same than Jan !
    Thanks Koen. I like the idea to use the relationshipType as a 'discriminator'  for the resource role to identify resource role.

    Ludovic

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