Open APIs

We are looking into way to Suspend a Service (either because it's customer initiated, like seasonal suspension, or for non-payment)

What we've noticed so far:

• ServiceOrderItem.action enumeration are: add, modify, delete, noChange.
  • In our current implementation, we are following 2 behaviours:
    • In some cases, we use ServiceOrderItem. action like a "Suspend" or "Resume", in addition to "add", "modify", "delete"...
    • In other cases, because we need to keep track of the suspension reason, we use ServiceOrderItem.action "modify", and Add a Suspension "Configuration" under the Service. the Suspension Configuration contains a SuspensionReason chraracteristic where we carry values like "Seasonal" or "Non-Payment" 
  • We concluded that suspension/resume are not handled via the  ServiceOrderItem.action

• ServiceRestriction.state enumeration are: feasibilityChecked, designed, reserved, inactive, active, terminated.
  • We assume that the suspend action would be a PATCH operation where service.state = 'inactive'
  • Similarly, the resume action would be a PATCH operation where service.state = 'active'

Is our understanding of handling Suspension correct?


------------------------------
Stephane AH-KO
CGI
------------------------------

Since the service lifecycle states are extensible, we added as "Suspended" state.   The standard isn't very clear but the state values are defined as "such as" meaning they are examples and not a defined, fixed list.   (I've opened Jira tickets on the wording so hopefully its clearer in the future).

The reason for a new state versus overloading "inactive" was to keep the definition of inactive as ready to activate (all resources allocated and ready*).   Depending on the reason and/or length of a suspension, some resources may be allocated to the suspended service (e.g., phone number) and other freed (reserved capacity).

There's always a trade off between adding a state and overloading existing ones.   We tried to have a clear status of the resources for each of the states and that drove creating a new state.    

*Our definition of "ready" would include things like VNFs that could be spun up when the service was made active, they didn't have to be running in the inactive state but all resources have to be able to be active in a short time frame (minutes or less).

------------------------------
Corey Clinger
Network as a Service Architect
Telstra
------------------------------

@Ludovic Robert, the domain expert for Service Ordering, is probably the best person to give an answer.
Your analysis seems reasonable. The question is whether the suspend reason should be part of the Service inventory, or rather would be better managed in the Product inventory (which is more likely to be exposed to the end ​customer).

------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------

Hello

We had same approach than @Corey Clinger and adding a suspended status (reacheable from inactive or active service status). The user cannot uses a suspended service and depending on the service we could suspend/inactive also some associated resource(s).

In order to suspend a service, from my perspective it it possible to do this:

• via a service order with a action change and a serviceState valued to 'suspended',
• via activation & configuration via a PATCH service to directly modify the service state,

Choice depends on your API architecture implementation but from API perspective both are valid for me.

Technically Service inventory API could be also use but it more for admin resason (to fix the installe base representation) but not to trigger operational suspension in the network.
Ludovic
​

------------------------------
Ludovic Robert
Orange
------------------------------

Original Message:
Sent: May 19, 2019 05:25
From: Jonathan Goldberg
Subject: TMF641 - How to Suspend a Service?

@Ludovic Robert, the domain expert for Service Ordering, is probably the best person to give an answer.
Your analysis seems reasonable. The question is whether the suspend reason should be part of the Service inventory, or rather would be better managed in the Product inventory (which is more likely to be exposed to the end ​customer).

------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------

I have a different view of suspension and have implemented it as such in a number of cases.

In many cases suspension is not a use case that disables a service. For voice services very often emergency calls and calls to customer care are still permitted. For data packages sometimes a reduced bandwidth is still available. Some countries have regulations that Free-to-Air TV channels should not be removed.

Therefore an "depended" suspension service is defined that modifies the properties of the base service.
The suspension use case becomes adding an optional service; the resuming use case is the removal of this service.

This way of modeling allows a very fine grained catalog based definition of what needs to happen in case of suspension and no additional states are required for services.

Regards

------------------------------
Koen Peeters
Ciminko Luxembourg
------------------------------

Original Message:
Sent: May 19, 2019 05:25
From: Jonathan Goldberg
Subject: TMF641 - How to Suspend a Service?

@Ludovic Robert, the domain expert for Service Ordering, is probably the best person to give an answer.
Your analysis seems reasonable. The question is whether the suspend reason should be part of the Service inventory, or rather would be better managed in the Product inventory (which is more likely to be exposed to the end ​customer).

------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------

Thanks all for your inputs

@Koen Peeters. We had a similar view for our Voice Service, where in our case, instead of adding a new "suspension" service, we added a "suspension" feature that could be added or removed under the Voice Service. The approach did not have lots of supporters...

We are now looking into using the service state. We were looking into extended the service.enumeration to "suspended" state. Thanks @Corey Clinger and ​​​@Ludovic Robert confirming the direction taken in your respective organizations.

------------------------------
Stephane AH-KO
CGI Info Systems Management Consulting Inc.
------------------------------

Original Message:
Sent: May 20, 2019 03:50
From: Koen Peeters
Subject: TMF641 - How to Suspend a Service?

I have a different view of suspension and have implemented it as such in a number of cases.

In many cases suspension is not a use case that disables a service. For voice services very often emergency calls and calls to customer care are still permitted. For data packages sometimes a reduced bandwidth is still available. Some countries have regulations that Free-to-Air TV channels should not be removed.

Therefore an "depended" suspension service is defined that modifies the properties of the base service.
The suspension use case becomes adding an optional service; the resuming use case is the removal of this service.

This way of modeling allows a very fine grained catalog based definition of what needs to happen in case of suspension and no additional states are required for services.

Regards

------------------------------
Koen Peeters
Ciminko Luxembourg
------------------------------


Original Message:
Sent: May 19, 2019 05:25
From: Jonathan Goldberg
Subject: TMF641 - How to Suspend a Service?

@Ludovic Robert, the domain expert for Service Ordering, is probably the best person to give an answer.
Your analysis seems reasonable. The question is whether the suspend reason should be part of the Service inventory, or rather would be better managed in the Product inventory (which is more likely to be exposed to the end ​customer).

------------------------------
Jonathan Goldberg
Amdocs Management Limited

------Original Message------

Thanks all for your inputs

@Koen Peeters. We had a similar view for our Voice Service, where in our case, instead of adding a new "suspension" service, we added a "suspension" feature that could be added or removed under the Voice Service. The approach did not have lots of supporters...

We are now looking into using the service state. We were looking into extended the service.enumeration to "suspended" state. Thanks @Corey Clinger and ​​​@Ludovic Robert confirming the direction taken in your respective organizations.

------------------------------
Stephane AH-KO
CGI Info Systems Management Consulting Inc.
------------------------------

In one of my projects, there is a special requirement with regard to suspension of service:
aggregate suspension days allowed < max suspension days allowed. Customer is allowed to suspend/resume services many times as long as the aggregate suspension days (customer value) < max suspension days allowed (system value).
@Koen Peeters, adding a suspension service (entity, not characteristics) help the team to resolve the issue. It is similar to your solution, which can handle complex/unexpected use cases.
It involves updating billing system, triggering provision and activation and updating product and service inventory.​​ It is aligned with product/service catalog well enough. 

Harry Chen
Hansen Technologies


------------------------------
Harry Chen
Hansen Technologies
------------------------------

Original Message:
Sent: May 22, 2019 05:03
From: Koen Peeters
Subject: TMF641 - How to Suspend a Service?

Hi Stephane,

I would like to add one more remark to the discussion.

In our experience using a "suspended" status on the status, does not work very well with catalog driven fulfilment.

That was an additional reason for not using it.

Regards

Koen Peeters

koen.peeters@ciminko.lu

Original Message------

Thanks all for your inputs

@Koen Peeters. We had a similar view for our Voice Service, where in our case, instead of adding a new "suspension" service, we added a "suspension" feature that could be added or removed under the Voice Service. The approach did not have lots of supporters...

We are now looking into using the service state. We were looking into extended the service.enumeration to "suspended" state. Thanks @Corey Clinger and ​​​@Ludovic Robert confirming the direction taken in your respective organizations.

------------------------------
Stephane AH-KO
CGI Info Systems Management Consulting Inc.
------------------------------

Hello
For me if the suspension has impact on the billing system and/or need some commercial rule checked (like number of suspended day/year) it needs to clearly defined as productSpecification/productOffering. We must have a product specification Mobile Line and another one Suspend Mobile Line. Each of them sold through a dedicated product offering. All commercial rules/price handled by them. I keep them in my product inventory.
Then, after at Service level, I'm not sure if it changes a lot to have 2 dedicated serviceSpecification . Of course, we can, and it should work, but if both productSpecification are derived from same mobile line Service Specification I guess it work as well no? And I will not multiply my service specification catalog. For me the capability for a mobile line to be suspended is a capability of the mobile line itself, not to something else. Perhaps some service doesn't have this capability.

My service will be suspended till the product Suspended is active.


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

Original Message:
Sent: Oct 07, 2021 05:26
From: Harry Chen
Subject: TMF641 - How to Suspend a Service?

In one of my projects, there is a special requirement with regard to suspension of service:
aggregate suspension days allowed < max suspension days allowed. Customer is allowed to suspend/resume services many times as long as the aggregate suspension days (customer value) < max suspension days allowed (system value).
@Koen Peeters, adding a suspension service (entity, not characteristics) help the team to resolve the issue. It is similar to your solution, which can handle complex/unexpected use cases.
It involves updating billing system, triggering provision and activation and updating product and service inventory.​​ It is aligned with product/service catalog well enough.

Harry Chen
Hansen Technologies


------------------------------
Harry Chen
Hansen Technologies
------------------------------


Original Message:
Sent: May 22, 2019 05:03
From: Koen Peeters
Subject: TMF641 - How to Suspend a Service?

Hi Stephane,

I would like to add one more remark to the discussion.

In our experience using a "suspended" status on the status, does not work very well with catalog driven fulfilment.

That was an additional reason for not using it.

Regards

Koen Peeters

koen.peeters@ciminko.lu

Original Message------

Thanks all for your inputs

@Koen Peeters. We had a similar view for our Voice Service, where in our case, instead of adding a new "suspension" service, we added a "suspension" feature that could be added or removed under the Voice Service. The approach did not have lots of supporters...

We are now looking into using the service state. We were looking into extended the service.enumeration to "suspended" state. Thanks @Corey Clinger and ​​​@Ludovic Robert confirming the direction taken in your respective organizations.

------------------------------
Stephane AH-KO
CGI Info Systems Management Consulting Inc.
------------------------------

Hi all,

there are many different views on suspensions - so let me add my view on it.
We model a suspension not as just a state of a product or service but instead as a separate resource which references a product or a service. So it has an own id, an own lifecycle etc. and points to a product/service.

The advantages of this approach are:

• one can add further suspension related information into this resource like
  • suspension type (e.g. full or partly)
  • suspension reason (e.g. payment issue, abuse or volluntary)
  • suspension initiator (e.g. customer or operator)
• a suspension is not part of the lifecycle of a product/service itself - hence a customer cannot nullify an operator initiated suspension by simmply deleting and re-booking the product which was suspended
• one can manage different suspensions at the same time (e.g. a customer initiated voluntary suspension together with an operator determined suspension because of payment issues) - resuming the customer initiated suspension would hence not automatically cancel the operator determined suspension 

The processing of setting/removing a suspension would have to take other potential suspensions into account and typically lead to a service state "suspended".

Regards
Thomas

------------------------------
Thomas Dupré
Deutsche Telekom AG
------------------------------

Original Message:
Sent: Oct 07, 2021 11:11
From: Ludovic Robert
Subject: TMF641 - How to Suspend a Service?

Hello
For me if the suspension has impact on the billing system and/or need some commercial rule checked (like number of suspended day/year) it needs to clearly defined as productSpecification/productOffering. We must have a product specification Mobile Line and another one Suspend Mobile Line. Each of them sold through a dedicated product offering. All commercial rules/price handled by them. I keep them in my product inventory.
Then, after at Service level, I'm not sure if it changes a lot to have 2 dedicated serviceSpecification . Of course, we can, and it should work, but if both productSpecification are derived from same mobile line Service Specification I guess it work as well no? And I will not multiply my service specification catalog. For me the capability for a mobile line to be suspended is a capability of the mobile line itself, not to something else. Perhaps some service doesn't have this capability.

My service will be suspended till the product Suspended is active.


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


Original Message:
Sent: Oct 07, 2021 05:26
From: Harry Chen
Subject: TMF641 - How to Suspend a Service?

In one of my projects, there is a special requirement with regard to suspension of service:
aggregate suspension days allowed < max suspension days allowed. Customer is allowed to suspend/resume services many times as long as the aggregate suspension days (customer value) < max suspension days allowed (system value).
@Koen Peeters, adding a suspension service (entity, not characteristics) help the team to resolve the issue. It is similar to your solution, which can handle complex/unexpected use cases.
It involves updating billing system, triggering provision and activation and updating product and service inventory.​​ It is aligned with product/service catalog well enough.

Harry Chen
Hansen Technologies


------------------------------
Harry Chen
Hansen Technologies


Original Message:
Sent: May 22, 2019 05:03
From: Koen Peeters
Subject: TMF641 - How to Suspend a Service?

Hi Stephane,

I would like to add one more remark to the discussion.

In our experience using a "suspended" status on the status, does not work very well with catalog driven fulfilment.

That was an additional reason for not using it.

Regards

Koen Peeters

koen.peeters@ciminko.lu

Original Message------

Thanks all for your inputs

@Koen Peeters. We had a similar view for our Voice Service, where in our case, instead of adding a new "suspension" service, we added a "suspension" feature that could be added or removed under the Voice Service. The approach did not have lots of supporters...

We are now looking into using the service state. We were looking into extended the service.enumeration to "suspended" state. Thanks @Corey Clinger and ​​​@Ludovic Robert confirming the direction taken in your respective organizations.

------------------------------
Stephane AH-KO
CGI Info Systems Management Consulting Inc.
------------------------------

The scenarios for Customer initiated suspension nd operator initiated suspension need to be handled separately.
For voluntary suspension, the ServiceOrdertime. action neds to be used by extending actions with values like SUSPEND, RESUME etc
For Involuntary Suspension, Service Restriction.state needs to be used

------------------------------
Sri Jagadish Baddukonda
Principal Consultant
Sigma Systems
------------------------------

Hi Stephane,

The action may continue to serve the suspension and resumption by way of adding and removing addon products with or without ​any commercial implications. However these can translate to resource facing services that suspend one or more services or resume the same. Some data models of some mature telco's employ innovative solutions using OO concepts.
Regards
Surojit

------------------------------
Surojit Mukerji
Enterprise Architect
------------------------------