Download
msan interconnect n.
Skip this Video
Loading SlideShow in 5 Seconds..
MSAN Interconnect PowerPoint Presentation
Download Presentation
MSAN Interconnect

MSAN Interconnect

140 Views Download Presentation
Download Presentation

MSAN Interconnect

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. MSAN Interconnect Update from Experts’ Group 18th April 2005 Paul RosbothamCo-chair

  2. Agenda • What’s been going on since our last meeting? • Why two distinct requirements? • MSAN Point of Handover • MSAN Voice Access • Next steps

  3. 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

  4. 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

  5. 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

  6. 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

  7. TDM Services TDM Services PSTN/ISDN Services PSTN/ISDN Services Other Services on IP Other Services on IP ATM Backhaul Services ATM Backhaul Services IP IP IP IP IP IP IP IP ATM Ethernet VLAN Ethernet VLAN ATM GFP GigE Physical GFP VCAT VCAT SDH Physical

  8. 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

  9. MSAN Point of Handover : Voice Interconnect First Approach – separate Media & Signalling (inbound call demonstrated) Baseband voice signal SIP(I) signalling : flows via Metronode PoH BT lines are controlled by BT session controller, using H.248 Media stream flows via MSAN PoH Service Execution Function BT MSAN Site Intelligence POTS Analogue M D F Session Controller ISDN ISDN2/30 DSL BT Network IPoL2 protocol MPLSCORE L2 Switch Router Media svr Gateway Signalling Border Function Business Data Session Border Function BT Altnet Signalling Border Function Altnet Core Network Session Border Function MPLSCORE Router Media svr Gateway Session Controller

  10. MSAN Point of Handover : Voice Interconnect Second Approach – routeing function at MSAN Service Execution Function BT MSAN Site Intelligence POTS Analogue M D F Session Controller ISDN ISDN2/30 DSL BT Network Baseband voice signal IPoL2 protocol MPLSCORE Routeing Function Router SIP(I) signalling : flows via MSAN PoH and is routed to Metronode Media svr Gateway Business Data BT lines are controlled by BT session controller, using H.248 Signalling & Session Border Function BT Altnet Altnet Core Network Media stream flows via MSAN PoH Signalling & Session Border Function MPLSCORE Router Media svr Gateway Session Controller

  11. 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

  12. Reachability : example situation Metronode A Secondary path to parent Metronode for MSANs 1, 2 & 4  , and MSAN 3  Metronode B 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 MSANs 1 & 2  , and MSAN 3  Secondary path to parent Metronode for MSAN 1  , and MSAN 3  MSAN 1 MSAN 3 MSAN 2 Primary path to parent Metronode for MSAN 3 Secondary path to parent Metronode for MSAN 4 MSAN 4 Primary path to parent Metronode for 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

  13. 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

  14. 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”

  15. 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

  16. Service Execution Function BT MSAN Site Intelligence POTS Analogue M D F Session Controller ISDN ISDN2/30 DSL BT Network Baseband voice signal MPLSCORE L2 Switch Router L2 pipe from MSAN to Altnet Media svr Gateway Altnet session controller controls MSAN line by H.248 Business Data BT Session controller communicates with subsequent session controllers by SIP(I) Altnet Altnet Core Network MPLSCORE Router Media stream routes via altnet Media svr Gateway Session Controller MSAN Voice Access (Option 1) – provided over Metronode Point of Handover

  17. Service Execution Function BT MSAN Site Intelligence POTS Analogue M D F Session Controller ISDN ISDN2/30 DSL BT Network Baseband voice signal MPLSCORE L2 Switch Router L2 pipe from MSAN to Altnet Media svr Gateway Altnet session controller controls MSAN line by H.248 Business Data BT Session controller communicates with subsequent session controllers by SIP(I) Altnet Altnet Core Network MPLSCORE Router Media stream routes via altnet Media svr Gateway Session Controller MSAN Voice Access (Option 1) – provided over MSAN Point of Handover

  18. Service Execution Function BT MSAN Site Intelligence POTS Analogue M D F Session Controller ISDN ISDN2/30 DSL BT Network Baseband voice signal VoIPoL2 protocol MPLSCORE L2 Switch Router H.248 control signal to MSAN line is from BT session controller Media svr Gateway Access Gateway Control Function in BT Session Controller maps H.248 into SIP Business Data BT Altnet Session controller communicates with subsequent session controllers by SIP(I) Altnet Altnet Core Network MPLSCORE Router Media stream routes via altnet Media svr Gateway Session Controller MSAN Voice Access (Option 2) – provided over Metronode Point of Handover

  19. 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

  20. 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.

  21. 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

  22. MSAN Voice Access - Scope • In principle MSAN Voice Access is required from all MSANs

  23. 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!