Ceragon Ip 20 Manual
Ceragon Ip 20 Manual
Ceragon Ip 20 Manual
FibeAir® IP-20G
Technical Description
November 2014
Release: 7.9
Document Revision A.05
Notice
This document contains information that is proprietary to Ceragon Networks Ltd. No part of this
publication may be reproduced, modified, or distributed without prior written authorization of
Ceragon Networks Ltd. This document is provided as is, without warranty of any kind.
Trademarks
Ceragon Networks®, FibeAir® and CeraView® are trademarks of Ceragon Networks Ltd.,
registered in the United States and other countries.
Ceragon® is a trademark of Ceragon Networks Ltd., registered in various countries.
CeraMap™, PolyView™, EncryptAir™, ConfigAir™, CeraMon™, EtherAir™, CeraBuild™, CeraWeb™,
and QuickAir™, are trademarks of Ceragon Networks Ltd.
Other names mentioned in this publication are owned by their respective holders.
Statement of Conditions
The information contained in this document is subject to change without notice. Ceragon
Networks Ltd. shall not be liable for errors contained herein or for incidental or consequential
damage in connection with the furnishing, performance, or use of this document or equipment
supplied with it.
Information to User
Any changes or modifications of equipment not expressly approved by the manufacturer could
void the user’s authority to operate the equipment and the warranty for such equipment.
Table of Contents
1. Synonyms and Acronyms .............................................................................. 14
2. Introduction .................................................................................................... 17
2.1 Product Overview ......................................................................................................... 18
2.1.1 IP-20G Radio Options .................................................................................................. 19
2.1.2 IP-20G Highlights ......................................................................................................... 20
2.1.3 IP-20G Protection Options ........................................................................................... 20
2.2 Reference Configurations ............................................................................................ 21
2.2.1 FibeAir IP-20 Platform Reference Topology ................................................................ 21
2.2.2 Dual Modem Activation ................................................................................................ 22
2.2.3 IDU Cascading with Dual Modems .............................................................................. 23
2.2.4 Chained Network .......................................................................................................... 24
2.2.5 Ring with Spur .............................................................................................................. 25
2.2.6 Aggregation/POP Site .................................................................................................. 26
2.3 New Features in Version T7.9 ..................................................................................... 27
5. Activation Keys............................................................................................... 61
5.1 Working with Activation Keys ....................................................................................... 62
5.2 Demo Mode .................................................................................................................. 62
5.3 Activation Key-Enabled Features ................................................................................. 62
List of Figures
IP-20 Platform Reference Topology .................................................................... 21
Native Sync Distribution Mode – Ring Scenario (Normal Operation) ............. 181
Native Sync Distribution Mode – Ring Scenario (Link Failure) ....................... 182
Hybrid Ethernet and TDM Services................................................................... 185
Hybrid Ethernet and TDM Services Carried Over Cascading Interfaces ........ 185
Hybrid Ethernet and Native TDM Services ....................................................... 186
1:1 TDM Path Protection – Ring Topology ....................................................... 187
List of Tables
New Features in Version T7.9 ............................................................................. 27
IP-20G Interfaces.................................................................................................. 32
2 x FE Splitter Cable Marketing Model................................................................ 35
RFU Selection Guide............................................................................................ 47
Target Audience
This manual is intended for use by Ceragon customers, potential customers,
and business partners. The purpose of this manual is to provide basic
information about the FibeAir IP-20G for use in system planning, and
determining which FibeAir IP-20G configuration is best suited for a specific
network.
Related Documents
FibeAir IP-20G User Guide, DOC-00041190
FibeAir IP-20G Installation Guide, DOC-00041192
FibeAir IP-20 Series MIB Reference
2. Introduction
This chapter provides an overview of the FibeAir IP-20G, Ceragon’s high-
performance edge node product. IP-20G is specially designed for edge/tail
sites, and features a small footprint, high density, and a high degree of
availability.
IP-20G is an integral part of the FibeAir family of high-capacity wireless
backhaul products. Together, the FibeAir family of products provides a wide
variety of backhaul solutions that can be used separately or combined to form
integrated backhaul networks or network segments.
This enables operators to utilize a combination of FibeAir IDUs and radio units
(RFUs) to build networks in which the most appropriate FibeAir product can
be utilized for each node in the network to provide the feature support,
capacity support, frequency range, density, and footprint that is optimized to
meet the needs of that particular node. The FibeAir series “pay-as-you-go”
activation key models further enable operators to build for the future by
adding capacity and functionality over time to meet the needs of network
growth without the need to add additional hardware.
2.1.1.1 RFU-C
FibeAir RFU-C is a fully software configurable, state-of-the-art RFU that
supports a broad range of interfaces and capacities from 10 Mbps up to 500
Mbps. RFU-C operates in the frequency range of 6-42 GHz.
RFU-C supports low to high capacities for traditional voice and Ethernet
services, as well as PDH/SDH or hybrid Ethernet and TDM interfaces. Traffic
capacity throughput and spectral efficiency are optimized with the desired
channel bandwidth. For maximum user choice flexibility, channel bandwidths
can be selected. RFU-Ce provides a range of modulations from QPSK to 1024
QAM.
When RFU-C operates in co-channel dual polarization (CCDP) mode using
XPIC, two carrier signals can be transmitted over a single channel, using
vertical and horizontal polarization. This enables double capacity in the same
spectrum bandwidth.
2.1.1.2 1500HP/RFU-HP
FibeAir 1500HP and RFU-HP are high transmit power RFUs designed for long
haul applications with multiple carrier traffic. Together with their unique
branching design, 1500HP and RFU-HP can chain up to five carriers per single
antenna port and 10 carriers for dual port, making them ideal for Trunk or
Multi Carrier applications. The 1500HP and RFU-HP can be installed in either
indoor or outdoor configurations. The 1500HP and RFU-HP also include a
power-saving feature (“green mode”) that enables the microwave system to
automatically detect when link conditions allow it to use less power.
1500HP/RFU-HP provide a range of modulations from QPSK to 1024 QAM.
1+0
1+0
16xE1s 6xGE/FE
(Optional)
Second Modem
Activation
2+0 XPIC/1+1 HSB
16xE1s 6xGE/FE
(Optional)
16xE1s 6xGE/FE
(Optional)
Second Modem
Activation
1+0 1+0
Second Modem
Activation
32xE1s 10xGE/FE
(Optional)
1+0
1+0
16xE1s 6xGE/FE 1+1/2+0 XPIC
(Optional)
16xE1s 6xGE/FE
(Optional)
32xE1s 10xGE/FE
(Optional)
16xE1s 6xGE/FE
(Optional)
Ring
Protection
16xE1s 6xGE/FE
16xE1s 6xGE/FE (Optional)
(Optional)
1+0
1+0
16xE1s 6xGE/FE
(Optional)
1+0
32xE1s 10xGE/FE
(Optional)
1+0
GE/FE
STM-1s
(Optional)
16xE1s 6xGE/FE
(Optional)
1+0
16xE1s 6xGE/FE
(Optional) 32xE1s 10xGE/FE
(Optional)
1+0
16xE1s 6xGE/FE
(Optional)
Display input voltage indication from CLI command n/a Operation > CLI Configuration >
Platform Configuration > Configuring
Management > Configuring and
Displaying Unit Parameters
Support Web EMS configuration for unmuting remote radio n/a Operation > Web EMS Configuration >
Radio > Remote Radio
Sync
48V
Radio Interface 1
Power
48V Supply Framer Modem IF
RFU
Interface RFU
(Optional Second
Interface)
ABC/BBS XPIC
Sync
Radio Interface 2
Sync
In/Out Sync Unit (Optional)
FE Management
Interfaces
CPU
Terminal
Ethernet
Ethernet Services
TDM Interfaces
GE Traffic
Interfaces
(Optional)
Network
Processor TDM
16 x E1
TDM Pseudowire Services Services Framer LIU
Interface
Processor
GE/Cascading Services
Interfaces
Engine
TDM Cross
Connect
Native TDM
Services
Multi-Carrier
ABC Engine
IP-20G Interfaces
RJ-45 Connector
Management Switch
(female)
TX+ 1
TX- 2
Port 1
RX+ 3
RX- 4
TX+ 5
TX- 6
Port 2
RX+ 7
RX- 8
If the user only needs to use a single management interface, a standard Cat5
RJ-45 cable (straight or cross) can be connected to the MGMT interface.
To access both management interfaces, a special 2 x FE splitter cable can be
ordered from Ceragon.
2 x FE Splitter Cable Marketing Model
1
Remote mount configuration is not supported for 42 GHz.
Split Mount √ √ √
Installation
Type
All-Indoor √
1+0/2+0/1+1/2+2 √ √ √
N+1 √
Configuration
N+0 ( N>2) √
3
SD support √ (IFC , BBS) √ (BBS) √ (BBS)
2
RFU-HP does not support 56 MHz channels at 11 GHz.
3
IFC at 40MHz is supported only for the 11GHz frequency band.
4.3 RFU-C
FibeAir RFU-C is a fully software configurable, state-of-the-art RFU that
supports a broad range of interfaces and capacities from 10 Mbps up to 500
Mbps. RFU-C operates in the frequency range of 6-42 GHz. RFU-C supports low
to high capacities for traditional voice and Ethernet services, as well as
PDH/SDH/SONET or hybrid Ethernet and TDM interfaces.
With RFU-C, traffic capacity throughput and spectral efficiency are optimized
with the desired channel bandwidth. For maximum user choice flexibility,
channel bandwidths from 3.5-56 MHz can be selected together with a range of
modulations. RFU-Ce provides a range of modulations from QPSK to 1024
QAM.4
When RFU-C operates in co-channel dual polarization (CCDP) mode using
XPIC, two carrier signals can be transmitted over a single channel, using
vertical and horizontal polarization. This enables double capacity in the same
spectrum bandwidth.
4
For details about supported modulation capabilities beyond 256 QAM using a standard RFU-C,
contact your Ceragon representative.
5
Remote mount configuration is not supported for 42 GHz.
4.4 1500HP/RFU-HP
FibeAir 1500HP and RFU-HP are high transmit power RFUs designed for long
haul applications with multiple carrier traffic. Together with their unique
branching design, 1500HP/RFU-HP can chain up to five carriers per single
antenna port and 10 carriers for dual port, making them ideal for Trunk or
Multi Carrier applications. The 1500HP/RFU-HP can be installed in either
indoor or split mount configurations.
The field-proven 1500HP/RFU-HP was designed to enable high quality
wireless communication in the most cost-effective manner. With tens of
thousands of units deployed worldwide, the 1500HP/RFU-HP serves mobile
operators enabling them to reach over longer distances while enabling the use
of smaller antennas. The RFU-HP also includes a power-saving feature (“green
mode”) that enables the microwave system to automatically detect when link
conditions allow it to use less power.
1500HP and RFU-HP 1RX support Space Diversity via Baseband Switching in
the IDU (BBS). The 1500HP 2RX, supports Space Diversity through IF
Combining (IFC). Both types of Space Diversity are valid solutions to deal with
the presence of multipath.
1500HP/RFU-HP provides a range of modulations from QPSK to 1024 QAM.
6
For guidance on the differences between 1500HP and RFU-HP, refer to RFU Selection Guide
on page 50.
7
1500 HP (11 GHz ) 40 MHz bandwidth does not support IF Combining. For this frequency,
space diversity is only available via BBS.
8
IP-20G support for 2048 QAM is planned for future release.
TX
350MHz IF TX TX Pre-
PA
chain Amp
Controller and
FSK peripherals DC / CTRL
Quadplexer
C C TCXO
RF LPBK
o o
n n
-48V
PSU
n n
e e RX
c c RX
LNA Extention port
combiner chain RX Main
140MHz t t
o o
r r RX
RX
LNA
chain RX Diversity
10M
diplexer
XLO
XPIC SW
Antenna
VCO
Diversity
IF & controller Board
RX
Chassis
IDU XPIC source
(Ntype conn.) sharing \ RSL ind.
(TNC conn.)
TX
350MHz IF TX TX FMM FLM
chain
Controller and
FSK peripherals DC / CTRL
Quadplexer
C C TXCO
RF LPBK
o o
n n
-48V
PSU
n n
e e RX
c c RX
LNA Extention port
chain RX Main
140MHz t t
o o
r r
10M
diplexer
XLO
XPIC SW
VCO
IF & controller Board
RX Board
Chassis
IDU XPIC source
(Ntype conn.) sharing \ RSL ind.
(TNC conn.)
TX
350MHz IF
TX
TX Pre-
RFIC PA
chain Amp
C C
(BMA conn.)
o o
IDU
n n 40M
RF LPBK
e e
c c
sharing \ RSL
-48V
XPIC source
(BMA conn.)
PSU section t t
ind.
o o RX
RX
r r RX
RFIC chain LNA Extention port
140MHz
40M
diplexer
XLO
XPIC SW
VCO
PSC TRX
Chassis
XPIC source
sharing \ RSL ind.
(TNC conn.)
Note that the main differences between the 1500HP 1RX and RFU-HP 1RX are:
The RFU-HP 1RX offers full support for 3.5M-56MHz channels.
The RFU-HP 1RX supports the green-mode feature
Both systems are fully compatible with all OCB and ICB devices.
9
1500 HP (11 GHz ) 40 MHz bandwidth does not support IF Combining. For this frequency,
space diversity is only available via BBS.
OCB – The Tx and the Rx path circulate together to the main OCB port.
When chaining multiple OCBs, each Tx signal is chained to the OCB Rx
signal and so on (uses S-bend section). For more details, refer to
1500HP/RFU-HP OCBs on page 55.
ICB – All the Tx signals are chained together to one Tx port (at the ICC) and
all the Rx signals are chained together to one Rx port (at the ICC). The ICC
circulates all the Tx and the Rx signals to one antenna port.
ld OCB OCB
Diversity/Non-Diversity Split-Mount
Space Diversity IFC (2Rx) (6, 7, 8 ,11GHz) 15OCBf-SD-xxxy-ZZZ-H/L
Non Space Diversity (1Rx) (6, 7, 8GHz) 15OCBf-xxxy-ZZ-H/L
10
11GHz Non Space Diversity (1Rx) 15OCB11w-xxxy-ZZ-H/L
10
11GHz OCB is a wide BW OCB which supports up to 40MHz, while the other OCBs (6L, 6H, 7,
8GHz) support up to 30MHz.
11
11GHz OCB is a wide BW OCB which supports up to 40MHz, while the other OCBs (6L, 6H, 7,
8GHz) support up to 30MHz.
5. Activation Keys
This chapter describes IP-20G’s activation key model. IP-20G offers a pay as-
you-grow concept in which future capacity growth and additional
functionality can be enabled with activation keys. Each unit contains a single
activation key.
Activation keys are divided into two categories:
Per Carrier – The activation key is per carrier.
Per Device – The activation key is per device, regardless of the number of
carriers supported by the device.
A 1+1 HSB configuration requires the same set of per-carrier activation keys
for both the active and the protected carriers.
12
H-QoS support is planned for future release.
IP-20-SL-Eth-OAM-FM Per Device Enables Connectivity Fault Management Connectivity Fault Management (FM)
(FM) per Y.1731/ 802.1ag and 802.3ah (CET
14
mode only).
13
Support for HTTPS and RADIUS is planned for future release.
14
FM support is planned for future release.
15
PM support is planned for future release.
6. Feature Description
This chapter describes the main IP-20G features. The feature descriptions are
divided into the categories listed below.
16
IP-20G support for 2048 QAM is planned for future release.
Header De-Duplication identifies traffic flows and replaces the header fields
with a "flow ID". This is done using a sophisticated algorithm that learns
unique flows by looking for repeating frame headers in the traffic stream over
the radio link and compressing them. The principle underlying this feature is
that frame headers in today’s networks use a long protocol stack that contains
a significant amount of redundant information.
Header De-Duplication can be customized for optimal benefit according to
network usage. The user can determine the layer or layers on which Header
De-Duplication operates, with the following options available:
Layer2 – Header De-Duplication operates on the Ethernet level.
MPLS – Header De-Duplication operates on the Ethernet and MPLS levels.
Layer3 – Header De-Duplication operates on the Ethernet and IP levels.
Layer4 – Header De-Duplication operates on all supported layers up to
Layer 4.
Tunnel – Header De-Duplication operates on Layer 2, Layer 3, and on the
Tunnel layer for packets carrying GTP or GRE frames.
Tunnel-Layer3 – Header De-Duplication operates on Layer 2, Layer 3, and
on the Tunnel and T-3 layers for packets carrying GTP or GRE frames.
IP-20G
Layer 3 | IPv4/IPv6
18/40 bytes compressed
Layer 4 | TCP/UDP
4/6 bytes compressed
End User
6.1.3 Latency
IP-20G provides best-in-class latency (RFC-2544) for all channels, making it
the obvious choice for LTE (Long-Term Evolution) networks. Refer to Ethernet
Latency Specifications on page 257.
IP-20G’s ability to meet the stringent latency requirements for LTE systems
provides the key to expanded broadband wireless services:
Longer radio chains
Larger radio rings
Shorter recovery times
More capacity
Easing of Broadband Wireless Access (BWA) limitations
Related topics:
Ethernet Latency Specifications
Egress Scheduling
Frame Cut-Through is a unique and innovative feature that ensures low
latency for delay-sensitive services, such as CES, VoIP, and control protocols.
With Frame Cut-Through, high-priority frames are pushed ahead of lower
priority frames, even if transmission of the lower priority frames has already
begun. Once the high priority frame has been transmitted, transmission of the
lower priority frame is resumed with no capacity loss and no re-transmission
required. This provides operators with:
Immunity to head-of-line blocking effects – key for transporting high-
priority, delay-sensitive traffic.
Reduced delay-variation and maximum-delay over the link:
Reduced end-to-end delay for TDM services.
Improved QoE for VoIP and other streaming applications.
Expedited delivery of critical control frames.
Propagation Delay with and without Frame Cut-Through
Propagation Delay
When enabled, Frame Cut-Through applies to all high priority frames, i.e., all
frames that are classified to a CoS queue with 4th (highest) priority.
Frame Cut-Through Operation
Related topics:
Cross Polarization Interference Canceller (XPIC)
Quality of Service (QoS)
FibeAir IP-20G employs full-range dynamic ACM. IP-20G’s ACM mechanism
copes with 90 dB per second fading in order to ensure high transmission
quality. IP-20G’s ACM mechanism is designed to work with IP-20G’s QoS
mechanism to ensure that high priority voice and data frames are never
dropped, thus maintaining even the most stringent service level agreements
(SLAs).
The hitless and errorless functionality of IP-20G’s ACM has another major
advantage in that it ensures that TCP/IP sessions do not time-out. Without
ACM, even interruptions as short as 50 milliseconds can lead to timeout of
TCP/IP sessions, which are followed by a drastic throughout decrease while
these sessions recover.
In the case of XPIC/ACM scripts, all the required conditions for XPIC apply.
The user can define a maximum profile. For example, if the user selects a
maximum profile of 5, the system will not climb above profile 5, even if
channel fading conditions allow it.
V V+h V
Carrier 1 Carrier 1
h
v
Carrier 2 Carrier 2
H H+v H
IP-20G IP-20G
The H+v signal is the combination of the desired signal H (horizontal) and the
interfering signal V (in lower case, to denote that it is the interfering signal).
The same happens with the vertical (V) signal reception= V+h. The XPIC
mechanism uses the received signals from both feeds and, manipulates them
to produce the desired data.
XPIC – Impact of Misalignments and Channel Degradation
Coupler Coupler
B -6d
-6d B
Coupling Path
Coupling Path
6.2.4 ATPC
ATPC is a closed-loop mechanism by which each carrier changes the
transmitted signal power according to the indication received across the link,
in order to achieve a desired RSL on the other side of the link.
ATPC enables the transmitter to operate at less than maximum power for
most of the time. When fading conditions occur, transmit power is increased
as needed until the maximum is reached.
The ATPC mechanism has several potential advantages, including less
transmitter power consumption and longer amplifier component life, thereby
reducing overall system cost.
ATPC is frequently used as a means to mitigate frequency interference issues
with the environment, thus allowing new radio links to be easily coordinated
in frequency congested areas.
Carrier 1 Carrier 1
Carrier 2 Carrier 2
Traffic Eth
Eth Traffic Splitter
Combiner
Carrier 3 Carrier 3
Carrier 4 Carrier 4
Radio &
RX
RMC
M
U
ABC
X
RX
SD RX
6.3.1.1 EVC
Subscriber services extend from UNI to UNI. Connectivity between UNIs is
defined as an Ethernet Virtual Connection (EVC), as shown in the following
figure.
Ethernet Virtual Connection (EVC)
An EVC is defined by the MEF as an association of two or more UNIs that limits
the exchange of service frames to UNIs in the Ethernet Virtual Connection. The
EVC perform two main functions:
Connects two or more customer sites (UNIs), enabling the transfer of
Ethernet frames between them.
Prevents data transfer involving customer sites that are not part of the
same EVC. This feature enables the EVC to maintain a secure and private
data channel.
A single UNI can support multiple EVCs via the Service Multiplexing attribute.
An ingress service frame that is mapped to the EVC can be delivered to one or
more of the UNIs in the EVC, other than the ingress UNI. It is vital to avoid
delivery back to the ingress UNI, and to avoid delivery to a UNI that does not
belong to the EVC. An EVC is always bi-directional in the sense that ingress
service frames can originate at any UNI in an EVC.
Service frames must be delivered with the same Ethernet MAC address and
frame structure that they had upon ingress to the service. In other words, the
frame must be unchanged from source to destination, in contrast to routing in
which headers are discarded. Based on these characteristics, an EVC can be
used to form a Layer 2 private line or Virtual Private Network (VPN).
One or more VLANs can be mapped (bundled) to a single EVC.
The MEF defines three generic Ethernet service type constructs, including
their associated service attributes and parameters:
Ethernet Line (E-Line)
Ethernet LAN (E-LAN)
Ethernet Tree (E-Tree)
Multiple Ethernet services are defined for each of the three generic Ethernet
service types. These services are differentiated by the method for service
identification used at the UNIs. Services using All-to-One Bundling UNIs (port-
based) are referred to as “Private” services, while services using Service
Multiplexed (VLAN-based) UNIs are referred to as “Virtual Private” services.
This relationship is shown in the following table.
MEF-Defined Ethernet Service Types
All-to-One Bundling refers to a UNI attribute in which all Customer Edge VLAN
IDs (CE-VLAN IDs) entering the service via the UNI are associated with a
single EVC. Bundling refers to a UNI attribute in which more than one CE-
VLAN ID can be associated with an EVC.
E-Line Service
The Ethernet line service (E-Line service) provides a point-to-point Ethernet
Virtual Connection (EVC) between two UNIs. The E-Line service type can be
used to create a broad range of Ethernet point-to-point services and to
maintain the necessary connectivity. In its simplest form, an E-Line service
type can provide symmetrical bandwidth for data sent in either direction with
no performance assurances, e.g., best effort service between two FE UNIs. In
more sophisticated forms, an E-Line service type can provide connectivity
between two UNIs with different line rates and can be defined with
performance assurances such as CIR with an associated CBS, EIR with an
associated EBS, delay, delay variation, loss, and availability for a given Class of
Service (CoS) instance. Service multiplexing can occur at one or both UNIs in
the EVC. For example, more than one point-to-point EVC can be offered on the
same physical port at one or both of the UNIs.
E-Line Service Type Using Point-to-Point EVC
to a single EVC at the UNI. In cases where the EVC speed is less than the UNI
speed, the CE is expected to shape traffic to the ingress bandwidth profile of
the service to prevent the traffic from being discarded by the service. The EPL
is a port-based service, with a single EVC across dedicated UNIs providing site-
to-site connectivity. EPL is the most popular Ethernet service type due to its
simplicity, and is used in diverse applications such as replacing a TDM private
line.
EPL Application Example
E-LAN Service
The E-LAN service type is based on Multipoint to Multipoint EVCs, and
provides multipoint connectivity by connecting two or more UNIs. Each site
(UNI) is connected to a multipoint EVC, and customer frames sent from one
UNI can be received at one or more UNIs. If additional sites are added, they
can be connected to the same multipoint EVC, simplifying the service
activation process. Logically, from the point of view of a customer using an
E-LAN service, the MEN can be viewed as a LAN.
E-LAN Service Type Using Multipoint-to-Multipoint EVC
The E-LAN service type can be used to create a broad range of services. In its
basic form, an E-LAN service can provide a best effort service with no
performance assurances between the UNIs. In more sophisticated forms, an
E-LAN service type can be defined with performance assurances such as CIR
with an associated CBS, EIR with an associated EBS, delay, delay variation,
loss, and availability for a given CoS instance.
For an E-LAN service type, service multiplexing may occur at none, one, or
more than one of the UNIs in the EVC. For example, an E-LAN service type
(Multipoint-to-Multipoint EVC) and an E-Line service type (Point-to-Point
EVC) can be service multiplexed at the same UNI. In such a case, the E-LAN
service type can be used to interconnect other customer sites while the E-Line
service type is used to connect to the Internet, with both services offered via
service multiplexing at the same UNI.
E-LAN services can simplify the interconnection among a large number of
sites, in comparison to hub/mesh topologies implemented using point-to-
point networking technologies such as Frame Relay and ATM.
In contrast, when using an E-LAN service, it is only necessary to add the new
UNI to the multipoint EVC. No additional EVCs are required, since the E-LAN
service uses a multipoint to multipoint EVC that enables the new UNI to
communicate with each of the others UNIs. Only one EVC is required to
achieve multi-site connectivity, as shown in the following figure.
Adding a Site Using an E-LAN service
The E-LAN service type can be used to create a broad range of services, such
as private LAN and virtual private LAN services.
E-Tree Service
The E-Tree service type is an Ethernet service type that is based on Rooted-
Multipoint EVCs. In its basic form, an E-Tree service can provide a single Root
for multiple Leaf UNIs. Each Leaf UNI can exchange data with only the Root
UNI. A service frame sent from one Leaf UNI cannot be delivered to another
Leaf UNI. This service can be particularly useful for Internet access, and video-
over-IP applications such as multicast/broadcast packet video. One or more
CoS values can be associated with an E-Tree service.
E-Tree Service Type Using Rooted-Multipoint EVC
Two or more Root UNIs can be supported in advanced forms of the E-Tree
service type. In this scenario, each Leaf UNI can exchange data only with the
Root UNIs. The Root UNIs can communicate with each other. Redundant
access to the Root can also be provided, effectively allowing for enhanced
service reliability and flexibility.
The IP-20G services concept is purpose built to support the standard MEF
services for mobile backhaul (MEF 22, mobile backhaul implementation
agreement), as an addition to the baseline definition of MEF Services (MEF 6)
using service attributes (as well as in MEF 10). E-Line, E-LAN and E-Tree
services are well defined as the standard services.
Any Service
Ethernet services (EVCs)
E-Line (Point-to-Point)
E-LAN (Multipoint)
E-Tree (Point-to-Multipoint)17
Port based (Smart Pipe) services
Any Transport
Native Ethernet (802.1Q/Q-in-Q)
Any topology and any mix of radio and fiber interfaces
Seamless interworking with any optical network (NG-SDH, packet optical
transport, IP/MPLS service/VPN routers)
17
E-Tree services are planned for future release.
18
H-QoS support is planned for future release.
19
CFM support is planned for future release.
20
E-Tree service support is planned for future release.
21
Split horizon is planned for future release.
22
LAG support is planned for future release.
P2P
Service
SNP SNP
UNI
P2P
NNI
Service
SAP SAP
Multipoint SNP SNP Multipoint
SN
SA Service Service
SNP SNP
PP SNP SNP
IP-20G
SAP SAP
SNP SNP
Multipoint Multipoint
Service Service
SNP
SNP
SAP
P2P
Service
SNP
SNP
SNP SNP
IP-20G IP-20G
Multipoint
Service
SNP
SNP SAP
IP-20G
The IP-20G services core provides for fully flexible C-VLAN and S-VLAN
encapsulation, with a full range of classification, preservation, and translation
options available. Service security and isolation is provided without limiting
the C-VLAN reuse capabilities of different customers.
P2P Service
Port 4 SP SP
SAP Port 9
SAP
P2P Service
User Port
Multipoint Service
SAP SNP
P2P Service
Port 1 Port 4
SP SP
SAP
SAP
Port 2 Port 5
P2P Service
SP
SAP SP
SAP
Port 3 Port 6
P2P services provide the building blocks for network services such as E-Line
EVC (EPL and EVPL EVCs) and port-based services (Smart Pipe).
Multipoint Service
Port 1 SP SP Port 4
SAP SAP
SP
SAP
Port 2 Port 5
SP SP
SAP
SAP
Port 3 Port 6
Multipoint services provide the building blocks for network services such as
E-LAN EVCs (EP-LAN and EVP-LAN EVCs), and for E-Line EVCs (EPL and EVPL
EVCs) in which only two service points are active. In such a case, the user can
disable MAC address learning in the service points to conserve system
resources.
The following table illustrates the operation of the learning and forwarding
mechanism.
Ethernet Services Learning and Forwarding
In addition to the dynamic learning mechanism, users can add static MAC
addresses for static routing in each service. These user entries are not
considered when determining the maximum size of the MAC forwarding table.
Users can manually clear all the dynamic entries from the MAC forwarding
table. Users can also delete static entries per service.
The system also provides an automatic flush process. An entry is erased from
the table as a result of:
The global aging time expires for the entry.
Loss of carrier occurs on the interface with which the entry is associated.
Resiliency protocols, such as MSTP or G.8032.
Management Service
Port 1
Port 4
SP
SAP SP
SAP
Port 2
Port 5
SP SP
SAP
SAP
Port 3
Port 6
SP SP
SAP
SAP
Local Management 1
Local Management 2
CPU
Management services can provide building blocks for network services such
as E-LAN EVCs (EP-LAN and EVP-LAN), as well as E-Line EVCs (EPL and EVPL
EVCs) in which only two service points are active.
Service Attributes
IP-20G services have the following attributes:
Service ID – A running number from 1 to 1024 that identifies the service.
The user must select the Service ID upon creating the service. The Service
ID cannot be edited after the service has been created. Service ID 1025 is
used for the pre-defined Management service.
Service Type – Determines the specific functionality that will be provided
for Ethernet traffic using the service. For example, a Point-to-Point service
provides traffic forwarding between two service points, with no need to
learn a service topology based on source and destination MAC addresses. A
Multipoint service enables operators to create an E-LAN service that
includes several service points.
Service Admin Mode – Defines whether or not the service is functional,
i.e., able to receive and transmit traffic. When the Service Admin Mode is
set to Operational, the service is fully functional. When the Service Admin
Mode is set to Reserved, the service occupies system resources but is
unable to transmit and receive data.
EVC-ID – The Ethernet Virtual Connection ID (end-to-end). This parameter
does not affect the network element’s behavior, but is used by the NMS for
topology management.
EVC Description – The Ethernet Virtual Connection description. This
parameter does not affect the network element’s behavior, but is used by
the NMS for topology management.
MNG
MNG MNG
MNG
MNG
MNG MNG
MNG MNG
MNG MNG
MNG
SAP
SNP SNP
SNP
SNP
SAP SAP
SNP SNP
SNP SNP
SAP
The following figure shows the usage of SAP, SNP and PIPE service points in a
microwave network. The SNPs are used for interconnection between the
network elements while the SAPs provide the access points for the network. A
Smart Pipe is also used, to provide connectivity between elements that require
port-based connectivity.
SAP, SNP and Pipe Service Points in a Microwave Network
Fiber Aggregation
Network
SAP
SNP
SNP
SNP
Microwave
SNP Network
SAP
SNP
SNP
NOC SNP
SNP
SNP
SNP
SNP
SAP
PIPE
PIPE
SNP
SAP
SAP
Base Station
The following table summarizes the service point types available per service
type.
Service Point Types per Service Type
SAP Classification
SAPs can be used with the following Attached Interface Types:
All to one – All C-VLANs and untagged frames that enter the interface are
classified to the same service point.
Dot1q – A single C-VLAN is classified to the service point.
QinQ – A single S-VLAN and C-VLAN combination is classified to the
service point.
Bundle C-Tag– A set of multiple C-VLANs are classified to the service
point.
Bundle S-Tag – A single S-VLAN and a set of multiple C-VLANs are
classified to the service point.
SNP classification
SNPs can be used with the following Attached Interface Types:
Dot1q – A single C VLAN is classified to the service point.
S-Tag – A single S- VLAN is classified to the service point.
MNG classification
Management service points can be used with the following Attached Interface
Types:
Dot1q – A single C-VLAN is classified to the service point.
S-Tag – A single S-VLAN is classified to the service point.
QinQ – A single S-VLAN and C-VLAN combination is classified into the
service point.
The following table shows which service point types can co-exist on the same
interface.
Service Point Types that can Co-Exist on the Same Interface
The following table shows in more detail which service point – Attached
Interface Type combinations can co-exist on the same interface.
Service Point Type-Attached Interface Type Combinations that can Co-Exist on the Same Interface
SP Type SAP SNP Pipe MNG
Attached Bundle Bundle
SP Type 802.1q All to One QinQ 802.1q S-Tag 802.1q S-Tag 802.1q QinQ S-Tag
Interface Type C-Tag S-Tag
Only for P2P
802.1q Yes Yes No No No No No No Yes No No
Service
Only for P2P
Bundle C-Tag Yes Yes No No No No No No Yes No No
Service
SAP
Bundle S-Tag No No Yes No Yes No No No No No Yes No
Only 1 All to One
All to One No No No No No No No No No No No
SP Per Interface
QinQ No No Yes No Yes No No No No No Yes No
Only for P2P
802.1q No No No No No Yes No No Yes No No
Service
SNP
Only for P2P
S-Tag No No No No No No Yes No No No Yes
Service
Only for P2P Only for P2P Only for P2P Only one Pipe SP
802.1q No No No No No Yes No No
Service Service Service Per Interface
Pipe
Only for P2P Only one Pipe SP
S-Tag No No No No No No No No No Yes
Service Per Interface
802.1q Yes Yes No No No Yes No Yes No No No No
MNG QinQ No No Yes No Yes No No No No No No No
S-Tag No No No No No No Yes No Yes No No No
SP1 SP2
Ingress Ingress
Port 1 Port 2
Egress Egress
When physical interfaces are grouped into a logical interface, IP-20G also
shows standard RMON statistics for the logical interface, i.e., for the group.
This information enables users to determine the cumulative statistics for the
group, rather than having to examine the statistics for each interface
individually.
Grouped Interfaces as a Single Logical Interface on Ingress Side
Physical Interface 2
Logical Interface SP SP
Physical Interface 1 Lo
gic
al I Physical Interface 3
nte
rfa
ce
LAG
Physical Interface 4
Physical Interface 2 Logical Interface SP SP
Service
23
This functionality is planned for future release.
Ethernet Statistics
The FibeAir IP-20G platform stores and displays statistics in accordance with
RMON and RMON2 standards.
Users can display various peak TX and RX rates (in seconds) and average TX
and RX rates (in seconds), both in bytes and in packets, for each measured
time interval. Users can also display the number of seconds in the interval
during which TX and RX rates exceeded the configured threshold.
The following transmit statistic counters are available:
Transmitted bytes (not including preamble) in good or bad frames. Low 32
bits.
Transmitted bytes (not including preamble) in good or bad frames. High
32 bits.
Transmitted frames (good or bad)
Multicast frames (good only)
Broadcast frames (good only)
Control frames transmitted
Pause control frame transmitted
FCS error frames
Frame length error
Oversized frames – frames with length > 1518 bytes (1522 bytes for VLAN-
tagged frames) without errors
Undersized frames (good only)
Fragments frames (undersized bad)
Jabber frames – frames with length > 1518 bytes (1522 for VLAN-tagged
frames) with errors
Frames with length 64 bytes, good or bad
Frames with length 65-127 bytes, good or bad
Frames with length 128-255 bytes, good or bad
Frames with length 256-511 bytes, good or bad
Frames with length 512-1023 bytes, good or bad.
Frames with length 1024-1518 bytes, good or bad
Frames with length 1519-1522 bytes, good or bad
The following receive statistic counters are available:
Received bytes (not including preamble) in good or bad frames. Low 32 bits.
Received bytes (not including preamble) in good or bad frames. High 32 bits.
Received frames (good or bad)
Multicast frames (good only)
Broadcast frames (good only)
Control frames received
Pause control frame received
FCS error frames
Frame length error
Code error
Counts oversized frames – frames with length > 1518 bytes (1522 bytes
for VLAN-tagged frames) without errors and frames with length >
MAX_LEN without errors
Undersized frames (good only)
Fragments frames (undersized bad)
Counts jabber frames – frames with length > 1518 bytes (1522 for VLAN-
tagged frames) with errors
Frames with length 64 bytes, good or bad
Frames with length 65-127 bytes, good or bad
Frames with length 128-255 bytes, good or bad
Frames with length 256-511 bytes, good or bad
Frames with length 512-1023 bytes, good or bad
Frames with length 1024-1518 bytes, good or bad
VLAN-tagged frames with length 1519-1522 bytes, good or bad
Frames with length > MAX_LEN without errors
Frames with length > MAX_LEN with errors
Radio
Interface 1 Physical Interface 1
General Attributes
Traffic Flow Administration – Enables traffic via the logical interface.
This attribute is useful when the user groups several physical interfaces
into a single logical interface. The user can enable or disable traffic to the
group using this parameter.
Default CoS – The default CoS value for frames passing through the
interface. This value can be overwritten on the service point and service
level. The Color is assumed to be Green.
For more information about classification at the logical interface level, refer to
Logical Interface-Level Classification on page 137.
24
This attribute is reserved for future use. The current release supports traffic shaping per queue
and per service bundle, which provides the equivalent of shaping per logical interface.
Related topics:
Ethernet Service Mode
In-Band Management
Quality of Service (QoS) deals with the way frames are handled within the
switching fabric. QoS is required in order to deal with many different network
scenarios, such as traffic congestion, packet availability, and delay restrictions.
IP-20G’s personalized QoS enables operators to handle a wide and diverse
range of scenarios. IP-20G’s smart QoS mechanism operates from the frame’s
ingress into the switching fabric until the moment the frame egresses via the
destination port.
QoS capability is very important due to the diverse topologies that exist in
today’s network scenarios. These can include, for example, streams from two
different ports that egress via single port, or a port-to-port connection that
holds hundreds of services. In each topology, a customized approach to
handling QoS will provide the best results.
The figure below shows the basic flow of IP-20G’s QoS mechanism. Traffic
ingresses (left to right) via the Ethernet or radio interfaces, on the “ingress
path.” Based on the services model, the system determines how to route the
traffic. Traffic is then directed to the most appropriate output queue via the
“egress path.”
QoS Block Diagram
Egress
Ingress
Marker
Rate Limit (Optional)
GE/Radio Port Classifier
(Policing) Queue Scheduler/
Manager Shaper
Port GE/Radio
(Optional)
Standard QoS/ H-QoS
Egress
Ingress
Marker
Rate Limit (Optional)
GE/Radio Port Classifier
(Policing) Queue Scheduler/
Manager Shaper
Port GE/Radio
(Optional)
Standard QoS/ H-QoS
Egress
Ingress CET/Pipe Marker
Rate Limit Services (Optional)
GE/Radio Port Classifier
(Policing) Queue Scheduler/
Manager Shaper
Port GE/Radio
(Optional)
Standard QoS/ H-QoS
The following figure illustrates the difference between how standard QoS and
H-QoS handle traffic:
Standard QoS and H-QoS Comparison
Standard QoS
V
Service 1 Voice
D
V Data
D Eth. Ethernet
Service 2 S traffic Radio
V
D S
Streaming
Service 3 S
H-QoS
V
Service 1 D Service 1
S
V
D
Ethernet
Service 2 Service 2
S
Radio
V
Service 3 D Service 3
S
Classification
IP-20G supports a hierarchical classification mechanism. The classification
mechanism examines incoming frames and determines their CoS and Color.
The benefit of hierarchical classification is that it provides the ability to “zoom
in” or “zoom out”, enabling classification at higher or lower levels of the
hierarchy. The nature of each traffic stream defines which level of the
hierarchical classifier to apply, or whether to use several levels of the
classification hierarchy in parallel.
The hierarchical classifier consists of the following levels:
Logical interface-level classification
Service point-level classification
Service level classification
SAP SNP
SAP
Logical interface level Service level
VLAN ID Default CoS
802.1p-based CoS Preserve Service Point Decision
DSCP-based CoS
MPLS EXP-based CoS
Default CoS
SAP SNP
SNP
SAP
Service
If no match is found at the logical interface level, the default CoS is applied to
incoming frames at this level. In this case, the Color of the frame is assumed to
be Green.
The following figure illustrates the hierarchy of priorities among classification
methods, from highest (on the left) to lowest (on the right) priority.
Classification Method Priorities
Highest
Priority
Lowest
Priority
Default value is CoS equal best effort and Color equal Green.
MPLS EXP Default Mapping to CoS and Color
If the service point CoS mode is configured to preserve previous CoS decision,
the CoS and Color are taken from the classification decision at the logical
interface level. If the service point CoS mode is configured to default service
point CoS mode, the CoS is taken from the service point’s default CoS, and the
Color is Green.
Service-Level Classification
Classification at the service level enables users to provide special treatment to
an entire service. For example, the user might decide that all frames in a
management service should be assigned a specific CoS regardless of the
ingress port. The following classification modes are supported at the service
level:
Preserve previous CoS decision (service point level)
Default CoS
If the service CoS mode is configured to preserve previous CoS decision,
frames passing through the service are given the CoS and Color that was
assigned at the service point level. If the service CoS mode is configured to
default CoS mode, the CoS is taken from the service’s default CoS, and the
Color is Green.
25
Service point-level rate metering is planned for future release.
26
Service point and CoS-level rate metering is planned for future release.
CoS 1
Service Frame
CoS 2 Ethertype
Point Type
CoS 3
At each level (logical interface, service point, and service point + CoS), users
can attach and activate a rate meter profile. Users must create the profile first,
then attach it to the interface, service point, or service point + CoS.
Committed Burst Size (CBS) – Frames within the defined CBS are marked
Green and passed through the QoS module. This limits the maximum
number of bytes available for a burst of service frames in order to ensure
that traffic conforms to the CIR. Permitted values are 2 to 128 Kbytes, with
a minimum granularity of 2 Kbytes.
Excess Information Rate (EIR) – Frames within the defined EIR are
marked Yellow and processed according to network availability. Frames
beyond the combined CIR and EIR are marked Red and dropped by the
policer. Permitted values are 0 to 1 Gbps, with a minimum granularity of
32 Kbps.
Excess Burst Size (EBS) – Frames within the defined EBS are marked
Yellow and processed according to network availability. Frames beyond
the combined CBS and EBS are marked Red and dropped by the policer.
Permitted values are 2 to 128 Kbytes, with a minimum granularity of
2 Kbytes.
Color Mode – Color mode can be enabled (Color aware) or disabled (Color
blind). In Color aware mode, all frames that ingress with a CFI/DEI field set
to 1 (Yellow) are treated as EIR frames, even if credits remain in the CIR
bucket. In Color blind mode, all ingress frames are treated first as Green
frames regardless of CFI/DEI value, then as Yellow frames (when there is
no credit in the Green bucket). A Color-blind policer discards any previous
Color decisions.
Coupling Flag – If the coupling flag between the Green and Yellow buckets
is enabled, then if the Green bucket reaches the maximum CBS value the
remaining credits are sent to the Yellow bucket up to the maximum value
of the Yellow bucket.
The following parameter is neither a profile parameter, nor specifically a rate
meter parameter, but rather, is a logical interface parameter. For more
information about logical interfaces, refer to Logical Interfaces on page 129.
Line Compensation – A rate meter can measure CIR and EIR at Layer 1 or
Layer 2 rates. Layer 1 capacity is equal to Layer 2 capacity plus 20
additional bytes for each frame due to the preamble and Inter Frame Gap
(IFG). In most cases, the preamble and IFG equals 20 bytes, but other
values are also possible. Line compensation defines the number of bytes to
be added to each frame for purposes of CIR and EIR calculation. When Line
Compensation is 20, the rate meter operates as Layer 1. When Line
Compensation is 0, the rate meter operates as Layer 2. This parameter is
very important to users that want to distinguish between Layer 1 and
Layer 2 traffic. For example, 1 Gbps of traffic at Layer 1 is equal to
~760 Mbps if the frame size is 64 bytes, but ~986 Mbps if the frame size is
1500 bytes. This demonstrates that counting at Layer 2 is not always fair
in comparison to counting at Layer 1, that is, the physical level.
Queue Manager
The queue manager (QM) is responsible for managing the output transmission
queues. IP-20G supports up to 2K service-level transmission queues, with
configurable buffer size. Users can specify the buffer size of each queue
independently. The total amount of memory dedicated to the queue buffers is
2 Gbits.
SP1 CoS2
SP3
CoS3 Service Bundle 1
CoS4 (8 Queues)
Multipoint
Service CoS5
CoS6
SP2 SP7 CoS7
CoS0
CoS1
SP2 SP3
CoS2
CoS7
CoS0
SP1
Drop Ratio CoS1
(%) CoS2
Queue
Multipoint SP3 CoS3 Service Bundle 3
Occupancy (KB)
Service CoS4 (8 Queues)
SP2 CoS5
CoS6
CoS7
CoS2
CoS5
Multipoint SP3 CoS6
Service CoS7
SP2
In the figure above, traffic is passing from left to right. The traffic passing from
the ingress path is routed to the correct egress destination interfaces via the
egress service points. As part of the assignment of the service points to the
interfaces, users define the group of eight queues through which traffic is to be
transmitted out of the service point. This is part of the service point egress
configuration.
After the traffic is tunneled from the ingress service points to the egress
service points, it is aggregated into one of the eight queues associated with the
specific service point. The exact queue is determined by the CoS calculated by
the ingress path. For example, if the calculated CoS is 6, the traffic is sent to
queue 6, and so on.
Before assigning traffic to the appropriate queue, the system makes a
determination whether to forward or drop the traffic using a WRED algorithm
with a predefined green and yellow curve for the desired queue. This
operation is integrated with the queue occupancy level.
The 2K queues share a single memory of 2 Gbits. IP-20G enables users to
define a specific size for each queue which is different from the default size.
Moreover, users can create an over-subscription scenario among the queues
for when the buffer size of the aggregate queues is lower than the total
memory allocated to all the queues. In doing this, the user must understand
both the benefits and the potential hazards, namely, that if a lack of buffer
space occurs, the queue manager will drop incoming frames without applying
the usual priority rules among frames.
The queue size is defined by the WRED profile that is associated with the
queue. For more details, refer to WRED on page 146.
WRED
The Weighted Random Early Detection (WRED) mechanism can increase
capacity utilization of TCP traffic by eliminating the phenomenon of global
synchronization. Global synchronization occurs when TCP flows sharing
bottleneck conditions receive loss indications at around the same time. This
can result in periods during which link bandwidth utilization drops
significantly as a consequence of simultaneous falling to a ”slow start” of all
the TCP flows. The following figure demonstrates the behavior of two TCP
flows over time without WRED.
Synchronized Packet Loss
When queue occupancy goes up, this means that the ingress path rate (the TCP
stream that is ingressing the switch) is higher than the egress path rate. This
difference in rates should be fixed in order to reduce packet drops and to
reach the maximal media utilization, since IP-20G will not egress packets to
the media at a rate which is higher than the media is able to transmit.
To deal with this, IP-20G enables users to define up to 30 WRED profiles. Each
profile contains a Green traffic curve and a Yellow traffic curve. These curves
describe the probability of randomly dropping frames as a function of queue
occupancy. In addition, using different curves for Yellow packets and Green
packets enables users to enforce the rule that Yellow packets be dropped
before Green packets when there is congestion.
IP-20G also includes a pre-defined read-only WRED profile that defines a tail-
drop curve. This profile is assigned profile number 31, and is configured with
the following values:
100% Yellow traffic drop after 16kbytes occupancy.
100% Green traffic drop after 32kbytes occupancy.
Yellow maximum drop is 100%
Green maximum drop is 100%
A WRED profile can be assigned to each queue. The WRED profile assigned to
the queue determines whether or not to drop incoming packets according to
the occupancy of the queue. Basically, as queue occupancy grows, the
probability of dropping each incoming frame increases as well. As a
consequence, statistically more TCP flows will be restrained before traffic
congestion occurs.
Yellow max
drop ratio
Green max
drop ratio
Queue depth [bytes]
Yellow min Green min
threshold threshold
Note: The tail-drop profile, Profile 31, is the default profile for
each queue. A tail drop curve is useful for reducing the
effective queue size, such as when low latency must be
guaranteed.
For each curve, frames are passed on and not dropped up to the minimum
Green and Yellow thresholds. From this point, WRED performs a pseudo-
random drop with a ratio based on the curve up to the maximum Green and
Yellow thresholds. Beyond this point, 100% of frames with the applicable
Color are dropped.
The system automatically assigns the default “tail drop” WRED profile (Profile
ID 31) to every queue. Users can change the WRED profile per queue based on
the application served by the queue.
H-QoS Hierarchy
The egress path hierarchy is based on the following levels:
Queue level
Service bundle level
Logical interface level
The queue level represents the physical priority queues. This level holds 2K
queues. Each eight queues are bundled and represent eight CoS priority levels.
One or more service points can be attached to a specific bundle, and the traffic
from the service point to one of the eight queues is based on the CoS that was
calculated on the ingress path.
Note: With standard QoS, all services are assigned to a single
default service bundle.
The service bundle level represents the groups of eight priority queues. Every
eight queues are managed as a single service bundle.
The interface level represents the physical port through which traffic from the
specified service point egresses.
The following summarizes the egress path hierarchy:
Up to 8 physical interfaces
One service bundle per interface in standard QoS / 256 service bundles in
H-QoS.
Eight queues per service bundle
Priority 4 (Highest)
Priority 3
Priority 2
Priority 1 (Lowest)
Single
CoS0 Rate
Single
CoS1 Rate
WFQ
Service 1 CoS2
Single
Rate
Single
CoS3 Rate
Dual
CoS4 Single Shaper
Rate
Single
CoS5 Rate
Single
CoS6 Rate WFQ
CoS7 Single
Rate
Single
Shaper
Single
CoS0 Rate
WFQ
Single
CoS1 Rate
Service 2 CoS2
Single
Rate
Single
CoS3 Rate
Dual
Single
CoS4 Rate
Shaper
Single
CoS5 Rate WFQ
Single
CoS6 Rate
CoS7 Single
Rate
Service Point
H- QoS Mode
As discussed above, users can select whether to work in Standard QoS mode
or H-QoS mode.
If the user configured all the egress service points to transmit traffic via a
single service bundle, the operational mode is Standard QoS. In this mode,
only Service Bundle 1 is active and there are eight output transmission
queues.
If the user configured the egress service points to transmit traffic via
multiple service bundles, the operational mode is H-QoS. H-QoS mode
enables users to fully distinguish among the streams and to achieve SLA
per service.
Queue Shapers
Users can configure up to 31 single leaky bucket shaper profiles. The CIR value
can be set to the following values:
16,000 – 32,000,000 bps – granularity of 16,000 bps
32,000,000 – 131,008,000 bps – granularity of 64,000 bps
Note: Users can enter any value within the permitted range. Based
on the value entered by the user, the software automatically
rounds off the setting according to the granularity. If the
user enters a value below the lowest granular value (except
0), the software adjusts the setting to the minimum.
Users can attach one of the configured queue shaper profiles to each priority
queue. If no profile is attached to the queue, no egress shaping is performed
on that queue.
Interface Shapers
Users can configure up to 31 single leaky bucket shaper profiles. The CIR can
be set to the following values:
0 – 8,192,000 bps – granularity of 32,000 bps
8,192,000 – 32,768,000 bps – granularity of 128,000 bps
32,768,000 – 131,072,000 bps – granularity of 512,000 bps
131,072,000 – 999,424,000 bps – granularity of 8,192,000 bps
Note: Users can enter any value within the permitted range. Based
on the value entered by the user, the software automatically
rounds off the setting according to the granularity. If the
user enters a value below the value (except 0), the software
adjusts the setting to the minimum.
Users can attach one of the configured interface shaper profiles to each
interface. If no profile is attached to the interface, no egress shaping is
performed on that interface.
Egress Scheduling
Egress scheduling is responsible for transmission from the priority queues. IP-
20G uses a unique algorithm with a hierarchical scheduling model over the
three levels of the egress path that enables compliance with SLA
requirements.
The scheduler scans all the queues over all the service bundles, per interface,
and determines which queue is ready to transmit. If more than one queue is
ready to transmit, the scheduler determines which queue transmits first based
on:
Queue Priority – A queue with higher priority is served before lower-
priority queues.
Weighted Fair Queuing (WFQ) – If two or more queues have the same
priority and are ready to transmit, the scheduler transmits frames from
the queues based on a WFQ algorithm that determines the ratio of frames
per queue based on a predefined weight assigned to each queue.
The following figure shows the scheduling mechanism for a single service
bundle (equivalent to Standard QoS). When a user assigns traffic to more than
a single service bundle (H-QoS mode), multiple instances of this model (up to
32 per port) are valid.
Interface Priority
The profile defines the exact order for serving the eight priority queues in a
single service bundle. When the user attaches a profile to an interface, all the
service bundles under the interface inherit the profile.
The priority mechanism distinguishes between two states of the service
bundle:
Green State – Committed state
Yellow state – Best effort state
Green State refers to any time when the service bundle total rate is below the
user-defined CIR. Yellow State refers to any time when the service bundle total
rate is above the user-defined CIR but below the PIR.
User can define up to four Green priority profiles, from 4 (highest) to 1
(lowest). An additional four Yellow priority profiles are defined automatically.
Note: When Frame Cut-Through is enabled, frames in queues with
4th priority pre-empt frames already in transmission over
the radio from other queues. For details, refer to Frame Cut-
Through on page 73.
The following table provides a sample of an interface priority profile. This
profile is also used as the default interface priority profile.
Profile ID (1-9)
CoS Green Priority (user Yellow Priority (read Description
defined) only)
0 1 1 Best Effort
1 2 1 Data Service 4
2 2 1 Data Service 3
3 2 1 Data Service 2
4 2 1 Data Service 1
5 3 1 Real Time 2 (Video with large buffer)
6 3 1 Real Time 1 (Video with small buffer)
7 4 4 Management (Sync, PDUs, etc.)
When the service bundle state is Green (committed state), the service bundle
priorities are as defined in the Green Priority column. When the service
bundle state is Yellow (best effort state), the service bundle priorities are
system-defined priorities shown in the Yellow Priority column.
Note: CoS 7 is always marked with the highest priority, no matter
what the service bundle state is, since it is assumed that
only high priority traffic will be tunneled via CoS 7.
The system supports up to nine interface priority profiles. Profiles 1 to 8 are
defined by the user, while profile 9 is the pre-defined read-only default
interface priority profile.
Profile ID (1-7)
CoS Queue Weight (Green) Queue Weight (Yellow – not visible to users)
0 20 20
1 20 20
2 20 20
3 20 20
4 20 20
5 20 20
6 20 20
7 20 20
Egress Statistics
Queue-Level Statistics
IP-20G supports the following counters per queue at the queue level:
Transmitted Green Packet (64 bits counter)
Transmitted Green Bytes (64 bits counter)
Transmitted Green Bits per Second (32 bits counter)
Dropped Green Packets (64 bits counter)
Dropped Green Bytes (64 bits counter)
Transmitted Yellow Packets (64 bits counter)
Transmitted Yellow Bytes (64 bits counter)
Transmitted Yellow Bits per Second (32 bits counter)
Dropped Yellow Packets (64 bits counter)
Dropped Yellow Bytes (64 bits counter)
Interface-Level Statistics
For information on statistics at the interface level, refer to Ethernet Statistics
on page 128.
Marker
Marking refers to the ability to overwrite the outgoing priority bits and Color
of the outer VLAN of the egress frame. Marking mode is only applied if the
outer frame is S-VLAN and S-VLAN CoS preservation is disabled, or if the outer
frame is C-VLAN and C-VLAN CoS preservation is disabled. If outer VLAN
preservation is enabled for the relevant outer VLAN, the egress CoS and Color
are the same as the CoS and Color of the frame when it ingressed into the
switching fabric.
Marking is performed according to a global table that maps CoS and Color
values to the 802.1p-UP bits and the DEI or CFI bits. If Marking is enabled on a
service point, the CoS and Color of frames egressing the service via that
service point are overwritten according to this global mapping table.
If marking and CoS preservation for the relevant outer VLAN are both
disabled, marking is applied according to the Green frame values in the global
marking table.
When marking is performed, the following global tables are used by the
marker to decide which CoS and Color to use as the egress CoS and Color bits.
802.1q UP Marking Table (C-VLAN)
The keys for these tables are the CoS and Color. The results are the
802.1q/802.1ad UP and CFI/DEI bits, which are user-configurable. It is
strongly recommended that the default values not be changed except by
advanced users.
Related topics:
Network Resiliency
Automatic State Propagation (ASP) enables propagation of radio failures back
to the Ethernet port. You can also configure ASP to close the Ethernet port
based on a radio failure at the remote carrier. ASP improves the recovery
performance of resiliency protocols.
Note: It is recommended to configure both ends of the link to the
same ASP configuration.
same physical ring. This includes a set of timers that enables operators to
optimize protection switching behavior per ERPI:
Wait to Restore (WTR) Timer – Defines a minimum time the system
waits after signal failure is recovered before reverting to idle state.
Guard Time – Prevents unnecessary state changes and loops.
Hold-off Time – Determines the time period from failure detection to
response.
Each ERPI maintains a state machine that defines the node’s state for purposes
of switching and convergence. The state is determined according to events
that occur in the ring, such as signal failure and forced or manual switch
requests, and their priority. Possible states are:
Idle
Protecting
Forced Switch (FS)
Manual Switch (MS)
Pending
As shown in the following figure, in idle (normal) state, R-APS messages pass
through all links in the ring, while the RPL is blocked for traffic. The RPL can
be on either edge of the ring. R-APS messages are sent every five seconds.
G.8032 Ring in Idle (Normal) State
RPL
IP-20G
(Blocked)
Ring Node 1
IP-20G
Ring Node 2
IP-20G
Ring Node 3
R-APS Messages
Traffic
Once a signal failure is detected, the RPL is unblocked for each ERPI. As shown
in the following figure, the ring switches to protecting state. The nodes that
detect the failure send periodic SF messages to alert the other nodes in the
link of the failure and initiate the protecting state.
IP-20G RPL
(Unblocked)
Ring Node 1
Signal
Failure
IP-20G
Ring Node 2
IP-20G
Ring Node 3
R-APS Messages
Traffic
The ability to define multiple ERPIs and assign them to different Ethernet
services or groups of services enables operators to perform load balancing by
configuring a different RPL for each ERPI. The following figure illustrates a
ring in which four ERPIs each carry services with 33% capacity in idle state,
since each link is designated the RPL, and is therefore idle, for a different ERPI.
Load Balancing Example in G.8032 Ring
RPL for
IP-20G
ERPI 1
Ring Node 1
RPL for
ERPI 2
Wireless Ring IP-20G
Ring Node 4
RPL for
RPL for
ERPI 4
ERPI 3
IP-20G
Ring Node 2
IP-20G
Ring Node 3
ERPI 1 Traffic
ERPI 2 Traffic
ERPI 3 Traffic
ERPI 4 Traffic
G.8032 Interoperability
G.8032 in IP-20G units is interoperable with IP-20N units running G.8032, as
well as third-party bridges running standard implementations of G.8032.
MSTP Benefits
MSTP significantly improves network resiliency in the following ways:
Prevents data loops by configuring the active topology for each MSTI such
that there is never more than a single route between any two points in the
network.
Provides for fault tolerance by automatically reconfiguring the spanning
tree topology whenever there is a bridge failure or breakdown in a data
path.
Automatically reconfigures the spanning tree to accommodate addition of
bridges and bridge ports to the network, without the formation of
transient data loops.
Enables frames assigned to different services or service groups to follow
different data routes within administratively established regions of the
network.
Provides for predictable and reproducible active topology based on
management of the MSTP parameters.
Operates transparently to the end stations.
Consumes very little bandwidth to establish and maintain MSTIs,
constituting a small percentage of the total available bandwidth which is
independent of both the total traffic supported by the network and the
total number of bridges or LANs in the network.
Does not require bridges to be individually configured before being added
to the network.
MSTP Operation
MSTP includes the following elements:
MST Region – A set of physically connected bridges that can be portioned
into a set of logical topologies.
Internal Spanning Tree (IST) – Every MST Region runs an IST, which is a
special spanning tree instance that disseminates STP topology information
for all other MSTIs.
CIST Root – The bridge that has the lowest Bridge ID among all the MST
Regions.
Common Spanning Tree (CST) – The single spanning tree calculated by
STP, RSTP, and MSTP to connect MST Regions. All bridges and LANs are
connected into a single CST.
Common Internal Spanning Tree (CIST) – A collection of the ISTs in
each MST Region, and the CST that interconnects the MST regions and
individual spanning trees. MSTP connects all bridges and LANs with a
single CIST.
MSTP specifies:
An MST Configuration Identifier that enables each bridge to advertise its
configuration for allocating frames with given VIDs to any of a number of
MSTIs.
A priority vector that consists of a bridge identifier and path cost
information for the CIST.
An MSTI priority vector for any given MSTI within each MST Region.
Each bridge selects a CIST priority vector for each port based on the priority
vectors and MST Configuration Identifiers received from the other bridges and
on an incremental path cost associated with each receiving port. The resulting
priority vectors are such that in a stable network:
One bridge is selected to be the CIST Root.
A minimum cost path to the CIST Root is selected for each bridge.
The CIST Regional Root is identified as the one root per MST Region whose
minimum cost path to the root is not through another bridge using the
same MST Configuration Identifier.
Based on priority vector comparisons and calculations performed by each
bridge for each MSTI, one bridge is independently selected for each MSTI to be
the MSTI Regional Root, and a minimum cost path is defined from each bridge
or LAN in each MST Region to the MSTI Regional Root.
The following events trigger MSTP re-convergence:
Addition or removal of a bridge or port.
A change in the operational state of a port or group (LAG or protection).
A change in the service to instance mapping.
A change in the maximum number of MSTIs.
A change in an MSTI bridge priority, port priority, or port cost.
Note: All except the last of these triggers can cause the entire
MSTP to re-converge. The last trigger only affects the
modified MSTI.
MSTP Interoperability
MSTP in IP-20G units is interoperable with:
IP-20N units running MSTP.
Third-party bridges running MSTP.
FibeAir IP-10 units running RSTP.
Third-party bridges running RSTP
6.3.10 OAM
FibeAir IP-20G provides complete Service Operations Administration and
Maintenance (SOAM) functionality at multiple layers, including:
Fault management status and alarms.
Maintenance signals, such as AIS, and RDI.
Maintenance commands, such as loopbacks and Linktrace commands.
IP-20G is fully compliant with 802.1ag, G.8013/Y.1731, MEF-17, MEF-20,
MEF-30, and MEF-31.
IP-20G End-to-End Service Management
TDM services
BNC/RNC
Fiber
Aggregation
Network
IP-20G IP-20G
Test
Equipment
6.4 Synchronization
This section describes IP-20G’s flexible synchronization solution that enables
operators to configure a combination of synchronization techniques, based on
the operator’s network and migration strategy, including:
Native Sync Distribution, for end-to-end distribution using GE, FE, E1, T3,
and/or T4 sync input and output.
SyncE PRC Pipe Regenerator mode, providing PRC grade (G.811)
performance for pipe (“regenerator”) applications.
Related topics:
NTP Support
27
T3 input support is planned for future release.
28
SyncE PRC Pipe Regenerator mode is planned for future release.
Local clock: Causes the interface to generate its signal from a local
oscillator, unrelated to the system reference frequency.
Synchronization reference: Causes the interface to generate its signal
from the system reference clock, which is taken from the
synchronization source.
Loop Timing: Causes the interface to generate the signal from its own
input.
The node’s synchronization mode. This can be:
Automatic: In this mode, the active source is automatically selected
based on the interface with highest available quality. Among interfaces
with identical quality, the interface with the highest priority is used.
Force: The user can force the system to use a certain interface as the
reference clock source.29
By configuring synchronization sources and transporting the reference
frequency to the related interfaces in a network, a frequency “flow” can be
achieved, as shown in the example below, where the reference frequency from
a single node is distributed to a number of base stations.
Synchronization Configuration
Sync Source
Radio Link
IP-20G Node
Ethernet Interface Signal Clock = Reference
IP-20G Node
Signal Clock = Reference Signal Clock = Reference
29
Force mode is planned for future release.
Eth
E1
Eth IP-20G
E1
IP-20G
Eth
E1
IP-20G
In native Sync Distribution mode, the following interfaces can be used as the
sync references:
E130
GE (SyncE)
T3 (E1 waveform)31
Additionally, the following interfaces can be used for sync output:
E1
GE/FE (SyncE)
T4 (2MHz or E1 waveform)
Native Sync Distribution mode can be used in any link configuration and any
network topology.
Ring topologies present special challenges for network synchronization. Any
system that contains more than one clock source for synchronization, or in
which topology loops may exist, requires an active mechanism to ensure that:
A single source is be used as the clock source throughout the network,
preferably the source with the highest accuracy.
There are no reference loops. In other words, no element in the network
will use an input frequency from an interface that ultimately derived that
frequency from one of the outputs of that network element.
30
Planned for future release.
31
Planned for future release.
Eth.
Sync
IP-20G
Node-B
Eth.
Sync
Sync Input
IP-20G
GPS/SSU
IP-20G
Node-B Eth
(with SyncE)
Native
sync distribution
Eth.
Sync
IP-20G
RNC or
Aggregation
switch/router
IP-20G at fiber node synchronized to:
Distributed clock is provided to Node-B • SyncE input from Ethernet uplink
using SyncE or dedicated Sync interface. • External Sync Input (From GPS, SSU, etc.)
Packet Based
Aggregation
Network
MW Radio link
BNC/RNC
IP-20G
IP-20G
Wireless
Carrier Ethernet Ring BNC/RNC
IP-20G
Fiber site
2
Native
1+0
IP-20G FE/GE interface
with SyncE
Ring site #2
IP-20G
Ring site #3
IP-20G
Tail site #3
IP-20G
Wireless
Carrier Ethernet Ring IP-20G BNC/RNC
IP-20G
Tail site #3
In order to prevent loops, an SSM with quality “Do Not Use” is sent
towards the active source interface
At any given moment, the system enables users to display:
The current source interface quality.
The current received SSM status for every source interface.
The current node reference source quality.
As a reference, the following are the possible quality values (from highest to
lowest):
AUTOMATIC (available only in interfaces for which SSM support is
implemented)
G.811
SSU-A
SSU-B
G.813/8262 - default
DO NOT USE
Failure (cannot be configured by user)
Services engine
E1 TDM
Traffic
Hybrid
TDM Radio
PW
Network processor (EVCs)
Packet
Traffic
GE/FE
Hybrid Ethernet and TDM services can also be transported via cascading
interfaces. This enables the creation of links among multiple IP-20G and IP-
20N units in a node for multi-carrier and multi-directional applications.
Hybrid Ethernet and TDM Services Carried Over Cascading Interfaces
TDM cross-connect
- (VCs)
SAP
Cascading Port TDM
Traffic
Hybrid
Port Radio
Packet
Traffic
Ethernet Services (EVCs)
SNP SNP
SAP
E1 Port SAP
Cascading Port
Port
Multipoint Service
SAP SNP
Related topics:
Synchronization
Synchronization for TDM trails can be provided by any of the following
synchronization methods:
Loop Timing – Timing is taken from incoming traffic.
Recovered Clock– Clock information is recovered on the egress path.
Extra information may be located in an RTP header that can be used to
correct frequency offsets. Recovered Clock can provide very accurate
synchronization, but requires low PDV.
Third Party
Equipment
End-Point
Interface
Path 2
IP-20G
Path 1
IP-20G IP-20G
End-Point IP-20G
Interface
Third Party
Equipment
End-Point
Interface
Third Party
SNCP Equipment SNCP
Path 1 Path 2
Third Party
Equipment
Third Party Third Party
Equipment
TDM Network
Network
Interface 1
Network
Interface 2
IP-20G IP-20G
Path 1 Path 2
End-Point IP-20G
Interface
Third Party
Equipment
As with 1:1 TDM path protection, the operator defines two separate network
paths for a single TDM service. However, unlike 1:1 TDM path protection,
traffic flows through both paths simultaneously, thereby supporting
interoperability with standard SNCP in the third party equipment.
Multipoint
Service
User Port SAP SNP Network
(UNI) Port
SAP SNP
32
CESoP mode is planned for future release.
33
IP/UDP (IETF) encapsulation is planned for future release.
34
MPLS (MFA8) encapsulation is planned for future release.
35
A subset of DS0 is supported in CESoP, which is planned for a future release.
In addition, there are a number of parameters at the PW Card level that must
be configured properly to ensure proper operation:
Ethernet traffic port settings
Speed
Duplex
Auto-negotiation
Flow control
TDM card IP address and subnet mask
Clock distribution
Related topics:
Synchronization
A key requirement of pseudowire technology is managing the synchronization
of TDM signals. IP-20G’s TDM Pseudowire supports the following
synchronization methods:
Absolute Reference Clock (Common Clock) – All E1 lines are
synchronized to the system reference clock.
Adaptive Clock Recovery – Clock information is included in the frames
that contain the TDM data. Extra information may be located in an RTP
header that can be used to correct frequency offsets. The clock information
is extracted at the point where the frames are received and reconverted to
TDM. The extracted clock information is used for the reconversion to TDM.
Adaptive Clock Recovery can provide very accurate synchronization, but
requires low PDV.
Differential Clock Recovery – A single common clock is given, while each
E1 line has its independent clock referenced to this common clock. 36
Loop Timing – The pseudowire output signal uses the clock of the
incoming E1 lines Timing will be independent for each E1 line.
36
Differential Clock Recovery is planned for future release.
the TDM module can determine the status of the entire network path, up to
and including the card’s TDM interface.
1:1 TDM path protection can be configured to operate in revertive mode. In
revertive mode, the system monitors the availability of the protected path at
all times. After switchover to the protecting path, once the protected path is
operational and available without any alarms, the system waits the user-
configured Wait to Restore (WTR) time and then, if the protected path
remains operational and available, initiates a revertive protection switch. A
single WTR time is configured for all the TDM trails in the system.
TDM PMs
Standard PM measurements are provided for each configured service:
Number of frames transmitted
Number of frames received
Number of lost frames detected
Number of frames received out-of-sequence but successfully reordered
Number of transitions from normal state to LOPS (loss of frame state)
Number of malformed frames received
Number of frames dropped because the receive buffer exceeded the
maximum allowed depth (jitter overruns)
Maximum deviation from the middle of the jitter buffer (maximum jitter
buffer deviation)
Minimum jitter buffer usage registered during the prior one second
(current minimum jitter buffer count)
Maximum jitter buffer usage registered during the prior one second
(current maximum jitter buffer count)
37
TDM Signal PMs
PMs are computed at the TDM card and reported at 15-minute intervals, with
one second granularity.
PMs for the recovered E1:
Errored seconds
Severely errored seconds
Unavailable seconds
PMs for the pseudowire Ethernet connection:
Frame Error Ratio (FER) performance
RFC 5604 PMs:
37
Support for TDM signal PMs is planned for future release.
Lost frames
Reordered frames
Buffer underruns
Misordered frames dropped
Malformed frames
PMs for incoming native E1 signal:
Errored seconds
Severely errored seconds
Unavailable seconds
PMs for incoming SDH 155MHz signal:
Errored seconds
Severely errored seconds
Severely errored framing seconds
Coding Violations
Hybrid Hybrid
Radio Radio
SDH Optical
Aggregation
Network
FibeAir IP-20 FibeAir IP-20 FibeAir IP-20
BNC/RNC
Tail site Aggregation site Fiber site
Hybrid Hybrid
Radio Radio
Fiber Packet
Aggregation
Network
FibeAir IP-10/20 FibeAir IP-20 FibeAir IP-20
BNC/RNC
Tail site Aggregation site Fiber site
All-Packet All-Packet
Radio Radio
SDH Optical
Aggregation
Network
FibeAir IP-20 FibeAir IP-20 FibeAir IP-20
BNC/RNC
Tail site Aggregation site Fiber site
All-Packet All-Packet
Radio Radio
Fiber Packet
Aggregation
Network
FibeAir IP-20 FibeAir IP-20 FibeAir IP-20
BNC/RNC
Tail site Aggregation site Fiber site
Northbound OSS/NMS
SNMP
NetAct
CLI Interface
NMS
Client NMS
TCP, Secured
SSL Channel Platform
XML
Over
HTTP
Web EMS
SNMP
HTTP/HTTPS HTTP/HTTPS
FTP/SFTP FTP/SFTP
CLI
HTTP
IP-20G
Craft
38
The option to edit the backup configuration is planned for future release.
39
Installation timer is planned for future release.
7.11 Alarms
The password cannot have been used within the user’s previous five
passwords.
Users can be prompted to change passwords after a configurable amount
of time (password aging).
Users can be blocked for a configurable time period after a configurable
number of unsuccessful login attempts.
Users can be configured to expire at a certain date
Mandatory change of password at first time login can be enabled and
disabled upon user configuration. It is enabled by default.
7.15.4.5 SNMP
IP-20G supports SNMP v1, V2c, and v3. The default community string in NMS
and the SNMP agent in the embedded SW are disabled. Users are allowed to
set community strings for access to IDUs.
IP-20G supports the following MIBs:
RFC-1213 (MIB II)
RMON MIB
Ceragon (proprietary) MIB.
Access to all IDUs in a node is provided by making use of the community and
context fields in SNMPv1 and SNMPv2c/SNMPv3, respectively.
7.15.4.7 SSH
The CLI interface supports SSH-2
Users of type of “administrator” or above can enable or disable SSH.
Standard Description
802.3 10base-T
802.3u 100base-T
802.3ab 1000base-T
802.3z 1000base-X
802.3ac Ethernet VLANs
802.1Q Virtual LAN (VLAN)
802.1p Class of service
802.1ad Provider bridges (QinQ)
802.3ad Link aggregation
Auto MDI/MDIX for 1000baseT
RFC 1349 IPv4 TOS
RFC 2474 IPv4 DSCP
RFC 2460 IPv6 Traffic Classes
Specification Description
MEF-2 Requirements and Framework for Ethernet Service
Protection
MEF-6.1 Metro Ethernet Services Definitions Phase 2
MEF-8 Implementation Agreement for the Emulation of PDH
Circuits over Metro Ethernet Networks
MEF-10.3 Ethernet Services Attributes Phase 3
MEF 22.1 Mobile Backhaul Implementation Agreement Phase 2
MEF-30.1 Service OAM Fault Management Implementation
Agreement Phase 2
MEF-35 Service OAM Performance Monitoring Implementation
Agreement
MEF Certifications
Certification Description
CE 2.0 Second generation Carrier Ethernet certification
MEF-18 Abstract Test Suite for Circuit Emulation Services
MEF-9 Abstract Test Suite for Ethernet Services at the UNI.
Certified for all service types (EPL, EVPL & E-LAN).
This is a first generation certification. It is fully covered
as part of CE2.0)
MEF-14 Abstract Test Suite for Traffic Management Phase 1.
Certified for all service types (EPL, EVPL & E-LAN).
This is a first generation certification. It is fully covered
as part of CE2.0)
40
HTTPS support is planned for future release.
41
Note that the voltage measured at the BNC port is not accurate and should be used only as an
aid.
9. Specifications
This chapter includes:
General Radio Specifications
Radio Capacity Specifications
Transmit Power Specifications
Receiver Threshold (RSL) Specifications
(dBm @ BER = 10-6)
Frequency Bands
Mediation Device Losses
Ethernet Latency Specifications
Ethernet Specifications
TDM Specifications
Synchronization Specifications
Mechanical Specifications
Environmental Specifications
Supported Antenna Types
Waveguide Specifications
Power Input Specifications
Power Consumption Specifications
Related Topics:
Standards and Certifications
Note: All specifications are subject to change without prior
notification.
Note: These figures are valid for RFU-Ce, 1500HP, and RFU-HP.
For exact capacity specifications for modulations beyond
256 QAM using standard RFU models, contact your Ceragon
representative.
42
Header De-Duplication is planned for future release.
Note: These figures are valid for RFU-Ce, 1500HP, and RFU-HP.
For exact capacity specifications for modulations beyond
256 QAM using standard RFU models, contact your Ceragon
representative.
Note: These figures are valid for RFU-Ce and RFU-HP. For exact
capacity specifications for modulations beyond 256 QAM
using standard RFU models, contact your Ceragon
representative.
These figures are valid for RFU-Ce and RFU-HP. For exact
capacity specifications for modulations beyond 256 QAM
using standard RFU models, contact your Ceragon
representative.
Note: These figures are valid for RFU-Ce, 1500HP, and RFU-HP.
For exact capacity specifications for modulations beyond
256 QAM using standard RFU models, contact your Ceragon
representative.
Note: These figures are valid for RFU-Ce, 1500HP, and RFU-HP.
For exact capacity specifications for modulations beyond
256 QAM using standard RFU models, contact your Ceragon
representative.
Note: These figures are valid for RFU-Ce and RFU-HP. For exact
capacity specifications for modulations beyond 256 QAM
using standard RFU models, contact your Ceragon
representative.
Modulation 6L-8 GHz 11-15 GHz 18-23 GHz 24GHz UL43 26 GHz 28 GHz 31 GHz 32-38 GHz 42 GHz
QPSK 26 24 22 0 21 14 16 18 15
8 PSK 26 24 22 0 21 14 16 18 15
16 QAM 25 23 21 0 20 14 15 17 14
32 QAM 24 22 20 0 19 14 14 16 13
64 QAM 24 22 20 0 19 14 14 16 13
128 QAM 24 22 20 0 19 14 14 16 13
256 QAM 22 20 18 0 17 12 12 14 11
512 QAM 22 20 18 0 17 9 12 14 11
1024 QAM 21 19 17 0 16 8 11 13 10
2048 QAM 19 17 15 0 14 6 9 11 8
43
For 1ft ant or lower.
Customers in countries following EC Directive 2006/771/EC (incl. amendments) must observe
the 100mW EIRP obligation by adjusting transmit power according to antenna gain and RF line
losses.
These Transmit Power values are applicable to all RFU-HP and 1500HP
Marketing Models for both Split Mount and All Indoor for RFUs produced on
or after March 16, 2014. These RFUs have Serial Numbers starting with
F114xxxxxx and higher.
The Transmit Power values for RFUs produced prior to March 16, 2014,
identified by lower Serial Numbers, are set forth in the Technical Descriptions
for FibeAir IP-10 products.
44
Refer to RFU-C roll-out plan for availability of each frequency.
45
Customers in countries following EC Directive 2006/771/EC (incl. amendments) must observe the
100mW EIRP obligation by adjusting transmit power according to antenna gain and RF line losses.
Channel
Profile Modulation
Spacing
6 7-10 11-15 18 23 2447 26 28 31-42
0 QPSK -89.0 -88.5 -89.0 -88.0 -87.5 -84.5 -86.5 -84.5 -85.5
1 8 PSK -84.5 -84.0 -84.5 -83.5 -83.0 -80.0 -82.0 -80.0 -81.0
2 16 QAM -82.5 -82.0 -82.5 -81.5 -81.0 -78.0 -80.0 -78.0 -79.0
3 32 QAM -79.0 -78.5 -79.0 -78.0 -77.5 -74.5 -76.5 -74.5 -75.5
4 64 QAM -76.0 -75.5 -76.0 -75.0 -74.5 -71.5 -73.5 -71.5 -72.5
5 128 QAM 28 MHz -72.5 -72.0 -72.5 -71.5 -71.0 -68.0 -70.0 -68.0 -69.0
6 256 QAM -69.5 -69.0 -69.5 -68.5 -68.0 -65.0 -67.0 -65.0 -66.0
7 512 QAM -67.5 -67.0 -67.5 -66.5 -66.0 -63.0 -65.0 -63.0 -64.0
8 1024 QAM (Strong FEC) -64.5 -64.0 -64.5 -63.5 -63.0 -60.0 -62.0 -60.0 -61.0
9 1024 QAM (Light FEC) -63.5 -63.0 -63.5 -62.5 -62.0 -59.0 -61.0 -59.0 -60.0
10 2048 QAM -60 -59.5 -60 -59 -58.5 -55.5 -57.5 -55.5 -56.5
0 QPSK -87.5 -87.0 -87.5 -86.5 -86.0 -80.5 -85.0 -83.0 -84.0
1 8 PSK -81.5 -81.0 -81.5 -80.5 -80.0 -74.5 -79.0 -77.0 -78.0
2 16 QAM -81.0 -80.5 -81.0 -80.0 -79.5 -74.0 -78.5 -76.5 -77.5
3 32 QAM -77.5 -77.0 -77.5 -76.5 -76.0 -70.5 -75.0 -73.0 -74.0
4 64 QAM -74.5 -74.0 -74.5 -73.5 -73.0 -67.5 -72.0 -70.0 -71.0
40 MHz
5 128 QAM -71.5 -71.0 -71.5 -70.5 -70.0 -64.5 -69.0 -67.0 -68.0
6 256 QAM -69.0 -68.5 -69.0 -68.0 -67.5 -62.0 -66.5 -64.5 -65.5
7 512 QAM -66.5 -66.0 -66.5 -65.5 -65.0 -59.5 -64.0 -62.0 -63.0
8 1024 QAM (strong FEC) -63.0 -62.5 -63.0 -62.0 -61.5 -56.0 -60.5 -58.5 -59.5
9 1024 QAM (light FEC) -62.0 -61.5 -62.0 -61.0 -60.5 -55.0 -59.5 -57.5 -58.5
46
Refer to RFU-C roll-out plan for availability of each frequency.
47
Customers in countries following EC Directive 2006/771/EC (incl. amendments) must observe
the 100mW EIRP obligation by adjusting transmit power according to antenna gain and RF line
losses.
Channel
Profile Modulation
Spacing
6 7-10 11-15 18 23 2447 26 28 31-42
0 QPSK -85.5 -85.0 -85.5 -84.5 -84.0 -81.0 -83.0 -81.0 -82.0
1 8 PSK -81.5 -81.0 -81.5 -80.5 -80.0 -77.0 -79.0 -77.0 -78.0
2 16 QAM -79.0 -78.5 -79.0 -78.0 -77.5 -74.5 -76.5 -74.5 -75.5
3 32 QAM -75.5 -75.0 -75.5 -74.5 -74.0 -71.0 -73.0 -71.0 -72.0
4 64 QAM -72.5 -72.0 -72.5 -71.5 -71.0 -68.0 -70.0 -68.0 -69.0
5 128 QAM 56 MHz -69.5 -69.0 -69.5 -68.5 -68.0 -65.0 -67.0 -65.0 -66.0
6 256 QAM -66.5 -66.0 -66.5 -65.5 -65.0 -62.0 -64.0 -62.0 -63.0
7 512 QAM -64.5 -64.0 -64.5 -63.5 -63.0 -60.0 -62.0 -60.0 -61.0
8 1024 QAM (Strong FEC) -61.0 -60.5 -61.0 -60.0 -59.5 -56.5 -58.5 -56.5 -57.5
9 1024 QAM (Light FEC) -60 -59.5 -60 -59 -58.5 -55.5 -57.5 -55.5 -56.5
10 2048 QAM -55.5 -55 -55.5 -54.5 -54 -51 -53 -51 -52
10501-10563 10333-10395
10333-10395 10501-10563
10 GHz
10529-10591 10361-10423 168A
10361-10423 10529-10591
10585-10647 10417-10479
11425-11725 10915-11207
13002-13141 12747-12866
12747-12866 13002-13141
266
13127-13246 12858-12990
12858-12990 13127-13246
12807-12919 13073-13185 266A
15110-15348 14620-14858
14620-14858 15110-15348
490
14887-15117 14397-14627
14397-14627 14887-15117
15144-15341 14500-14697
644
14500-14697 15144-15341
14975-15135 14500-14660
14500-14660 14975-15135
475
15135-15295 14660-14820
19160-19700 18126-18690
18126-18690 19160-19700
1010
18 GHz 18710-19220 17700-18200
17700-18200 18710-19220
19260-19700 17700-18140
1560
17700-18140 19260-19700
23000-23600 22000-22600
23 GHz 1008
22000-22600 23000-23600
22400-23000 21200-21800 1232 /1200
48
24UL GHz
24000 - 24250 24000 - 24250 All
25530-26030 24520-25030
24520-25030 25530-26030
1008
25980-26480 24970-25480
28150-28350 27700-27900
27700-27900 28150-28350
450
27950-28150 27500-27700
27500-27700 27950-28150
28050-28200 27700-27850 350
27700-27850 28050-28200
27960-28110 27610-27760
28 GHz
27610-27760 27960-28110
28090-28315 27600-27825 490
27600-27825 28090-28315
29004-29453 27996-28445 1008
27996-28445 29004-29453
28556-29005 27548-27997
27548-27997 28556-29005
29100-29125 29225-29250 125
48
Customers in countries following EC Directive 2006/771/EC (incl. amendments) must observe
the 100mW EIRP obligation by adjusting transmit power according to antenna gain and RF line
losses.
40550-41278 42050-42778
42 GHz 42050-42778 40550-41278 1500
41222-41950.5 42722-43450
42722-43450 41222-41950.5
Notes:
(c) – Radio Carrier
CCDP – Co-channel dual polarization
SP – Single pole antenna
DP – Dual pole antenna
In addition, the following losses will be added when using these items:
1+1
2+1 3+1 4+1
Configuration Interfaces 1+0 FD
3+0 4+0 5+0
2+0
6L 4
6H 4.5
WG losses per 100m
7/8GHz 6
11GHz 10
Added to adjacent
Symmetrical Coupler 3
channel configuration
All-Indoor Tx and Rx 0.3 (1c) 0.3 (1c) 0.7 (2c) 0.7 (2c) 1.1 (3c)
CCDP with DP antenna
Diversity RX 0.2 (1c) 0.2 (1c) 0.6 (2c) 0.6 (2c) 1.0 (3c)
Tx and Rx 0.3 (1c) 0.7 (2c) 1.1 (3c) 1.5 (4c) 1.9 (5c)
SP Non adjacent channels
Diversity RX 0.2 (1c) 0.6 (2c) 1.0 (3c) 1.4 (4c) 1.8 (5c)
CCDP with DP antenna Tx and Rx 0.3 (1c) 0.7 (1c) 1.1 (2c) 1.1 (2c) 1.5 (3c)
Upgrade Ready Diversity RX 0.2 (1c) 0.6 (1c) 1.0 (2c) 1.0 (2c) 1.4 (3c)
CCDP with DP antenna Tx and Rx 1.5 (3c) 1.9 (4c) 1.9 (4c) 2.3 (5c) 2.3 (6c)
Upgrade Ready Diversity RX 1.4 (3c) 1.8 (4c) 1.8 (4c) 2.2 (5c) 2.2 (6c)
49
Planned for future release.
50
Planned for future release.
51
Planned for future release.
52
Planned for future release.
Height: 44 mm (1RU)
Width: 426 mm
IDU Dimensions
Depth: 180 mm
Weight: 2.5 kg
Coaxial cable RG-223 (300 ft), Belden 9914/RG-8 (1000 ft)
IDU-RFU Connection or equivalent, TNC connectors to the IDU, N-type connectors
(male) to the RFU.
Height: 200 mm
Width: 200 mm
RFU-C Dimensions
Depth: 85 mm
Weight: 4kg/9 lbs.
RFU-C Standard 50 mm-120 mm/2”-4.5” (subject to vendor and antenna
Mounting OD Pole size)
Height: 490 mm
1500HP/RFU-HP Width: 144 mm
Dimensions Depth: 280 mm
Weight: 7 kg (excluding Branching)
Height: 420 mm
1500HP/RFU-HP Width: 110 mm
OCB Branching
Depth: 380 mm
(Split Mount and
Compact All-Indoor ) Weight: 7 kg
Recommended torque for RFU-OCB connection: 17 Nm
1500HP/RFU-HP
Standard Mounting 76-114 mm (subject to vendor and antenna size)
OD Pole