Synchronisation in Future VF Mobile Networks · Node B 2G ATM TDM 3G R99 3G R5+, B3G E t h ( I P)...

Synchronisation in Future VF Mobile Networks

Max Gasparroni – VF Group R&DITSF 2007 – London, November 2007

ITSF 2007 - London

15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public2

CONTENTS

1. VF Mobile plus strategy

2. VF backhaul challenge

3. Synchronization solutions for VF converged networks

4. VF synchronisation activities and lab test results

5. Summary and next stepsEnsuring synchronisation

for the next generation of VF cellular IP backhaul


VF mobile plus strategyTransform Vodafone from a mobile only to a total communication provider

64 – 144 kbps 64 – 384 kbps 0.384 – 4 Mbps 0.384 – 7 Mbps 20+ to > 50 Mbps

Key propositions: Mobile Internet, Fixed offering, Mobile Advertising

Mobile Internet

Extending traditional Internet interactions to the mobile1

3GWCDMA-FDD

GSMGPRS/EDGE 3G + HSPA NGMN

(LTE-WiMAX)3G + HSDPA

time2000 2004 2007 2008 2010+

Provide faster wireless networks for richer services


VF mobile plus strategy (cont.)

DSL Offering(and PC integration)

Consumer + Enterprise

2Integrated media rich services for mobiles and PC

cellular DSL

1 2 3 4 5Loop Length(km)

DSL reach and bit rate

VDSL

ADSL2+

ADSL2

ADSL

SHDSLRE-ADSL2

8

3

11

24

52Mbps

100Mbps

VDSL2

Provide faster fixed connectivity for richer services

time

2000

2009

2007

http://www.logitech.com/index.cfm/products/details/DE/DE,CRID=2204,CONTENTID=10860


Backhaul Challenge - Backhaul convergence towards IP

Regardless of the ‘backhaul end game’, a unified transport layer (IP/Ethernet) will enable the opportunistic exploitation of different physical connections available…

Critical need to ensure for current and future mobile networks… (future-proof)

RNC

BSC

SGSNs

GGSNs

Internet

CPN (IP/MPLS)

MGWs Servers

GRX

VPNCorporate

STM-1ATM

IP<->ATM IWF

IP<->TDMIWF

STM-1TDM

IP TransportIP TransportIP TransportIP Transport

TDM/ATM<->IPIWFBTS

Node B

2G

ATM

TDM3G R99

3G R5+,B3G

Eth (IP)

eBTS

PSN Backhaul IP/Ethernet over fibre, MW,

leased lines, etc.

3G R5+,B3G

Ethernet (IP)

eBTS S-GW/MMEASN GW

Ethernet (IP)IP DSLAM

xDSL (Eth)

BRAS

The migration from a ‘synchronous’ circuit-switched (TDM/ATM) to an ‘asynchronous’ packet-switched (IP/Ethernet) transport creates a ‘synchronization’ issue for Vodafone…

Mobile Internet and fixed offering will put an enormous pressure on the backhaul network…


Migration to native IP - Timeframe

2008 – early 2009

(limited demand)

• Self-build backhaul network expansion (native Ethernet over MW, fibre, etc.)

• Backhaul network provisioning for LLU (xDSL) which could be used for cellular backhaul as well

• Sporadic native Ethernet connectivity offered by fixed providers as replacement of leased lines

Mid 2009 onwards

(extensive demand –network wide)

• Migration of IP/MPLS over existing SDH/PDH infrastructure (POS, ML-PPP) towards native

Ethernet

• Widespread deployment of Ethernet MW

• Extensive native Ethernet connectivity offered by fixed providers as replacement of leased lines

Deploy some ‘interim solutions’ (based on cost and accuracy requirements) until future-proof solutions reach the required maturity level…


Vodafone involvement in synchronisation

Why is Vodafone Group R&D involved in synchronisation ?

Global coordination

Avoid duplication in developing technology required by the majority VF OpCos

Economy of scale

Identify a ‘common’ solution fulfilling current and future requirements of the various VF OpCos (useful in case of network consolidation)

Technology roll-out

Advice VF OpCos on ‘optimal’ solutions to deploy (both interim and long-term) and the list of ‘preferred’ suppliers

Technology shaping

Work collaboratively with strategic suppliers to make sure the solution meets VF requirements


Vodafone Group R&D Activities

1. Sync techniques scouting

• R&D has been engaging with the major players to identify the optimal solution for VF taking into account:

- current and future wireless technologies and backhaul connectivity- deployment scenarios (macro, micro, femto)- cost targets

2. Technology assessment

• Perform lab tests to assess synchronization performance under ‘severe’ loading conditions

• identify necessary protocol modifications / optimisations / customisations

• Disseminate the results to major stakeholders in VF and relevantvendors

3. Live trials• Engage with VF OpCos to carry out live trials of the identified

solution• Test the technology in realistic (not controlled) environment

4. Commercial Engagement

• Assist VF Group Technology and OpCos on commercial aspects (RFP, RFQ)

We are here!

What is Vodafone R&D doing in synchronisation ?


Synchronization requirements for VF networks

Frequency Sync• WCDMA FDD systems

_ +/- 50 ppb (part per billion)‗ +/- 100ppb for pico/femto

• WCDMA TDD systems_ +/-2.5 μs (micro second)

between base stations is required (+/- 1.25 μs between ref and BTS)‗ CDMA 2000: +/-3 μs time

alignment

• Mobile WiMAX_ < +/-2.5 μs (or down to +/-

1.0 μs for some WiMAXprofiles)

Time Sync

Mobile Networks

< 100 ppb (part per billion)One-way Video IPTV

< 100 ppb (part per billion)One-way Video HDTV

< 500 ppb (part per billion)One-way Video MPEG

< 50 ppb (part per billion)Two-way Video

< 100 ppm (part per million)Ethernet Best Effort

< 32 ppm (part per million)Voice

SYNCHRONIZATION REQUIREMENTAPPLICATION

Real-Time Applications

• Frequency Synchronisation: +/- 50 ppb Accuracy (GSM, 3G and LTE FDD systems)• Phase Synchronisation (relative-time sync): +/- 2.5 μs Time Accuracy (TDD systems -including WiMAX) -> could be down to +/- 1.0 μs for some WiMAX profiles


1. Sync techniques scoutingGPS receiver at every node Deliver frequency and time (up to 50ns accuracy claimed)

Not always viable (indoor cells)

Expensive oscillators required ($500) for periods of unavailability (not 99.999% solution)

Packet –basedIn-band synchronization (adaptive clock recovery)

The clock is reconstructed using the packet interarrival rate

Inexpensive solution

Subjected to network load conditions, not ‘always-on’ and deliver frequency (not phase)

Could represent a viable ‘interim’ solution only in certain scenarios

Packet –basedOut-of-band

synchronization

Clock information is transmitted via dedicated timing packets (master <-> slave)

‘Always-on’ solution (even without traffic data)

Ubiquitous solution (works over any transport technology)

Can deliver frequency and phase (FDD and TDD systems)

Major protocols: IEEE 1588v2, IETF NTP version 4

Network synchronous Sync Ethernet

Use the PHY clock from bit stream (similar to SDH/PDH), each node recovers clock

Only deliver frequency and not phase

Independent from network load

Represent an excellent SDH/PDH replacement option -> viable ‘interim’ solution

IEEE 1588v2 represents the most promising ‘long-term’ solution(in conjunction with Sync Eth)


1. Sync techniques scouting - IEEE 1588v2 as ubiquitous sync solution

RNC

BSC

SGSNs

GGSNs

Internet

CPN (IP/MPLS)

MGWs Servers

GRX

VPNCorporate

STM-1ATM

IP<->ATM IWF

IP<->TDMIWF

STM-1TDM

TDM/ATM<->IPIWFBTS

Node B

2G

ATM

TDM3G R99

3G R5+,B3GEth (IP)

E-NodeB

PSN Backhaul IP/Ethernet over fibre, MW,

leased lines, etc.

3G R5+, B3G Ethernet (IP)

E-NodeB S-GW/MMEASN GW

Ethernet (IP)

DSLResidential VAP

DSLAM

BTS

2G

SHDSL (TDM)

3G R99

TDM/ATM<->IPIWF

Node B

SHDSL (ATM

)

Enterprise VAPMicro and Pico cells

Ethernet (IP)

PRC

IEEE 1588v2 Grand Master

IEEE 1588 slave board

IEEE 1588 sync packets

Primary reference clock

IP link

Boundary clock or Grand master with GPS/LORAN….

Note: Sync Ethernet could be used as L1 sync mechanism replacing existing SDH wherever applicable


2. Technology Assessment - IEEE 1588v2 lab tests

Phase I – Jul 2006 -> Jan 2007 (completed)

Initial assessment of IEEE 1588v2 accuracy in delivering frequencyObjective

IP/MPLS network with Ethernet connectivityBackhaul

IEEE 1588v2 - SemtechEquipment

Reference clock, data analysis – Horsebridgeand Oscilloquartz

IP/MPLS backbone, traffic generators - Tellabs

Phase II – Jul 2007 -> Oct 2007 (completed)

IEEE 1588v2 accuracy in delivering frequency and phase (relative time)Objective


IEEE 1588v2 - Semtech

Equipment

Reference clock, data analysis - Symmetricom

IP/MPLS backbone, traffic generators – Tellabs

Remote sync monitoring systems - Chronos


2. Technology Assessment - IEEE 1588v2 lab tests (cont.)

Phase IV – Jan 2008 -> June 2008 (to be started)

IEEE 1588v2 frequency and phase accuracy with various backhaul configsObjective

IP/MPLS, Carrier Ethernet, MW, GPON, xDSL, etc.Backhaul

IEEE 1588v2, reference clock, data analysis – Brilliant telecomEquipment

Backhaul (various tx technologies) – Nokia Siemens Networks

Phase III – Oct 2007 -> Dec 2007 (ongoing)

IP DSLAM synchronisation with IEEE 1588v2Objective

SHDSL for E1 over copperBackhaul


Equipment


IP/MPLS backbone, traffic generators – Tellabs/Alcatel-Lucent

IP DSLAM – Alcatel-LucentRemote sync monitoring systems - Chronos

SHDSL modems with NTR support – RAD data communications



Phase I – Jul 2006 -> Jan 2007






Phase II – Jul 2007 -> Oct 2007




Equipment





8660A

10MHz ref clock

5585 CaesiumPrimary

Reference Clock

8630E

2.048 MHz output

.Background

Traffic Generatorport 1

BackgroundTraffic Generator

port 5


port 2


port 3


port 4

IEEE 1588 test session

Multi service IP routers

8620B

8620C

8620D

Base Station Emulated

Traffic

2.048 MHz ref clock

TIE, MTIEAnalyser

Oscilloquartz

STS 5565

SemtechIEEE 1588v2 master board

Lab tests – Phase I testbed

HorsebridgeSystem Integrator

SemtechIEEE 1588v2 chipset

and master clock

TellabsIP/MPLS backbone

IEEE 1588v2 Semtech Master

IEEE 1588 Slave

Base Station 1

Base Station 2

Base Station 3

Base Station 4

Frequency accuracy is measured

Oscilloquartz

OscilloquartzReference clock and

data analysis


Lab tests – Phase I traffic scenarios

Different Levels of Constant Traffic

• 20%, 50%, 80%, 90% and 100% of network capacity. (QoS was necessary for the 100% case. For all other cases, tests passed without QoS)

Bursty Traffic Modulation

• Generate constant traffic at 10% of network and on top add bursts of traffic at 75% of network capacity for periods of 5 seconds. The time between consecutive heavy bursts will be set at 2, 5 and 10 seconds randomly

On/Off Traffic Modulation

• Generate constant traffic at 10% of network and on top add bursts of traffic at 75% of network capacity for one hour, then 0% for the next hour, then 75% again for next hour, and so on

Ramp Traffic Modulation

• Generate constant traffic at 10% of network and on top add 75% of traffic in 2.5% increments every 1 minute. Once reached the 75% mark, startdecreasing the traffic by 2.5% decrement (again every 1 minute)

Routing Change • Bypass two MULTI SERVICE ROUTERS switches for a period of time and then restore. The period be in the order of 1000 seconds

Network Overload• Overload the network by adding up to 90% of network capacity (in addition to

the 10% of constant traffic) for periods of 10, 100 and 1000 seconds. (QoSnecessary for this test)

Network Outages • Break the network connection for various periods of time (e.g. 10, 100 and 1000 seconds) and restore

• Frequency accuracy measured


Phase I Lab tests conclusions

Enhancements to 1588v2 slave algorithm necessary to cope with Ramp Scenario (likely to happen in real networks)

IEEE 1588v2 packets need to be prioritized (i.e. QoS support) if network overload conditions are likely in the deployed backhaul infrastructure

Further work is necessary to assess/improve performance:• With different routers manufacturers and backhaul infrastructures• With different IEEE 1588v2 chipsets• To test phase alignment as well as frequency accuracy

IEEE 1588v2 delivers good performance for most of test scenarios1

2

3

4



Phase I – Jul 2006 -> Jan 2007






Phase II – Jul 2007 -> Oct 2007




Equipment





Lab tests – Phase II testbed

SymmetricomTiming master and data

analysis

SemtechIEEE 1588v2 chipset

ChronosRemote sync monitoring

systems

TellabsIP/MPLS backbone

Phase alignment and Frequency accuracy are measured


Lab tests – Phase II traffic scenarios

Different Levels of Constant Traffic

• 20%, 50% and 80%, 90% and 100% of network capacity. (inconsistent behaviour for 100% traffic, with and without QoS, which needs further work)

Bursty Traffic• Generate constant traffic at 10% of network and on top add bursts of traffic at 75% of network

capacity for periods of 5 seconds. The time between consecutive heavy bursts will be set at 2, 5 and 10 seconds randomly.

On/Off Traffic • Generate constant traffic at 10% of network and on top add bursts of traffic at 75% of network capacity for one hour, then 0% for the next hour, then 75% again for next hour, and so on

Ramp Traffic• Generate constant traffic at 10% of network and on top add 75% of traffic in 2.5% increments

every 1 minute. Once reached the 75% mark, start decreasing the traffic by 2.5% decrement (again every 1 minute)

Routing Change• Bypass two Ethernet switches for a period of time and then restore. The period be in the

order of 1000 seconds. (The IEEE1588 fails if a second routing change topology happens whilst slave still in holdover and the new PDV higher)

Network Overload• Overload the network by adding up to 90% of network capacity (in addition to the 10% of

constant traffic) for periods of 10, 100 and 1000 seconds. There is lack of improvement with QoS. (Difference from phase I possibly due to different 1588 packet size and rate)

Network Outages • Break the network connection for various periods of time (e.g. 10, 100 and 1000 seconds) and restore.

• Phase and Frequency accuracy measured

G.8261 Ramp Traffic• Generate constant traffic at 20% of network capacity (20% DL and 8.6% UL) and on top add

60% of traffic in 1% increments every 12 minutes. Once reached the 80% mark (i.e. after 12 hours), start decreasing the traffic by 1% decrement (again every 12 minute)

G.8261 Network Congestion

• Start with 40% of network load. After a stabilization period, increase network disturbance load to 100% for 10s, then restore. Repeat with a congestion period of 100s

Susceptibility and Immunity

• Perform susceptibility and immunity tests by degrading the recorded PDV profile (using ANUE network emulator) and see when the IEEE 1588v2 slave clock breaches the target synchronization masks -> postponed to future tests


Phase II results – Ramp Traffic modulation

Recorded PDV distribution and scatter

Ramp Traffic Modulation

• Generate constant traffic at 10% of network and on top add 75% of traffic in 2.5% increments every 1 minute. Once reached the 75% mark, startdecreasing the traffic by 2.5% decrement (again every 1 minute)

0%

2%

4%

6%

8%

10%

12%

14%

16%

-9.0E-06 9.1E-05 1.9E-04 2.9E-04 3.9E-04 4.9E-04

M to SS to M

-1.E-04

1.E-04

3.E-04

5.E-04

0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 18,000

Time (s)

Del

ay (s

) MS Pkt delaySM Pkt delay

Floor movement starts above 50% load


Phase II results – Ramp Traffic modulation (cont.)

Phase and MTIE

<1 μs phase error (under E1 sync mask)

Semtech improved algorithm can now cope with packet delay floor movement…


Phase II Lab tests conclusions

Semtech improved slave algorithm can now cope with packet delay ‘floor movement’(experienced with ramp traffic)

Enhancements to 1588v2 slave algorithm necessary to cope with big and longer than 100s step changes scenarios with and without QoS support (unlikely to happen in real networks)

Test results show that the Sync packet data rate (128, 64, 32, 16) does not make a huge impact on performance

IEEE 1588v2 delivers good performance for most of test scenarios considering both frequency and phase alignment

1

2

3

4



Phase IV – Jan 2008 -> June 2008

IEEE 1588v2 frequency and phase accuracy with various backhaul configsObjective

IP/MPLS, Carrier Ethernet, MW, GPON, xDSL, etc.Backhaul

IEEE 1588v2, reference clock, data analysis – Brilliant telecomEquipment

Backhaul (various tx technologies) – Nokia Siemens Networks

Phase III – Oct 2007 -> Dec 2007

IP DSLAM synchronisation with IEEE 1588v2Objective

SHDSL for E1 over copperBackhaul


Equipment


IP/MPLS backbone, traffic generators – Tellabs/Alcatel-Lucent

IP DSLAM – Alcatel-LucentRemote sync monitoring systems - Chronos

SHDSL modems with NTR support – RAD data communications


Phase III - IP DSLAM synchronisation with IEEE 1588v2 High level diagram

ADSL ModemFibre

SHDSL Modem

ULLSynchronous link

Eth HSPA offloader

Multiservice routerdevice

DSLAM

E1 ATM

RNC

BSCEth HSPA

E1 TDM

SHDSL (with NTR support)

STM-1 ATM

E1/ VC12 (STM-1)

2.048 MHz

UMTS

GSM

IP/MPLS

PRC

1588v2Grand Master

1588v2slave

ADSL

SHDSL(with NTR support)

IEEE 1588v2 pkts

RAD LA-130 SHDSL modem

TDM PWE3 (CESoPSN/SAToP)

ATM PWE3 (ATMoPSN)

Assess whether IEEE 1588v2 provides a synchronization solution for the tactical usage of xDSL to backhaul macro cellular traffic (SHDSL to supply E1 over copper twisted pairs)

Compliance with the E1 sync mask will enable VF to deploy IEEE 1588v2 instead of GPS receivers at each LLU DSLAM (with evident cost benefits)

SHDSL

8-wire

IMA


Phase III - IP DSLAM synchronisation with IEEE 1588v2 Stage 1 test setup

No traffic is sent over the E1 SHDSL link

Frequency accuracy achieved at E1 link after SHDSL measured against G.823 (E1) sync and traffic masks

NTR configured over SHDSL

DSLAMALU ISAM 7302

Tellabs 86xx IP/MPLS backbone

Traffic generator

Traffic sink

PRC

1588v2Grand Master

1588v2slave

2.048 MHz output

2.048 MHz BITS input

GbETwisted copper pairRAD LA-130

SHDSL modem1x E1

2.048 MHz measure in

2.048 MHz ref in

2.04

8 M

Hz

ref

cloc

k

ChronosSyncwatch(probe 1)


2.048 MHz ref in2.048 MHz measure in 2.

048

MH

z cl

ock

reco

vere

d fro

m

IEE

E 1

588v

2 sl

ave


Lab tests – Phase III traffic scenarios Stage 1

Different Levels of Constant Traffic • 20%, 50% and 80% of network capacity. 100% load not tested

On/Off Traffic • Generate constant traffic at 10% of network and on top add bursts of traffic at 75% of network capacity for one hour, then 0% for the next hour, then 75% again for next hour, and so on

Ramp Traffic• Generate constant traffic at 10% of network and on top add 75% of traffic in 2.5% increments

every 1 minute. Once reached the 75% mark, start decreasing the traffic by 2.5% decrement (again every 1 minute)

• Frequency accuracy of the E1 link measured_ Unloaded E1 link

• Only a subset of tests run so far…

G.8261 Ramp Traffic• Generate constant traffic at 20% of network capacity (20% DL and 8.6% UL) and on top add

60% of traffic in 1% increments every 12 minutes. Once reached the 80% mark (i.e. after 12 hours), start decreasing the traffic by 1% decrement (again every 12 minute2)

Bursty Traffic• Generate constant traffic at 10% of network and on top add bursts of traffic at 75% of network

capacity for periods of 5 seconds. The time between consecutive heavy bursts will be set at 2, 5 and 10 seconds randomly.


Phase III results stage 1 - 80% constant load• Probe 1: Frequency accuracy of the recovered 2Mb/s E1 signal by the SHDSL modem compared with the 2.048 MHz SSU (Symmetricom 5540)

• Probe 2: Frequency accuracy of the recovered 2Mb/s E1 signal by the SHDSL modem compared with the IEEE 1588 slave board 2.048 MHz output (Semtech TopSync), measuring the degradation introduced by SHDSL (with NTR support)

Overall accuracy pretty much the same as IEEE 1588v2 slave clock

SHDSL does not introduce any major degradation


Phase III - IP DSLAM synchronisation with IEEE 1588v2 Stage 2 test setup

Loaded E1 over SHDSL lines with traffic flowing between RNC and NodeB

Probes at input and output of NodeB to understand the effect of NodeB filtering

DSLAMALU ISAM 7302

Traffic generator

Traffic sink

PRC

1588v2Grand Master

1588v2slave

2.048 MHz output

2.048 MHz BITS input

GbE

Twisted copper pair

RAD LA-130

SHDSL modem1x E1

RNC EdifaceSDXC

ATP Backhaul network

ATM STM1

NodeB

Alcatel-Lucent 77xx IP/MPLS backbone

Tests currently ongoing…

2.048 MHz measure in

2.048 MHz ref in

2.048 MHz ref clock


E1 output


30dB passive tap

2.048 MHz ref clock



Summary

The activities being carried out by Vodafone Group are helping Vodafone to…

Determine the sync strategy for VF

• Interim solutions will be a combination between adaptive clocking, sync Ethernet and GPS depending on requirements

• Long term solution is IEEE 1588v2 in combination with GPS/Loran/… and sync Ethernet

Assess the maturity level of IEEE 1588v2

• 9-12 months still necessary for algorithm refinements to cope with all possible scenarios

• Widespread adoption of IEEE 1588v2 to start in 2009 when network nodes with integrated IEEE 1588v2 chipsets should be available

Determine the ‘limits’of IEEE 1588v2 with different scenarios

• How many and where to place IEEE 1588v2 grand masters

• Understand for which situations QoS is necessary

• Assess whether (and if so, where) boundary clocks are necessary

Support 1588v2 vendors refine their solutions to meet VF requirements

• Test IEEE 1588v2 algorithms under very stressed (and hopefully unrealistic) conditions

• Test IEEE 1588v2 with different backhaul infrastructures


Next steps

Conclude all the lab tests (up to Phase IV)

Perform live trials on some selected VF OpCos

Start engaging VF strategic base station and multi-service routers vendors to express VF preference for sync solutions

Continue engagement with the relevant parts of Vodafone concerning the roll-out of the preferred solutions at global level


Acknowledgments

http://www.chronos.co.uk/index.php

http://www.horsebridge.net/index.htm

http://www.symmetricom.com/index.aspx

http://www.alcatel-lucent.com/wps/portal/!ut/p/kcxml/04_Sj9SPykssy0xPLMnMz0vM0Y_QjzKLd4w3cjUDSUGYpvqRKGIG8Y4IkSB9b31fj_zcVP0A_YLc0IhyR0dFAJgg_-M!/delta/base64xml/L3dJdyEvd0ZNQUFzQUMvNElVRS82X0FfMkU2

http://www.brillianttelecom.com/

[email protected]

Max GasparroniVodafone GROUP R&DVodafone Group Services LimitedVodafone House, The ConnectionNewbury, Berkshire RG14 2FN UK

mailto:[email protected]

Date post:	13-May-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Synchronisation in Future VF Mobile Networks · Node B 2G ATM TDM 3G R99 3G R5+, B3G E t h ( I P)...

Documents