Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public3
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public4
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public5
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…
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public6
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…
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public7
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public8
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 ?
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public9
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public10
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)
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public11
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public12
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
IP/MPLS network with Ethernet connectivityBackhaul
IEEE 1588v2 - Semtech
Equipment
Reference clock, data analysis - Symmetricom
IP/MPLS backbone, traffic generators – Tellabs
Remote sync monitoring systems - Chronos
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public13
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
IEEE 1588v2 - Semtech
Equipment
Reference clock, data analysis - Symmetricom
IP/MPLS backbone, traffic generators – Tellabs/Alcatel-Lucent
IP DSLAM – Alcatel-LucentRemote sync monitoring systems - Chronos
SHDSL modems with NTR support – RAD data communications
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public14
2. Technology Assessment - IEEE 1588v2 lab tests
Phase I – Jul 2006 -> Jan 2007
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
IEEE 1588v2 accuracy in delivering frequency and phase (relative time)Objective
IP/MPLS network with Ethernet connectivityBackhaul
IEEE 1588v2 - Semtech
Equipment
Reference clock, data analysis - Symmetricom
IP/MPLS backbone, traffic generators – Tellabs
Remote sync monitoring systems - Chronos
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public15
8660A
10MHz ref clock
5585 CaesiumPrimary
Reference Clock
8630E
2.048 MHz output
.Background
Traffic Generatorport 1
BackgroundTraffic Generator
port 5
BackgroundTraffic Generator
port 2
BackgroundTraffic Generator
port 3
BackgroundTraffic Generator
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public16
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public17
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public18
2. Technology Assessment - IEEE 1588v2 lab tests
Phase I – Jul 2006 -> Jan 2007
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
IEEE 1588v2 accuracy in delivering frequency and phase (relative time)Objective
IP/MPLS network with Ethernet connectivityBackhaul
IEEE 1588v2 - Semtech
Equipment
Reference clock, data analysis - Symmetricom
IP/MPLS backbone, traffic generators – Tellabs
Remote sync monitoring systems - Chronos
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public19
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public20
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public21
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public22
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…
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public23
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public24
2. Technology Assessment - IEEE 1588v2 lab tests
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
IEEE 1588v2 - Semtech
Equipment
Reference clock, data analysis - Symmetricom
IP/MPLS backbone, traffic generators – Tellabs/Alcatel-Lucent
IP DSLAM – Alcatel-LucentRemote sync monitoring systems - Chronos
SHDSL modems with NTR support – RAD data communications
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public25
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public26
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)
ChronosSyncwatch(probe 2)
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public27
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.
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public28
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public29
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
ChronosSyncwatch(probe 1)
E1 output
ChronosSyncwatch(probe 3)
30dB passive tap
2.048 MHz ref clock
ChronosSyncwatch(probe 2)
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public30
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public31
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
15 November 2007Synchronisation in Future VF Mobile Networks C1 – Not Classified / Public32
Acknowledgments
Max GasparroniVodafone GROUP R&DVodafone Group Services LimitedVodafone House, The ConnectionNewbury, Berkshire RG14 2FN UK