Transcript Broadband Roadmap – Existing products

MSAN Interconnect
Update from Experts’ Group
18th April 2005
Paul Rosbotham
Co-chair
Agenda
•What’s been going on since our last meeting?
•Why two distinct requirements?
•MSAN Point of Handover
•MSAN Voice Access
•Next steps
What’s been going on since the last meeting?
• After the last meeting an Experts Group was formed
• Involvement of BT Wholesale, C&W, Energis, Global Crossing, ntl, Telewest &
Thus
• An “outline of requirements” developed to scope the discussion area
• Various meetings held between the altnets
• Two meetings held with BT
• Much of the delay has been because of the difficulty in organising these
meetings
• Participants are heavily committed to NGN activity in NICC/Consult21
• MSAN Interconnect not seen as highest priority
• Requirements have been developed
•
Fully agreed for MSAN Point of Handover
•
Largely agreed for MSAN Voice Access
Why two sets of requirements?
• In discussions it became clear that two sets of requirements were being
intermingled/confused:
• A requirement for physical handover of capacity at the MSAN layer
• This is being termed “MSAN Point of Handover”
• A requirement for functional control of the MSAN equipment, particularly for
baseband voice
• This is being termed “MSAN Voice Access”
• The requirements are largely (but not totally) independent of one another
MSAN Point of Handover
•
MSAN Point of Handover foresees the provision of the multiservice pipe
at the MSAN layer rather than solely at Metronodes.
•
The motivation of MSAN Point of Handover is based upon the premise
that the fewer network elements traversed, the lower the cost
•
The driver is that by substituting BT backhaul from the Metronode to
MSAN location with their own, operators may be able to reduce
conveyance costs
MSAN Point of Handover
• The Experts Group has not gone into the technical detail of the
multiservice pipe
• The logic is that the same standards as used at the Metronode level will apply
at the MSAN level
• These standards are under development by NICC/TSG/ARS
• In brief, standards are based around ethernet over SDH(GFP) – see next
slide
• By “multiservice”, we envisage the point of handover being able to
accommodate all services including Interconnect Voice, MSAN Voice
Access, PPC, WES and bitstream services
• Special considerations apply for interconnect voice : see subsequent
slides
• Further study is required around reachability : see subsequent slides
IP
ATM
IP
GFP
IP
IP
Ethernet VLAN
IP
GigE Physical
VCAT
SDH Physical
IP
IP
IP
Ethernet VLAN
GFP
VCAT
ATM
TDM Services
ATM Backhaul Services
PSTN/ISDN Services
Other Services on IP
Other Services on IP
PSTN/ISDN Services
ATM Backhaul Services
TDM Services
MSAN Point of Handover : Interconnect Voice
• PSTN interconnect will use SIP(I) signalling
• As BT’s lines will be controlled by BT’s session controller (aka callserver), it is
necessary for the SIP(I) signalling to route to the session controller
• This session controller is likely to be located at the Metronodes
• Two basic solutions to this; either
• Voice signalling needs to be sent to the Metronode interconnect, media stream via the
MSAN Point of Handover (NB nothing in interconnect standards dictate that signalling and media need
follow the same path, and signalling is a very small volume of traffic), or
• Some form of basic routeing capability is required at the MSAN (but this need not necessarily
be a separate box…potentially could be part of the MSAN)
• It is accepted that operators may wish to have firewalling capability at
interconnects
• This can be divided into Signalling Border Functions and Session Border Functions.
• According to the architectural decisions above, there will be a need for the Session
Border and possibly Signalling Border functionality at the MSAN site
MSAN Point of Handover : Voice Interconnect First Approach –
separate Media & Signalling (inbound call demonstrated)
Service Execution Function
POTS
Intelligence
ISDN
Session Controller
Analogue
ISDN2/30
DSL
M
IPoL2 protocol
Baseband voice signal
L2
Switch
D
SIP(I) signalling :
flows via Metronode
PoH
BT lines are controlled
by BT session
controller, using H.248
MPLS
CORE
Router
F
Media svr
Business
Data
Session
Border
Function
Media stream flows via
MSAN PoH
BT
Signalling
Border Altnet
Function Core Network
Session
Border
Function
Altnet
MPLS
CORE
Router
Media svr
BT MSAN Site
Gateway
Signalling
BT Network
Border
Function
Gateway
Session Controller
MSAN Point of Handover : Voice Interconnect Second Approach
– routeing function at MSAN
Service Execution Function
POTS
Intelligence
ISDN
Session Controller
Analogue
ISDN2/30
DSL
M
IPoL2 protocol
Baseband voice signal
Routeing
Function
D
SIP(I) signalling :
flows via MSAN
PoH and is routed to
Metronode
BT lines are controlled
by BT session
controller, using H.248
MPLS
CORE
Router
F
Media svr
Business
Data
Gateway
BT Network
Signalling &
Session
Border
Function
BT
Altnet
Altnet
Core Network
Signalling &
Session
Border
Function
Media stream flows via
MSAN PoH
Media svr
BT MSAN Site
MPLS
CORE
Router
Gateway
Session Controller
Reachability
• The Experts Group has had extensive discussion on reachability, and
concluded that this is an issue for further study.
• The architecture of 21CN is not strictly a “star” from the Metronode
• Some MSANs are connected to their parent Metronode – in a
transmission/L2 context – via another MSAN
• This approach has been variously termed “parent/subtending MSANs”, or
“MSAN clusters”
• The issue is complex as MSANs could be daisy-chained between two
Metronodes.
• Further discussion is required, once the evolving 21CN network design is
clearer, of which MSANs will be “reachable” from a given MSAN Point of
Handover
• In general, it is likely that “child” MSANs will be reachable from an MSAN
Point of Handover, where a “child” is defined as an MSAN whose primary
path to its parent Metronode is via the MSAN with the Point of Handover
Reachability : example situation
Secondary path to parent
Metronode for MSANs 1, 2 &
4  , and MSAN 3 
Metronode
A
Secondary path to parent
Metronode for MSANs 1, 2 & 4
Secondary path to parent
Metronode for MSAN 3
Primary path to parent
Metronode for MSANs 1, 2 &
4
Secondary path to parent
Metronode for MSAN 1  ,
and MSAN 3 
MSAN
1
Metronode
B
Secondary path to parent
Metronode for MSANs 1 & 2  ,
and MSAN 3 
MSAN
3
MSAN
2
Primary path to parent Metronode
for MSAN 3
Secondary path to parent
Metronode for MSAN 4
Primary path to parent Metronode
for MSAN 4
MSAN
4
A connection to MSAN 1 would probably provide reachability to MSANs 1, 2 & 4
A connection to MSAN 4 would probably only provide reachability to MSAN 4
Scope of MSAN Point of Handover
• It is foreseen that much – but not necessarily all – MSAN Point of
Handover is required at;
• Where there is existing transmission build for interconnect (voice, PPC, ATM,
WES, LLU), and
• Where operators are building out for LLU purposes
• Following this logic, it is expected that MSAN Point of Handover will be
required at perhaps 10-15% of MSANs
• Because these will tend to be larger sites, and the “reachability”
considerations, this may cover a higher proportion of customer lines
MSAN Voice Access
• MSAN Voice Access is driven by two considerations
• The desire of alternative communications providers to directly control the functionality
provided to their customers hosted on BT’s network (both for outbound and inbound
calls)
• The desire to minimise cost via only incorporating essential BT network elements into
the call path (in this context alternate communications providers question whether the
BT call session controller is essential)
• Option 1 : MSAN Voice Access would foresee the control of individual customer
lines by alternative communications providers’ call session controllers
• The control protocol would be H.248
• Details to be agreed via NICC
• Option 2 : MSAN Voice Access would be via an Application Gateway Control
Function (within the BT call server)
• This would present SIP to the alternate communications provider
• The physical presentation of MSAN Voice Access could be either at the
Metronode or MSAN layer
• (if the latter, this would utilise an MSAN Point of Handover)
• MSAN Voice Access can be visualised as a “Next Generation CPS”
MSAN Voice Access – Basic requirements
• At a basic level, individual customer lines would be controlled by a call
session controller from a third party communications provider, rather than
BT.
• The MSAN line card would be configured to send all traffic from a
specified customer line to a particular communications provider, probably
by using a distinct L2 path.
• Overall control and management of the MSAN would remain with BT.
• In this context, BT’s support systems would maintain overall control of the
MSAN, e.g. for configuring that a line is controlled by a particular comms
provider, or for restarts etc
• A management interface – network hook – is required between BT and the
communications providers to exchange status information
MSAN Voice Access (Option 1) – provided over Metronode
Point of Handover
Service Execution Function
POTS
Intelligence
ISDN
Session Controller
Analogue
ISDN2/30
DSL
M
Baseband voice signal
L2
Switch
D
L2 pipe from MSAN
to Altnet
MPLS
CORE
Router
F
Altnet session controller
controls MSAN line by
H.248
Media svr
Business
Data
Gateway
BT Network
BT
Session controller
communicates with
subsequent session
controllers by SIP(I)
Altnet
Altnet
Core Network
MPLS
CORE
Router
Media stream routes via altnet
Media svr
BT MSAN Site
Gateway
Session Controller
MSAN Voice Access (Option 1) – provided over MSAN Point
of Handover
Service Execution Function
POTS
Intelligence
ISDN
Session Controller
Analogue
ISDN2/30
DSL
M
Baseband voice signal
L2
Switch
D
L2 pipe from MSAN
to Altnet
MPLS
CORE
Router
F
Altnet session controller
controls MSAN line by
H.248
Media svr
Business
Data
Gateway
BT Network
BT
Session controller
communicates with
subsequent session
controllers by SIP(I)
Altnet
Altnet
Core Network
MPLS
CORE
Router
Media stream routes via altnet
Media svr
BT MSAN Site
Gateway
Session Controller
MSAN Voice Access (Option 2) – provided over Metronode
Point of Handover
Service Execution Function
POTS
Intelligence
ISDN
Session Controller
Analogue
ISDN2/30
DSL
M
VoIPoL2 protocol
Baseband voice signal
H.248 control signal to
MSAN line is from BT
session controller
L2
Switch
D
MPLS
CORE
Router
F
Access Gateway
Control Function in BT
Session Controller maps
H.248 into SIP
Altnet Session controller
communicates with
subsequent session
controllers by SIP(I)
Media svr
Business
Data
Gateway
BT Network
BT
Altnet
Altnet
Core Network
MPLS
CORE
Router
Media stream routes via altnet
Media svr
BT MSAN Site
Gateway
Session Controller
MSAN Voice Access – Bandwidth control
• At a given MSAN, each individual comms provider may not have sufficient
customers to make statistical multiplexing possible
• E.g. if a communications provider has only one customer, if they had to pay for a virtual
pipe from the Metronode to the MSAN of finite size, this would effectively turn into a
leased line for that customer.
• For Option 1, a potential solution appears to be an interface to BT’s bandwidth
manager to allow the L2 pipe to be dynamically varied in size.
• Details to be determined by Network Hooks group
• For Option 2, the AGCF would manage the available bandwidth
• NB In most cases this consideration does not materially impact the overall
dimensioning of the Metronode-MSAN link
• choice of comms provider should not (subject to price elasticity!) change the volume of
calls a customer makes,
• same customers will be hosted on the same MSANs
• “In most cases” rather than in all cases, because if MSAN Voice Access is provided
over an MSAN Point of Handover, this would have an impact
MSAN Voice Access – Enhanced Requirements
• In addition to the basic requirements, some communications providers
have expressed an interest in a capability with enhanced routeing
• Whilst these enhanced requirements are needed, it has been agreed
that consideration of these should not interfere with fulfilling the more
basic requirements.
• Some other communications providers have expressed doubt about the
technical feasibility of these requirements.
MSAN Voice Access – Enhanced Requirements
• Consider the case where
• Comms Provider A has connections to Cardiff Metronode, but not Carlisle
• Comms Provider B has connections to both Cardiff & Carlisle Metronodes
• The requirements are;
• That a call from a CP-A Cardiff MSAN Voice Access customer to another Cardiff
customer should be routed directly by BT and not trombone via CP-A
• Similar to SAD
• That a call from a CP-A Cardiff MSAN Voice Access customer to a Carlisle customer
should be routed via CP-B
• Signalling may flow by CP-A, but media should not
• That a call from a CP-A Cardiff MSAN Voice Access customer to a Carlisle customer
should be routed by BT
• Further Study is needed into these requirements : Thus have recently produced a
discussion paper
MSAN Voice Access - Scope
•In principle MSAN Voice Access is required from all MSANs
Next Steps
• The MSAN Point of Handover requirements documentation has been
agreed by the Experts Group, and now we need to know if anyone
requires any changes to the document.
• The MSAN Voice Access requirements documentation will be imminently
agreed by the Experts Group, and we need feedback on any changes to
the content.
• Formally, the role of the MSAN Group was to define the requirements
hence this would mean “our work is done”.
• However, there are a series of “areas for further study” and “enhanced
requirements” which the Experts Group could add value by considering
• ….subject to prioritisation of other workload!