LTE- A Sync Architecture & Standards - פוקוס...

Power Matters.TM 1 © 2015 Microsemi Corporation. Company Proprietary

Power Matters.TM

Trusted Innovative Market Driven

LTE-A Sync Architecture & Standards

Timing & Synchronization Technological Seminar Eran Gilat 25/05/2016


ITU-T Synchronization Standards


Frequency G.8261: Timing and Synchronization Aspects in Packet Networks (Frequency)

Time/Phase G.8271: Time and Phase Synchronization Aspects in Packet Networks

G.8273: Packet-Based Equipment Clocks for Time/Phase: Framework

Structure of ITU-T Sync Requirements

G.8265.1: Precision Time Protocol Telecom Profile for Frequency Synchronization

G.8275.1: PTP Telecom Profile for Time/Phase Synchronization, Full OPS

Basic Aspects

Clocks

Methods

Profiles G.8265.2 PTP Telecom Profile for Frequency #2

G.8261.1: PDV Network Limits Applicable to Packet-Based Methods (Frequency)

G.8271.1: Network Requirements for Time/Phase Full on Path Support Network

Requirements

G.8273.1: Grandmaster (T-GM)

G.8262: Timing Characteristics of a Synchronous Ethernet Equipment Slave Clock (EEC)

G.8263: Timing Characteristics of Packet-Based Equipment Clocks (PEC)

G.8264: Distribution of Timing Information through Packet Networks

G.8275.2: PTP Telecom Profile for Time/Phase Synchronization, Partial OPS

G.8271.2: Network Requirements for Time/Phase Partial On Path Support

Definitions / Terminology

G.8260: Definitions and Terminology for Synchronization in Packet Networks

G.8261.2: Reserved for future use

G.8272: PRTC (Primary Reference Time Clock)

G.8273.2: Boundary/Slave Clock (T-BC/T-TSC)

G.8273.4: Assisted PTS Telecom Time Slave Clock

G.8274: Reserved for future use

agreed ongoing options

G.8275: Architecture and Requirements for Packet-Based Time and Phase Delivery

G.8265: Architecture and Requirements for Packet-Based Frequency Delivery

G.8273.3: Transparent Clock (T-TC) G.8266: Timing characteristics of packet master clock for frequency synchronization

G.8272.1: enhanced PRTC

G.8262.1: enhanced EEC


• Managed Ethernet backhaul consistent, known performance, low packet delay variation

Frequency Synchronization: G.8265.1 Basic Architecture

• Central deployment of high capacity PTP grandmaster

• Common deployment model today: 100s of networks worldwide

CORE ACCESS AGGREGATION

Macro eNodeB

Small Cell Aggregation

Metro Small Cells

PTP GM

PTP GM

Embedded PTP Slave Clock


Time Error Budget Example (G.8271.1)

+ 1.5 µs end-to-end budget

+ 100 ns

(PRTC)

+ 150 ns

(end equip.)

+ 250 ns

(holdover budget) + 250 ns

(network asymmetry compensation)

+ 200 ns

(dynamic time error)

+ 550 ns constant time error

(+ 50 ns per node, 10BCs+1slave)

PEC-M

End Equip.

PTP Grandmaster

Packet Network PTP Slave

PEC-S-T

Reference Point A, B

Reference Point

C

Ref. Point

D

PRTC

Ref. Point

E

+ 1.1 µs network budget


G.8275.1 Time Profile (Full On Path Support)

• PTP Multicast / L2

• “Time Boundary Clock” (T-BC) on every NE

• Phy layer from syncE

• 10 “Class A” / 20 “Class B” T-BC in a chain

• Based on classical sync hop by hop

engineering

• completely impractical for existing or for

MPLS based networks

• Accepted for greenfield deployments

• Still has some issues with network

asymmetry

CORE AGGREGATION ACCESS

BC

BC BC

BC

SyncE

SyncE

SyncE

SyncE

BC SyncE

Macro eNodeB

BC SyncE

BC BC BC

PTP GM

SyncE

PTP GM

SyncE Small Cell

Aggregation Metro Small Cells

BC

SyncE

SyncE

SyncE SyncE

BC SyncE

BC SyncE


G.8275 Distributed PRTC Functions

The ITU notes that the PRTC GM can be moved to the edge of the network to facilitate delivery of time/phase information to the Slave Clocks

Core network (uncalibrated links)

Backhaul network

Backhaul network

Primary path Optional Frequency reference used to secure GNSS failures

PRTC #1 PRTC #2

PRC #1 PRC #2

Note: T-GM are connected to the PRTC in this architecture


WIP to facilitate more flexible PTP deployment models for existing heterogeneous networks

Performance issues remain to be resolved

Role of APTS is under examination

G.8275.2 Time Profile (Partial On Path Support)

CORE ACCESS AGGREGATION

Macro eNodeB

Small Cell Agg.

Metro Small Cells

PTP GM

PTP GM

Microwave

High PDV / 3rd Party

Edge Master Clock

Edge BC


No change in network hardware

Operated over existing MPLS / CE network

• Preserves MPLS value proposition

No change to back office engineering and operations processes

Mitigates asymmetry as an issue

Sync not dependent on embedded NE

• Quality of BC design not an issue

Advantages of the G.8275.2 Architecture

Leverages existing investment made in GPS at eNodeB sites

Can leverage existing PTP GM deployments

Can leverage existing GPS at eNodeB

Compliant to existing sync standards

• compatible with G.8265.1 profile

Simple and easy to deploy for all LTE architectures

Cost Effective Alternative

PTP GM

Edge Master Clock


PTP Principles – IEEE 1588 implementation: Fault scenarios with G.8275.1

• Mid-chain site’s reference is lost and falls to Holdover

• While data transport may have a redundant path, to deliver sufficiently accurate PTP, the entire routing path must be re-taught

• This process usually takes 15-30 minutes

• During this time, the PTP will be provided downwards, towards all nodes in the edge, by the same BC which is in HO and will be very much outside of our error budget

• A switch, enabled with BC, bases its holdover on a 15$ oscillator (gives, at best a 2x10^-6 vs. a TP2700 with a 1x10^-11 HO)

PRC

GM

End Equipment

Time Slave Clock

T-SC PRTC

GNS

S

Packet Network with

10 or 20 T-BC

T-BC T-BC T-BC T-BC

Holdover


• Mid chain site performed a power cycle (e.g. generator temporary failure)

• The site power may be up and running along with data but since establishing the relationship with the GM takes 15-30 minutes, the clock quality will be very poor

• After the power cycle, the site and the switch will be up and running and will supply the entire downward chain with PTP of its poor quality

• Even if immediately synced with PTP, it will be with up to a 5 microsec phase offset because it has not learned the path yet. When our entire network phase offset budget is < 1microsec, that’s not good enough

PRC

GM

End Equipment

Time Slave Clock

T-SC PRTC

GNS

S

Packet Network with

10 or 20 T-BC

T-BC T-BC T-BC T-BC

Power cycle

PTP Principles – IEEE 1588 implementation: Fault scenarios with G.8275.1


• When a site before the PRTC fails, the sync quality downwards in the chain is not impaired

• All elements continue to get the PTP from the PRTC as if nothing happened

• The PRTC will recognize, via the APTS that the PTP flow from the GM is impaired and could alert us

PRC

Frequency ref

GM

End Equipment

Time Slave Clock

T-SC PRTC

GNSS

Packet Network

G.8265.1 Unicast Segment 1 G.8265.1 Unicast Segment 2

PRTC

APTS Node TP-2700

Holdover

GNSS

PTP Principles – IEEE 1588 implementation: Fault scenarios with G.8275.2 + APTS


• When the PRTC loses its GNSS signal, it will rely on APTS as its secondary source which includes the network asymmetric compensation

• All elements continue to get the PTP from the PRTC as if nothing happened

• The PRTC will recognize loss of GNSS signal and alert

PRC

Frequency ref

GM

End Equipment

Time Slave Clock

T-SC PRTC

GNSS

Packet Network

G.8265.1 Unicast Segment 1 G.8265.1 Unicast Segment 2

PRTC

APTS Node TP-2700

Holdover

GNSS

PTP Principles – IEEE 1588 implementation: Fault scenarios with G.8275.2 + APTS


G.8274.3 Assisted Partial Timing Support (APTS)

• APTS PRTC maybe placed at any point on the sync chain

• It is expected that most deployment will be at points near to the eNB where the time error budget can be most easily controlled

PRC

Frequency ref

GM

End Equipment

Time Slave Clock

T-SC PRTC

GNSS

Packet Network

PTP Segment 1 PTP Segment 2

PRTC

APTS Node


Case Studies for Phase Delivery / LTE-A


Example 1: Unicast PTP /L2 with OPS (BC)

Attributes

• “Centralised “ architecture, PRC + SSU + PRTC + GM

• PTP Unicast over Layer 2, “Time Boundary Clock” (T-BC) on every NE

• Traceable Physical layer frequency support from syncE

• 10 hops or less

• Extensive testing to measure overall time-transfer accuracy determined the choice of Unicast over Multicast and Ubiquity of T-BC

• Use of G.8275.1 clock attributes on Unicast flow

Packet Network with T-BC AND Unicast PTP

Sync E

PRC

GNSS

SSU

T-GM

PRTC

T-SC T-BC T-BC T-BC T-BC

eNB


Example 2: TDM Core PTP/L3 Distributed PRTC

Attributes

• MBH is 3rd Party black hole transport layer

• Sync is at “outlying / edge islands” - Campus, high rise, malls

• Edge can be PTP Unicast over MPLS or Multicast over L2, or GPS

• Now proposed as G.8275.2 with APTS

• May have PRTC in Core backing up PRTC at the edge

3rd MBH GNSS

PRTC

CE / IP

T-SC

eNB

TDM


Example 3: Unicast / L3 + m/c PTP / L2 at Edge

Attributes

• SSU + PRTC + GM + PTP Unicast over Layer 3 to AG1

• Dimension = “restrained” G.8265.1 (< 5 “hops”) • No Physical layer frequency support at Edge

• L2 multicast AG1 edge to eNB

Unicast Layer 3 Packet Network

AG1

m/c L2 Edge

T-BC T-SC

eNB

PRC

GNSS

SSU

GM

PRTC


Example 4: PTP from Core Backup to APTS enabled PRTC

Attributes

• “Centralised “ PTP & syncE with distributed PRTC at edge • PTP Unicast over MPLS, No T-BC in core network (pre-G.8275.2)

• PTP from core used as backup to APTS

• Up to 10 hops Core to Edge

Async Transport

PRC

APTS

GNSS

SSU

GM

PRTC

GNSS

PRTC

L2 or L3

T-SC

eNB


Example 5: Unicast / L2 no syncE + CPRI

Attributes

• SSU + PRTC + GM + PTP Unicast over Layer 2 to BBU site

• No Physical layer frequency support – uses CPRI for Freq

• PTP is backup from PRC between Core and APTS node

Unicast / Layer 2 CPRI

eNB

PRC

GNSS

SSU

GM

PRTC

GNSS

BBU

T-SC

PRTC


Lesson Learned from Field Trials


G.8275.1 isn’t the cure for Asymmetry • Transport elements especially Microwave and routers may cause

stochastic delays

• Embedded BC without APTS capability is incapable of fixing asymmetry

• Nevertheless, some algorithms are better than others..

Lesson Learned from POC #1

22 ©


Lesson Learned from POC #1(Contd.)

TC 2: Partial On-Path

TP2700 with GNSS input

TC 3: Partial On-Path (Loss of GPS)

TP2700 with Asymmetry correction

TC 1: Partial On-Path

TP2700 with PTP input only (BC)

TC 4: Full On-Path Support (G.8275.1)

Embedded in 3rd party CSR


Each transport type has to be tested for PDV separately • Experience shown that one equipment type with same transport

onwards can change result entirely (example on next slide) – 10G Router added 240us of delay over other 10G router from the same

vendor

– Same router created 2us of asymmetry

Lesson Learned from POC #2

24 ©


Asymmetry Histogram pick is at -2.04us :

Floor is at around 371usec delay, overall PDV is above 9.9ms on reverse path!

Lesson Learned from POC #2 (“bad router”)

25 ©


Asymmetry Histogram pick is at 0, 70% of the packets are within +/-200ns:

Floor is at around 127usec delay, overall PDV is ~5us

Lesson Learned from POC #2 (“good router”)

26 ©


Microsemi Corporation (Nasdaq: MSCC) offers a comprehensive portfolio of semiconductor and system

solutions for communications, defense & security, aerospace and industrial markets. Products include high-

performance and radiation-hardened analog mixed-signal integrated circuits, FPGAs, SoCs and ASICs; power

management products; timing and synchronization devices and precise time solutions, setting the world’s standard for time; voice processing devices; RF solutions; discrete components; security technologies and

scalable anti-tamper products; Power-over-Ethernet ICs and midspans; as well as custom design capabilities

and services. Microsemi is headquartered in Aliso Viejo, Calif., and has approximately 3,400 employees globally.

Learn more at www.microsemi.com.

©2015 Microsemi Corporation. All rights reserved. Microsemi and the Microsemi logo are registered trademarks of Microsemi Corporation. All other trademarks and service marks are the property of their respective owners.

Microsemi makes no warranty, representation, or guarantee regarding the information contained herein or the suitability of its products and services for any particular purpose, nor does Microsemi assume any liability whatsoever arising out of the application or use of any product or circuit. The products sold hereunder and any other products sold by Microsemi have been subject to limited testing and should not be used in conjunction with mission-critical equipment or applications. Any performance specifications are believed to be reliable but are not verified, and Buyer must conduct and complete all performance and other testing of the products, alone and together with, or installed in, any end-products. Buyer shall not rely on any data and performance specifications or parameters provided by Microsemi. It is the Buyer’s responsibility to independently determine suitability of any products and to test and verify the same. The information provided by Microsemi hereunder is provided “as is, where is” and with all faults, and the entire risk associated with such information is entirely with the Buyer. Microsemi does not grant, explicitly or implicitly, to any party any patent rights, licenses, or any other IP rights, whether with regard to such information itself or anything described by such information. Information provided in this document is proprietary to Microsemi, and Microsemi reserves the right to make any changes to the information in this document or to any products and services at any time without notice.

Microsemi Corporate Headquarters

One Enterprise, Aliso Viejo, CA 92656 USA Within the USA: +1 (800) 713-4113 Outside the USA: +1 (949) 380-6100 Sales: +1 (949) 380-6136 Fax: +1 (949) 215-4996 email: [email protected]

Thank You!

LTE- A Sync Architecture & Standards - פוקוס...

Documents

Transcript of LTE- A Sync Architecture & Standards - פוקוס...