Open APIs

 View Only
  • 1.  TMF 645 future dating of service qualification requests

    TM Forum Member
    Posted 18 days ago
    Hi TMF 645 experts,
    I am looking for a service qualification feature which checks the feasibility/eligibility or alternative option for a given service at a future date AND a future period of time. This use case may be relevant e.g. for providing temporary IP-VPN services requiring a certain QoS, Bandwidth etc...

    What I find in the swagger definition is:

    CheckServiceQualificationItem sub-resource

    A ServiceQualificationItem relates to a specific service being checked in a qualification operation.

    expectedActivationDate A date time (DateTime). The date when the service is expected to be activated.

    expectedServiceAvailabilityDate A date time (DateTime). Date when the requester looks for service availability.

    expirationDate A date time (DateTime). Date when the qualification item response expires

    So there is a clearly defined start time for the requested availablity, i.e. "expectedActivationDate", "expectedServiceAvailabilityDate" and a time how long the response is valid "expirationDate". How would you formulate a service qualitication request which has an expected deactivation date as well when the service may become unavailable again?

    thanks for your guidance
    roland



    ------------------------------
    roland Werding
    Deutsche Telekom AG
    ------------------------------


  • 2.  RE: TMF 645 future dating of service qualification requests

    TM Forum Member
    Posted 17 days ago
    Hello Roland
    This is an interesting case, and I do not think that current model as it supports it.
    I see 2 ways to handle it:
    1. Add another date attribute like expectedDeactivationDate
    2. Replace expectedActivationDate with expectedActivationPeriod and define it with a startDate/endDate attributes
    I have a preference for the second option (it seems to me 'cleaner'), but it implies some API change - the first option is probably easier to implement and do no break API compliance.

    Hope it helps
    Ludovic

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



  • 3.  RE: TMF 645 future dating of service qualification requests

    Posted 16 days ago
    Hello Both,
    An interesting topic which I believes needs a wider discussion to cover a variety of use cases. which possibly apply to the product qualification API as well as the service qualification API.
    The original question posed I believe relates to temporary technical solutions which may then be replaced at some time in the future and therefore already have an end date planned?

    An example I have seen in the UK is the use of radio access to premises for a private circuit as a temporary measure prior to installing fibre.
    In this case however the service can stay in place as long as is needed until the replacement arrangement is available. In this case there is no need to specify the end date in advance.
    All that happens is in the product order the customer can say whether temporary radio access is acceptable as a means of getting the circuit in on time.

    Another example is where the product itself is planned to have a short lifetime where the termination date is planned in from the beginning. So temporary special coverage with mobile base stations for concerts or outside broadcast circuits for sports events are two examples I can think of. The need to specify the anticipated deactivation date is to check terms and conditions on pricing but also to assist planners in deciding how to fulfil the requirement. The specification of a period is valid here because one knows the start and the end and this might affect feasibility.

    But the third example I can think of relates to the closure of networks and the migration/termination of services on them that have been there for some time. This involves adding expected deactivation dates retrospectively to already activated services and stating when it is no longer possible to activate new services in specific locations.

    For example in the UK BT/Openreach intend to stop selling PSTN/ISDN services generally from 2023 and close the relevant networks in 2025 and have indeed already issued "Stop Sell" notices for specific locations. Note because of this product qualification for BT includes saying this offering is no longer available for new product orders in this specific location from a particular date and into the future.

    In this third case  one is adding a planned termination date to a service long after it was activated as well as saying anything new has a planned end date.

    So I agree that there is something to be added here but I suspect it has to be done with reference to the product qualification API as well as the service qualification API and should cover the range of scenarios above?


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



  • 4.  RE: TMF 645 future dating of service qualification requests

    TM Forum Member
    Posted 15 days ago
    Hi,

    For many service providers the idea that service can have a pre-determined termination is not very common.
    Never the less is scenario presented by Roland is actually part of normal business for service providers that offer temporary services. It is also quite common in case of services that rely on scarce resources such as radio spectrum for microwave links or satellite capacity.
    The same resource can be used for new services offered to new prospects after the termination date.

    I suggest the use of an extra attribute like suggested by @Ludovic Robert as option 1.
    In our implementation we have named the date attribute expectedTerminationDate; the name was choosen to be in line with the state diagram of service in TMF638.
    Is it not a good idea to create a jira ticket to add this attribute for a next release?

    Regards




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



  • 5.  RE: TMF 645 future dating of service qualification requests

    TM Forum Member
    Posted 12 days ago

    Hi all,

    thanks a lot for the responses. Yes we are thinking about defined temporary services as they will be requested by TV-stations for events....

    Br

    Roland

     






  • 6.  RE: TMF 645 future dating of service qualification requests

    TM Forum Member
    Posted 12 days ago
    Hello

    @Koen Peeters: Is it not a good idea to create a jira ticket to add this attribute for a next release?

    Yes :)
    Done : [AP-3766] Add an expectedDeactivationDate for TMF645 - TM Forum JIRA

    I've tagged also Derrick & Roland for tracking in the Jira (and copied part of Roland first post).
    Thanks

    Ludovic

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