Open APIs

• ServCo1 has a product P1 which is a fiber P2P access to location X and (optical) network termination point defined by UTAC1 (Universal Telecom Access Code - EAN18 format)
• For this ServCo1 (Service Operator Company 1) once submitted a B2B productOrder PO1 for this Fiber P2P access (action='add') for location X and NTP UTAC1 to the NetCo.
• To realize this the NetCo (Network Company) created an optical patch in a POP between the 'feeding' of ServCo1 and the NetCo's owned local access to the location X.

• the end customer switches to another ServCo2 for the internet service
• the ServCo2 submits to the NetCo a B2B product order PO1 for a P2P access to same location X and NTP UTAC1 on Date D
• the NetCo will plan to remove the existing patch from ServCo1
• the ServCo1 has the ability to react (approve or reject) on this scenario as his network trail/path will get broken and one or more services run on it
• in this context ServCo1 is seen as 'Donor', ServCo2 as 'Recipient'
• the scenario is to some extend similar to the number porting scenario but there is no dial number resource involved, rather a patch owned by the netCo in a POP in the network. 

1. ServCo2 submit a normal TMF622 B2B product order PO2 (action=add) for a P2P Access Product Offering at Location X, NTP UTAC1 to the NetCo.
2. The NetCo receives the product order PO2
3. The NetCo detects that there is an existing product P1 of ServCo1 active
4. The NetCo creates itself, internally a TMF622 termination product order PO3 (action=remove) similar as with a forced termination for non-payment.
5. The product P1 is put into state 'pending_termination' while waiting ServCo1 approval
6. Here there is already a first choice of solution - how to inform ServCo1 of what is happening?:
   - we could send ServCo1 a TMF622  ProductOrderStateChange event of the PO3 on its product P1, however ServCo1 is not really the creator of PO3, it is the NetCo itself - [Q1: acceptable?]
   - alternatively, we could request ServCo1 to listen to the TMF637 ProductInventory ProductStateChange events as it is his product - [Q2:better solution?]. 
7. How could the ServCo1 react? It cannot issue a product order amend or other patch on ServCo2's PO2 as has no rights to do this.
   We suggest the following:
   - or ServCo1 accepts by submitting a new termination B2B product order PO4 (action='delete') on its owned product P1
   - or ServCo1 rejects by submitting a modification B2B product order PO4 (action='noChange') on it product P1, possibly with a special reason.[Q3: acceptable/good approach?]
8. At the end:
   - or the product order PO2 of ServCo2 and internal order PO3 are fully executed (Donor accepted or did not react) 
   - or ServCo2 cancels its original product order PO2 (Donor rejected, Recipient agrees to roll-back)
   - or there is a conflicting situation between ServCo1 and ServCo2 that must be resolved probably resulting in putting all in a 'held' situation, potentially cancelling everything.

Hello,

is this a question similar to "porting" in mobile network? Mobile porting looks like what you describe:

• 1x network owner: Walhalla Networks
• 2x service operators/MVNOs: BluePeak Mobile, Aurora Mobile. Both use the same physical network provided by Walhalla Networks.

BluePeak's End Customer wants to move its services from BluePeak Mobile to Aurora Mobile.

You wrote:

•  "There are 4 parties involved"
•  "we could send ServCo1 a TMF622..."

can you say who is "we"?

I'm guessing that "we" is "Proximus". but is Proximus one of the 4 parties?

• ServCo1 has a product P1 which is a fiber P2P access to location X and (optical) network termination point defined by UTAC1 (Universal Telecom Access Code - EAN18 format)
• For this ServCo1 (Service Operator Company 1) once submitted a B2B productOrder PO1 for this Fiber P2P access (action='add') for location X and NTP UTAC1 to the NetCo.
• To realize this the NetCo (Network Company) created an optical patch in a POP between the 'feeding' of ServCo1 and the NetCo's owned local access to the location X.

• the end customer switches to another ServCo2 for the internet service
• the ServCo2 submits to the NetCo a B2B product order PO1 for a P2P access to same location X and NTP UTAC1 on Date D
• the NetCo will plan to remove the existing patch from ServCo1
• the ServCo1 has the ability to react (approve or reject) on this scenario as his network trail/path will get broken and one or more services run on it
• in this context ServCo1 is seen as 'Donor', ServCo2 as 'Recipient'
• the scenario is to some extend similar to the number porting scenario but there is no dial number resource involved, rather a patch owned by the netCo in a POP in the network. 

1. ServCo2 submit a normal TMF622 B2B product order PO2 (action=add) for a P2P Access Product Offering at Location X, NTP UTAC1 to the NetCo.
2. The NetCo receives the product order PO2
3. The NetCo detects that there is an existing product P1 of ServCo1 active
4. The NetCo creates itself, internally a TMF622 termination product order PO3 (action=remove) similar as with a forced termination for non-payment.
5. The product P1 is put into state 'pending_termination' while waiting ServCo1 approval
6. Here there is already a first choice of solution - how to inform ServCo1 of what is happening?:
   - we could send ServCo1 a TMF622  ProductOrderStateChange event of the PO3 on its product P1, however ServCo1 is not really the creator of PO3, it is the NetCo itself - [Q1: acceptable?]
   - alternatively, we could request ServCo1 to listen to the TMF637 ProductInventory ProductStateChange events as it is his product - [Q2:better solution?]. 
7. How could the ServCo1 react? It cannot issue a product order amend or other patch on ServCo2's PO2 as has no rights to do this.
   We suggest the following:
   - or ServCo1 accepts by submitting a new termination B2B product order PO4 (action='delete') on its owned product P1
   - or ServCo1 rejects by submitting a modification B2B product order PO4 (action='noChange') on it product P1, possibly with a special reason.[Q3: acceptable/good approach?]
8. At the end:
   - or the product order PO2 of ServCo2 and internal order PO3 are fully executed (Donor accepted or did not react) 
   - or ServCo2 cancels its original product order PO2 (Donor rejected, Recipient agrees to roll-back)
   - or there is a conflicting situation between ServCo1 and ServCo2 that must be resolved probably resulting in putting all in a 'held' situation, potentially cancelling everything.

Hi Matthieu,
We (Proximus) are developing a solution for our affiliate NetCo.
The 'we' in the text is effectively 'The NetCo' ( I replaced it meanwhile in the text ).
The 4th involved party is the end customer but in this scenario the end customer is only very indirectly involved in the operation.
The scenario is indeed to some extend similar to (mobile) 'porting', we need a mechanism to announce, to accept, to decline.
However, the involved resource is not the same: there is no 'resource' (MSISDN) that is owned by ServCo1 (his MSISDN range), that gets used by another ServCo2.
In our case the updated resource is a physical patch in a POP that change the E2E network trail/path and that is & stays always owned/managed by the NetCo. 
kr,
Peter

Hello,

is this a question similar to "porting" in mobile network? Mobile porting looks like what you describe:

• 1x network owner: Walhalla Networks
• 2x service operators/MVNOs: BluePeak Mobile, Aurora Mobile. Both use the same physical network provided by Walhalla Networks.

BluePeak's End Customer wants to move its services from BluePeak Mobile to Aurora Mobile.

You wrote:

•  "There are 4 parties involved"
•  "we could send ServCo1 a TMF622..."

can you say who is "we"?

I'm guessing that "we" is "Proximus". but is Proximus one of the 4 parties?

• ServCo1 has a product P1 which is a fiber P2P access to location X and (optical) network termination point defined by UTAC1 (Universal Telecom Access Code - EAN18 format)
• For this ServCo1 (Service Operator Company 1) once submitted a B2B productOrder PO1 for this Fiber P2P access (action='add') for location X and NTP UTAC1 to the NetCo.
• To realize this the NetCo (Network Company) created an optical patch in a POP between the 'feeding' of ServCo1 and the NetCo's owned local access to the location X.

• the end customer switches to another ServCo2 for the internet service
• the ServCo2 submits to the NetCo a B2B product order PO1 for a P2P access to same location X and NTP UTAC1 on Date D
• the NetCo will plan to remove the existing patch from ServCo1
• the ServCo1 has the ability to react (approve or reject) on this scenario as his network trail/path will get broken and one or more services run on it
• in this context ServCo1 is seen as 'Donor', ServCo2 as 'Recipient'
• the scenario is to some extend similar to the number porting scenario but there is no dial number resource involved, rather a patch owned by the netCo in a POP in the network. 

1. ServCo2 submit a normal TMF622 B2B product order PO2 (action=add) for a P2P Access Product Offering at Location X, NTP UTAC1 to the NetCo.
2. The NetCo receives the product order PO2
3. The NetCo detects that there is an existing product P1 of ServCo1 active
4. The NetCo creates itself, internally a TMF622 termination product order PO3 (action=remove) similar as with a forced termination for non-payment.
5. The product P1 is put into state 'pending_termination' while waiting ServCo1 approval
6. Here there is already a first choice of solution - how to inform ServCo1 of what is happening?:
   - we could send ServCo1 a TMF622  ProductOrderStateChange event of the PO3 on its product P1, however ServCo1 is not really the creator of PO3, it is the NetCo itself - [Q1: acceptable?]
   - alternatively, we could request ServCo1 to listen to the TMF637 ProductInventory ProductStateChange events as it is his product - [Q2:better solution?]. 
7. How could the ServCo1 react? It cannot issue a product order amend or other patch on ServCo2's PO2 as has no rights to do this.
   We suggest the following:
   - or ServCo1 accepts by submitting a new termination B2B product order PO4 (action='delete') on its owned product P1
   - or ServCo1 rejects by submitting a modification B2B product order PO4 (action='noChange') on it product P1, possibly with a special reason.[Q3: acceptable/good approach?]
8. At the end:
   - or the product order PO2 of ServCo2 and internal order PO3 are fully executed (Donor accepted or did not react) 
   - or ServCo2 cancels its original product order PO2 (Donor rejected, Recipient agrees to roll-back)
   - or there is a conflicting situation between ServCo1 and ServCo2 that must be resolved probably resulting in putting all in a 'held' situation, potentially cancelling everything.

The Wholesale Broadband project is looking to address the switching and takeover scenarios, see:

Use Cases for ISP Migration - Standardising Wholesale Broadband – Fibre Access (BFA) - TM Forum Confluence

If local/national regulation allows it I would suggest to "negotiate" the switching before any order is placed to the NetCo. This is my understanding of the process in the UK (One Touch Switch).

The end-customer is in charge and decides whether to switch ISP - and the donor ISP is the only party which can inform the end-customer of the consequences of switching (eg. breaking a contract, impact on other services etc.)

As a result the NetCo does not necessarily need to be involved in the process until this is resolved, they merely receive orders (add/terminate) from the involved ISPs.
(I realize this is not the process you described, but from a NetCo/Wholesaler perspective I think this is a better solution if possible)

As an additional option you could envision the gaining ISP "authorizing" the termination of the existing service (for the donor ISP), meaning the NetCo can terminate that service (without the donor ISP "approving" it - since we assume this has been previously agreed between the gaining ISP and donor ISP) 

Hi Matthieu,
We (Proximus) are developing a solution for our affiliate NetCo.
The 'we' in the text is effectively 'The NetCo' ( I replaced it meanwhile in the text ).
The 4th involved party is the end customer but in this scenario the end customer is only very indirectly involved in the operation.
The scenario is indeed to some extend similar to (mobile) 'porting', we need a mechanism to announce, to accept, to decline.
However, the involved resource is not the same: there is no 'resource' (MSISDN) that is owned by ServCo1 (his MSISDN range), that gets used by another ServCo2.
In our case the updated resource is a physical patch in a POP that change the E2E network trail/path and that is & stays always owned/managed by the NetCo. 
kr,
Peter

Hello,

is this a question similar to "porting" in mobile network? Mobile porting looks like what you describe:

• 1x network owner: Walhalla Networks
• 2x service operators/MVNOs: BluePeak Mobile, Aurora Mobile. Both use the same physical network provided by Walhalla Networks.

BluePeak's End Customer wants to move its services from BluePeak Mobile to Aurora Mobile.

You wrote:

•  "There are 4 parties involved"
•  "we could send ServCo1 a TMF622..."

can you say who is "we"?

I'm guessing that "we" is "Proximus". but is Proximus one of the 4 parties?

• ServCo1 has a product P1 which is a fiber P2P access to location X and (optical) network termination point defined by UTAC1 (Universal Telecom Access Code - EAN18 format)
• For this ServCo1 (Service Operator Company 1) once submitted a B2B productOrder PO1 for this Fiber P2P access (action='add') for location X and NTP UTAC1 to the NetCo.
• To realize this the NetCo (Network Company) created an optical patch in a POP between the 'feeding' of ServCo1 and the NetCo's owned local access to the location X.

• the end customer switches to another ServCo2 for the internet service
• the ServCo2 submits to the NetCo a B2B product order PO1 for a P2P access to same location X and NTP UTAC1 on Date D
• the NetCo will plan to remove the existing patch from ServCo1
• the ServCo1 has the ability to react (approve or reject) on this scenario as his network trail/path will get broken and one or more services run on it
• in this context ServCo1 is seen as 'Donor', ServCo2 as 'Recipient'
• the scenario is to some extend similar to the number porting scenario but there is no dial number resource involved, rather a patch owned by the netCo in a POP in the network. 

1. ServCo2 submit a normal TMF622 B2B product order PO2 (action=add) for a P2P Access Product Offering at Location X, NTP UTAC1 to the NetCo.
2. The NetCo receives the product order PO2
3. The NetCo detects that there is an existing product P1 of ServCo1 active
4. The NetCo creates itself, internally a TMF622 termination product order PO3 (action=remove) similar as with a forced termination for non-payment.
5. The product P1 is put into state 'pending_termination' while waiting ServCo1 approval
6. Here there is already a first choice of solution - how to inform ServCo1 of what is happening?:
   - we could send ServCo1 a TMF622  ProductOrderStateChange event of the PO3 on its product P1, however ServCo1 is not really the creator of PO3, it is the NetCo itself - [Q1: acceptable?]
   - alternatively, we could request ServCo1 to listen to the TMF637 ProductInventory ProductStateChange events as it is his product - [Q2:better solution?]. 
7. How could the ServCo1 react? It cannot issue a product order amend or other patch on ServCo2's PO2 as has no rights to do this.
   We suggest the following:
   - or ServCo1 accepts by submitting a new termination B2B product order PO4 (action='delete') on its owned product P1
   - or ServCo1 rejects by submitting a modification B2B product order PO4 (action='noChange') on it product P1, possibly with a special reason.[Q3: acceptable/good approach?]
8. At the end:
   - or the product order PO2 of ServCo2 and internal order PO3 are fully executed (Donor accepted or did not react) 
   - or ServCo2 cancels its original product order PO2 (Donor rejected, Recipient agrees to roll-back)
   - or there is a conflicting situation between ServCo1 and ServCo2 that must be resolved probably resulting in putting all in a 'held' situation, potentially cancelling everything.

Hi Peter,

As Kristian is mentioning, the workgroup Standarising Wholesale Broadband in TMF is defining a use case for this scenario. The first version of the document is due for publication end November

The workgroup currently already has participants from several countries (UK, Germany, Norway, ...) and we would welcome Proximus to join the team.

The negotiation is documented in the "Wholesale Line Transfer Agreement". The negotiation in the preorder stage is handled using a TMF651 Agreement API. The receiving sends an agreement to the Netco that is presigned by the enduser and the receiving ServCo. The Netco get the approval of the donor and provides feedback on the completion of the agreement.

The ProductOrder should contain reference to a reference to this agreement to be valid. The sequence diagram below is from the use case TMFS018 document that is scheduled for publication in November.

The Wholesale Broadband project is looking to address the switching and takeover scenarios, see:

Use Cases for ISP Migration - Standardising Wholesale Broadband – Fibre Access (BFA) - TM Forum Confluence

If local/national regulation allows it I would suggest to "negotiate" the switching before any order is placed to the NetCo. This is my understanding of the process in the UK (One Touch Switch).

The end-customer is in charge and decides whether to switch ISP - and the donor ISP is the only party which can inform the end-customer of the consequences of switching (eg. breaking a contract, impact on other services etc.)

As a result the NetCo does not necessarily need to be involved in the process until this is resolved, they merely receive orders (add/terminate) from the involved ISPs.
(I realize this is not the process you described, but from a NetCo/Wholesaler perspective I think this is a better solution if possible)

As an additional option you could envision the gaining ISP "authorizing" the termination of the existing service (for the donor ISP), meaning the NetCo can terminate that service (without the donor ISP "approving" it - since we assume this has been previously agreed between the gaining ISP and donor ISP) 

Hi Matthieu,
We (Proximus) are developing a solution for our affiliate NetCo.
The 'we' in the text is effectively 'The NetCo' ( I replaced it meanwhile in the text ).
The 4th involved party is the end customer but in this scenario the end customer is only very indirectly involved in the operation.
The scenario is indeed to some extend similar to (mobile) 'porting', we need a mechanism to announce, to accept, to decline.
However, the involved resource is not the same: there is no 'resource' (MSISDN) that is owned by ServCo1 (his MSISDN range), that gets used by another ServCo2.
In our case the updated resource is a physical patch in a POP that change the E2E network trail/path and that is & stays always owned/managed by the NetCo. 
kr,
Peter

Hello,

is this a question similar to "porting" in mobile network? Mobile porting looks like what you describe:

• 1x network owner: Walhalla Networks
• 2x service operators/MVNOs: BluePeak Mobile, Aurora Mobile. Both use the same physical network provided by Walhalla Networks.

BluePeak's End Customer wants to move its services from BluePeak Mobile to Aurora Mobile.

You wrote:

•  "There are 4 parties involved"
•  "we could send ServCo1 a TMF622..."

can you say who is "we"?

I'm guessing that "we" is "Proximus". but is Proximus one of the 4 parties?

• ServCo1 has a product P1 which is a fiber P2P access to location X and (optical) network termination point defined by UTAC1 (Universal Telecom Access Code - EAN18 format)
• For this ServCo1 (Service Operator Company 1) once submitted a B2B productOrder PO1 for this Fiber P2P access (action='add') for location X and NTP UTAC1 to the NetCo.
• To realize this the NetCo (Network Company) created an optical patch in a POP between the 'feeding' of ServCo1 and the NetCo's owned local access to the location X.

• the end customer switches to another ServCo2 for the internet service
• the ServCo2 submits to the NetCo a B2B product order PO1 for a P2P access to same location X and NTP UTAC1 on Date D
• the NetCo will plan to remove the existing patch from ServCo1
• the ServCo1 has the ability to react (approve or reject) on this scenario as his network trail/path will get broken and one or more services run on it
• in this context ServCo1 is seen as 'Donor', ServCo2 as 'Recipient'
• the scenario is to some extend similar to the number porting scenario but there is no dial number resource involved, rather a patch owned by the netCo in a POP in the network. 

1. ServCo2 submit a normal TMF622 B2B product order PO2 (action=add) for a P2P Access Product Offering at Location X, NTP UTAC1 to the NetCo.
2. The NetCo receives the product order PO2
3. The NetCo detects that there is an existing product P1 of ServCo1 active
4. The NetCo creates itself, internally a TMF622 termination product order PO3 (action=remove) similar as with a forced termination for non-payment.
5. The product P1 is put into state 'pending_termination' while waiting ServCo1 approval
6. Here there is already a first choice of solution - how to inform ServCo1 of what is happening?:
   - we could send ServCo1 a TMF622  ProductOrderStateChange event of the PO3 on its product P1, however ServCo1 is not really the creator of PO3, it is the NetCo itself - [Q1: acceptable?]
   - alternatively, we could request ServCo1 to listen to the TMF637 ProductInventory ProductStateChange events as it is his product - [Q2:better solution?]. 
7. How could the ServCo1 react? It cannot issue a product order amend or other patch on ServCo2's PO2 as has no rights to do this.
   We suggest the following:
   - or ServCo1 accepts by submitting a new termination B2B product order PO4 (action='delete') on its owned product P1
   - or ServCo1 rejects by submitting a modification B2B product order PO4 (action='noChange') on it product P1, possibly with a special reason.[Q3: acceptable/good approach?]
8. At the end:
   - or the product order PO2 of ServCo2 and internal order PO3 are fully executed (Donor accepted or did not react) 
   - or ServCo2 cancels its original product order PO2 (Donor rejected, Recipient agrees to roll-back)
   - or there is a conflicting situation between ServCo1 and ServCo2 that must be resolved probably resulting in putting all in a 'held' situation, potentially cancelling everything.

Koen,
Kristian,
Thanks for sharing this work. Meanwhile we discussed it also internally.
We do like your suggested approach:
- rather use upfront agreement(s) & interactions with both receiving & donating wholesale buyer towards the NetCo.
- use of the productStateChangeEvent to inform the donor (which will not have submitted the productOrder and hence cannot receive the orderStateChange events).
- use of a requestedCompletionDate which does not require - after accepted agreements - any APT booking anymore (normally).

Although we're entering a bit late in your initiative, we would be still interested in participating in the finalization of your work.
So if you can one way or the other provide also access to the full document, we are highly interested.
We have real upcoming needs & can provide additional inputs/situations.

Hi Peter,

As Kristian is mentioning, the workgroup Standarising Wholesale Broadband in TMF is defining a use case for this scenario. The first version of the document is due for publication end November

The workgroup currently already has participants from several countries (UK, Germany, Norway, ...) and we would welcome Proximus to join the team.

The negotiation is documented in the "Wholesale Line Transfer Agreement". The negotiation in the preorder stage is handled using a TMF651 Agreement API. The receiving sends an agreement to the Netco that is presigned by the enduser and the receiving ServCo. The Netco get the approval of the donor and provides feedback on the completion of the agreement.

The ProductOrder should contain reference to a reference to this agreement to be valid. The sequence diagram below is from the use case TMFS018 document that is scheduled for publication in November.

The Wholesale Broadband project is looking to address the switching and takeover scenarios, see:

Use Cases for ISP Migration - Standardising Wholesale Broadband – Fibre Access (BFA) - TM Forum Confluence

If local/national regulation allows it I would suggest to "negotiate" the switching before any order is placed to the NetCo. This is my understanding of the process in the UK (One Touch Switch).

The end-customer is in charge and decides whether to switch ISP - and the donor ISP is the only party which can inform the end-customer of the consequences of switching (eg. breaking a contract, impact on other services etc.)

As a result the NetCo does not necessarily need to be involved in the process until this is resolved, they merely receive orders (add/terminate) from the involved ISPs.
(I realize this is not the process you described, but from a NetCo/Wholesaler perspective I think this is a better solution if possible)

As an additional option you could envision the gaining ISP "authorizing" the termination of the existing service (for the donor ISP), meaning the NetCo can terminate that service (without the donor ISP "approving" it - since we assume this has been previously agreed between the gaining ISP and donor ISP) 

Hi Matthieu,
We (Proximus) are developing a solution for our affiliate NetCo.
The 'we' in the text is effectively 'The NetCo' ( I replaced it meanwhile in the text ).
The 4th involved party is the end customer but in this scenario the end customer is only very indirectly involved in the operation.
The scenario is indeed to some extend similar to (mobile) 'porting', we need a mechanism to announce, to accept, to decline.
However, the involved resource is not the same: there is no 'resource' (MSISDN) that is owned by ServCo1 (his MSISDN range), that gets used by another ServCo2.
In our case the updated resource is a physical patch in a POP that change the E2E network trail/path and that is & stays always owned/managed by the NetCo. 
kr,
Peter

Hello,

is this a question similar to "porting" in mobile network? Mobile porting looks like what you describe:

• 1x network owner: Walhalla Networks
• 2x service operators/MVNOs: BluePeak Mobile, Aurora Mobile. Both use the same physical network provided by Walhalla Networks.

BluePeak's End Customer wants to move its services from BluePeak Mobile to Aurora Mobile.

You wrote:

•  "There are 4 parties involved"
•  "we could send ServCo1 a TMF622..."

can you say who is "we"?

I'm guessing that "we" is "Proximus". but is Proximus one of the 4 parties?

• ServCo1 has a product P1 which is a fiber P2P access to location X and (optical) network termination point defined by UTAC1 (Universal Telecom Access Code - EAN18 format)
• For this ServCo1 (Service Operator Company 1) once submitted a B2B productOrder PO1 for this Fiber P2P access (action='add') for location X and NTP UTAC1 to the NetCo.
• To realize this the NetCo (Network Company) created an optical patch in a POP between the 'feeding' of ServCo1 and the NetCo's owned local access to the location X.

• the end customer switches to another ServCo2 for the internet service
• the ServCo2 submits to the NetCo a B2B product order PO1 for a P2P access to same location X and NTP UTAC1 on Date D
• the NetCo will plan to remove the existing patch from ServCo1
• the ServCo1 has the ability to react (approve or reject) on this scenario as his network trail/path will get broken and one or more services run on it
• in this context ServCo1 is seen as 'Donor', ServCo2 as 'Recipient'
• the scenario is to some extend similar to the number porting scenario but there is no dial number resource involved, rather a patch owned by the netCo in a POP in the network. 

1. ServCo2 submit a normal TMF622 B2B product order PO2 (action=add) for a P2P Access Product Offering at Location X, NTP UTAC1 to the NetCo.
2. The NetCo receives the product order PO2
3. The NetCo detects that there is an existing product P1 of ServCo1 active
4. The NetCo creates itself, internally a TMF622 termination product order PO3 (action=remove) similar as with a forced termination for non-payment.
5. The product P1 is put into state 'pending_termination' while waiting ServCo1 approval
6. Here there is already a first choice of solution - how to inform ServCo1 of what is happening?:
   - we could send ServCo1 a TMF622  ProductOrderStateChange event of the PO3 on its product P1, however ServCo1 is not really the creator of PO3, it is the NetCo itself - [Q1: acceptable?]
   - alternatively, we could request ServCo1 to listen to the TMF637 ProductInventory ProductStateChange events as it is his product - [Q2:better solution?]. 
7. How could the ServCo1 react? It cannot issue a product order amend or other patch on ServCo2's PO2 as has no rights to do this.
   We suggest the following:
   - or ServCo1 accepts by submitting a new termination B2B product order PO4 (action='delete') on its owned product P1
   - or ServCo1 rejects by submitting a modification B2B product order PO4 (action='noChange') on it product P1, possibly with a special reason.[Q3: acceptable/good approach?]
8. At the end:
   - or the product order PO2 of ServCo2 and internal order PO3 are fully executed (Donor accepted or did not react) 
   - or ServCo2 cancels its original product order PO2 (Donor rejected, Recipient agrees to roll-back)
   - or there is a conflicting situation between ServCo1 and ServCo2 that must be resolved probably resulting in putting all in a 'held' situation, potentially cancelling everything.