Arena provisioning guide

Title page

 Interoute Voice Network

Arena

Provisioning guide

 Document Issue

Scope
This document details the provisioning required to enable a customer to be a part of Arena, Interoute ’ s carrier exchange.

It covers the provisioning required on both the Sonus and NexTone to enable calls from one customer ’ s partition to hop, in a controlled manner, to that of another customer.

Introduction
Arena is intended to be a carrier ’ s exchange, allowing multiple carriers (both TDM and IP) to buy and sell voice and data termination.

The service will comprise of three main service areas:

1) The Exchange. This is the main forum similar to a stock exchange where members will be able to conduct trading deals with other members who have published rates to the forum. Functionality will also include the ability to conduct private deals, for those members who do not wish to be made public.

2) Routing is the core of the VVN. Enhancements have been made to the VVN routing engine for Arena. This will allow members the ability to move traffic from their own partition to other member ’ s areas. This will be locked down to only allowing members with permission and the underlying commercial agreements to be able to ’ jump ’ partitions. A mechanism is also needed to control the amount of traffic which can cross the member ’ s partitions.

3) Statistical reporting – This allows members to track their traffic both to and from the exchange on a near real time basis. It will allow them to react quickly when to bad quality carriers are in routing as well as detect and act on faults.

This document concentrates on provisioning the routing and control of Arena on both the Sonus & NexTone platforms.

Arena sign up
These procedures are based on the following assumptions:


 * The customer signing up for Arena is already a VVN customer and has opted to join the exchange.


 * Each carrier that has a NexTone registered gateway only has one public realm (even with multiple gateways in use). I.e. a one to one mapping between a Sonus partition and a NexTone Realm. This is reliant on the dtg/otg migration having already been completed.

The migration from normal VVN to Arena VVN is a reversible migration, controlled by configuration on the NexTone.

Arena design
The following flow chart details, at a high level, how partition hopping is achieved with Arena. It includes the four core call scenarios:

1. IP originating end point hopping from its originating partition to a terminating IP end point in its own and separate partition.

2. IP originating end point hopping from its originating partition to a terminating TDM gateway in its own and separate partition.

3. TDM gateway call hopping from its originating partition to a terminating IP end point in its own and separate partition.

4. TDM gateway call hopping from its originating partition to a terminating TDM gateway in its own and separate partition.

Each Arena call may hop multiple times.



Figure 1: Arena Call Flow

Arena provisioning summary
This section details the steps to be followed to enable Arena.

Many of the steps are common irrelevant of the Arena scenario.

IP to IP


Figure 2: IP to IP Arena scenario

1) Determine the two VVN customers that have agreed to trade traffic with each other, either in a uni or bi-lateral agreement.

2) On NexTone provision two PEER, Arena specific, endpoint V ports. These ports allow hopping between partitions. Both are to be configured with:


 * Generic SIP Endpoints
 * No calling Plan
 * Route Media

2.1) The first PEER endpoint V port is logically thought of as the terminating partitions PEER V port. It is provisioned with:


 * A name/Registration ID representative of the partition (and therefore Realm) you wish to hop to.

Name= < TERMINATING PART REALM NAME > _PEERS

e.g. IRT_GBSIPE_IRT_PEERS (i.e. < REALM NAME > _PEERS)


 * An IP address equal to the RSA of the Realm that you wish to hop to.
 * A Realm equal to that of the partition you are hopping from.
 * A DTG equal to the hop that is taking place. MUST MATCH SONUS.

DTG= < ORIG PART IDENTIFIER > _GBSIP_ < ORIG PART > _PH_ < TERM PART >

e.g. KRT_GBSIP_KRM_PH_IRT

2.2) The second PEER endpoint V port is logically thought of as the originating partition PEER V port. It is provisioned with:


 * A name/Registration ID representative of the partition you wish to hop from.

Name= < ORIG PART REALM NAME > _PEERS

e.g. KRM_GBSIPE_KORUM_PEERS (i.e. < REALM NAME > _PEERS)


 * An IP address equal to the RSA of the Realm that you are hopping from.
 * A Realm equal to that of the partition you want to hop to
 * A new OTG equal to the partition that you are hopping to. MUST MATCH SONUS.

OTG= < 3 CHAR PARTITION IDENTIFIER > _GBSIP_ < END POINT ID >

e.g. IRT_GBSIP_IRT

3) Assign CAC for these PEER V ports, thus limiting the amount of partition hopping traffic that can take place. The CAC limit is configured on the first PEER V port (the PEER port of the partition you are hopping to), thus controlling hops to a partition.



4) There are a number of trunk groups used to achieve Arena, these all need to be provisioned on the Sonus PSX and carefully matched against the NexTone config.

For Intra partition ’ non Arena ’ calls and for first query in an Arena call from an IP endpoint:

TG TYPE A

OTG= < 3 CHAR PARTITION IDENTIFIER > _GBSIP_ < END POINT ID >

e.g. KRM_GBSIP_KORUM or IRT_GBSIP_IRT

For terminating intra partition and the final leg of Arena calls to an IP endpoint:

TG TYPE B

DTG= < 3 CHAR PARTITION IDENTIFIER > _GBSIP_ < END POINT ID >

e.g. KRM_GBSIP_KORUM or IRT_GBSIP_IRT

For Inter partition Arena calls, calls hopping out to another carrier ’ s partition:

TG TYPE C

DTG= < ORIG PART IDENTIFIER > _GBARE_ < TERM PART ID > _OUT

e.g. IRT_GBARE_KRM_OUT (IRT hopping to KRM, IRT traffic OUT to KRM)

For Inter partition Arena calls, calls hopping in to a carrier ’ s partition from another:

TG TYPE D

OTG= < TERM PART IDENTIFIER > _GBARE_SIP_ < ORIG PART > _IN

e.g. KRM_GBARE_IRT_IN (IRT hopping to KRM, IRT traffic IN to KRM)

For TDM terminating/originating calls:

TG TYPE E

The original trunk group type associated with GSX for C7, PRI etc

DTG= < ORIG PART IDENTIFIER > _ < COUNTRY ID >< PROTOCOL > _DESCRIPTOR

e.g. CTD_CHSS7_IRT_ARENA

TG TYPE F

The original trunk group type associated with GSX for C7, PRI etc

OTG= < ORIG PART IDENTIFIER > _ < COUNTRY ID >< PROTOCOL > _DESCRIPTOR

e.g. CTD_CHSS7_IRT_ARENA

For IP to IP Arena calls this is how the trunk groups are used:

1. The first INVITE/query to the PSX has an OTG equal to TG TYPE A.

2. The response to this redirects the call with a TG TYPE C. This directs the NexTone to next hop realm (therefore partition).

3. The call is then routed back to the PSX and tagged with a TG TYPE D.

4. The response to this query redirects the call with TG TYPE B, instructing the NexTone that hopping had completed and to terminate to the call to the IP gateway.

5) To enable us to back the customer out of Arena on Sonus make a note of the customers relevant (to Arena) Routing Labels Routes. Once a back up has been made it is possible to start introducing Arena as a route. For a chosen destination add a route that directs the call to the NexTone with a DTG instructing the NexTone to perform a partition hop.

Add this route in addition to the current routes, as and when CAC kicks in Crankback will allow the call to complete when Arena limit exceeded.



6) Configure PSX routing so that when a call comes in with an OTG of TG TYPE D the Arena traffic routes appropriately; be it another hop or to terminate. For example traffic hopping to CTD from KRM, will arrive in the IRT partition with OTG CTD_GBARE_IRT_IN. A specific class of service has been applied to CTD_GBARE_IRT_IN with forced routing forcing Arena over a certain TDM trunk, specified by CTD for Arena traffic: CTD_CHSS7_IRT_ARENA.

7) To enable us to back the customer out of Arena; on NexTone make a note of endpoint ’ s Protocol tab settings. After back up; change these fields on the Protocol tab for the endpoint of the originating customer:


 * Src. Trunk Group: Leave blank
 * Dest. Trunk Group: Leave as is with existing DTG in place.
 * New Src. Ingress Trunk Group: Enter in the OTG to be used for this endpoint. This must match the OTG on the SONUS
 * New Src. Egress Trunk Group: Blank out.



Now traffic from that end point will be involved in Arena, with the NexTone performing partition hopping as controlled by the PSX.

IP to TDM


Figure 3: IP to TDM

For an IP to TDM the only difference is in step 4 & 5.

For IP to TDM Arena: The first INVITE/query to the PSX has an OTG equal to TG TYPE A.

The response to this redirects the call with a TG TYPE C. This directs the NexTone to next hop realm (therefore partition).

The call is then routed back to the PSX and tagged with a TG TYPE D.

The response to this query redirects the call with TG TYPE E, instructing the NexTone that hopping had completed and to terminate to the call to the TDM Gateway.

TDM to IP


Figure 4: TDM to IP

For a TDM to IP the only difference is in step 4 & 5.

The first INVITE/query to the PSX from the GSX has an OTG equal to TG TYPE F.

The response to this redirects the call with a TG TYPE C. This directs the NexTone to next hop realm (therefore partition).

The call is then routed back to the PSX and tagged with a TG TYPE D.

The response to this query redirects the call with TG TYPE B, instructing the NexTone that hopping had completed and to terminate to the call to the IP gateway.

TDM to TDM


Figure 5: TDM to TDM

For a TDM to TDM the only difference is in step 4 & 5.

The first INVITE/query to the PSX from the GSX has an OTG equal to TG TYPE E.

The response to this redirects the call with a TG TYPE C. This directs the NexTone to next hop realm (therefore partition).

The call is then routed back to the PSX and tagged with a TG TYPE D.

The response to this query redirects the call with TG TYPE E, instructing the NexTone that hopping had completed and to terminate to the call to the TDM Gateway...

Arena provisioning back out
To reverse the changes and remove customer from Arena:

1) Nextone: Revert all changes on customer ’ s endpoint Protocol settings.

2) Sonus: Un-tick the In-Service radio button for the Arena Route.

Realms
The customer already has an external and internal realm (e.g. IRT_GBSIPE_IRT and IRT_GBSIPI_IRT respectively).

External Realm
In moving to Arena the customer will continue to use their existing public external realm.

Internal Realm
Until now intra partition VVN calls Ingress to the NexTone were routed to the PSXs by using DTGs, Destination Trunk Groups, these were implemented on the NexTone via an endpoint ’ s New Source Egress Trunk Group fields.

This field assigned DTGs to an Ingress call which allowed calls to be subsequently routed to PSX V ports (in the relevant internal Realm) with a matching DTG.

This meant that every customer had an internal realm and as each realm requires a media pool we were rapidly using up all of the available pools. So in moving to Arena the decision was made to use realms and therefore pools more efficiently; one way to achieve this was by migrating customers to using only one internal shared realm. This would be possible if Sonus would be able to determine where the call originated from, this is where OTG based routing on the Sonus comes into play.

In moving to Arena Ingress calls to the NexTone will be routed by using the default calling plan as opposed to DTGs.

This default calling plan is assigned to PSX V ports (V port 76 for each of network PSX) in the new INT_GB_DEFAULT internal realm.

Endpoint V ports
Arena utilises the existing customer endpoint V port (with certain changes) and also introduces Arena partition hopping specific endpoint V ports.

Existing Endpoint V port
The VVN customer already has an endpoint V port provisioned within their Realm.



As previously mentioned, prior to Arena, VVN ingress calls were routed to the PSX via DTGs implemented by New Src. Egress Trunk Group field. Now with Arena we will use the default calling plan so we need to blank the New Src. Egress Trunk Group field and ensure that ’ Send Dest. Trunk Group ’ is not selected:



In addition to these changes we will now be using the New Src. Ingress Trunk Group field. This will be used to enable the Sonus PSX to perform originating trunk group based routing for VVN calls (both normal intra partition and Arena partition hopping). This New Src. Ingress Trunk Group or Originating Trunk Group (OTG) is to be equal to the existing DTG.



Trunk group based routing is detailed in the Sonus section.

PSX Endpoint V port
As opposed to a V port per customer realm on each PSX. Arena utilises just one V port for all customers for each PSX. This new V port is in the new internal realm with the new default calling plan.



GSX Endpoint V port
As opposed to a V port per customer realm for each GSX. Arena utilises just one V port for all customers in the new internal realm. Routing calls from the GSX to this V port and onwards are achieved by existing DTGs.



New Arena specific Endpoint V port
Arena requires new partition hopping endpoint V ports. Each partition hop requires two new PEER endpoint V ports.

The first endpoint V port is provisioned with


 * A name/Registration ID representative of the partition you wish to hop to
 * an IP address equal to the RSA of the Realm that you wish to hop to
 * a Realm equal to that of the partition you are hopping from
 * a DTG equal to the hop that is taking place

The second endpoint V port is provisioned with


 * A name/Registration ID representative of the partition you wish to hop from
 * an IP address equal to the RSA of the Realm that you are hopping from
 * a Realm equal to that of the partition you want to hop to
 * a new OTG equal to the partition that you are hopping to

For example: KRM wants to be able to partition hop to IRT.

The first endpoint V port is provisioned with


 * A name/Registration ID representative of the partition you wish to hop to
 * IRT_GBSIPE_IRT_PEERS
 * an IP address equal to the RSA of the Realm that you wish to hop to
 * IRT Realm ’ s RSA
 * a Realm equal to that of the partition you are hopping from
 * KRM_GBSIPE_KORUM
 * a DTG equal to the hop that is taking place
 * KRM_GBARE_IRT_OUT refers to KRM hopping to IRT

The second endpoint V port is provisioned with


 * A name/Registration ID representative of the partition you wish to hop from
 * KRM_GBSIPE_KORUM_PEERS
 * an IP address equal to the RSA of the Realm that you are hopping from
 * KRM Realm ’ s RSA
 * a Realm equal to that of the partition you want to hop to
 * IRT_GBSIPE_IRT
 * a new OTG equal to the partition that you are hopping to
 * IRT_GBARE_KRM_IN refers to KRM hopping to IRT

Call Admission Control
CAC is defined against the PEER endpoint to control the volume of traffic hopping from one partition to another.

To limit how much KRM traffic hops to IRTs partition we enter a Max Total Call value on the IRT PEERS V port. In this instance we have limited the hop to 60 simultaneous calls.



OTG
OTGs will be used by the Sonus PSX to perform originating trunk group based routing. How they are used is detailed under the end point section.

DTG
DTGs will be included in Sip Re-Directs issued from the Sonus PSX, these will be used by both Sonus GSX and NexTone to route the calls.

Sonus Provisioning Detail
The customer already has certain entities provisioned already for VVN.

Partition and Carrier
The VVN customer will already have an associated partition and carrier.

SIP Server
To save on Nextone pool resources Arena is to only use one private realm for routing between Nextone and the Sonus. This means that the Sonus only has one IP address reference for all Arena routing from the Nextone. This reference is via the SIP server entity. The SIP server in use depends on the NexTone that is performing the hop – e.g. LON002NXT1. This has the IP address of the private NexTone realm – e.g. 84.233.173.148



IP Signalling Profile
Ensure that IP_PH_DTG_OTG IP Signalling Profile is used for TG TYPEs A, B, C and D. This will ensure that OTG and DTG information is used and included in the GSX CDRs.

Ensure that the terminating TDM trunk group has an Ip Signalling Profile that will include OTG & DTGs.

Signalling Profile
Ensure that the correct Signalling Profile is used for TG TYPEs A, B, C and D. These all need to have Signalling Profiles that


 * Restore Ingree Numbers (Double Dip Control)
 * Don ’ t convert called number (leaving country code on called number)

E.g. SIP_PH

To enable crank back ensure that the second, third etc, route choice trunk groups have signalling profiles with Reorder Trunk Based On ISUP Prefernece. This allows Crankback of calls to occur.



Trunk Group entries for OTG
To distinguish one customers call from another using the same IP address (SIP server) we use originating trunk group based routing. This can be implemented because when a call comes from the NexTone it has been tagged with an OTG detailing the partition (therefore customer) that the call has come from (as either an initial request or as a request following a partition hop).

To enable OTG based routing all of the OTGs used on the NexTone must be configured on the Sonus against the relevant Arena (in this case LON002NXT1) SIP server.

For instance a call hopping from Korum to Interoute partition will involve a call coming into the PSX:

Firstly from realm INT_GB_DEFAULT with an OTG=KRM_GBSIP_KORUM

And then from the same realm with OTG=IRT_GBARE_KRM_IN.

These OTGs can then be used by the PSX in routing the call.

Trunk Group entries for DTG
The routing intelligence behind Arena is provided by the Sonus PSX. When a call comes in from one carrier the PSX determines if the call is to hop to another carrier ’ s partition. If it is to hop then the PSX needs to respond to the call request with a Sip Re-Direct which itself directs the call to hop. The hop is actually carried out internally on the NexTone but using information provided to it by the PSX. The information dictating whether to hop or not is the Destination Trunk Group, DTG, carried in the SIP Re-Direct Contact Header.

Session Initiation Protocol

Status-Line: SIP/2.0 300 Multiple Choices

Status-Code: 300

Message Header

Via: SIP/2.0/UDP 84.233.173.148:5060;branch=07e3c1ff70b0080dd921fd1b1693b68d

From: "8888888" < sip:8888888@84.233.173.148;otg=IRT_GBSIP_IRT > ;tag=000e830f371100e617dda8f7-051e8dbb

SIP from address: "8888888" < sip:8888888@84.233.173.148;otg=IRT_GBSIP_IRT >

SIP tag: 000e830f371100e617dda8f7-051e8dbb

To: < sip:00442070259428@84.233.172.149:5060 > ;tag=gK00a1e57b

SIP to address: < sip:00442070259428@84.233.172.149:5060 >

SIP tag: gK00a1e57b

Call-ID: 1817845-3323167760-405167@interface-e1000g0

CSeq: 1 INVITE

Contact: < sip:00442070259428@212.23.47.50:4000;dtg=IRT_GBSS7_GLBX >

Contact: < sip:00442070259428@212.23.47.50:4000;dtg=IRT_GBSS7_TELEGB >

Contact: < sip:00442070259428@212.23.47.50:4000;dtg=IRT_GBSS7_TSYS >

Contact: < sip:00442070259428@212.23.47.50:4000;dtg=IRT_GBSS7_REACH >

As with the OTGs these DTGs need to be provisioned on the PSX, again against the relevant Arena (in this case LON002NXT1) SIP server.

For instance a call hopping from Korum to Interoute partition will involve a call coming into the PSX twice:

Firstly the call will come in from realm INT_GB_DEFAULT with an OTG=KRM_GBSIP_KORUM. The PSX will determine that a hop is to occur (Standard Route & Routing Label) and respond to the request with a terminating trunk group indicating to NexTone to hop partition DTG=KRM_GBARE_IRT_OUT.

Secondly an INVITE from the same realm with OTG=IRT_GBSIP_IRT. The PSX will determine that a hop has occurred and that no more hopping is to occur. It will respond with a DTG equal to the terminating PSTN trunk.

Standard Route
VVN customers will already have Standard Route entries. If certain calls are to hop from one partition to another then SR entries for those calls need to reference a Routing Label that will enable the NexTone to hop (i.e. DTG).

Routing Label
New Routing Labels specifically for Arena are required. For example to hop from KRM to IRT the PSX needs to Re-Direct the call back to the NexTone with a partition hop dtg.

Add this route in addition to the current routes, as and when CAC kicks in Crankback will allow the call to complete when Arena limit exceeded.





SSREQ for Arena calls
To use SSREQ for ARENA calls you need to use the following settings. To simulate a call from NexTone to GSX following Arena partition hopping:

Basic:





Advanced:







No Hop completion

 * Check CDRs on both platforms

No bandwidth error in NexTone CDR

 * Ensure that for the GSX entry on the NexTone only one V port exists in the INT_GB_DEFAULT realm. Multiple instances will cause routing failures, indicated by

PSX/GSX cant route

 * Ensure that following query to PSX the number is restored to original number before the next hop.
 * Ensure that the INVITE sent to the GSX contains a dtg. This is controlled by the IP signalling profile for the associated terminating TDM trunk group.
 * Ensure otg in requests to PSX.

NexTone cant route

 * Ensure it gets dtg ’ s in redirects
 * Ensure default calling plan is in place
 * Ensure CAC limit not exceeded; check call graph?