MSAN Interconnect
-
Upload
stephen-daugherty -
Category
Documents
-
view
162 -
download
12
description
Transcript of MSAN Interconnect
MSAN Interconnect
Update from Experts’ Group
18th April 2005
Paul RosbothamCo-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
GigE Physical
IP
SDH Physical
VCAT
ATM
AT
M B
ackh
aul S
ervi
ces
GFP
Ethernet VLAN
IPIPIP IP
VCAT
ATMGFP
Ethernet VLAN
IPIPIP
PS
TN
/ISD
N S
ervi
ces
Oth
er S
ervi
ces
on I
P
TD
M S
ervi
ces
PS
TN
/ISD
N S
ervi
ces
Oth
er S
ervi
ces
on I
P
AT
M B
ackh
aul S
ervi
ces
TD
M S
ervi
ces
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
BT MSAN Site
BT Network
Analogue
ISDN2/30
Router
GatewayMedia svr
Service Execution Function
Session Controller
Intelligence
MPLSCORE
IPoL2 protocolM
D
F
Altnet Core Network
Router
GatewayMedia svr
Session Controller
MPLSCORE
BT
Altnet
POTS
DSL
ISDN
BusinessData
L2 Switch
SignallingBorder
Function
SignallingBorder
Function
SessionBorder
Function
SessionBorder
Function
SIP(I) signalling : flows via Metronode PoH
BT lines are controlled by BT session controller, using H.248
Media stream flows via MSAN PoH
Baseband voice signal
MSAN Point of Handover : Voice Interconnect First Approach – separate Media & Signalling (inbound call demonstrated)
BT MSAN Site
BT Network
Analogue
ISDN2/30
Router
GatewayMedia svr
Service Execution Function
Session Controller
Intelligence
MPLSCORE
IPoL2 protocolM
D
F
Altnet Core Network
Router
GatewayMedia svr
Session Controller
MPLSCORE
BT
Altnet
POTS
DSL
ISDN
BusinessData
Routeing Function
Signalling & SessionBorder
Function
Signalling & SessionBorder
Function
SIP(I) signalling : flows via MSAN PoH and is routed to Metronode
BT lines are controlled by BT session controller, using H.248
Media stream flows via MSAN PoH
Baseband voice signal
MSAN Point of Handover : Voice Interconnect Second Approach – routeing function at MSAN
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
MetronodeA
MetronodeB
MSAN1
MSAN2
MSAN3
MSAN4
Primary path to parent Metronode for MSANs 1, 2 & 4
Secondary path to parent Metronode for MSAN 3
Primary path to parent Metronode for MSAN 3
Primary path to parent Metronode for MSAN 4
Secondary path to parent Metronode for MSAN 1 , and MSAN 3
Secondary path to parent Metronode for MSANs 1 & 2 , and MSAN 3
Secondary path to parent Metronode for MSAN 4
Secondary path to parent Metronode for MSANs 1, 2 & 4
Secondary path to parent Metronode for MSANs 1, 2 & 4 , and MSAN 3
A connection to MSAN 1 would probably provide reachability to MSANs 1, 2 & 4A 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
BT MSAN Site
BT Network
Analogue
ISDN2/30
Router
GatewayMedia svr
Service Execution Function
Session Controller
Intelligence
MPLSCORE
M
D
F
Altnet Core Network
Router
GatewayMedia svr
Session Controller
MPLSCORE
BT
Altnet
POTS
DSL
ISDN
BusinessData
L2 Switch
Baseband voice signal
L2 pipe from MSAN to Altnet
Altnet session controller controls MSAN line by H.248
Session controller communicates with subsequent session controllers by SIP(I)
Media stream routes via altnet
MSAN Voice Access (Option 1) – provided over MSAN Point of Handover
BT MSAN Site
BT Network
Analogue
ISDN2/30
Router
GatewayMedia svr
Service Execution Function
Session Controller
Intelligence
MPLSCORE
M
D
F
Altnet Core Network
Router
GatewayMedia svr
Session Controller
MPLSCORE
BT
Altnet
POTS
DSL
ISDN
BusinessData
L2 Switch
Baseband voice signal
L2 pipe from MSAN to Altnet
Altnet session controller controls MSAN line by H.248
Session controller communicates with subsequent session controllers by SIP(I)
Media stream routes via altnet
MSAN Voice Access (Option 2) – provided over Metronode Point of Handover
BT MSAN Site
BT Network
Analogue
ISDN2/30
Router
GatewayMedia svr
Service Execution Function
Session Controller
Intelligence
MPLSCORE
VoIPoL2 protocolM
D
F
Altnet Core Network
Router
GatewayMedia svr
Session Controller
MPLSCORE
BT
Altnet
POTS
DSL
ISDN
BusinessData
L2 Switch
Baseband voice signal
Altnet Session controller communicates with subsequent session controllers by SIP(I)
H.248 control signal to MSAN line is from BT session controller
Access GatewayControl Function in BT Session Controller maps H.248 into SIP
Media stream routes via altnet
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!