Open APIs

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.
------------------------------

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
------------------------------

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
------------------------------

Original Message:
Sent: Mar 04, 2022 12:07
From: Ludovic Robert
Subject: TMF645 - query based on existing service

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
------------------------------

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
------------------------------

Original Message:
Sent: Mar 05, 2022 12:59
From: Derrick Evans
Subject: TMF645 - query based on existing service

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
------------------------------


Original Message:
Sent: Mar 04, 2022 12:07
From: Ludovic Robert
Subject: TMF645 - query based on existing service

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

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.
------------------------------

Original Message:
Sent: Mar 04, 2022 12:07
From: Ludovic Robert
Subject: TMF645 - query based on existing service

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
------------------------------

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
------------------------------

Original Message:
Sent: Mar 07, 2022 09:23
From: Ján Krištof
Subject: TMF645 - query based on existing service

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.
------------------------------


Original Message:
Sent: Mar 04, 2022 12:07
From: Ludovic Robert
Subject: TMF645 - query based on existing service

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

Hi Koen,

thank you very much for sharing. Very helpful.

Jan

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

Original Message:
Sent: Mar 07, 2022 09:42
From: Koen Peeters
Subject: TMF645 - query based on existing service

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
------------------------------


Original Message:
Sent: Mar 07, 2022 09:23
From: Ján Krištof
Subject: TMF645 - query based on existing service

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.


Original Message:
Sent: Mar 04, 2022 12:07
From: Ludovic Robert
Subject: TMF645 - query based on existing service

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

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
------------------------------

Original Message:
Sent: Mar 08, 2022 01:50
From: Ján Krištof
Subject: TMF645 - query based on existing service

Hi Koen,

thank you very much for sharing. Very helpful.

Jan

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


Original Message:
Sent: Mar 07, 2022 09:42
From: Koen Peeters
Subject: TMF645 - query based on existing service

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


Original Message:
Sent: Mar 07, 2022 09:23
From: Ján Krištof
Subject: TMF645 - query based on existing service

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.


Original Message:
Sent: Mar 04, 2022 12:07
From: Ludovic Robert
Subject: TMF645 - query based on existing service

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