CONSULT21
BRIEFING
21CN PSTN emulation technical issues
briefing
Issue1: Briefing Number C21–NS-002
Date: 17th February 2006
IMPORTANT NOTE
Please note that this represents current thinking and is subject to
change.
This document is supplied to you in confidence as part of the
Consult21 Process. It should not be circulated outside the agreed
Consult21 Communications Providers.
The information contained within this document is provided by BT
to promote understanding and facilitate ongoing discussions at the
Network Structure Working Group. Any questions relating to this
information should be raised initially with this forum or by emailing
consult.21@bt.com
Copyright © British Telecommunications plc 2006
Page 1
Background
This document summarises the BT view on the four issues identified in the PSTN emulation technical
consultation document and referred to the Consult21 Network Structures Working Group.
1
Managing voice bandwidth on the MSIL
The bandwidth on the MSIL between Border Gateways or equivalent in each CP’s network needs to
be assigned to the different services. How should this assignment be done and policed?
This issue will be referred to the Consult21 Network Structures Working Group for resolution. No
response required for this consultation.
BT view
The MSIL link, as defined in the NICC standards, can offer different transport capabilities to match
different service types e.g.

TDM supporting services such as traditional PSTN circuit-switched interconnects and PPCs

ATM supporting services such as DataStream

Ethernet -yet to be defined but with a view of supporting Ethernet services in future

IP - for a number of services such as Internet Peering, PSTNoIP, VPNs etc.
Each service that is offered by BT has to define how it uses the appropriate MSIL transport capability;
the transport capability of an MSIL is useless by itself.
The NICC standard requires that the each Ethernet VLAN is of a defined fixed bandwidth which has
policing and traffic shaping at each end. In 21CN this is a requirement on the Fibre MSAN Ethernet
switch as well as the management control to set it up.
For PSTNoIP there are two service types, signalling and media:
Signalling - PSTN SIP-I signalling will have its own fixed bandwidth VLAN in a MSIL. Any CP can
have multiple physical PoHs with one (and possibly, but unlikely, more) signalling VLANs in each one.
SIP-I Signalling over SCTP between two Call Servers can be sent over more than one VLAN on
different geographic POHs with automatic failure and recovery to get geographic resilience. A
signalling VLAN is capable and likely to simultaneously carry the signalling traffic between a number of
different CS<->CS pairs. See embedded diagram below from the NICC standard.
The bandwidth required is therefore dependent on the number of CSs sharing the bandwidth of each
VALN, , the geographic fail-over strategy for each CS to CS signalling path they choose and the peak
signalling rates (+ some overhead) and is impossible to specify as a rule of thumb. Maybe the NICC
management working group should produce some planning guidlines for this and the media stream.
The key thing to note is that the signalling service and its physical implementation is independent to
the media steam for PSTNoIP or any other service.
Media - The PSTNoIP media stream is carried on its own VLAN within the MSIL of fixed policed
bandwidth. Each media stream (telephone call) passes through a border gateway controlled by its own
call server / SIP back-to-back user agent. As a result of the signalling requests, the border gateway is
instructed to open up a pinhole for that individual media stream and the gateway polices the
bandwidth that is requested. (See embedded diagram below). Each media stream will require
approximately 100kbit/s for each 64kbit/s speech stream due to the packet overheads. There should
also be some overhead left in the fill of the fixed VLAN bandwidth as a guide. This overhead depends
on the size of the VLAN, small ones needing greater percentage overhead than larger ones.
Page 2
Note that there is a bandwidth management function in this diagram which relates only to the
interconnect. This function is can be provided by the media border function which can refuse requests
from the " Edge session controller" (i.e. call server / SIP back-to-back user agent) to open a policed
media stream pin hole if there is insufficient VLAN Bandwidth.
2
Non functional aspects
The capacity of traffic passing between networks in the new technology appears to be flexible in that,
up to a certain point, the interconnect can handle an amount of calls, yet to be determined. At some
point, the number of calls per minute will reach a maximum and overload arrangements will need to be
employed. Also during the planning phase, interconnect resilience should be addressed.
These issues will be referred to the Consult21 Network Structures Working Group for resolution. No
response required for this consultation.
BT view
The ability to prevent more calls than bandwidth (i.e. "route busy"), the overload of call processing (i.e.
rate of calls per minute), and resilience scenarios are addressed in the NICC doc ND1612 and SPEC
17.
Links between networks must be bandwidth managed (as discussed under Managing voice bandwidth
on the MISL). SIP-I must support ACC in the ISUP for overload control. The annexes of ND1612
show signalling resilience options but no figures as to how reliable an Interconnect should be. Some
(contractual) discussions will be needed on the agreed resilience and how this is achieved
3
Impact on Call Servers
Call Servers have a finite call handling capacity which needs to be planned and policed. The impact of
call volumes and call processing rates on the servers needs to be agreed for the purpose of
interconnect.
This issue will be referred to the Consult21 Network Structures Working Group for resolution. No
response required for this consultation.
BT view
In general, the calls capacity of the network is driven by two parameters:
1. The amount of bandwidth required to carry the media (64kbit/s per call in TDM and around
100kbit/s per call in IP)
2. The number of calls per second that the Call Servers can process.
There is a relationship between the two that is determined by the call holding time. For example, if the
call holding time is 120 seconds, then each circuit supports 1 call every 120s (+ a bit more as circuits
can't be released and seized instantly), hence 120 circuits would produce 1 call per second, 1200
circuits would produce 10 calls per second, etc. This relationship can be broken by traffic patterns that
have very short call hold times, e.g. televotes. If the call holding time is reduced then a given number
of circuits produce more calls per second.
Page 3
In IP there are no circuits but we know that a call uses a given amount of bandwidth hence a similar
relationship exists between bandwidth, call holding time and calls per second. Such dimensioning
calculations also have to take account of short calls (e.g. Televotes). We also have to ensure that the
signalling bandwidth between components is sufficient to cope with the required calls per second.
It will get more complicated when we move to variable bandwidth calls - but for PSTN/ISDN the
bandwidth is fixed.
For PSTN/ISDN, the Call Server will use bandwidth management, initially in the form of call counting,
to ensure sufficient bandwidth between media components and the core IP network before it sets up a
call. The 21CN core network is being deployed to be non-blocking i.e. more than sufficient bandwidth
available.
Some Session Border Controllers and Call Servers have a call rate limiter function both inbound and
outbound. This will help but an overload control mechanism such as ACC will be needed. SIP has
nothing yet. BT working in TISPAN for an NGN overload control protocol (GOCAP) which could be
standardised late summer.
4
Circuit reservation for 999/112 calls
In the current legacy network circuits are reserved for the use of 999/112 emergency services. CPs
who are interested in using the NGN equivalent to this reservation of capacity should note that a
similar call counting or circuit reservation will need to be incorporated in their NGN design and BT
interconnect for 999/112 calls.
For information only. No response required for this consultation
BT view
See the embedded document that is BT’s proposed text on Priority Calls to be included in ND1612.
Note that it is planned to expose this text to the wider NICC/TSG membership during w/c 20 February.
D:\Documents and
Settings\802045124\My Documents\Voice Technology\Standards\NICC\NDs for IP IX\ND1612 PSTN-ISDN Gen Connectivity\Comments\ND1612 Pr
Page 4