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!