Ceragon FibeAir IP 20N Technical Description 10.9 Rev A.04

Technical Description
FibeAir® IP-20N
August 2019 | Rev A.04

CeraOS: 10.9
© Copyright 2019 by Ceragon Networks Ltd. All rights reserved.
Technical Description for FibeAir IP-20N, CeraOS 10.9
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 damage in connection with the furnishing, performance, or
use of this document or equipment supplied with it.
Open Source Statement

The Product may use open source software, among them O/S software released under the GPL or GPL alike
license ("Open Source License"). Inasmuch that such software is being used, it is released under the Open
Source License, accordingly. The complete list of the software being used in this product including their
respective license and the aforementioned public available changes is accessible at:
Network element site: ftp://ne-open-source.license-system.com
NMS site: ftp://nms-open-source.license-system.com/
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.
Intended Use/Limitation
Fixed point-to-point radio links for private networks.
Authorized to Use
Only entities with individual authorization from the National Regulator to operate the mentioned radio
equipment.
The equipment can be used in the following EU countries:
Austria (AT) - Belgium (BE) - Bulgaria (BG) - Switzerland/Liechtenstein (CH) - Cyprus (CY) - Czech Republic (CZ)
- Germany (DE) – Denmark (DK) - Estonia (EE) - Finland (FI) - France (FR) -Greece (GR) - Hungary (HU) -
Ireland (IE) – Iceland (IS) – Italy (IT) – Lithuania (LT) - Luxembourg (LU) – Latvia (LV) - Malta (MT) -
Netherlands (NL) - Norway (NO) - Portugal (PT) - Romania (RO) - Sweden (SE) - Slovenia (SI) - Slovak Republic
(SK) – United Kingdom (UK) – Spain (SP) – Poland (PL)
Page 2 of 468
Ceragon Proprietary and Confidential

Table of Contents
1. Synonyms and Acronyms ........................................................................................ 23
2. Introduction............................................................................................................ 27
2.1 Product Overview ...................................................................................................................... 28
2.1.1 IP-20N Radio Options ................................................................................................................. 29
2.1.2 IP-20N Hardware Options and Scalability .................................................................................. 30
2.1.3 FibeAir IP-20N Interoperability with other Ceragon Products ................................................... 32
2.1.4 Supported IP-20N Radio Configurations .................................................................................... 33
2.1.5 Configurations Implemented using RFU-C or 1500HP/RFU-HP with RMC-A or RMC-B ............. 33
2.1.6 Configurations Implemented using RFU-D, RFU-D-HP, RFU-E, or RFU-S with RIC-D ................. 35
2.1.7 IP-20N’s No-Single-Point-of-Failure Architecture ...................................................................... 37
2.2 Solution Overview ...................................................................................................................... 38
2.3 FibeAir IP-20 Assured Platform .................................................................................................. 39
2.4 New Features in CeraOS 10.7.5 and CeraOS 10.9 ...................................................................... 40
3. IDU Hardware Description ....................................................................................... 41

3.1 Hardware Architecture .............................................................................................................. 43
3.2 Front Panel Description ............................................................................................................. 48
3.3 Chassis Slots and Card Population Guidelines ........................................................................... 50
3.3.1 TCC GbE Interface Limitations.................................................................................................... 51
3.3.2 Adjacent Pair Guidelines ............................................................................................................ 52
3.3.3 Slot Sections and 2.5 Gbps Mode .............................................................................................. 53
3.3.4 Additional Slot Guidelines .......................................................................................................... 55
3.3.5 Sample Chassis Configurations .................................................................................................. 56
3.4 Traffic Control Cards (TCC) ......................................................................................................... 62
3.4.1 TCC Redundancy ........................................................................................................................ 65
3.5 Radio Interface Cards (RIC) ........................................................................................................ 67
3.6 Radio Modem Cards (RMC) ........................................................................................................ 69
3.7 Ethernet Line Cards (LIC-X) ........................................................................................................ 70
3.7.1 10G Interface Protection............................................................................................................ 72
3.8 TDM Line Cards (LIC-T) ............................................................................................................... 73
3.9 Power Distribution Cards (PDC) ................................................................................................. 75
3.10 Inventory Module (IVM) ............................................................................................................ 78
3.11 Fans Module .............................................................................................................................. 79
3.12 Filter Tray (Optional) .................................................................................................................. 80
4. RFU Hardware Description and Branching Options ................................................... 81

4.1 RFU Overview............................................................................................................................. 82
4.2 RFU Selection Guide ................................................................................................................... 83
Page 3 of 468

4.3 RFU-D ......................................................................................................................................... 84

4.3.1 Main Features of RFU-D ............................................................................................................. 85
4.3.2 RFU-D Functional Block Diagram ............................................................................................... 85
4.3.3 RFU-D Radio Interfaces .............................................................................................................. 86
4.3.4 RFU-D Marketing Models ........................................................................................................... 88
4.3.5 RFU-D MultiCore Mediation Devices (MCMD) ........................................................................... 91
4.4 RFU-D-HP ................................................................................................................................... 93
4.4.1 Main Features of RFU-D-HP ....................................................................................................... 94
4.4.2 RFU-D-HP Functional Block Diagram.......................................................................................... 94
4.4.3 RFU-D-HP Radio Interfaces ........................................................................................................ 95
4.4.4 RFU-D-HP Branching Options ..................................................................................................... 98
4.4.5 RFU-D-HP Marketing Models ...................................................................................................105
4.4.6 RFU-D-HP Marketing Models – All-Indoor Terminals ..............................................................110
4.5 RFU-E ........................................................................................................................................112
4.5.1 Main Features of RFU-E ...........................................................................................................112
4.5.2 RFU-E Functional Block Diagram ..............................................................................................112
4.5.3 RFU-E Radio Interfaces.............................................................................................................114
4.5.4 RFU-E Marketing Models .........................................................................................................115
4.6 RFU-S ........................................................................................................................................116
4.6.1 Main Features of RFU-S ...........................................................................................................116
4.6.2 RFU-S Functional Block Diagram ..............................................................................................116
4.6.3 RFU-S Interfaces .......................................................................................................................117
4.6.4 RFU-S Marketing Models .........................................................................................................118
4.6.5 RFU-S Mediation Devices .........................................................................................................122
4.7 RFU-C .......................................................................................................................................123
4.7.1 Main Features of RFU-C ...........................................................................................................123
4.7.2 RFU-C Functional Block Diagram ..............................................................................................124
4.8 1500HP/RFU-HP .......................................................................................................................125
4.8.1 Main Features of 1500HP/RFU-HP ...........................................................................................125
4.8.2 1500HP/RFU-HP Functional Block Diagram and Concept of Operation ..................................127
4.8.3 1500HP/RFU-HP Comparison Table .........................................................................................129
4.8.4 1500HP/RFU-HP System Configurations ..................................................................................130
4.8.5 Split Mount Configuration and Branching Network ................................................................130
4.8.6 1500HP/RFU-HP Models and Part Numbers ............................................................................136
4.8.7 OCB Part Numbers ...................................................................................................................137
4.8.8 OCB Part Number Format ........................................................................................................138
5. Activation Keys ..................................................................................................... 139

5.1 Working with Activation Keys ..................................................................................................139
5.2 Demo Mode .............................................................................................................................139
5.3 Activation Key Reclaim .............................................................................................................140
5.4 Activation Key-Enabled Features .............................................................................................140
6. Feature Description............................................................................................... 147

6.1 Innovative Techniques to Boost Capacity and Reduce Latency ...............................................148
Page 4 of 468

6.1.1 Capacity Summary ...................................................................................................................149

6.1.2 Unique MultiCore Architecture of RFU-D and RFU-D-HP ........................................................150
6.1.3 Header De-Duplication.............................................................................................................155
6.1.4 Latency .....................................................................................................................................157
6.1.5 Frame Cut-Through ..................................................................................................................158
6.2 Radio Features .........................................................................................................................160
6.2.1 Hybrid Multi-Carrier Adaptive Bandwidth Control (Hybrid MC-ABC) ......................................161
6.2.2 Space Diversity .........................................................................................................................168
6.2.3 HSB Protection .........................................................................................................................176
6.2.4 Adaptive Coding Modulation (ACM) ........................................................................................178
6.2.5 Cross Polarization Interference Canceller (XPIC) .....................................................................186
6.2.6 ATPC .........................................................................................................................................190
6.2.7 Radio Signal Quality PMs .........................................................................................................191
6.2.8 Radio Utilization PMs ...............................................................................................................191
6.3 Ethernet Features ....................................................................................................................192
6.3.1 Ethernet Services Overview .....................................................................................................193
6.3.2 IP-20N’s Ethernet Capabilities .................................................................................................209
6.3.3 Supported Standards ...............................................................................................................210
6.3.4 Ethernet Service Model ...........................................................................................................211
6.3.5 Ethernet Interfaces ..................................................................................................................229
6.3.6 Quality of Service (QoS) ...........................................................................................................239
6.3.7 Global Switch Configuration ....................................................................................................267
6.3.8 Automatic State Propagation and Link Loss Forwarding .........................................................267
6.3.9 Network Resiliency ..................................................................................................................268
6.3.10 OAM .........................................................................................................................................275
6.4 Synchronization .......................................................................................................................279
6.4.1 Synchronization Overview .......................................................................................................279
6.4.2 IP-20N Synchronization Solution .............................................................................................280
6.4.3 Native Sync Distribution Mode ................................................................................................282
6.4.4 SyncE PRC Pipe Regenerator Mode .........................................................................................288
6.4.5 IEEE-1588v2 PTP Optimized Transport ....................................................................................289
6.5 TDM Services............................................................................................................................296
6.5.1 Native TDM Trails .....................................................................................................................297
6.5.2 TDM Pseudowire ......................................................................................................................302
6.5.3 STM-1 Interfaces ......................................................................................................................307
6.5.4 TDM Card and Interface Protection .........................................................................................308
6.5.5 TDM Reference Solutions ........................................................................................................311
6.6 Radio Payload Encryption and FIPS ..........................................................................................313
6.6.1 AES-256 Payload Encryption ....................................................................................................313
6.6.2 FIPS 140-2 Compliance .............................................................................................................315
7. FibeAir IP-20N Management ................................................................................. 317

7.1 Management Overview ...........................................................................................................318
7.2 Automatic Network Topology Discovery with LLDP Protocol ..................................................319
7.3 Management Communication Channels and Protocols ..........................................................320
Page 5 of 468

7.4 Web-Based Element Management System (Web EMS) ..........................................................322

7.5 Command Line Interface (CLI) ..................................................................................................323
7.6 Slot Management and Card Configuration ..............................................................................323
7.7 Configuration Management .....................................................................................................323
7.8 Software Management ............................................................................................................324
7.8.1 Backup Software Version .........................................................................................................324
7.9 CeraPlan Service for Creating Pre-Defined Configuration Files ...............................................325
7.10 IPv6 Support .............................................................................................................................325
7.11 In-Band Management ..............................................................................................................326
7.12 Local Management ..................................................................................................................326
7.13 Alarms ......................................................................................................................................327
7.13.1 Configurable BER Threshold Alarms and Traps ........................................................................327
7.13.2 RSL Threshold Alarm ................................................................................................................327
7.13.3 Editing and Disabling Alarms and Events .................................................................................327
7.13.4 Timeout for Trap Generation ...................................................................................................327
7.14 External Alarms ........................................................................................................................328
7.15 NTP Support .............................................................................................................................328
7.16 UTC Support .............................................................................................................................328
7.17 System Security Features .........................................................................................................328
7.17.1 Ceragon’s Layered Security Concept........................................................................................329
7.17.2 Defenses in Management Communication Channels ..............................................................329
7.17.3 Defenses in User and System Authentication Procedures .......................................................330
7.17.4 Secure Communication Channels ............................................................................................332
7.17.5 Security Log ..............................................................................................................................335
8. Standards and Certifications .................................................................................. 337

8.1 Supported Ethernet Standards ................................................................................................338
8.2 MEF Certifications for Ethernet Services .................................................................................339
8.3 Supported TDM Pseudowire Encapsulations ...........................................................................340
8.4 Standards Compliance .............................................................................................................340
8.5 Network Management, Diagnostics, Status, and Alarms.........................................................341
9. Specifications........................................................................................................ 342
9.1 General Radio Specifications ...................................................................................................343
9.1.1 General Radio Specifications for Microwave RFUs ..................................................................343
9.1.2 General Radio Specifications for E-Band ..................................................................................344
9.2 Radio Scripts ............................................................................................................................345
9.2.1 MRMC Scripts Supported with RIC-D and RFU-D, RFU-D-HP, and RFU-S.................................346
9.2.2 MRMC Scripts Supported with RIC-D and RFU-E .....................................................................347
9.2.3 MRMC Scripts Supported with RMC-B .....................................................................................348
Page 6 of 468

9.2.4 MRMC Scripts Supported with RMC-A.....................................................................................349

9.3 Radio Capacity Specifications ..................................................................................................350
9.3.1 Radio Capacity Specifications – RIC-D with RFU-D, RFU-D-HP, and RFU-S ..............................350
9.3.2 Radio Capacity Specifications – RIC-D with RFU-E ...................................................................364
9.3.3 Radio Capacity Specifications – RMC-B ....................................................................................367
9.3.4 Radio Capacity Specifications – RMC-B with XPIC ...................................................................374
9.3.5 Radio Capacity Specifications – RMC-A....................................................................................381
9.4 Transmit Power Specifications (dBm) ......................................................................................384
9.4.1 Transmit Power with RFU-D .....................................................................................................384
9.4.2 Transmit Power with RFU-D-HP ...............................................................................................385
9.4.3 Transmit Power with RFU-S .....................................................................................................386
9.4.4 Transmit Power with RFU-E .....................................................................................................387
9.4.5 Transmit Power with RFU-C (dBm) ..........................................................................................388
9.4.6 Transmit Power with 1500HP/RFU-HP (dBm) ..........................................................................389
9.5 Receiver Threshold Specifications ...........................................................................................391
9.5.1 Receiver Thresholds with RFU-D and RFU-S ............................................................................391
9.5.2 Receiver Thresholds with RFU-D-HP ........................................................................................397
9.5.3 Receiver Thresholds with RFU-E ..............................................................................................399
9.5.4 Receiver Thresholds with RMC-B and RFU-C ...........................................................................400
9.5.5 Receiver Thresholds with RFU-HP ............................................................................................403
9.5.6 Receiver Thresholds with 1500HP ...........................................................................................405
9.5.7 Receiver Thresholds with RMC-A and RFU-C ...........................................................................407
9.6 Frequency Bands ......................................................................................................................409
9.6.1 Frequency Bands – RFU-D, RFU-D-HP, RFU-S, and RFU-C ........................................................409
9.6.2 Frequency Bands – RFU-E ........................................................................................................421
9.6.3 Frequency Bands – 1500HP and RFU-HP .................................................................................422
9.7 Ethernet Latency Specifications ...............................................................................................423
9.7.1 Ethernet Latency with RIC-D and RFU-D, RFU-D-HP, and RFU-S ..............................................423
9.7.2 Ethernet Latency with RIC-D and RFU-E ..................................................................................428
9.7.3 Ethernet Latency with RMC-B ..................................................................................................431
9.7.4 Ethernet Latency with RMC-A ..................................................................................................434
9.8 Mediation Device and Branching Network Losses ...................................................................436
9.8.1 RFU-D/RFU-D-HP Mediation Device Losses .............................................................................436
9.8.2 RFU-D-HP Branching Losses – Channel Filters-Based Branching .............................................438
9.8.3 RFU-E Mediation Device Losses ...............................................................................................441
9.8.4 RFU-S and RFU-C Mediation Device Losses .............................................................................441
9.8.5 1500HP/RFU-HP Branching Network Losses ............................................................................442
9.9 Ethernet Specifications ............................................................................................................447
9.9.1 Ethernet Interface Specifications .............................................................................................447
9.9.2 Carrier Ethernet Functionality .................................................................................................447
9.9.3 Approved SFP Modules ............................................................................................................448
9.10 TDM Specifications ..................................................................................................................449
9.10.1 E1 Cross Connect .....................................................................................................................449
9.10.2 E1 Interface Specifications .......................................................................................................449
9.10.3 Pseudowire Specifications .......................................................................................................449
Page 7 of 468

9.10.4 Electrical STM-1 SFP Interface Specifications ..........................................................................450

9.10.5 Optical STM-1 SFP Interface Specifications .............................................................................450
9.10.6 Approved STM-1 SFP Modules .................................................................................................451
9.11 Mechanical Specifications ........................................................................................................452
9.12 Environmental Specifications...................................................................................................454
9.12.1 Environmental Specifications for IDU ......................................................................................454
9.12.2 Environmental Specifications for RFU ......................................................................................454
9.13 Supported Antenna Types .......................................................................................................455
9.13.2 RFU-E Antenna Connection ......................................................................................................456
9.14 Waveguide Specifications ........................................................................................................457
9.14.1 RFU-D and RFU-S Waveguide Specifications ............................................................................457
9.14.2 RFU-D-HP Waveguide Specifications – Split Mount Configurations ........................................457
9.14.3 RFU-D-HP Waveguide Specifications – All Indoor Configurations ...........................................458
9.14.4 RFU-C Waveguide Specifications .............................................................................................458
9.14.5 1500HP/RFU-HP Waveguide Specifications .............................................................................459
9.14.6 1500HP/RFU-HP Antenna Interface Requirements .................................................................459
9.15 Power Input Specifications ......................................................................................................460
9.16 Power Consumption Specifications .........................................................................................461
9.17 IDU-RFU Cable Connection ......................................................................................................462
10. Annex 1: RFU-HP Transmit Power and RSL at Radio Ports ....................................... 463
10.1 Transmit Power Specifications (dBm) ......................................................................................463
10.2 Receiver Threshold Specifications ...........................................................................................465
10.2.1 Receiver Threshold – RFU-HP ..................................................................................................465
10.2.2 Receiver Threshold – 1500HP ..................................................................................................467
Page 8 of 468

List of Figures
Figure 1: IP-20N 1RU Chassis..................................................................................................................41
Figure 2: IP-20N 2RU Chassis..................................................................................................................41
Figure 3: Chassis Management ..............................................................................................................44
Figure 4: Traffic Connectivity in 2RU Chassis with TCC Redundancy .....................................................45
Figure 5: IP-20N IDU Block Diagram – 1RU Chassis ................................................................................46
Figure 6: IP-20N IDU Block Diagram – 2RU Chassis with TCC and PDC Redundancy .............................47
Figure 7: IP-20N Front Panel and Interfaces – 1RU Chassis ...................................................................48
Figure 8: IP-20N Front Panel and Interfaces – 2RU Chassis ...................................................................49
Figure 9: 1RU Chassis Slot Numbering ...................................................................................................50
Figure 10: 2RU Chassis Slot Numbering .................................................................................................50
Figure 11: 1RU Chassis – Slot Sections ...................................................................................................53
Figure 12: 2RU Chassis – Slot Sections ...................................................................................................54
Figure 13: Sample Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (1 Gbps) ....................................56
Figure 14: Sample Chassis Configuration – 4 x 2+0 Multi-Carrier ABC (1 Gbps) ....................................57
Figure 15: Sample Chassis Configuration – 2 x 2+0 Multi-Carrier ABC with RST (1 or 2.5 Gbps) ...........58
Figure 16: Sample Chassis Configuration – 1 x 8+0 Multi-Carrier ABC (2.5 Gbps) .................................59
Figure 17: Sample Chassis Configuration – 1 x 6+0 Multi-Carrier ABC with RST (2.5 Gbps) ..................60
Figure 18: Sample Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (2.5 Gbps) .................................61
Figure 19: TCC ........................................................................................................................................62
Figure 20: TCC-B and TCC-B-MC Interfaces ............................................................................................63
Figure 21: TCC-B2/TCC-B2-XG-MC Interfaces ........................................................................................63
Figure 22: TCC-B2/TCC-B2-XG-MC Management Interface Pin Connections .........................................64
Figure 23: RIC-D ......................................................................................................................................67
Figure 24: RIC-D Interfaces .....................................................................................................................68
Figure 25: RMC-A ...................................................................................................................................69
Figure 26: RMC-B....................................................................................................................................69
Figure 27: RMC-A and RMC-B Interfaces................................................................................................69
Figure 28: LIC-X-E4-Elec (4x GbE) ...........................................................................................................70
Figure 29: LIC-X-E4-Opt (4x GbE) ............................................................................................................70
Figure 30: LIC-X-E10 (1x 10G) .................................................................................................................71
Figure 31: LIC-X-E4-Elec (4x GbE) Interfaces ..........................................................................................71
Figure 32: LIC-X-E4-Opt (4x GbE) Interfaces ...........................................................................................71
Figure 33: LIC-X-E10 (1x 10G) Interface .................................................................................................72
Figure 34: LIC-T16 (16 x E1) ....................................................................................................................73
Page 9 of 468

Figure 35: LIC-T155 (1 x ch-STM-1) ........................................................................................................73

Figure 36: LIC-STM1/OC3-RST (1 x STM-1) .............................................................................................73
Figure 37: LIC-T16 (16x E1) Interfaces ....................................................................................................74
Figure 38: LIC-T155 (1 x ch-STM-1) Interfaces .......................................................................................74
Figure 39: LIC-STM1/OC3-RST (1 x STM-1) Interfaces ............................................................................74
Figure 40: Single-Input PDC ....................................................................................................................75
Figure 41: Dual-Input PDC ......................................................................................................................75
Figure 42: PDC – Functional Diagram .....................................................................................................76
Figure 43: Standard PDC Interfaces .......................................................................................................76
Figure 44: Dual-Input PDC Interfaces .....................................................................................................76
Figure 45: Power Distribution with Redundant PDCs ............................................................................77
Figure 46: Fans Module – 1RU ...............................................................................................................79
Figure 47: Fans Module – 2RU ...............................................................................................................79
Figure 48: Fans Module Diagram ...........................................................................................................79
Figure 49: Filter Tray Sliding into Filter Slot (2RU Chassis) .....................................................................80
Figure 50: RFU-D Functional Block Diagram – 2+0 Configuration ..........................................................86
Figure 51: RFU-D Radio Interfaces (6 to 15 GHz) ...................................................................................86
Figure 52: RFU-D Rear View (Left) and Front View (Right) .....................................................................87
Figure 53: RFU-D Interfaces (All Frequency Bands) ................................................................................87
Figure 54: Radio Unit and Diplexer Unit .................................................................................................89
Figure 55: Splitter ...................................................................................................................................92
Figure 56: OMT .......................................................................................................................................92
Figure 57: RFU-D-HP Functional Block Diagram – 2+0 Configuration ....................................................95
Figure 58: RFU-D-HP Radio Interfaces ....................................................................................................95
Figure 59: RFU-D-HP Front Side Interfaces ............................................................................................96
Figure 60: RFU-D-HP Interfaces ..............................................................................................................96
Figure 61: Radio Unit and Diplexer Unit .................................................................................................99
Figure 62: Open Diplexer Unit ................................................................................................................99
Figure 63: RFU-D-HP Coupler ...............................................................................................................100
Figure 64: RFU-D-HP OCU ....................................................................................................................101
Figure 65: Open OCU Showing the Channel Filters ..............................................................................101
Figure 66: OCU Channel Filters – Functional Description ....................................................................102
Figure 67: OCU Channel Filters – Internal Electrical Connections ........................................................102
Figure 68: RFU-D-HP Fully Assembled All-Indoor Terminal ..................................................................103
Figure 69: RFU-D-HP All-Indoor Marketing Model Structure ...............................................................110
Page 10 of 468

Figure 70: RFU-E Functional Block Diagram – 1+0 Configuration ........................................................113

Figure 71: RFU-E Antenna Interfaces ...................................................................................................114
Figure 72: RFU-D Front Side Interfaces ................................................................................................114
Figure 73: RFU-E Interfaces ..................................................................................................................115
Figure 74: RFU-S Functional Block Diagram – 1+0 Configuration ........................................................117
Figure 75: RFU-S Front Side Interfaces .................................................................................................117
Figure 76: RFU-S Data and Power Interfaces .......................................................................................118
Figure 77: RFU-S Radio Unit and Diplexers Unit (Separate) .................................................................120
Figure 78: RFU-S Radio Unit and Diplexers Unit (Attached) .................................................................120
Figure 79: RFU-S Coupler/Splitter ........................................................................................................122
Figure 80: RFU-S OMT ..........................................................................................................................122
Figure 81: RFU-C Functional Block Diagram – 1+0 Configuration ........................................................124
Figure 82: 1500HP 2RX in 1+0 SD Configuration ..................................................................................127
Figure 83: 1500HP 1RX in 1+0 SD Configuration ..................................................................................128
Figure 84: RFU-HP 1RX in 1+0 SD Configuration ..................................................................................128
Figure 85: All-Indoor Vertical Branching ..............................................................................................131
Figure 86: Split-Mount Branching and All-Indoor Compact ................................................................131
Figure 87: Old OCB ...............................................................................................................................132
Figure 88: OCB ......................................................................................................................................132
Figure 89: OCB and DCB Block Diagrams..............................................................................................133
Figure 90: RFU-D/RFU-D-HP MultiCore Modem and RFIC Chipsets .....................................................150
Figure 91: Performance Characteristics of Generic, 1+0 Single-Carrier Radio .....................................151
Figure 92: Doubling RFU-D/RFU-D-HP’s Capacity by Activating Second Core ......................................152
Figure 93: Header De-Duplication ........................................................................................................155
Figure 94: Header De-Duplication Potential Throughput Savings per Layer ........................................156
Figure 95: Propagation Delay with and without Frame Cut-Through ..................................................158
Figure 96: Frame Cut-Through .............................................................................................................159
Figure 97: Frame Cut-Through Operation ............................................................................................159
Figure 98: TCC-Based Multi-Carrier ABC Traffic Flow ...........................................................................162
Figure 99: Multi-Carrier ABC Minimum Bandwidth Override ..............................................................165
Figure 100: Direct and Reflected Signals ..............................................................................................168
Figure 101: 2+0 BBC Space Diversity ....................................................................................................171
Figure 102: Sample Chassis Configuration – 2+0 BBC Space Diversity .................................................172
Figure 103: Sample Chassis Configuration – 4+0 BBC Space Diversity .................................................172
Figure 104: Sample Chassis Configuration – 2 X 2+0 BBC Space Diversity ...........................................173
Page 11 of 468

Figure 105: Sample Chassis Configuration – 2 X 4+0 BBC Space Diversity ...........................................174
Figure 106: BBS Space Diversity ...........................................................................................................175
Figure 107: Path Loss on Secondary Path of 1+1 HSB Protection Link .................................................177
Figure 108: Adaptive Coding and Modulation with 13 Working Points ...............................................181
Figure 109: ACM with Adaptive Power Contrasted to Other ACM Implementations ..........................185
Figure 110: Dual Polarization ...............................................................................................................186
Figure 111: XPIC Implementation – RFU-C and 1500HP/RFU-HP.........................................................187
Figure 112: XPIC Implementation – RIC-D with RFU-D or RFU-D-HP ...................................................187
Figure 113: XPIC – Impact of Misalignments and Channel Degradation ..............................................188
Figure 114: Basic Ethernet Service Model ............................................................................................193
Figure 115: Ethernet Virtual Connection (EVC) ....................................................................................194
Figure 116: Point to Point EVC .............................................................................................................195
Figure 117: Multipoint to Multipoint EVC ............................................................................................195
Figure 118: Rooted Multipoint EVC ......................................................................................................195
Figure 119: MEF Ethernet Services Definition Framework ..................................................................197
Figure 120: E-Line Service Type Using Point-to-Point EVC ...................................................................198
Figure 121: EPL Application Example ...................................................................................................199
Figure 122: EVPL Application Example .................................................................................................200
Figure 123: E-LAN Service Type Using Multipoint-to-Multipoint EVC ..................................................200
Figure 124: Adding a Site Using an E-Line service ................................................................................201
Figure 125: Adding a Site Using an E-LAN service ................................................................................201
Figure 126: MEF Ethernet Private LAN Example ..................................................................................202
Figure 127: MEF Ethernet Virtual Private LAN Example.......................................................................203
Figure 128: E-Tree Service Type Using Rooted-Multipoint EVC ...........................................................203
Figure 129: E-Tree Service Type Using Multiple Roots.........................................................................204
Figure 130: MEF Ethernet Private Tree Example .................................................................................205
Figure 131: Ethernet Virtual Private Tree Example ..............................................................................206
Figure 132: Mobile Backhaul Reference Model ...................................................................................206
Figure 133: Packet Service Core Building Blocks ..................................................................................207
Figure 134: IP-20N Services Model ......................................................................................................211
Figure 135: IP-20N Services Core .........................................................................................................213
Figure 136: IP-20N Services Flow .........................................................................................................214
Figure 137: Point-to-Point Service .......................................................................................................215
Figure 138: Multipoint Service .............................................................................................................216
Figure 139: Management Service ........................................................................................................218
Page 12 of 468

Figure 140: Management Service and its Service Points .....................................................................220

Figure 141: SAPs and SNPs ...................................................................................................................221
Figure 142: Pipe Service Points ............................................................................................................221
Figure 143: SAP, SNP and Pipe Service Points in a Microwave Network .............................................222
Figure 144: Service Path Relationship on Point-to-Point Service Path ................................................226
Figure 145: Physical and Logical Interfaces ..........................................................................................229
Figure 146: Grouped Interfaces as a Single Logical Interface on Ingress Side .....................................230
Figure 147: Grouped Interfaces as a Single Logical Interface on Egress Side ......................................230
Figure 148: Relationship of Logical Interfaces to the Switching Fabric ................................................234
Figure 149: QoS Block Diagram ............................................................................................................239
Figure 150: Standard QoS and H-QoS Comparison ..............................................................................241
Figure 151: Hierarchical Classification .................................................................................................242
Figure 152: Classification Method Priorities ........................................................................................243
Figure 153: Ingress Policing Model ......................................................................................................248
Figure 154: IP-20N Queue Manager .....................................................................................................251
Figure 155: Synchronized Packet Loss ..................................................................................................252
Figure 156: Random Packet Loss with Increased Capacity Utilization Using WRED ............................253
Figure 157: WRED Profile Curve ...........................................................................................................254
Figure 158: Detailed H-QoS Diagram ...................................................................................................257
Figure 159: Scheduling Mechanism for a Single Service Bundle ..........................................................260
Figure 160: G.8032 Ring in Idle (Normal) State ....................................................................................270
Figure 161: G.8032 Ring in Protecting State ........................................................................................271
Figure 162: Load Balancing Example in G.8032 Ring ............................................................................271
Figure 163: IP-20N End-to-End Service Management ..........................................................................275
Figure 164: SOAM Maintenance Entities (Example) ............................................................................276
Figure 165: Ethernet Line Interface Loopback – Application Examples ...............................................277
Figure 166: Native Sync Distribution Mode .........................................................................................282
Figure 167: Synchronization Configuration ..........................................................................................284
Figure 168: Native Sync Distribution Mode Usage Example ................................................................286
Figure 169: Native Sync Distribution Mode – Tree Scenario ................................................................286
Figure 170: Native Sync Distribution Mode – Ring Scenario (Normal Operation) ...............................287
Figure 171: Native Sync Distribution Mode – Ring Scenario (Link Failure) ..........................................287
Figure 172: Synchronous Ethernet (SyncE) ..........................................................................................288
Figure 173: IEEE-1588v2 PTP Optimized Transport – General Architecture ........................................289
Figure 174: Calculating the Propagation Delay for PTP Packets ..........................................................290
Page 13 of 468

Figure 175: Transparent Clock – General Architecture ........................................................................293

Figure 176: Transparent Clock Delay Compensation ...........................................................................294
Figure 177: Boundary Clock – General Architecture ............................................................................295
Figure 178: Hybrid Ethernet and TDM Services ...................................................................................296
Figure 179: Hybrid Ethernet and TDM Services Carried Over Cascading Interfaces ............................297
Figure 180: Hybrid Ethernet and Native TDM Services ........................................................................298
Figure 181: 1:1 TDM Path Protection – Ring Topology ........................................................................299
Figure 182: 1+1TDM Path Protection – Dual Homing Topology ..........................................................300
Figure 183: All-Packet Ethernet and TDM Pseudowire Services ..........................................................302
Figure 184: 1+1 HSB Card Protection for LIC-T16 (E1) Cards ...............................................................308
Figure 185: 1+1 HSB Protection for LIC-T155 (STM-1) and LIC-STM1/OC3-RST Cards .........................309
Figure 186: Uni-directional MSP for LIC-T155 (STM-1) Cards ..............................................................310
Figure 187: Native TDM Trail Interoperability with Optical SDH Equipment .......................................311
Figure 188: Native TDM Trail Interoperability with TDM Pseudowire-over-Packet Aggregation ........311
Figure 189: TDM Pseudowire Interoperability with Optical SDH Equipment ......................................311
Figure 190: TDM Pseudowire Interoperability with Third-Party Packet Aggregation Equipment .......312
Figure 191: AES-256 Encrypted Link .....................................................................................................313
Figure 192: Integrated IP-20N Management Tools ..............................................................................318
Figure 193: Security Solution Architecture Concept ............................................................................329
Figure 194: Designated ETSI System Class Explanation........................................................................345
Figure 195: RFU-HP Branching System using Adjacent Channel OCBs .................................................443
Figure 196: RFU-HP Branching System using Symmetrical Coupler .....................................................443
Figure 197: Four-Adjacent Channel configuration using a symmetrical coupler .................................444
Page 14 of 468

List of Tables
Table 1: IP-20N 1RU and 2RU Scalability -------------------------------------------------------------------------------- 31
Table 2: Interoperability with Other Ceragon Products------------------------------------------------------------- 32
Table 3: Radio Configuration Options for RFU-C and 1500HP/RFU-HP ----------------------------------------- 33
Table 4: Radio Configuration Options for RFU-D, RFU-D-HP, RFU-E, or RFU-S with RIC-D ---------------- 35
Table 5: New Features in CeraOS 10.7.5 and CeraOS 10.9 --------------------------------------------------------- 40
Table 6: Card Types Allowed Per Slot – 1RU --------------------------------------------------------------------------- 50
Table 7: Card Types Allowed Per Slot – 2RU --------------------------------------------------------------------------- 51
Table 8: Slot Limitations When Used with TCC-B2 or TCC-B2-XG-MC ------------------------------------------ 51
Table 9: Card Type Usage Per Section Capacity ----------------------------------------------------------------------- 53
Table 10: Additional Slot Limitations with Multi-Carrier ABC ----------------------------------------------------- 55
Table 11: 2 x FE Splitter Cable Marketing Model --------------------------------------------------------------------- 64
Table 12: TCC Comparison Table ------------------------------------------------------------------------------------------ 65
Table 13: Y-Cable for Electrical Splitter Mode FE Traffic Interface Protection -------------------------------- 66
Table 14: RFU Selection Guide --------------------------------------------------------------------------------------------- 83
Table 15: RFU-D Interfaces ------------------------------------------------------------------------------------------------- 87
Table 16: RFU-D Marketing Model Structure, 6 to 15 GHz (Radio Unit) ---------------------------------------- 88
Table 17: RFU-D Marketing Model Structure, 6 to 15 GHz (Diplexer Unit) ------------------------------------ 88
Table 18: RFU-D Marketing Model Structure– Possible Values (Easy Set - Radio Unit Only) ------------- 89
Table 19: RFU-D Marketing Model Structure– Possible Values (Easy Set - Diplexer Unit Only)---------- 89
Table 20: RFU-D Diplexer Unit Marketing Model Examples ------------------------------------------------------- 90
Table 21: RFU-D Marketing Model Structure,18 to 42 GHz -------------------------------------------------------- 90
Table 22: RFU-D Marketing Model Structure– Possible Values --------------------------------------------------- 90
Table 23: RFU-D Marketing Model Examples (18-42 GHz) --------------------------------------------------------- 91
Table 24: RFU-D Mediation Devices -------------------------------------------------------------------------------------- 91
Table 25: RFU-D-HP Interfaces -------------------------------------------------------------------------------------------- 97
Table 26: RFU-D-HP Mediation Devices ------------------------------------------------------------------------------- 100
Table 27: All-Indoor Radio Configuration Options for RFU-D-HP ----------------------------------------------- 104
Table 28: RFU-D-HP Marketing Models – Radio Unit -------------------------------------------------------------- 105
Table 29: DXDHff-xxxY-ccWdd-eeWgg-t ------------------------------------------------------------------------------ 105
Table 30: RFU-D-HP Diplexers Unit Marketing Model Example ------------------------------------------------ 106
Table 31: RFU-D-HP MCMD Marketing Models --------------------------------------------------------------------- 107
Table 32: Marketing Model Structure – OCU ------------------------------------------------------------------------ 108
Table 33: RFU-D-HP OCU Marketing Model Example ------------------------------------------------------------- 108
Table 34: RFU-D-HP Branching Unit Marketing Models ---------------------------------------------------------- 109
Page 15 of 468

Table 35: RFU-D-HP All-Indoor Marketing Model Structure ----------------------------------------------------- 110

Table 36: RFU-E Interfaces ------------------------------------------------------------------------------------------------ 115
Table 37: RFU-E Marketing Models ------------------------------------------------------------------------------------ 115
Table 38: RFU-S Interfaces ------------------------------------------------------------------------------------------------ 118
Table 39: RFU-S Marketing Model Syntax, 6 to 15 GHz (Radio Unit) ------------------------------------------ 119
Table 40: RFU-S Marketing Model Syntax, 6 to 15 GHz (Diplexer Unit) -------------------------------------- 119
Table 41: RFU-S Marketing Model Structure– Possible Values (Easy Set - Radio Unit Only) ------------ 120
Table 42: : RFU-S Marketing Model Structure– Possible Values (Easy Set - Diplexer Unit Only) ------ 120
Table 43: RFU-S Diplexer Unit Marketing Model Example ------------------------------------------------------- 121
Table 44: RFU-S Marketing Model Structure,18 to 42 GHz ------------------------------------------------------ 121
Table 45: RFU-S Marketing Model Structure– Possible Values ------------------------------------------------- 121
Table 46: RFU-S Marketing Model Examples (18-42 GHz) ------------------------------------------------------- 122
Table 47: 1500HP/RFU-HP Comparison Table ----------------------------------------------------------------------- 129
Table 48: OCB Component Summary ---------------------------------------------------------------------------------- 135
Table 49: RFU Models – 1RX Units-------------------------------------------------------------------------------------- 136
Table 50: RFU Models – 2RX Units-------------------------------------------------------------------------------------- 136
Table 51: OCB Part Numbers --------------------------------------------------------------------------------------------- 137
Table 52: Activation Key Types ------------------------------------------------------------------------------------------ 141
Table 53: Capacity Activation Key Levels ----------------------------------------------------------------------------- 144
Table 54: CET Node Activation Key Levels ---------------------------------------------------------------------------- 146
Table 55: TCO Comparison Between Single-Carrier and MultiCore Systems-------------------------------- 154
Table 56: RIC-D Multi-Carrier ABC – RFU-Based vs. TCC-Based ------------------------------------------------- 163
Table 57: Space Diversity Methods ------------------------------------------------------------------------------------- 169
Table 58: ACM Working Points (Profiles) – RIC-D with Microwave RFUs ------------------------------------ 179
Table 59: ACM Working Points (Profiles) – RIC-D with E-Band RFU (RFU-E) -------------------------------- 179
Table 60: ACM Working Points (Profiles) – RMC-A ----------------------------------------------------------------- 180
Table 61: ACM Working Points (Profiles) – RMC-B ----------------------------------------------------------------- 180
Table 62: MEF-Defined Ethernet Service Types --------------------------------------------------------------------- 197
Table 63: Ethernet Services Learning and Forwarding ------------------------------------------------------------ 217
Table 64: Service Point Types per Service Type --------------------------------------------------------------------- 223
Table 65: Service Point Types that can Co-Exist on the Same Interface -------------------------------------- 224
Table 66: Service Point Type-Attached Interface Type Combinations that can Co-Exist on the Same
Interface ----------------------------------------------------------------------------------------------------------------------- 225
Table 67: C-VLAN 802.1 UP and CFI Default Mapping to CoS and Color ------------------------------------- 243
Table 68: S-VLAN 802.1 UP and DEI Default Mapping to CoS and Color ------------------------------------- 244
Table 69: MPLS EXP Default Mapping to CoS and Color ---------------------------------------------------------- 244
Page 16 of 468

Table 70: DSCP Default Mapping to CoS and Color ---------------------------------------------------------------- 245
Table 71: QoS Priority Profile Example -------------------------------------------------------------------------------- 261
Table 72: WFQ Profile Example------------------------------------------------------------------------------------------ 262
Table 73: 802.1q UP Marking Table (C-VLAN) ----------------------------------------------------------------------- 265
Table 74: 802.1ad UP Marking Table (S-VLAN) ---------------------------------------------------------------------- 265
Table 75: Summary and Comparison of Standard QoS and H-QoS -------------------------------------------- 266
Table 76: Native Sync Interface Options ------------------------------------------------------------------------------ 283
Table 77: Boundary Clock Input Options ------------------------------------------------------------------------------ 295
Table 78: Boundary Clock Output Options --------------------------------------------------------------------------- 295
Table 79: Y-Cable for LIC-T16 Card Protection ---------------------------------------------------------------------- 309
Table 80: FIPS-Compliant Marketing Models ------------------------------------------------------------------------ 315
Table 81: Dedicated Management Ports ------------------------------------------------------------------------------ 320
Table 82: Supported Ethernet Standards ----------------------------------------------------------------------------- 338
Table 83: Supported MEF Specifications ------------------------------------------------------------------------------ 339
Table 84: MEF Certifications --------------------------------------------------------------------------------------------- 339
Table 85: Radio Frequencies --------------------------------------------------------------------------------------------- 343
Table 86: General Radio Specifications – Microwave RFUs ------------------------------------------------------ 343
Table 87: Radio Frequencies and General Radio Specifications – RFU-E ------------------------------------- 344
Table 88: Frequency Tuning Range for RFU-E ----------------------------------------------------------------------- 344
Table 89: MRMC Scripts Supported with RIC-D and RFU-D, RFU-D-HP, and RFU-S ----------------------- 346
Table 90: MRMC Scripts Supported with RIC-D and RFU-E ------------------------------------------------------ 347
Table 91: MRMC Scripts Supported with RMC-B ------------------------------------------------------------------- 348
Table 92: MRMC Scripts Supported with RMC-A ------------------------------------------------------------------- 349
Table 93: Radio Capacity for 14 MHz ---------------------------------------------------------------------------------- 350
Table 100: Radio Capacity for 40 MHz --------------------------------------------------------------------------------- 357
Page 17 of 468

Table 105: Radio Capacity for 112 MHz ------------------------------------------------------------------------------- 362

Table 109: Radio Capacity for 62.5 MHz ------------------------------------------------------------------------------ 365
Table 113: Radio Capacity for 3.5 MHz – Script ID 1023 ---------------------------------------------------------- 367
Table 114: Radio Capacity for 7 MHz – Script ID 1008 ------------------------------------------------------------ 367
Table 115: Radio Capacity for 14 MHz – Script ID 1009----------------------------------------------------------- 368
Table 129: Radio Capacity for 7 MHz – Script ID 33 ---------------------------------------------------------------- 381
Table 130: Radio Capacity for 14 MHz – Script ID 23 -------------------------------------------------------------- 381
Table 134: Transmit power specifications for RFU-D (dBm) ----------------------------------------------------- 384
Table 135: Pmin Power for RFU-D -------------------------------------------------------------------------------------- 384
Table 136: Transmit power specifications for RFU-D-HP (dBm) ------------------------------------------------ 385
Table 137: Diplexer Unit Typical Losses with RFU-D-HP ---------------------------------------------------------- 385
Table 138: Transmit power specifications for RFU-S (dBm) ----------------------------------------------------- 386
Table 139: Pmin Power for RFU-S --------------------------------------------------------------------------------------- 386
Page 18 of 468

Table 140: Transmit power specifications for RFU-E (dBm) ----------------------------------------------------- 387
Table 141: Transmit Power with RFU-C (dBm) ---------------------------------------------------------------------- 388
Table 142: Pmin Power with RFU-C ------------------------------------------------------------------------------------ 388
Table 143: Transmit power specifications for RFU-HP 1RX (dBm) --------------------------------------------- 389
Table 144: Transmit power specifications for RFU-HP 2RX (1500HP) (dBm) -------------------------------- 390
Table 145: Receiver Thresholds with RFU-D and RFU-S (6-18 GHz) ------------------------------------------- 391
Table 146: Receiver Thresholds with RFU-D and RFU-S (23-42 GHz) ------------------------------------------ 394
Table 147: Receiver Thresholds with RFU-D-HP -------------------------------------------------------------------- 397
Table 148: Receiver Thresholds with RFU-E -------------------------------------------------------------------------- 399
Table 149: Receiver Thresholds with RMC-B and RFU-C---------------------------------------------------------- 400
Table 150: Receiver Thresholds with RFU-HP ----------------------------------------------------------------------- 403
Table 151: Receiver Thresholds with 1500HP ----------------------------------------------------------------------- 405
Table 152: Receiver Thresholds with RMC-A and RFU-C --------------------------------------------------------- 407
Table 153: RFU-C Receiver Threshold (RSL) with RMC-A (dBm @ BER = 10-6) ----------------------------- 407
Table 154: Frequency Bands – RFU-C, RFU-D, RFU-D-HP, and RFU-S ----------------------------------------- 409
Table 155: Frequency Bands – RFU-E ---------------------------------------------------------------------------------- 421
Table 156: Frequency Bands – 1500HP and RFU-HP --------------------------------------------------------------- 422
Table 157: Ethernet Latency with RIC-D and RFU-D and RFU-S – 14 MHz Channel Bandwidth -------- 423
Table 158: Ethernet Latency with RIC-D and RFU-D, RFU-D-HP, and RFU-S – 28 MHz Channel
Bandwidth --------------------------------------------------------------------------------------------------------------------- 424
Bandwidth --------------------------------------------------------------------------------------------------------------------- 425
Bandwidth --------------------------------------------------------------------------------------------------------------------- 426
Bandwidth --------------------------------------------------------------------------------------------------------------------- 427
Table 162: Ethernet Latency with RIC-D and RFU-E – 14 MHz Channel Bandwidth ----------------------- 428
Table 163: Ethernet Latency with RIC-D and RFU-E – 28 MHz Channel Bandwidth ----------------------- 428
Table 164: Ethernet Latency with RIC-D and RFU-E – 62.5 MHz Channel Bandwidth -------------------- 429
Table 165: Ethernet Latency with RIC-D and RFU-E – 125 MHz Channel Bandwidth --------------------- 429
Table 168: Ethernet Latency with RMC-B – 3.5 MHz Channel Bandwidth ----------------------------------- 431
Table 169: Ethernet Latency with RMC-B – 7 MHz Channel Bandwidth-------------------------------------- 431
Table 170: Ethernet Latency with RMC-B – 14 MHz Channel Bandwidth ------------------------------------ 432
Page 19 of 468

Table 174: Ethernet Latency with RMC-A – 14 MHz Channel Bandwidth ------------------------------------ 434
Table 175: Ethernet Latency with RMC-A – 28 MHz Channel Bandwidth ------------------------------------ 434
Table 176: Ethernet Latency with RMC-A – 40MHz Channel Bandwidth ------------------------------------ 435
Table 177: Ethernet Latency with RMC-A – 56MHz Channel Bandwidth ------------------------------------ 435
Table 178: RFU-D/RFU-D-HP Mediation Device Losses ----------------------------------------------------------- 436
Table 179: RFU-D-HP Filter-Based Branching Losses – Remote Mount--------------------------------------- 438
Table 180: RFU-D-HP Filter-Based Branching Losses – All-Indoor ---------------------------------------------- 439
Table 181: RFU-E Mediation Device Losses -------------------------------------------------------------------------- 441
Table 182: RFU-C and RFU-S Mediation Device Losses ----------------------------------------------------------- 441
Table 183: 1500HP/RFU-HP Branching Network Losses ---------------------------------------------------------- 442
Table 184: Added Losses -------------------------------------------------------------------------------------------------- 442
Table 185: 1500HP/RFU-HP All-Indoor Branching Loss – Part 1 ------------------------------------------------ 445
Table 186: 1500HP/RFU-HP All-Indoor Branching Loss – Part 2 ------------------------------------------------ 446
Table 187: Ethernet Interface Specifications ------------------------------------------------------------------------ 447
Table 188: Carrier Ethernet Functionality ---------------------------------------------------------------------------- 447
Table 189: Approved GbE SFP Modules ------------------------------------------------------------------------------- 448
Table 190: Approved 2.5 GbE SFP Modules -------------------------------------------------------------------------- 448
Table 191: Approved 10 GbE SFP Modules --------------------------------------------------------------------------- 448
Table 192: E1 Cross Connect --------------------------------------------------------------------------------------------- 449
Table 193: Pseudowire Specifications --------------------------------------------------------------------------------- 449
Table 194: Electrical STM-1 SFP Interface Specifications --------------------------------------------------------- 450
Table 195: Optical STM-1 SFP Interface Specifications ----------------------------------------------------------- 450
Table 196: Approved STM-1 SFP Modules---------------------------------------------------------------------------- 451
Table 197: IDU Chassis Mechanical Specifications ----------------------------------------------------------------- 452
Table 198: IDU Card and Tray Weights -------------------------------------------------------------------------------- 452
Table 199: RFU-C Mechanical Specifications ------------------------------------------------------------------------ 452
Table 200: 1500HP/RFUHP Mechanical Specifications ------------------------------------------------------------ 453
Table 201: RFU-D Mechanical Specifications (including diplexer unit) --------------------------------------- 453
Table 202: RFU-D-HP Mechanical Specifications (including diplexer or OCU unit) ------------------------ 453
Table 203: RFU-E Mechanical Specifications ------------------------------------------------------------------------- 453
Table 204: RFU-S Mechanical Specifications ------------------------------------------------------------------------- 453
Table 205: Supported Antenna Types per RFU ---------------------------------------------------------------------- 455
Table 206: RFU-E Integrated Antenna – Electrical Parameters ------------------------------------------------- 456
Table 207: RFU-D and RFU-S – Waveguide Flanges ---------------------------------------------------------------- 457
Page 20 of 468

Table 208: RFU-D-HP – Waveguide Flanges for Split Mount Configurations -------------------------------- 457
Table 209: RFU-D-HP – Waveguide Flanges for All-Indoor Configurations ---------------------------------- 458
Table 210: RFU-C – Waveguide Flanges ------------------------------------------------------------------------------- 458
Table 211: 1500HP/RFU-HP – Waveguide Flanges ----------------------------------------------------------------- 459
Table 212: 1500HP/RFU-HP Antenna Interface Requirements ------------------------------------------------- 459
Table 213: Power Input Specifications -------------------------------------------------------------------------------- 460
Table 214: Power Consumption Specifications --------------------------------------------------------------------- 461
Table 215: IDU-RFU Cable Connection -------------------------------------------------------------------------------- 462
Table 216: Transmit Power Specifications for RFU-HP 1RX (dBm) --------------------------------------------- 463
Table 217: Transmit power specifications for RFU-HP 2RX (1500HP) (dBm) -------------------------------- 464
Table 218: Receiver Threshold – RFU-HP ----------------------------------------------------------------------------- 465
Table 219: Receiver Threshold – 1500HP ----------------------------------------------------------------------------- 467
Page 21 of 468

About This Guide

This document describes the main features, components, and specifications of the
FibeAir IP-20N. This document applies to CeraOS version 10.9.
What You Should Know

This document describes applicable ETSI standards and specifications.
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-20N for use in system planning, and determining which
FibeAir IP-20N configuration is best suited for a specific network.
Related Documents
• FibeAir IP-20 User Guide for FibeAir IP-20N, IP-20A, IP-20LH, and Evolution IP-
20LH
• FibeAir IP-20N Installation Guide, DOC-00040492
• FibeAir IP-20 Series MIB Reference
Page 22 of 468

1. Synonyms and Acronyms
Acronym Equivalent Term
ACM Adaptive Coding and Modulation

ACR Adaptive Clock Recovery
AES Advanced Encryption Standard
AIS Alarm Indication Signal
ATPC Automatic Tx Power Control
BBC Baseband Combining
BBS Baseband Switching
BER Bit Error Ratio
BLSR Bidirectional Line Switch Ring
BMCA Best Master Clock Algorithm
BPDU Bridge Protocol Data Units
BWA Broadband Wireless Access
CBS Committed Burst Size
CCDP Co-channel dual polarization
CE Customer Equipment
CET Carrier-Ethernet Transport
CFM Connectivity Fault Management
CIR Committed Information Rate
CLI Command Line Interface
CoS Class of Service
DA Destination Address
DSCP Differentiated Service Code Point
EBS Excess Burst Size
EIR Excess Information Rate
EPL Ethernet Private Line
EVPL Ethernet Virtual Private Line
EVC Ethernet Virtual Connection
FEC Forward Error Correction
FTP (SFTP) File Transfer Protocol (Secured File Transfer Protocol)
GbE Gigabit Ethernet
Page 23 of 468

GMT Greenwich Mean Time

HSB Hot Standby
HSO Hot Switchover
HTTP (HTTPS) Hypertext Transfer Protocol (Secured HTTP)
IDC Indoor Controller
IDU Indoor unit
LACP Link Aggregation Control Protocol
LANs Local area networks
LLF Link Loss Forwarding
LOC Loss of Carrier
LOF Loss of Frame
LoS Line of Sight
LOS Loss of Signal
LTE Long-Term Evolution
LTE-TDD LTE Time-Division Duplex
MAID Maintenance Association (MA) Identifier (ID)
MEN Metro Ethernet Network
MPLS Multiprotocol Label Switching
MRU Maximum Receive Unit
MSP Multiplex Section Protection
MSTP Multiple Spanning Tree Protocol
MTU Maximum Transmit Capability
NMS Network Management System
NTP Network Time Protocol
OAM Operation Administration & Maintenance (Protocols)
OFDMA Orthogonal Frequency-Division Multiple Access
OOF Out-of-Frame
PCM Pulse Code Modulation
PDU Power Distribution Unit
PDV Packed Delay Variation
PIR Peak Information Rate
PM Performance Monitoring
Page 24 of 468

PN Provider Network (Port)

PSN Packet Switched Network
PTP Precision Timing-Protocol
PW Pseudowire
QoE Quality of-Experience
QoS Quality of Service
RBAC Role-Based Access Control
RDI Remote Defect Indication
RFU Radio Frequency Unit
RMON Ethernet Statistics
RSL Received Signal Level
RSTP Rapid Spanning Tree Protocol
SAP Service Access Point
SD Space Diversity
SFTP Secure FTP
SLA Service level agreements
SNMP Simple Network Management Protocol
SNP Service Network Point
SNTP Simple Network Time Protocol
SP Service Point
STP Spanning Tree Protocol
SSH Secured Shell (Protocol)
SSM Synchronization Status Messages
SyncE Synchronous Ethernet
TC Traffic Class
TDD Time-Division Duplex
ToD Time of Day
TOS Type of Service
UE User Equipment
UNI User Network Interface
UTC Coordinated Universal Time
VC Virtual Containers
Page 25 of 468

Web EMS Web-Based Element Management System

WG Wave guide
WFQ Weighted Fair Queue
WRED Weighted Random Early Detection
XPIC Cross Polarization Interference Cancellation
Page 26 of 468

2. Introduction
This chapter provides an overview of the IP-20N, Ceragon’s high capacity, split-
mount aggregation node. IP-20N is designed for ultra-high flexibility and
modularity. It is optimized for nodal deployment, with a small footprint, high
density, and a high degree of scalability and availability.
IP-20N is an integral part of the FibeAir IP-20 family of high-capacity wireless
backhaul products. Together, the FibeAir IP-20 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 IP-20 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 node.
FibeAir IP-20N enables operators to continuously increase operational efficiency
and provide better quality of experience to their customers. Highlights include:
• Provides the highest radio capacity and spectral efficiency in any condition
and any frequency channel size (up to 112 MHz in microwave bands and up to
500 MHz in E-band).
• Doubles wireless backhaul capacity via remote activation of another radio
carrier with no site visits required – the fastest transmission network setup
from planning to fulfillment.
• Reduces tower or roof-top equipment footprint by 50% in dual carrier
configurations.
• Enables operators to deploy sites where needed, removing wireless backhaul
constraints by doubling the reuse of microwave frequency channels, using
Advanced Frequency Reuse technology embedded in the multicore technology.
• Optimizes E-Band aggregation sites, supporting TDM over E-Band and
enhancing existing microwave links with E-Band.
Ceragon’s diverse portfolio of RFUs enables operators to utilize a large variety of
radio capabilities in a single IP-20N aggregation node or in multiple nodes,
depending on the network requirements. This includes MultiCore functionality,
XPIC, both microwave and E-Band frequencies ranges, wide-channel support (up
to 112 MHz in microwave bands and up to 500 MHz in E-band), modulations of up
to 4096 QAM, and high-power and ultra-high-power options.
Additionally, IP-20N’s modular structure provides for the gradual expansion of network
nodes through the addition of line and radio cards, utilizing a single 1RU or 2RU chassis.
This chapter includes:

• Product Overview
• Solution Overview
• FibeAir IP-20 Assured Platform
• New Features in CeraOS 10.7.5 and CeraOS 10.9
Page 27 of 468

2.1 Product Overview

FibeAir IP-20N is a highly modular and flexible wireless backhaul product that is
optimized for multi-carrier and nodal deployment, with a small footprint, high
density, and a high degree of scalability and availability. An IP-20N system is based
on a chassis, which is provided in sizes that fit a single rack unit or two rack units,
and which contains five or ten slots for any mix of Ethernet, TDM, and radio cards.
FibeAir IP-20N can use any mix of Ceragon RFUs to provide a wide variety of radio
features and functionality, tailored to the needs of the operator. RFUs such as
single-carrier RFU-S and MultiCore RFU-D support wide channels of up to 112 MHz
and modulations of up to 4096 QAM. In the same IP-20N node, operators can use
both microwave and E-band frequencies, standard, high-power, and ultra-high-
power radios, and MultiCore or single core radios.
The MultiCore RFU-D and RFU-D-HP radios enable operators to start with a single
carrier with the option of enabling the second carrier remotely when network
capacity requirements increase. MultiCore radios also enable IP-20N to support
advanced features such as Multi-Carrier ABC configurations of up to 8+0, as well
as 4x2+0 and 2x4+0.
By expanding available capacity, the IP-20 Platform helps operators meet specific
traffic needs in both the traditional microwave spectrum and new frequency
bands.
FibeAir IP-20N enables operators to increase their operational efficiency and
provide better quality of experience to their customers. IP-20N provides support
for emerging services, standards, and networking protocols (future proof). It also
enables operators to reduce TCO by supporting rich, revenue-generating services,
simplified management for reduced OPEX, and improved service availability and
time-to-revenue. IP-20N features an advanced feature set for Carrier Ethernet
Transport, including a sophisticated Ethernet services engine, cutting-edge header
de-duplication techniques, frame cut-through, and more.
IP-20N provides an innovative TDM and packet backhaul services aggregation
solution that is designed to meet the challenges faced by operators building next-
generation wireless backhaul networks for delivery of packet-based services.
Meeting these challenges requires the ability to maintain services with strict SLA
by enforcing a services policy that guarantees and monitors service performance.
It also requires the ability to manage the explosion of data by ensuring capacity
allocation and traffic management under wireless link congestion scenarios.
IP-20N is optimized for multi-carrier and aggregation nodes by means of its high
modularity, scalability, and flexibility. The IP-20N aggregation solution is based
upon rich backhaul services and simplified management that are supported using
advanced QoS, service OAM, and carrier-grade service resiliency (G.8032, MSTP).
Page 28 of 468

2.1.1 IP-20N Radio Options

An IP-20N system consists of an IP-20N indoor unit (IDU) and one or more radio
frequency units (RFUs). Ceragon RFUs can be divided into the following two
categories:
• RFUs that are connected to the IDU over optical fiber or electrical CAT-5/6
using a RIC-D card:
 RFU-D – MultiCore RFU that operates in the 6-42 GHz frequency range, supporting
channel bandwidth of 14-112 MHz and modulations of BSPK to 4096 QAM.
 RFU-D-HP – High-Power MultiCore RFU that operates in the 4-11 GHz frequency
range, supporting channel bandwidth of 14-112 MHz and modulations of BSPK to
4096 QAM.
 RFU-E –Operates in the E-band frequency range, supporting 71-76 GHz and 81-86
GHz frequencies, channel bandwidth of 14, 28, 62.5, 125, 250, and 500 MHz, and
modulations of BSPK to 1024 QAM.
 RFU-S – Operates in the 6-42 GHz frequency range, supporting channel bandwidth
of 14-112 MHz and modulations of BSPK to 4096 QAM.
• RFUs that use RMC-A or RMC-B to interface with the IDU:
 RFU-C – Operates in the 6-42 GHz frequency range, supporting channel bandwidth
of 3.5-56 MHz and modulations of QSPK to 2048 QAM.
 RFU-HP/1500HP – High-Power RFU that operates in the 6-11 GHz frequency range,
supporting channel bandwidth of 3.5-56 MHz and modulations of QSPK to 2048
QAM.
Page 29 of 468

2.1.2 IP-20N Hardware Options and Scalability

IP-20N chassis are available in 1RU and 2RU versions, each of which supports a
common set of cards for traffic, radio interface, and management:
• Traffic/Control Card (TCC)
 TCC-B – Contains 2 x 1 GbE Ethernet combo interfaces (electrical or optical)
 TCC-B-MC – Contains 2 x 1 GbE Ethernet combo interfaces (electrical or optical)
and supports Multi-Carrier ABC
 TCC-B2 – Contains 2 x GbE optical interfaces, 2 x dual mode cascading or electrical
GbE interfaces, and 2 x electrical GbE interfaces
 TCC-B2-XG-MC – Contains 2 x GbE optical interfaces, 2 x dual mode cascading or
electrical GbE interfaces, and 2 x electrical GbE interfaces, and supports up to four
Multi-Carrier ABC groups.
• Radio Interface Cards (RIC)
 RIC-D – Used to connect IDU with RFU-D, RFU-D-HP, RFU-E, and RFU-S. Includes
electrical or optical RFU interfaces. Each RFU interface supports up to 2.5 Gbps.
Note: For a detailed list of supported configurations, see Supported IP-
20N Radio Configurations on page 33.
• Radio Modem Cards (RMC)
 RMC-B – Can be used with RFU-C and 1500HP/RFU-HP RFUs. Supports up to 2048
QAM (with ACM) and XPIC.
 RMC-A – Can be used with RFU-C and 1500HP/RFU-HP RFUs. Based on the same
modem technology used in Ceragon’s FibeAir IP-10 series IDUs, including IP-10G
and IP-10E. RMC-A supports up to 256 QAM (with ACM).
Note: IP-10G links with IP-20N units using RMC-A do not support native
TDM services.
• Line Cards (LIC)
 Ethernet – LIC-X-E4-Elec (4x GbE), with 1 GbE combo interface and 3 GbE electrical
(RJ-45) interfaces
 Ethernet – LIC-X-E4-Opt (4x GbE) with 1 GbE combo interface and 3 GbE optical
(SFP) interfaces
 Ethernet – LIC-X-E10 (1x10G), with a single 10G optical (SFP+) interface
 TDM – LIC-T16 (16x E1)
 TDM – LIC-T155 (1x ch-STM-1)
 TDM –LIC-STM1/OC3-RST (1 x STM-1)
The 1RU chassis supports up to 5 carriers, with redundancy options for radio and
traffic, and a dual-feed power option for power redundancy.
The 2RU chassis supports up to 10 carriers, with redundancy options for
management, radio, traffic, and power.
Page 30 of 468

Table 1: IP-20N 1RU and 2RU Scalability
Interface Type 1RU Chassis 2RU Chassis

Maximum Maximum Number Maximum Number Maximum Number
Number of of Radio/Line of RMCs/RICs/LICs of Radio/Line
RMCs/RICs/LICs Interfaces Interfaces
Radio (RFU) 5 x RMC or RIC 5 x RFU 10 x RMC or 8x RIC 10 x RFU

Ethernet 1 x LIC-X-E4- 10 X GbE/FE1 2 x LIC-X-E4- 10 x GbE/FE2
(GbE/FE) Elec/Opt (4x GbE) Elec/Opt (4x GbE)
or LIC-X-E10 (10G) or LIC-X-E10 (10G)
TDM – E1s 4 x any combination of LIC-T16 (16x E1) 8 x any combination of LIC-T16 (16x E1)
TDM – ch-STM-1 and LIC-T155 (1x ch-STM-1) and LIC-T155 (1x ch-STM-1)
TDM – STM-1 4 x LIC-STM1/OC3-RST 8 x LIC-STM1/OC3-RST
1
2 x GE interfaces on the TCC-B-MC or 6 x GE interfaces on the TCC-B2 or TCC-B2-XG-MC, and 4 x GE
interfaces on the Ethernet LIC, for a total of 6 or 10 GE interfaces per chassis.
2
When an Ethernet LIC is installed in slot 12, two GE interfaces on the TCC-B or TCC-B-MC are disabled,
leaving a total of 8 GE interfaces per chassis. When using a TCC-B2 or TCC-B2-XG-MC, four GE
interfaces on the TCC are disabled, leaving a total of 10 GE interfaces per chassis.
Page 31 of 468

2.1.3 FibeAir IP-20N Interoperability with other Ceragon Products

1+1 HSB and 2+0 LAG links, as well as 1+0 links, can be configured between IP-20N
radio carriers using RMC-A and IP-10G R3/IP-10E R3 units.
Links using RMC-B or RIC-D are interoperable with other FibeAir IP-20 IDUs and
RFUs as described in Table 2.
Notes: For specific software version requirements, refer to the Release
Notes for the version you are using.
MRMC scripts for RFUs that use RIC-D are interoperable with
RMC-B scripts up to 2048 QAM.
Table 2: Interoperability with Other Ceragon Products
Site 1 Site 2 Link Configuration

IDU RFU IDU RFU
IP-20N RFU-C IP-20G, IP-20GX RFU-C 1+0, 2+0 MC-ABC, 1+1 HSB
IP-20N RFU-C IP-20N, IP-20F RFU-S3 1+03
IP-20N RFU-S IP-20F RFU-S 1+0
IP-20N RFU-S IP-20N, IP-20GX, IP- RFU-C3 1+03
20G
IP-20N RFU-D IP-20F, RFU-D 1+0, 2+0 MC-ABC
IP-20N RFU-D IP-20N, IP-20GX, IP- RFU-C3 2+0 MC-ABC3
20G
IP-20N RFU-D IP-20C3 2+0 MC-ABC3
IP-20N RFU-E IP-20F RFU-E 1+0
IP-20N RFU-E IP-20E 1+0 (up to 250 MHz)
IP-20N RFU-D-HP IP-20F RFU-D-HP 1+0, 2+0 MC-ABC
Links using RMC-A (all supported RFUs) are interoperable with IP-10G and IP-10E
IDUs. This enables operators to introduce IP-20N into existing FibeAir networks
gradually as a high-density ultra-modular solution for appropriate nodes. For
example, IP-20N can be used at nodal sites, working with IP-10G and/or IP-10E
units at cost optimized 1+0 tail or chain sites.
3
Planned for future release.
Page 32 of 468

2.1.4 Supported IP-20N Radio Configurations

There are two sets of configurations:
• Configurations implemented with RFU-C or 1500HP/RFU-HP connected to the
IDU via RMC-A or RMC-B
• Configurations implemented with RFU-D, RFU-D-HP, RFU-E, or RFU-S
connected to the IDU via RIC-D.
Note: RMCs and RIC-Ds can be used in the same chassis, subject to
certain slot restrictions. For details, see Slot Sections and 2.5
Gbps Mode on page 53.
2.1.5 Configurations Implemented using RFU-C or 1500HP/RFU-HP with

RMC-A or RMC-B
For configurations using RFU-C or 1500HP/RFU-HP with RMC-A or RMC-B, the
following requirements should be taken into account:
• Multi-Carrier ABC configurations require TCC-B-MC or TCC-B2-XG-MC, and
RMC-B.
• With TCC-B-MC, one Multi-Carrier ABC group can be configured per unit with
up to 8 carriers aggregated in the group and a total radio capacity of 1 Gbps.
• With TCC-B2-XG-MC, the following is supported:
 A single Multi-Carrier ABC group of up to 8+0 with capacity of up to 2.5
Gbps.
 Up to four Multi-Carrier ABC groups, with capacity of up to 1 Gbps per
group.
• Multi-Carrier ABC configurations can be combined with non-Multi-Carrier ABC
configurations in the same unit. For example, a single IP-20N unit can support
a 4+0 Multi-Carrier ABC group and, in addition, an N+0 or a 1+1 HSB
protection group that is not part of the Multi-Carrier ABC group.
The following radio configurations are available for RFU-C and 1500HP/RFU-HP:
Table 3: Radio Configuration Options for RFU-C and 1500HP/RFU-HP
Configuration Notes
1+0
1+0 IF Combining Requires RMC-B and 1500HP
2+0 Single Polarization Requires Multi-Carrier ABC or LAG.
2+0 Dual Polarization (XPIC) Requires Multi-Carrier ABC or LAG.
3+0 Requires Multi-Carrier ABC or LAG.
4+0 IF Combining Requires Multi-Carrier ABC and 1500HP.
4+0 IF Combining and XPIC Requires Multi-Carrier ABC and 1500HP.
Page 33 of 468

Configuration Notes

1+1 HSB Protection
1+1 HSB Protection with BBS Space Diversity Requires Multi-Carrier ABC
2+2 HSB Protection Requires Multi-Carrier ABC
2+2 HSB Protection with BBS Space Diversity Requires Multi-Carrier ABC
2+2 HSB Protection with XPIC Requires Multi-Carrier ABC
2+2 HSB Protection with BBS Space Diversity and XPIC Requires Multi-Carrier ABC
2+2 HSB Protection with IF Combining and XPIC Requires Multi-Carrier ABC and 1500HP
2 X 2+0 Multi-Carrier ABC Requires TCC-B2-XG-MC, RMC-B, and Multi-Carrier ABC
4 X 2+0 Multi Carrier ABC Requires TCC-B2-XG-MC, RMC-B, and Multi-Carrier ABC
2 X 1+1 HSB-SD Requires TCC-B2-XG-MC, RMC-B, and Multi-Carrier ABC
2 X 4+0 Multi-Carrier ABC Requires TCC-B2-XG-MC, RMC-B, and Multi-Carrier ABC
Page 34 of 468

2.1.6 Configurations Implemented using RFU-D, RFU-D-HP, RFU-E, or RFU-S

with RIC-D
For RIC-D, Multi-Carrier ABC groups can be implemented in either of two ways:
• TCC-based Multi-Carrier ABC – Multi-Carrier ABC is implemented via the TCC,
and requires TCC-B-MC or TCC-B2-XG-MC. Multiple groups in a single unit and
high-capacity groups require TCC-B2-XG-MC. This is the same type of Multi-
Carrier ABC used with RMCs, and is available for RIC-Ds from CeraOS 10.5.
These configurations must be implemented by using up to four RIC-D cards,
each connected to a MultiCore RFU (RFU-D or RFU-D-HP). For example, an 8+0
Multi-Carrier ABC group must use four RIC-D cards, each connected to an
RFU-D or RFU-D-HP.
• RFU-based Multi-Carrier ABC – Multi-Carrier ABC is implemented in the RFU
(RFU-D or RFU-D-HP). This type of Multi-Carrier ABC is available for 2+0 Multi-
Carrier ABC configurations that consist of the two radios in a MultiCore RFU-D
or RFU-D-HP. It is supported from CeraOS 10.0, and can be used with any TCC.
For details, see TCC and RFU-Based Multi-Carrier ABC on page 162.
The following split-mount configurations are available for RIC-Ds:

Table 4: Radio Configuration Options for RFU-D, RFU-D-HP, RFU-E, or RFU-S with RIC-D
Configuration Supported RFUs Notes
8 X 1+04 RFU-S
4 X 1+05 RFU-E
4 X 2+0 (XPIC optional)6 RFU-D, RFU-D-HP Requires TCC-based or RFU-based Multi-Carrier ABC
2 X 4+0 (XPIC optional) RFU-D, RFU-D-HP Requires TCC-based Multi-Carrier ABC
4+0 (XPIC optional) RFU-D, RFU-D-HP Requires TCC-based Multi-Carrier ABC
4 X 2+0 SD (XPIC optional)7 RFU-D, RFU-D-HP Requires TCC-based Multi-Carrier ABC
2 X 4+0 SD (XPIC optional) 9 RFU-D, RFU-D-HP Requires TCC-based Multi-Carrier ABC
1 X 8+09 RFU-D, RFU-D-HP Requires TCC-B2-XG-MC. XPIC optional.
2 X 2+2 HSB9 RFU-D, RFU-D-HP
2 X 2+2 HSB-SD9 RFU-D-HP
4
With 112 MHz channels, 6 x 1+0 configuration is supported in CeraOS 10.9.
5
6
7
Page 35 of 468

Configuration Supported RFUs Notes
2+0 BBC Space Diversity RFU-D, RFU-D-HP Requires TCC-B2-XG-MC and TCC-based Multi-Carrier ABC
4+0 BBC Space Diversity RFU-D, RFU-D-HP Requires TCC-B2-XG-MC and TCC-based Multi-Carrier ABC
2 X 2+0 BBC Space Diversity RFU-D, RFU-D-HP Requires TCC-B2-XG-MC and TCC-based Multi-Carrier ABC
2 X 4+0 BBC Space Diversity RFU-D, RFU-D-HP Requires TCC-B2-XG-MC and TCC-based Multi-Carrier ABC
Page 36 of 468

2.1.7 IP-20N’s No-Single-Point-of-Failure Architecture

IP-20N is built according to a no-single-point-of-failure architecture, with full
support for the hot-swapping of cards.
The 2RU IP-20N supports TCC Redundancy, with two TCCs for full redundancy of
the unit’s control functionality.
Radio redundancy is provided via the RMC and RIC cards, which can be configured
in 1+1 or 2+2 HSB/BBS pairs.
Interface protection is available for the 10G interface on LIC-X-10 Ethernet LICs,
using an optical Y-splitter cable to connect the two 10G interfaces and the
external switch.
Redundancy can also be provided by Multi-Carrier ABC, which can group up to
eight carriers into a single group. In the event that a carrier goes out of service,
the remaining carriers continue to operate with graceful degradation of service to
ensure that not all data is lost, but rather, a reduction of bandwidth occurs.
Redundancy for both Ethernet and radio interfaces is available also by using link
aggregation groups (LAG). LAGs can provide redundancy for Ethernet and radio
interfaces on separate cards as well as on the same card.
TDM redundancy is provided as follows:
• LIC-T16 (16x E1) – Redundancy is available using 1:1 or 1+1 Path Protection, or
1+1 HSB Card Protection.
• LIC-T155 (1x ch-STM-1) – Redundancy is available using 1:1 or 1+1 Path
Protection, 1+1 HSB Card Protection, and Uni-Directional MSP Card
Protection.
• LIC-STM1/OC3-RST – Redundancy is available using 1+1 HSB Card Protection.
IP-20N provides fully distributed power supply architecture, with an option for
dual-feed power. In a 1RU chassis, dual-feed power can be provided by an
optional dual-feed Power Distribution Card (PDC). In a 2RU chassis, dual-feed
power can be provided by using two independent PDC cards.
IP-20N includes a set of redundant fans that can continue sustained operation in
the event of a single fan failure.
Page 37 of 468

2.2 Solution Overview

FibeAir IP-20N is part of the FibeAir IP-20 family of integrated wireless backhaul
devices. The IP-20 family constitutes a single platform serving all radio transport
technologies. The IP-20 platform consists of a variety of product types built
around a powerful software-defined engine and operated by a common operating
system (CeraOS).
The IP-20 platform provides:
• Ultra-high capacities
• Support for any radio transmission technology in any topology and any
installation configuration.
• High service granularity and rich- service-centric features.
IP-20N is interoperable over the radio link with IP-10G and IP-10E IDUs.
Page 38 of 468

2.3 FibeAir IP-20 Assured Platform

Ceragon’s FibeAir® IP-20 Assured platform enhances network reliability and
security, ensuring that mission-critical networks maintain availability, and
protecting the confidentiality and integrity of their users’ data.
The FibeAir IP-20 Assured platform is compliant with FIPS 140-2, including:
• Compliance with FIPS 140-2 specifications for cryptography module.
• FIPS 140-2 Level 2 physical security.
• AES-256 encryption (FIPS 197) over radio links.
The FibeAir IP-20 Assured platform also provides:
• Secured communication and protocols for management interface.
• Centralized user authentication management via RADIUS.
• Advanced identity management and password policy enforcement.
• Security events log.
• Secure product architecture and development.
The following products are included in the FibeAir IP-20 Assured platform:
• FibeAir IP-20N Assured
• FibeAir IP-20A Assured
• FibeAir IP-20LH Assured
• FibeAir IP-20G Assured
• FibeAir IP-20GX Assured
• FibeAir IP-20C Assured
• FibeAir IP-20S Assured
Notes: CeraOS 10.9 cannot be used in FibeAir IP-20 Assured platforms.
For FibeAir IP-20 Assured, use CeraOS 8.3.
RFU-D, RFU-D-HP, RFU-E, and RFU-S cannot be used with FibeAir

IP-20N Assured.
Page 39 of 468

2.4 New Features in CeraOS 10.7.5 and CeraOS 10.9

The following table lists the features that have been added in CeraOS versions
10.7.5 and 10.9, and indicates where further information can be found on the new
features in this manual and where configuration instructions can be found in the
User Guide.
Table 5: New Features in CeraOS 10.7.5 and CeraOS 10.9
Feature Further Information Configuration Instructions in the User’s Added in

Guide Release
QoS Classification Per MAC QoS on the Ingress Path on Section 7.2.7, Modifying the MAC 10.9
Destination Address page 241 DA Classification Table
Ethernet Service Points – Ingress
Attributes, in Section 6.1.9.2, The
Ethernet Service Points Page
New Scripts for BBC Space Diversity MRMC Scripts Supported with Section 3.9, Configuring BBC Space 10.9
with RFU-D and RFU-D-HP RIC-D and RFU-D, RFU-D-HP, Diversity
and RFU-S on page 346
All-Indoor Configurations with RFU-D- All-Indoor Terminals on n/a 10.9
HP page 103 and RFU-D-HP
Marketing Models – All-Indoor
Terminals on page 110
40 MHz channel support with BBC Space Diversity on page 168 Section 3.9, Configuring BBC Space 10.7.5
Space Diversity (RFU-D and RFU-D-HP) Diversity
Page 40 of 468

3. IDU Hardware Description

This chapter describes the IP-20N IDU and its components.
Two types of chassis are available for the IP-20N IDU:
• 1RU – Fits in a single rack unit, with support for a mixture of up to five radio
carriers and line cards.
• 2RU – Fits in a double rack unit, with support for a mixture of up ten radio
carriers and line cards.
Figure 1: IP-20N 1RU Chassis Figure 2: IP-20N 2RU Chassis
The IP-20N IDU is built upon a unified architecture with common cards, including:
• Traffic Control Card (TCC)
• Line Cards (LIC), including:
 Ethernet – LIC-X-E4-Elec (4x GbE), with 1 GbE combo interface 1 GbE electrical (RJ-
45) interface, and 2 dual mode electrical or cascading interfaces
 Ethernet – LIC-X-E4-Opt (4x GbE), with 1 GbE combo interface, 1 GbE optical (SFP)
interface, and 2 dual mode optical or cascading interfaces
 Ethernet – LIC-X-E10 (1x10G), with a single 10G optical interface
 TDM – LIC-T16 (16x E1)
 TDM – LIC-T155 (1x ch-STM-1)
 TDM – LIC-STM1/OC3-RST (1 x STM-1)
Page 41 of 468


• Hardware Architecture
• Front Panel Description
• Chassis Slots and Card Population Guidelines
• Traffic Control Cards (TCC)
• Ethernet Line Cards (LIC-X)
• TDM Line Cards (LIC-T)
• Power Distribution Cards (PDC)
• Inventory Module (IVM)
• Fans Module
• Filter Tray (Optional)
Page 42 of 468

3.1 Hardware Architecture

IP-20N is a modular unit based on a 1RU or 2RU chassis into which a variety of
cards can be inserted for traffic, radio interface, management, and power supply.
The IP-20N backplane provides connectivity among the slots in the chassis for
management, power distribution, and traffic aggregation.
An IP-20N chassis and the cards it contains are managed by a Traffic Control Card
(TCC). A 2RU IP-20N can contain two TCCs for TCC Redundancy. TCCs also include
GbE Ethernet traffic and FE management interfaces.
Note: The optical GbE traffic interfaces on the TCC can be used with
TCC Redundancy in software versions 8.2 and higher.
Two types of radio cards are available to provide the interface between the IP-
20N and the RFU:
• Radio Modem Card (RMC) – Provides the modem interface with the RFU-C and
RFU-HP/1500HP.
• Radio Interface Card (RIC) – Interfaces with the RFU-D, RFU-D-HP, RFU-E, and
RFU-S.
A 1RU IP-20N can contain up to five RMCs and/or RICs. A 2RU IP-20N can contain
up to ten RMCs or up to eight RICs.
Line Interface Cards (LICs) can be added to provide additional traffic interfaces.
Ethernet and TDM LICs can be used. A 2RU chassis can contain up to ten LICs, up
to two of which can be Ethernet LICs. A 1RU chassis can contain up to five LICs,
one of which can be an Ethernet LIC.
Note: In a 2RU chassis with two Ethernet LICs, the GbE interfaces on
the TCC cannot be used.
IP-20N receives an external supply of -48v via a Power Distribution Card (PDC). For
power redundancy, a 1RU chassis can contain a dual-feed PDC that can be
connected to separate power sources. A 2RU chassis can contain two PDCs
connected to separate power sources. The PDC or PDCs distribute the power via
the backplane to all the modules in the chassis.
IP-20N implements internal chassis management via a dedicated channel between
the TCCs and each slot in the chassis, including the PDCs and the FAN slots.
Page 43 of 468

The following figure shows the IP-20N internal chassis management

interconnections.
2RU Chassis – Up to 10 RMCs/LICs or 8 RICs
1RU Chassis – Up to 5 RMCs/RICs/LICs
(Any Combination)
RMC-D / RMC-S / LIC

TCC 1 RMC-D/RMC-S
RMC-D/RMC-S
TCC 2 (in 2RU
High Availability
Backplane RMC, RIC, or LIC
node)
FAN Tray
PDC (2 x PDC
option in 2RU
chassis).
Control lines for PDC and FAN Tray.

Black – TCC 1
Green – TCC 2
Figure 3: Chassis Management
IP-20N implements traffic connectivity via a star topology in which the TCC serves
as the main switch, aggregating traffic from all the LICs in the chassis. In a 2RU
Page 44 of 468

chassis with TCC redundancy, a dual star topology is utilized to provide full
redundancy.
TCC Slot 11 Slot 12
Slot 7 Slot 8 Slot 9 Slot 10
Slot 3 Slot 4 Slot 5 Slot 6
Path to active TCC

TCC Slot 1 Slot 2
Path to standby TCC
Figure 4: Traffic Connectivity in 2RU Chassis with TCC Redundancy
Page 45 of 468

The following figures provide detailed block diagrams of the IP-20N 1RU and 2RU
chassis, respectively.
System Backplane
TDM Sync Ethernet MC-ABC
RMC Power Supply
48V PDC IF
Framer Modem IF Interface RFU
to RFU
TCC XPIC
Power Supply
RMC Power Supply
Sync Unit
IF
1588 1588 BC/TC to RFU
FE Management
Interfaces (1 or 2)
CPU
Terminal
Ethernet RIC Power Supply
GE Traffic Ethernet Services

Interfaces Network RFU
Interface RFU
(2 to 6) Processor
Services XPIC
Engine
TDM Cross
Native TDM
Services
RIC Power Supply
Connect
RFU
Interface RFU
Multi-Carrier
ABC Engine
Power Supply
STM-1 RST
STM-1 RST
Line Card
Service
STM-1 Interface
E1 Line Card
TDM Pseudowire
Services TDM
16 x E1
Services Framer LIU
Interface
Processor
Power Supply
TDM Pseudowire
ch-STM-1 Line Card
Services
TDM
STM-1
Services Framer LIU
Interface
Processor
Power Supply
Ethernet Line Card

Ethernet Line Interface
Power Supply
Figure 5: IP-20N IDU Block Diagram – 1RU Chassis
Page 46 of 468

System Backplane
TDM Sync Ethernet MC-ABC
RMC Power Supply
48V PDC 1 IF
to RFU
TCC 1 XPIC
Power Supply
RMC Power Supply
Sync Unit
IF
1588 1588 BC/TC Framer Modem IF Interface
to RFU
RFU
FE Management
Interfaces (1 or 2)
CPU
Terminal
Ethernet RIC Power Supply
GE Traffic Ethernet Services

Interfaces Network RFU
Interface RFU
(2 to 6) Processor
Services XPIC
Engine
TDM Cross
Native TDM
Services RIC Power Supply
Connect
RFU
Interface RFU
Multi-Carrier
ABC Engine
Power Supply
TCC 2 STM-1 RST

(Optional) STM-1 RST
Line Card
Service
Power Supply STM-1 Interface
Sync Unit
1588 1588 BC/TC E1 Line Card
TDM Pseudowire
Services TDM
FE Management 16 x E1
Interfaces (1 or 2) Services Framer LIU
CPU Processor
Interface
Terminal
Ethernet
Ethernet Services Power Supply
GE Traffic
Interfaces Network
(2 to 6) Processor
TDM Pseudowire
ch-STM-1 Line Card
Services
Services TDM
Services Framer LIU
STM-1
Interface
Engine Processor
Native TDM
TDM Cross Services
Connect Power Supply
Multi-Carrier Ethernet Line Card

ABC Engine
48V
PDC 2
(Optional) Ethernet Line Interface
Power Supply
Figure 6: IP-20N IDU Block Diagram – 2RU Chassis with TCC and PDC Redundancy
Page 47 of 468

3.2 Front Panel Description

This section describes the IP-20N’s front panel. The following sections provide
detailed descriptions of the IP-20N cards and interfaces.
IP-20N provides two basic chassis options:
• 1RU – Fits in a single 19” rack slot, with one Main Traffic and Control Card
(TCC), five universal slots for a combination of up to five Radio Modem Cards
(RMCs) and/or Radio Interface Cards (RICs) and/or Line Cards for traffic (LICs).
Additional slots are provided for a Power Distribution Card (PDC) and a fans
tray.
• 2RU – Fits in two 19” rack slots, with two Main Traffic and Control Cards
(TCCs), ten universal slots for a combination of up to ten Radio Modem Cards
(RMCs) and/or Radio Interface Cards (RICs) and/or Line Cards for traffic (LICs).
Additional slots are provided for two Power Distribution Cards (PDCs) and a
fans tray.
Note: Ethernet LICs can only be placed in Slot 2 of a 1RU chassis and
Slots 2 and 12 of a 2RU chassis.
Figure 7: IP-20N Front Panel and Interfaces – 1RU Chassis
Page 48 of 468

Figure 8: IP-20N Front Panel and Interfaces – 2RU Chassis
Page 49 of 468

3.3 Chassis Slots and Card Population Guidelines

The figures below show the 1RU and 2RU chassis slot numbers.
Figure 9: 1RU Chassis Slot Numbering
Figure 10: 2RU Chassis Slot Numbering
The following tables list the card types that can be placed in each slot:
Table 6: Card Types Allowed Per Slot – 1RU
Slot Number Allowed Card Type Notes
1 • TCC
2 • RMC-A, RMC-B, RIC-D Does not include LIC-STM1/OC3-RST (1 x
• Ethernet LIC STM1/OC-3)
• TDM LIC
3-6 • RMC-A, RMC-B, RIC-D When a single Multi-Carrier ABC group is
• TDM LIC used, consisting of RMCs, Slot 3 can be
unoccupied or must be populated with an
RMC, which must be part of the Multi-
Carrier ABC group (Bug ID 127456).
Page 50 of 468

Table 7: Card Types Allowed Per Slot – 2RU
Slot Number Allowed Card Type Notes
1 • TCC
2,12 • RMC-A, RMC-B, RIC-D Does not include LIC-STM1/OC3-RST (1 x
• Ethernet LIC STM1/OC-3)
• TDM LIC
3 - 10 • RMC-A, RMC-B, RIC-D When a single Multi-Carrier ABC group is
• TDM LIC used, consisting of RMCs, Slot 3 can be
unoccupied or must be populated with an
RMC, which must be part of the Multi-
Carrier ABC group.
11 • TCC Only valid when TCC redundancy is enabled.
3.3.1 TCC GbE Interface Limitations

When an Ethernet LIC is installed in Slot 12, the two GbE interfaces on the TCC-B
or TCC-B-MC are disabled, leaving a total of 8 GbE interfaces per chassis.
When using a TCC-B2 or TCC-B2-XG-MC, you should avoid placing any type of
traffic cards (Ethernet LIC, TDM LIC, RMC, and RIC) in certain slots. If you place a
traffic card in one of these slots, some interfaces on the TCC-B2 or TCC-B2-XG-MC
cannot be used, as described in the following table.
Table 8: Slot Limitations When Used with TCC-B2 or TCC-B2-XG-MC
Traffic Card in Slot: TCC-B2/TCC-B2-XG-MC Interfaces Not Available for Use:
9 GbE5
10 GbE6
12 • Ethernet LIC in Slot 12: SFP1, SFP2, GbE3/CS3, GbE4/CS4
• TDM LIC, RMC, or RIC in Slot 12: GbE3/CS3 only
Page 51 of 468

3.3.2 Adjacent Pair Guidelines

RMCs that are planned to be used in XPIC configurations must be placed in
adjacent pairs, as follows:
• Slots 3 and 4
• Slots 5 and 6
• Slots 7 and 8 (2RU only)
• Slots 9 and 10 (2RU only)
If you configuring 2+2 HSB with XPIC, you must configure the radio protection
group in non-adjacent channels, e.g., Slots 3 and 5 or Slots 4 and 6. That is
because the XPIC groups must be configured in adjacent slots. For example:
• XPIC Group #1: Slots 3 and 4
• XPIC Group #2: Slots 5 and 6
• Protection Group #1: Slots 3 and 5
• Protection Group #2: Slots 4 and 6
Note: XPIC with RIC-D is supported between the two carriers of a
MultiCore RFU-D or RFU-D-HP, but not between different RIC-Ds.
Page 52 of 468

3.3.3 Slot Sections and 2.5 Gbps Mode

The slots in the chassis are divided into sections, as described below. Each section
can be configured to 1 Gbps mode (default) or 2.5 Gbps mode, and a card cannot
exceed the capacity of the section it is in.
Table 9: Card Type Usage Per Section Capacity
Card Type 2.5 Gbps Mode 1 Gbps Mode
RIC-D No restrictions No restrictions

RMC-B Must be part of a Multi- Multi-Carrier ABC and 1+0
Carrier ABC group
RMC-A Cannot be used 1+0
LIC-X-E10 Cannot be used Slot section (B, E, or F) is automatically
configured to 10 Gbps mode when the
Expected Card Type is set to LIC-X-E10.
LIC-X-E4-Elec Cannot be used Slot sections B, E, and F– no restrictions
LIC-X-E4-Opt Cannot be used Slot sections B, E, and F– no restrictions
LIC-T16 Cannot be used No restrictions
LIC-T155 Cannot be used No restrictions
LIC-STM1/OC3-RST Must be part of a Multi- Must be part of a Multi-Carrier ABC
Carrier ABC group group
Figure 11: 1RU Chassis – Slot Sections
Page 53 of 468

Figure 12: 2RU Chassis – Slot Sections
In 1 Gbps mode, you can mix all types of traffic and radio cards in the same
section, subject to the card population guidelines described in the rest of this
chapter.
It is important to note that only the following cards can operate in a section
configured to 2.5 Gbps mode:
• RIC-D
• RMC-B, as part of a Multi-Carrier ABC group
• LIC-STM1/OC3-RST, as part of a Multi-Carrier ABC group
• RMC-E, as part of a Multi-Carrier ABC group
For 500 MHz channels, the RIC-D connected to the RFU-E must be placed in a slot
section configured to 2.5 Gbps mode.
If you plan to use 2.5 Gbps TCC-Based Multi-Carrier ABC groups, you must
configure Slot Section A (1RU chassis) or C (2RU chassis) to 2.5 Gbps mode. In this
configuration, the 2.5 Gbps groups must be Group 1 and Group 3.
Note: Only RIC-D cards and LIC-STM1/OC3-RST cards are supported in
multiple 2.5 Gbps groups.
Page 54 of 468

3.3.4 Additional Slot Guidelines

When using Multi-Carrier ABC, the ABC mechanism requires one slot on the
chassis as a dedicated Multi-Carrier ABC slot. That means the slot either be
populated with a card that belongs to the ABC group or the slot must be empty.
The identity of this dedicated slot depends on the ID number of the ABC group, as
described in Table 10. For example, if two Multi-Carrier ABC groups are configured
on a 2RU chassis and given Group ID 1 and Group ID 2, Slot 3 and Slot 4 should
both be populated by cards assigned to an ABC group.
Note: The cards do not have to be assigned specifically to the group
that corresponds to the slot. For example, the card in slot 3 could
be assigned to ABC Group 2.
Table 10: Additional Slot Limitations with Multi-Carrier ABC
Group Number 2RU Chassis 1RU Chassis
1 3 3
2 4 4
3 7 5
4 8 6
Page 55 of 468

3.3.5 Sample Chassis Configurations

To illustrate the guidelines set forth in this chapter, this section provides several
sample slot chassis configuration options for 2RU chassis that include Multi-
Carrier ABC groups with RIC-D cards and other traffic cards. The purpose of these
examples is to guide system planners through some of the more complex chassis
configuration scenarios.
For additional sample chassis configurations, see BBC Space Diversity Slot
Placement and Use Cases on page 171.
3.3.5.1 Sample Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (1 Gbps)
11 – TCC-B2-XG-MC 12 -Traffic PDC2

(Optional)
7 – Traffic 8 - Traffic 9 - Traffic 10 -Traffic
Filter
Fans
3 -RIC-D 4 -RIC-D 5 -RIC-D 6 -RIC-D
1 – TCC-B2-XG-MC 2 - Traffic PDC1
Figure 13: Sample Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (1 Gbps)
This configuration uses four RIC-D cards with four RFU-D or RFU-D-HP RFUs to
provide 2 x 4+0 Multi-Carrier ABC groups, each with a capacity of 1 Gbps.
In this configuration:
• Slot Section C must be set to 1 Gbps mode.
• The RIC-D cards are placed in Slots 3, 4, 5, and 6.
• ABC Group 1 includes all four radio carriers connected to Slots 3 and 4.
Note: It is highly recommended to use the Group IDs 1 and 2 to
preserve the use of Slots 7 and 8 for other traffic cards.
• The remaining slots can be populated with Ethernet and/or TDM traffic cards.
No additional radio cards can be used.
Page 56 of 468

3.3.5.2 Sample Chassis Configuration – 4 x 2+0 Multi-Carrier ABC (1 Gbps)

(Optional)
7 – Empty 8 - Empty 9 - Traffic 10 -Traffic
Filter
Fans
Figure 14: Sample Chassis Configuration – 4 x 2+0 Multi-Carrier ABC (1 Gbps)
provide 4 x 2+0 Multi-Carrier ABC groups, each with a capacity of 1 Gbps.
• Slot Section C must be set to 1 Gbps mode.
• ABC Group 1 includes the two carriers connected to Slot 3.
• Slots 2, 9, 10, and 12 can be populated with Ethernet and/or TDM traffic
cards. No additional radio cards can be used.
• Slots 7 and 8 cannot be populated.
Page 57 of 468

3.3.5.3 Sample Chassis Configuration – 2 x 2+0 Multi-Carrier ABC with RST (1 Gbps/2
Gbps)

(Optional)
7 – RST 8 - RST 9 - Traffic 10 -Traffic
Filter
Fans
3 -RIC-D 4 -RIC-D 5 -Traffic 6 -Traffic
Figure 15: Sample Chassis Configuration – 2 x 2+0 Multi-Carrier ABC with RST (1 or 2.5
Gbps)
This configuration uses two RIC-D cards with two RFU-D or RFU-D-HP RFUs, along
with two LIC-STM1/OC3-RST cards, to provide two Multi-Carrier ABC groups with
two radio carriers and one RST card in each group. Each group has a capacity of
1 Gbps or 2 Gbps.
• Slot Section C can be set to 1 Gbps or 2 Gbps mode.
• The RIC-D cards are placed in Slots 3 and 4.
• The LIC-STM1/OC3-RST cards are placed in slots 7 and 8.
• ABC Group 1 includes the two carriers connected to Slot 3 and the LIC-
STM1/OC-3-RST card in Slot 7.
• ABC Group 3 includes the two carriers connected to Slot 4 and the LIC-
STM1/OC-3-RST card in Slot 8.
Note: You must use Groups IDs 1 and 3 for the RIC-D/RST groups.
• The remaining slots can be populated with Ethernet, TDM, and/or radio cards.
Up to 4 additional radio carriers can be used, besides the carriers connected
to Slots 3 and 4.
Page 58 of 468

3.3.5.4 Sample Chassis Configuration – 1 x 8+0 Multi-Carrier ABC (2.5 Gbps)

(Optional)
7 – Empty 8 – Empty 9 - Traffic 10 -Traffic
Filter
Fans
Figure 16: Sample Chassis Configuration – 1 x 8+0 Multi-Carrier ABC (2.5 Gbps)
provide a single 8+0 Multi-Carrier ABC group with 2.5 Gbps capacity.
• Slot Section C must be set to 2.5 Gbps mode.
• ABC Group 1 includes all 8 carriers connected to Slots 3, 4, 5, and 6.
Page 59 of 468

3.3.5.5 Sample Chassis Configuration – 1 x 6+0 Multi-Carrier ABC with RST (2.5 Gbps)

(Optional)
7 – RST 8 - RST 9 - Traffic 10 -Traffic
Filter
Fans
3 -RIC-D 4 -RIC-D 5 -RIC-D 6 -Traffic
Figure 17: Sample Chassis Configuration – 1 x 6+0 Multi-Carrier ABC with RST (2.5 Gbps)
This configuration uses three RIC-D cards with three RFU-D or RFU-D-HP RFUs,
along with two LIC-STM1/OC3-RST cards, to provide a 6+0 Multi-Carrier ABC
groups with six radio carriers and two RST cards, with 2.5 Gbps capacity.
• The RIC-D cards are placed in Slots 3, 4, and 5.
• The LIC-STM1/OC3-RST cards used in the Multi-Carrier ABC group are placed
in Slots 7 and 8.
• ABC Group 1 includes all 6 carriers connected to Slots 3, 4, and 5, and the RST
cards in Slots 7 and 8.
• The remaining slots can be populated with Ethernet, TDM, and or radio cards.
Up to 2 additional radio carriers can be used, besides the carriers connected
to Slots 3, 4, and 5.
Page 60 of 468

3.3.5.6 Sample Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (2.5 Gbps)

(Optional)
7 – Empty 8 - Empty 9 - Traffic 10 -Traffic
Filter
Fans
Figure 18: Sample Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (2.5 Gbps)
provide 2 x 4+0 Multi-Carrier ABC groups, each with a capacity of 2.5 Gbps.
Note: You must use Group IDs 1 and 3.
Page 61 of 468

3.4 Traffic Control Cards (TCC)

The Traffic Control Card (TCC) provides the control functionality for the IP-20N
unit. It also provides Ethernet management and traffic interfaces.
Figure 19: TCC
FibeAir IP-20N offers the following types of TCC:

• TCC-B – Standard TCC option. Provides 2 x FE Ethernet management interfaces
and 2 x GbE combo interfaces (electrical or optical) for Ethernet traffic.
• TCC-B-MC – Supports single Multi-Carrier ABC groups with capacity of up to 1
Gbps. Provides 2 x FE Ethernet management interfaces and 2 x GbE combo
interfaces (electrical or optical) for Ethernet traffic.
• TCC-B2 – Provides 2 x FE Ethernet management interfaces, 2 x GbE optical
interfaces, 2 x GbE electrical interfaces, and 2 x dual mode electrical or
cascading interfaces.
• TCC-B2-XG-MC – Supports up to two Multi-Carrier ABC groups with capacity of
2.5 Gbps8 or up to four Multi-Carrier ABC groups with capacity of 1 Gbps per
group. Provides 2 x FE Ethernet management interfaces, 2 x GbE optical
interfaces, 2 x GbE electrical interfaces, and 2 x dual mode electrical or
cascading interfaces.
8
Only RIC-D cards and LIC-STM1/OC3-RST cards are supported in multiple 2.5 Gbps groups.
Page 62 of 468

The TCC is responsible for the following IP-20N functionality:

• Provides the main CPU for the IP-20N chassis
• Responsible for chassis management
• Responsible for switch aggregation
• Responsible for synchronization in the IP-20N chassis
Figure 20: TCC-B and TCC-B-MC Interfaces
TCC-B and TCC-B-MC contain two GbE Ethernet interfaces and two FE interfaces
for management.
For the GbE interfaces, you can choose between two optical (SFP) and two
electrical (RJ-45) physical interfaces. The electrical interfaces are labeled GbE1 and
GbE2. The optical interfaces are labeled SFP1 and SFP2. The optical interfaces are
located to the right of the electrical interfaces.
The FE management interfaces are labeled MGMT1 and MGMT2. These interfaces
are 100BaseT with auto negotiation and auto crossover.
Figure 21: TCC-B2/TCC-B2-XG-MC Interfaces
TCC-B2 and TCC-B2-XG-MC contain two optical GbE interfaces: SFP1 and SFP2.
TCC-B2 and TCC-B2-XG-MC contain two electrical GbE interfaces: GbE5 and GbE6.
GbE3/CS3 and GbE4/CS4 can be configured as normal GbE traffic interfaces or as
cascading interfaces. When operating in cascading mode, these interfaces can handle
hybrid Ethernet and Native TDM traffic, enabling operators to create links among
multiple IP-20 units in a node for multi-directional applications based on hybrid
Ethernet and Native or pseudowire TDM services.
Page 63 of 468

Note: TCC-B2 cannot be used with software versions prior to 8.0 and
TCC-B2-XG-MC cannot be used with software versions prior to
8.2.
TCC-B2 and TCC-B2-XG-MC contain two FE management interfaces, which connect
to a single RJ-45 physical connector on the front panel (MGMT).
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
Figure 22: TCC-B2/TCC-B2-XG-MC Management Interface Pin Connections
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.
Table 11: 2 x FE Splitter Cable Marketing Model
Marketing Model Marketing Description Part Number
SPL-ETH-CBL Ethernet split cable rohs WA-0245-0
All TCC models also contain the following interfaces:

• One RJ-45 terminal interface (RS-232)
• One DB-9 interface for external alarms, supporting five pairs of signals
• One RJ-45 synchronization interface for clock input and clock output
All TCC models contain the following LED:
• ACT – Indicates whether the card is working properly (Green) or if there is an
error or a problem with the card’s functionality (Red).
All TCC models can be used in both 1RU and 2RU IP-20N chassis.
Page 64 of 468

The following table summarizes the functionality supported by the various TCC
models.
Table 12: TCC Comparison Table
TCC Type Ethernet Traffic Interfaces Multi-Carrier ABC Support
TCC-B 2 x Gb combo (optical or electrical) Only with RIC-D and RFU-D or RFU-D-
interfaces HP
TCC-B-MC 2 x Gb combo (optical or electrical) • 1 x up to 8+0 Multi-Carrier ABC9
interfaces • 1 Gbps
TCC-B2 2 x Gb electrical interfaces Only with RIC-D and RFU-D or RFU-D-
2 x Gb optical interfaces HP
2 x dual mode electrical or cascading
interfaces
TCC-B2-XG-MC 2 x Gb electrical interfaces • 1 x up to 8+0 Multi-Carrier ABC9
2 x Gb optical interfaces 4 X 2+0 Multi-Carrier ABC
2 x dual mode electrical or cascading • 4 X 1+1 HSB Protection with BBS
interfaces Space Diversity
• 2 X 4+0 Multi-Carrier ABC
• 1 or 2.5 Gbps (user-configurable)10
• 2 X 2+2 HSB-SD
3.4.1 TCC Redundancy

The 2RU IP-20N can have two TCCs for TCC redundancy. TCC protection must be
enabled in order for TCC redundancy to operate. All TCC models support TCC
redundancy, but the two TCCs must be the same model.
In a redundant TCC configuration, the TCCs share chassis configuration and status
information via the chassis’ internal management channels.
Activation key information, MAC addresses, and serial numbers, are stored in the
Inventory Module (IVM). In a redundant TCC configuration, both TCC cards can
access the IVM.
TCC switchover takes place automatically upon failure of the active TCC. TCC
switchover can also be performed manually by the user.
9
With RMC-B and RIC-D, a Multi-Carrier ABC group can include up to eight radio and STM1/OC3-RST
members in total. With RMC-E, a Multi-Carrier ABC group can include up to eight radio members and
up to eight STM1/OC3-RST members, for a combined total of 16 members.
10
2.5 Gbps mode can be used with up to two Multi-Carrier ABC groups. Only RIC-D cards and LIC-
STM1/OC3-RST cards are supported in multiple 2.5 Gbps groups.
Page 65 of 468

Hot Switchover (HSO) is also available for all TCC models. HSO takes place with no
unit reset and a minimal traffic disruption.
There are three modes for Ethernet interface protection with TCC redundancy:
• Ethernet Line Protection Mode – Traffic is routed to the Ethernet interfaces on
the TCC via two interfaces on an external switch. Ethernet Line Protection
requires that the external switch support LACP. Ethernet Line Protection
Mode can be used with optical and electrical Ethernet interfaces.
• Optical Splitter Mode – An optical splitter cable is used to connect both the
active and the standby Ethernet ports. Optical Splitter Mode can be used with
optical Ethernet interfaces only.
• Electrical Splitter Mode - A Y-cable is used to connect to both the active and
the standby Ethernet ports. With Electrical Splitter Mode, interface protection
is only supported for speeds up to 100 Mbps (Fast Ethernet). Electrical Splitter
Mode can be used with electrical Ethernet interfaces only.
All of these methods are supported with all TCC models.
For Electrical Splitter Mode, the following Y-cable must be connected to the
relevant interfaces on the active and standby TCCs:
Table 13: Y-Cable for Electrical Splitter Mode FE Traffic Interface Protection
Part Number Marketing Model Description
WA-0244-0 15P-PROT-CBL CABLE,RJ45F TO 2XRJ45, 1.34M,CAT-5E,
T3 synchronization input via the TCC Sync interface is supported with TCC
Redundancy. A Y cable is used to connect to the relevant interfaces on the active
and standby TCCs.
T4 synchronization output is not supported with TCC Redundancy.
The following events trigger TCC switchover:
• Manual or Forced Switch
• Removal of the active TCC from the chassis
• Loss of Carrier (LOC) in any of the optical Ethernet interfaces on the TCC
LOC takes place if the Admin status of the interface is Enabled and the
Operational status is Down. If the interface is closed as a result of ASP, the
interface is not considered to be in LOC state, and TCC switchover is not triggered.
Following TCC switchover triggered by LOC, there is an automatic timeout of one
minute before any further TCC switchover can take place due to LOC.
Page 66 of 468

3.5 Radio Interface Cards (RIC)

The Radio Interface Card (RIC) provides interfaces between the IDU and any of the
following RFUs:
• RFU-D
• RFU-D-HP
• RFU-E
• RFU-S
The 1RU model of IP-20N can accommodate up to five RICs. The 2RU model of IP-
20N can accommodate eight RICs.
IP-20N offers the RIC-D. The RIC-D includes two combo interfaces to the RFU
(optical or electrical), each with a capacity of 2.5 Gbps.11
Note: To use a RIC-D in 2.5 Gbps mode, you must place the RIC-D in a
section of the chassis configured for 2.5 Gbps mode. For details,
see Slot Sections and 2.5 Gbps Mode on page 53.
In CeraOS 10.9, the following RFU configurations are supported per RIC-D:
• 1 x RFU-D
• 1 x RFU-D-HP
• 1x RFU-E
• 1 x RFU-S
Figure 23: RIC-D
11
In CeraOS 10.3, only one RFU interface (RFU1) can be used on the RIC-D.
Page 67 of 468

Figure 24: RIC-D Interfaces
RICs can be placed in any slot except the TCC slot (Slot 1 and, in a 2RU chassis,
Slot 11).
Page 68 of 468

3.6 Radio Modem Cards (RMC)

The Radio Modem Card (RMC) provides the modem interface between the IDU
and any of the following RFUs:
• RFU-C
• RFU-HP/1500HP
The 1RU model of IP-20N can accommodate up to five RMCs. The 2RU model of
IP-20N can accommodate up to ten RMCs.
IP-20N offers two types of RMC:
• RMC-A – RMC-A is based on the modem used in Ceragon’s FibeAir series IDUs,
including IP-10G and IP-10E. RMC-A supports up to 256 QAM (with ACM).
• RMC-B – RMC-B supports up to 2048 QAM (with ACM), as well as Header De-
Duplication and XPIC.
Figure 25: RMC-A Figure 26: RMC-B
Figure 27: RMC-A and RMC-B Interfaces
RMCs can be placed in any slot except the TCC slot (Slot 1 and, in a 2RU chassis,
Slot 11). RMCs use a TNC interface to connect to the RFU.
Page 69 of 468

3.7 Ethernet Line Cards (LIC-X)

IP-20N offers the following types of Ethernet Line Cards (Ethernet LICs):
• LIC-X-E4-Elec (4x GbE), with 1 GbE combo interface, 1 GbE electrical (RJ-45)
interface, and 2 dual mode electrical or cascading interfaces
• LIC-X-E4-Opt (4x GbE), with 1 GbE combo interface, 1 GbE optical (SFP)
interface, and 2 dual mode optical or cascading interfaces
• LIC-X-E10, with a single 10G optical interface
GbE3 and GbE 4 in LIC-X-E4-Elec, and SFP3 and SFP4 in LIC-X-E4-Opt, can be
configured as normal GbE traffic interfaces or as cascading interfaces. When
operating in cascading mode, these interfaces can handle hybrid Ethernet and
Native TDM traffic, enabling operators to create links among multiple IP-20 units
in a node for multi-directional applications based on hybrid Ethernet and Native
or pseudowire TDM services.
Notes: The 10G interface on the LIC-X-E10 cannot be used as a
cascading interface.
The LIC-X-E10 requires TCC-B2-XG-MC.
Figure 28: LIC-X-E4-Elec (4x GbE) Figure 29: LIC-X-E4-Opt (4x GbE)
Page 70 of 468

Figure 30: LIC-X-E10 (1x 10G)
In a 1RU chassis, an Ethernet LIC can only be placed in Slot 2.

In a 2RU chassis, Ethernet LICs can only be placed in Slots 2 and 12.
Figure 31: LIC-X-E4-Elec (4x GbE) Interfaces
Figure 32: LIC-X-E4-Opt (4x GbE) Interfaces
Page 71 of 468

Figure 33: LIC-X-E10 (1x 10G) Interface
3.7.1 10G Interface Protection

Interface protection is available for the 10G interface on LIC-X-10 Ethernet LICs.
An optical Y-splitter cable is used to connect the two 10G interfaces and the
external switch.
The following events trigger switchover from the active to the standby interface:
• Loss of Carrier (LOC) on the active interface.
• Operational state on the active interface is Down.
• The LIC with the active interface is removed from the chassis.
• The LIC with the active interface is disabled.
• Manual switch.
• Force switch.
• Lockout.
Page 72 of 468

3.8 TDM Line Cards (LIC-T)

IP-20N offers the following types of TDM Line Cards (TDM LICs):
• LIC-T16 (16 x E1)
• LIC-T155 (1 x ch-STM-1)
• LIC-STM1/OC3-RST (1 x STM-1)
Figure 34: LIC-T16 (16 x E1) Figure 35: LIC-T155 (1 x ch-STM-1)
Figure 36: LIC-STM1/OC3-RST (1 x STM-1)
LIC-T16 and LIC-T155 cards can be placed in any slot except the TCC and PDC slots
(Slot 1 and, in a 2RU chassis, Slot 11). LIC-STM1/OC3-RST cards can be placed in
any slot except the TCC and PDC slots (Slot 1 and, in a 2RU chassis, Slot 11) and
Slot 2 and, in a 2RU chassis, Slot 12.
Page 73 of 468

Figure 37: LIC-T16 (16x E1) Interfaces
Figure 38: LIC-T155 (1 x ch-STM-1) Interfaces
Figure 39: LIC-STM1/OC3-RST (1 x STM-1) Interfaces
Notes: The synchronization interface on the LIC-T155 is not in use. T3

synchronization input and T4 synchronization output are
supported via TCC cards.
LIC-T16 Part Number: 24-L004-0 cannot be used with software
versions prior to 8.0.
Page 74 of 468

3.9 Power Distribution Cards (PDC)

FibeAir IP-20N receives an external supply of -48V current via one or two Power
Distribution Cards (PDCs). The PDC or PDCs distribute the power via the backplane
to all the modules in the chassis. Each module receives the 48V input and
regulates it down to the operating voltage required by that module. Some RFUs
are powered from the PDC, via the RMC or RIC-D that is connected to the RFU.
See IDU-RFU Cable Connection on page 462.
Figure 40: Single-Input PDC Figure 41: Dual-Input PDC
The PDC monitors the power supply for undervoltage and overvoltage. The PDC
includes a LED labeled ACT, which displays Green during normal operation. If the
voltage goes below -38V, the LED displays Red and raises an undervoltage alarm.
When the voltage returns to -40V or higher, the Red indication goes off and the
Green indication reappears, and the undervoltage alarm is cleared.
The PDC also raises an alarm if the voltage goes over the overvoltage threshold.
The overvoltage threshold can be defined by the user. By default, an alarm is
raised if the voltage goes over 60V and is cleared when the voltage returns to 58V
or lower.
In addition, IP-20N provides PMs that indicate, per 15-minute and 24-hour
periods:
• The number of seconds the unit was in an undervoltage state during the
measured period.
• The number of seconds the unit was in an overvoltage state during the
measured period.
• The lowest voltage during the measured period.
• The highest voltage during the measured period.
These PMs are displayed generically without specifying the PDC. The overvoltage
PM starts being counted when at least one of the PDCs is in overvoltage
condition. The undervoltage PM starts being counted only when both PDCs are in
undervoltage condition.
Page 75 of 468

The PDC includes reverse polarity protection, so that if the positive (+) and
negative (-) inputs are mixed up, the system remains shutdown.
The PDC can tolerate up-to -60V, with a maximum current of 30A.
PDC
Comperator
48V - External
LED
Figure 42: PDC – Functional Diagram
A 1RU chassis includes a single power distribution card (PDC) with a dual-feed
option for power redundancy. With the dual-feed option, users can connect two
power supplies to the PDC for power redundancy.
Figure 43: Standard PDC Interfaces Figure 44: Dual-Input PDC Interfaces
A 2RU IP-20N can use two PDC cards for redundancy. Each PDC provides 48V
power to all modules in the chassis via the backplane, on different lines. A diode
bridge in the modules prevents power spikes and unstable power from the two
power sources.
Page 76 of 468

-48V Input
from PDC 1
-48V Input
from PDC 2
RMC / LIC
RMC / LIC
RMC / LIC
PDC 1
TCC1
PDC 2
TCC2
FAN’s
IVM
Figure 45: Power Distribution with Redundant PDCs
Page 77 of 468

3.10 Inventory Module (IVM)

Each FibeAir IP-20N unit includes an Inventory Module (IVM). The IVM is used to
store inventory information for the chassis. It is part of the basic chassis package,
and is located on the backplane of the chassis. There is no user access to the IVM.
Note: The same IVM is used for 1RU and 2RU chassis.
The IVM contains pre-programmed information that defines the chassis and its
slots, including:
• Module types that can be inserted into the chassis, per slot
• Product and card names
• Internal MAC addresses
• Serial number
• Hardware versions
• Activation-key-enabled features and capacities
Upon software initialization, the IP-20N software accesses the IVM to validate the
chassis type and hardware revision, and to verify the activation key for enabled
features and capacities.
Page 78 of 468

3.11 Fans Module

IP-20N uses a fans module in both 1RU and 2RU chassis.
Note: Separate fans modules are used in a 1RU and a 2RU chassis.
The fans module contains four 48V fans. The fans draw air into one side of the
chassis, and push the air out the other side.
Figure 46: Fans Module – 1RU Figure 47: Fans Module – 2RU
In the 2RU fan module, the fans’ speed is dependent on the internal temperature
of the IDU. The fan controller regulates the speed of the fans and thus the airflow
through the chassis, keeping the internal temperature within the operating
temperature range. The fans’ speed never decreases below a minimum level of
speed, and the fans do not stop completely at any temperature range.
FANs Module
FAN
3.3V from TCC (1RU)
Control
-48V from Backplane (2RU)
Figure 48: Fans Module Diagram
Page 79 of 468

3.12 Filter Tray (Optional)

IP-20N offers a filter as optional equipment. If a filter tray is not ordered, the IP-
20N chassis is delivered with a blank filter slot cover.
Figure 49: Filter Tray Sliding into Filter Slot (2RU Chassis)
Page 80 of 468

4. RFU Hardware Description and Branching Options

The radio carrier functionality for an IP-20N node is provided by Radio Frequency
Units (RFUs). An IP-20N can support up to ten (2RU chassis) or five (1RU chassis)
RFUs.
IP-20N works with the following RFUs:
Standard Power
• RFU-D
• RFU-E
• RFU-S
• RFU-C
High Power
• RFU-D-HP
• 1500HP
• RFU-HP

• RFU Overview
• RFU Selection Guide
• RFU-D
• RFU-D-HP
• RFU-E
• RFU-S
• RFU-C
• 1500HP/RFU-HP
Page 81 of 468

4.1 RFU Overview

FibeAir Radio Frequency Units (RFUs) were designed with sturdiness, power,
simplicity, and compatibility in mind. These advanced systems provide high-power
transmission for short and long distances and can be assembled and installed
quickly and easily. Any of the RFUs described in this chapter can be used with an
IP-20N.
The Ceragon RFU portfolio includes RFUs that operate in the microwave bands (4-
42 GHz) and the E-Band (71-86 GHz). In microwave bands, Ceragon RFUs deliver
high capacity over 3.5-112 MHz channels with configurable modulation schemes
and a range of modulations from BPSK to 4096 QAM. In E-Band, RFU-E delivers
high capacity over channels of 14, 28, 62.5, 125, 250, and 500 MHz with
configurable modulation schemes and a range of modulations from BPSK to 1024
QAM.
The RFUs support low to high capacities for traditional voice, mission critical, and
emerging Ethernet services, with any mix of interfaces, pure Ethernet, pure TDM,
or hybrid Ethernet and TDM interfaces (Native2).
RFUs support advanced features, such as XPIC, to help operators achieve high
spectral efficiency and capacity with the lowest possible OPEX. The RFU-D-HP
enables operators to double capacity without increasing the equipment’s physical
footprint.
Ceragon RFUs can be divided into the following two categories:
• The following RFUs use RIC-D to interface with the IDU:
 RFU-S (6 – 42 GHz)
 RFU-E (71-86 and 81-86 GHz)
 RFU-D (6 – 42 GHz)
 RFU-D-HP (4 – 11 GHz)
• The following RFUs use RMC-A or RMC-B to interface with the IDU:
 RFU-C (6 – 42 GHz)
 RFU-HP/1500HP (6 – 11 GHz)
All FibeAir RFUs can be installed in split-mount configurations. In addition, the
following RFUs can be installed in all-indoor configurations:
• 1500HP (6–11 GHz)
• RFU-HP (6-8 GHz)
• RFU-D-HP (4 – 11 GHz)
For information about the IDU-RFU connection, see IDU-RFU Cable Connection on
page 462.
Page 82 of 468

4.2 RFU Selection Guide

The following table can be used to help you select the RFU that is appropriate to
your location.
Table 14: RFU Selection Guide
Character RFU-D RFU-D-HP RFU-E RFU-S 1500HP/ RFU-C

RFU-HP
Installation Type Direct Mount √ √12 √ √ − √
Remote Mount √ √ √ √ √ √
All-Indoor − √ − − √ −
Configuration 1+0 √ √ √ √ √ √
2+0 √ √ − − √ √
1+1 √13 √13 − √13 √
2+2 √13 √13 − − √ √
N+0 ( N>2) √ √ − − √ −
SD support √ (BBC) √ (BBC) − − √ (IFC, BBS) √ (BBS)
Available Filter Diplexers √ √ √ √ − √

Types
Channel Filters − √ − − √ −
Lowest Modulation BPSK BPSK BPSK BPSK QPSK QPSK
Highest Modulation 4096 QAM 4096 QAM 1024 QAM 4096 QAM 2048 QAM 2048 QAM
Frequency Range (GHz) 6 – 42 4 – 11 71 – 76, 81 – 86 6 – 42 6 – 11 6 – 42
Carriers per RFU 2 2 1 1 1 1
Supported Radio Cards RIC-D RIC-D RIC-D RIC-D RMC-A, RMC-B RMC-A, RMC-B
12
Direct Mount is supported for 6 to 11 GHz only.
13
Page 83 of 468

4.3 RFU-D
RFU-D brings MultiCore features and capabilities to split-mount configurations.
RFU-D incorporates two modems, which are connected to the IDU via a single SFP
or RJ-45 interface to the RIC-D. This enables a single RIC-D to support four carriers
by interfacing with two MultiCore RFU-D RFUs, each with two carriers. For further
information on the advantages of RFU-D’s multicore architecture, see Unique
MultiCore Architecture of RFU-D and RFU-D-HP on page 150.
RFU-D’s usage mode is scalable, enabling operators to limit initial costs by
purchasing the basic single core mode, then expanding to MultiCore mode with
no additional hardware or installation required when network expansion requires
additional capacity. RFU-D can also be used in dual-receiver mode to enable BBC
Space Diversity, also with no additional hardware or installation required.
RFU-D’s MultiCore design enables it to support MultiCore capacity-boosting
features such as XPIC. Operators using RFU-D RFUs can incorporate these features
in IP-20N aggregation site nodes to increase spectral efficiency and capacity, while
minimizing the site’s footprint.
RFU-D operates in the frequency range of 6-42 GHz. RFU-D supports low to high
capacities for traditional voice and Ethernet services, as well as PDH/ or hybrid
Ethernet and TDM interfaces.
With RFU-D, traffic capacity throughput and spectral efficiency are optimized with
the desired channel bandwidth. For maximum user choice flexibility, channel
bandwidths from 14-112 MHz can be selected together with a range of
modulations. RFU-D provides a range of modulations from BPSK to 4096 QAM.
Using Ceragon’s Easy Set technology, a RFU-D consists of a generic radio unit and
a diplexer unit. For 6 to 15 GHz, the diplexer unit is field-replaceable, which means
it can be replaced without replacing the radio unit. The generic radio unit covers
an entire frequency band. It is the diplexer unit, which is passive, that determines
the sub-band coverage for the entire integrated RFU-D unit. This provides
operators with major benefits in terms of both deployment time and
maintenance.
For maintenance, the operator can reduce the number of spare radio units in its
inventory because a single generic radio unit can be used for any sub-band. This
means that for a site covering four channel ranges within a single frequency band,
a single spare radio unit can be kept on hand, because that unit can be used as a
spare for any of the RFU-D units in the site. The diplexer units, because they are
passive, are much less likely to require replacement, so the maintenance of spare
parts for the diplexer units is much less of a concern for the operator.
Page 84 of 468

The use of separate generic radio units and diplexer units also enables operators
to achieve a quicker system deployment time. In the planning stage, when the
frequency bands have been determined but the exact sub-band layout is still
under consideration, operators can already order all the radio units required for
the frequency bands that have been determined, and can begin ordering diplexer
units for the approximate sub-bands that are anticipated, while still determining
the exact network parameters. This enables faster delivery and deployment of the
network.
For 18 to 42 GHz, the diplexer unit is preassembled with the RFU-D and cannot be
replaced in the field.
4.3.1 Main Features of RFU-D

• Frequency range – Operates in the frequency range 6 – 42 GHz
• More power in a smaller package - Up to 29 dBm for extended distance,
enhanced availability, use of smaller antennas
• Configurable Modulation – BPSK – 4096 QAM
• Configurable Channel Bandwidth – 14 MHz – 112 MHz
• Compact, lightweight form factor - Reduces installation and warehousing
costs
• IDU Interface – RIC-D.
• Supported configurations
 MultiCore 2+0 Single/Dual Polarization
 2 x MultiCore 2+0 SP/DP
 MultiCore 2+2 SP/DP HSB14
• BBC Space Diversity
• Efficient and easy installation - Direct mount installation with different
antenna types
For additional information:

• Specifications
4.3.2 RFU-D Functional Block Diagram

The RFU is responsible for RF signal processing, and includes an RF transmitter
and an RF receiver with all their related functions.
RFU-D is designed to provide a high-capacity RF module, with a variety of low-loss
mediation devices to accommodate different RF configurations.
The following block diagram illustrates the functional modules of an RFU-D in a
2+0 configuration.
14
Page 85 of 468

RSL Source Sharing

Grounding Connector (BNC) (TNC)
DC Supply TRX Diplexer

OMT
DC
Cover
POE Input
Supply Power
Diplexer
RSL
MIMO/MU/ Ref VCO
Ext XPIC
Modem Clock unit
Ti
MIMO ADC
Interface SFP Modulator
TX
DAC TX Converter Driver
PA
10Gbps
V-Pole
2.5Gbps
SFP
RX
SFP Mod-De ADC Rx Converter
GbE
ref
FPGA
PHY Clks PLL TCXO
GbE
DC Phy
(Traffic+MNG)
POE
ADC
Modulator
Main
TX
PA
2.5Gbps
H-Pole
+ POE
Mod-De
RX
ADC Rx Converter
CPU Radio
Figure 50: RFU-D Functional Block Diagram – 2+0 Configuration
4.3.3 RFU-D Radio Interfaces

The following figures show the RFU-D TX and RX interfaces.
Figure 51: RFU-D Radio Interfaces (6 to 15 GHz)
Page 86 of 468

Figure 52: RFU-D Rear View (Left) and Front View (Right)
Figure 53: RFU-D Interfaces (All Frequency Bands)
Table 15: RFU-D Interfaces
Interface Description
P1 PoE / RFU Interface (RJ-45)

P2 RFU Interface (SFP)
P4 Data Sharing
Page 87 of 468

4.3.4 RFU-D Marketing Models

For frequencies of 6 to 15 GHz, RFU-D uses the Easy Set technology in which the
radio and the diplexer unit are delivered as separate units.
For frequencies of 18 to 42 GHz, the RFU-D unit is delivered as one unit, consisting
of both the radio and the diplexers.
This section explains how to read RFU-D marketing models, including marketing
models for the diplexer unit for 6-15 GHz links. Constructing a marketing model
for the purpose of ordering equipment should always be done using a
configurator.
Note: Not all marketing model fields are always necessary to define a
valid marketing model. If a specific field is not applicable, it
should be omitted.
4.3.4.1 Marketing Models for Easy Set RFU-D Radio and Diplexer Units, 6 to 15 GHz
For frequencies of 6 to 15 GHz, the RFU-D radio unit and diplexer unit are ordered
separately. Using Easy Set technology, the diplexer unit is assembled on the
RFU-D radio unit during link installation in the field. The radio unit is generic; only
the diplexer unit (DXU) is sub-band specific, which facilities link planning,
ordering, and maintenance as described above.
Table 16 provides the marketing model structure for the RFU-D Easy Set radio
unit.
Table 17 provides the marketing model structure for the RFU-D Easy Set diplexer
unit.
Table 16: RFU-D Marketing Model Structure, 6 to 15 GHz (Radio Unit)
Marketing Model Description
RFU-D-ff RFU-D, Dual Core, High capacity, Split Mount Radio only, ff GHz
Table 17: RFU-D Marketing Model Structure, 6 to 15 GHz (Diplexer Unit)
DXDff-xxxY-
RFU-D Diplexers Unit, ff GHz, Block xxxY, ccWdd-eeWgg, High/Low
ccWdd-eeWgg-t
Page 88 of 468

Figure 54: Radio Unit and Diplexer Unit
Table 18: RFU-D Marketing Model Structure– Possible Values (Easy Set - Radio Unit
Only)
Placeholder in Description Possible Values

Marketing Model
ff Frequency band 06,07,08,10,11,13,15
Table 19: RFU-D Marketing Model Structure– Possible Values (Easy Set - Diplexer
Unit Only)

Marketing Model
ff Frequency band L6,U6,07,08,10,11,13,15

xxxY TX-RX separation and block xxx - TRS 3 figures in [MHz].
indication (Ceragon Y - Letter to indicate frequency block.
internal) Example: 266A
The frequency block is a Ceragon internal parameter
which defines different channelization using the same
TRS and frequency band.
Page 89 of 468


Marketing Model
ccWdd, eeWgg Channel indication or {Start ch}W{End ch} Example: 10W15

LOW/HIGH or blank (eeWgg is optional when using two different diplexers
Example: 1W5, 10W15)
t TX low / TX high indication L – TX Low
H – TX high
Table 20 provides examples of specific RFU-D diplexer unit marketing models based on the syntax described
above.
Table 20: RFU-D Diplexer Unit Marketing Model Examples
Marketing Model Example Explanation
DXD08-119A-01W03-L RFU-D Diplexers Unit, 8GHz, TRS=119MHz, two identical Diplexers Uniting
channels 1 to 3, TX low
DXDL6-252A-05W06-01W02-H RFU-D Diplexers Unit, L6GHz, 252MHz TRS, different Diplexers Uniting
channels 5 to 6 and 1 to 2, TX high
4.3.4.2 Marketing Model for RFU-D Unit, 18-42 GHz

When ordering an RFU-D, a single unit is ordered according to the following
marketing model syntax: RFU-D-ff-xxxY-ccWdd-eeWgg-t.
Table 21: RFU-D Marketing Model Structure,18 to 42 GHz
RFU-D-ff-xxxY-ccWdd-eeWgg- RFU-D, Dual Core, High Capacity, Split Mount Radio, ff

t GHz, Block xxxY, ccWdd-eeWgg, High/Low
Table 22: RFU-D Marketing Model Structure– Possible Values

Marketing Model
ff Frequency band 18, 23, 24, 26, 28, 32, 36, 38, 42
Page 90 of 468


Marketing Model

H – TX high
The following are some examples of specific RFU-D 18 to 42 GHz marketing models based on the syntax
specified above.
Table 23: RFU-D Marketing Model Examples (18-42 GHz)
RFU-D-08-119A-01W03-L RFU-D Diplexers Unit, 8GHz, TRS=119MHz, two identical Diplexers Uniting
channels 1 to 3, TX low
RFU-D-L6-252A-05W06-01W02- RFU-D Diplexers Unit, L6GHz, 252MHz TRS, different Diplexers Uniting
H channels 5 to 6 and 1 to 2, TX high
4.3.5 RFU-D MultiCore Mediation Devices (MCMD)

The Dual Core Mediation Devices (MCMD) are designed to offer a simple and
compact solution for a direct mount installation of the RFU-D on a standard
Ceragon antenna interface.
RFU-D is equipped with two antenna ports, which mandates the use of unique
mediation devices to facilitate direct mount configurations. The following two
examples show dual core mediation devices that enable the connection of a single
RFU-D to an antenna. For the full set of mediation devices, refer to the RFU-D
Installation Guide.
Table 24: RFU-D Mediation Devices
MCMD type Functionality
Splitter Combines the two cores using the same polarization

OMT Combines the two cores on alternate polarizations (H,V)
Page 91 of 468

Figure 55: Splitter
Figure 56: OMT
Page 92 of 468

4.4 RFU-D-HP
RFU-D-HP is a MultiCore RFU that provides high power for long-haul applications.
Like RFU-D, RFU-D-HP incorporates two modems, which are connected to the IDU
via a single SFP or RJ-45 interface to the RIC-D. For further information on the
advantages of RFU-D-HP’s Multicore architecture, see Unique MultiCore
Architecture of RFU-D and RFU-D-HP on page 150.
RFU-D-HP enables operators to benefit from high transmit power of up to 38
dBm, while also benefitting from MultiCore capacity-boosting features such as
XPIC. Operators using RFU-D-HP RFUs can incorporate these features in IP-20N
aggregation site nodes to increase spectral efficiency and capacity, while
minimizing the site’s footprint.
RFU-D-HP’s usage mode is scalable, enabling operators to limit initial costs by
purchasing the basic single core mode, then expanding to MultiCore mode with
no additional hardware or installation required when network expansion requires
additional capacity. RFU-D-HP can also be used in dual-receiver mode to enable
BBC Space Diversity, also with no additional hardware or installation required.
RFU-D-HP offers a flexible and modular branching system that enables the
combination of different bands for different carriers. For example, the same link
can be used for both L6 and U6 or 7 and 8 GHz channels.
RFU-D-HP can be used with wide diplexer-based branching, enabling direct mount
installation. Diplexers can be used for direct mount configurations of up to 4+0.
RFU-D-HP can also be used with channel filter-based branching, enabling
configurations of up to 8+0 per polarization in remote mount and all-indoor
configurations.
To maximize operational flexibility, both diplexers and channel filters are provided
separately for the radio units, enabling the diplexers or filters to be changed in the
field with minimal downtime and no risk of impairing the RFU’s sealing.
For all-indoor configurations, the IDU, the RFUs, and the channel filter-based
branching system are ordered as a single item and delivered, pre-assembled, pre-
tested, and pre-configured in a rack.
RFU-D-HP operates in the frequency range of 4-11 GHz. RFU-D-HP supports low to
high capacities for traditional voice and Ethernet services, as well as PDH/ or
hybrid Ethernet and TDM interfaces.
With RFU-D-HP, traffic capacity throughput and spectral efficiency are optimized
with the desired channel bandwidth. For maximum user choice flexibility, channel
modulations. RFU-D-HP provides a range of modulations from BPSK to 4096 QAM.
Page 93 of 468

4.4.1 Main Features of RFU-D-HP

• High transmit power – Up to 38 dBm, ideal for long-haul/high-power
applications
• Compact, form factor - Reduces installation and warehousing costs
• IDU Interface – RIC-D
• Supported Configurations
 Single Carrier 1+0
 MultiCore 2+0 Single/Dual Polarization
 2 x MultiCore 2+0 SP/DP
 2+0 BBC Space Diversity
 2 x 2+0 BBC Space Diversity
 2 x 4+0 BBC Space Diversity
 MultiCore 2+2 SP/DP HSB15
• BBC Space Diversity
4.4.2 RFU-D-HP Functional Block Diagram

RFU-D-HP is designed to provide a high-power RF module, and the ability to
concatenate several carriers with minimal RF branching loss.
The following block diagram illustrates the functional modules of an RFU-D-HP in a
2+0 configuration.
15
Page 94 of 468

RSL Source Sharing

Grounding Connector (PINs) (TNC)
Main board DC Supply TRX Diplexer

DC OMT
Unit
Supply Power
Diplexer
RSL
MIMO/MU/ Ref VCO
Ext XPIC
Modem Clock unit
Ti
MIMO ADC
TX
PA
10Gbps
H-Pole
V-Pole
2.5Gbps
RX
SFP
ref
FPGA
PHY 40MHz
Clks PLL
GbE TCXO
Phy
(Traffic+MNG)
ADC
Modulator
TX
Main DAC Tx Converter Driver
PA
H-Pole
V-Pole
2.5Gbps
Mod-De
RX
ADC Rx Converter
CPU Radio
Figure 57: RFU-D-HP Functional Block Diagram – 2+0 Configuration
4.4.3 RFU-D-HP Radio Interfaces

The following figures show the RFU-D-HP TX and RX interfaces.
Figure 58: RFU-D-HP Radio Interfaces
Page 95 of 468

Figure 59: RFU-D-HP Front Side Interfaces
Figure 60: RFU-D-HP Interfaces
Page 96 of 468

Table 25: RFU-D-HP Interfaces
PWR Power Connector, 48VDC

P1 RFU Interface (RJ-45)
P3 Data Sharing
P4 48VDC output for fans unit, for all-indoor configurations only.

• Specifications
Page 97 of 468

4.4.4 RFU-D-HP Branching Options

The following branching options are available for RFU-D-HP:
• Diplexers – Split-mount installation using wide diplexer-based branching,
enabling direct or remote mount installation. Diplexers can be used for direct
mount configurations of up to 4+0.
Note: 4 and 5 GHz diplexer-based configurations are always
implemented via remote mount.
• Channel Filter-Based Branching – Split-mount installation suitable for
configurations of up to 16+0 per polarization in remote-mount and all-indoor
configurations.
• All-Indoor – For use in locations with harsh environmental conditions
requiring all the equipment to be installed indoors or in which it is difficult to
maintain the radio units close to the antennas.
To maximize operational flexibility, both diplexers and channel filters are provided
separately for the radio units, enabling the diplexers or filters to be changed in the
field with minimal downtime and no risk of impairing the RFU’s sealing. For all-
indoor configurations, the IDU, the RFUs, and the channel filter-based branching
system are ordered as a single package and delivered, pre-assembled, in a rack.
4.4.4.1 RFU-D-HP Diplexer Unit (DXU)

The Diplexer Unit (DXU) is used for configurations of up to two radio units. The
DXU is assembled directly behind the radio unit to form the complete RFU-D-HP.
The radio unit is generic; only the (DXU) is sub-band specific, which facilities link
planning, ordering, and maintenance as described above.
Figure 61 shows the radio unit and the diplexer unit from front and back. In each
picture, the radio unit is on the right.
Page 98 of 468

Figure 61: Radio Unit and Diplexer Unit
Figure 62: Open Diplexer Unit
Page 99 of 468

For split-mount configurations, diplexer-based filtering can be used with up to

two RFU-D-HP units (four carriers). For suitable frequency ranges and antenna
sizes, the RFU-D-HP unit, including the diplexer unit, can be installed on the
antenna in a direct mount configuration.
A diplexer-based RFU-D-HP unit can also be installed in a remote-mount
configuration, using a remote mount kit.
MultiCore Mediation Devices (MCMD)

This section describes the MultiCore Mediation Devices (MCMD) available for
installation of RFU-D-HP units using diplexers.
The MCMDs are designed to offer a simple and compact solution for direct mount
installations of the MultiCore RFU-D-HP on a standard Ceragon antenna interface.
The RFU-D-HP is equipped with two antenna ports, which mandates the use of
unique mediation devices to facilitate direct mount configurations. The following
two examples show dual core mediation devices that enable the connection of a
single RFU-D-HP unit to an antenna. For the full set of mediation devices, refer to
the RFU-D-HP Installation Guide.
Figure 63: RFU-D-HP Coupler
Table 26: RFU-D-HP Mediation Devices
MCMD Type Functionality
OMT Combines the two carriers on alternate polarizations (H,V)

Splitter Combines the two carriers using the same polarization
Dual Splitter Combines the four carriers, two carriers on each polarization
Dual Coupler Couples four carriers, two carriers on each polarization. For 2+2 HSB
Dual Circulator Low loss combining of four carriers, two carriers on each polarization
Space Diversity Allows for easy SD connection of the Space Diversity antenna using
coaxial cable
Page 100 of 468

4.4.4.2 Channel Filter-Based Split-Mount Branching

For multiple carriers, up to four radio units can be cascaded and circulated
together to the antenna port. This function is performed by branching networks
that consist of OCUs and various components that connect multiple OCUs in the
branching chain. The branching network routes the signals from the RFUs to the
antenna.
The Tx and the Rx path circulate together to the main OCB port. Each OCU
includes Tx and Rx channel filters for two carriers.
When chaining multiple OCBs, each Tx signal is chained to the OCB Rx signal, and
both signals are chained to the next OCB using an S-band.
Outdoor Circulator Unit (OCU)

The OCU contains the channel filters, together with circulators, connecting two Tx
channels and two Rx channels from the RFU-D-HP radio unit to the antenna port.
Front Back
Figure 64: RFU-D-HP OCU
Figure 65: Open OCU Showing the Channel Filters
Page 101 of 468

The OCU includes channel filters for two carriers. The OCU ports towards the RFU-
D-HP radio ports become internal ports once the OCU is assembled behind the
RFU-D-HP radio unit.
Figure 66: OCU Channel Filters – Functional Description
Figure 67: OCU Channel Filters – Internal Electrical Connections
Page 102 of 468

4.4.4.3 All-Indoor Terminals

An RFU-D-HP all-indoor terminal supports up to eight RFU units containing up to
16 carriers in a single rack. Adjacent channel configurations can be used in all-
indoor terminals.
All-indoor terminals support no-single-point-of-failure architecture, with fully
protected PDUs, IDUs, and RFUs.
PDU
Sub-Rack
#1
Sub-Rack
#2
Sub-Rack
#3
Sub-Rack
#4
Sub-Rack
#5
Sub-Rack
#6
Sub-Rack
#7
Sub-Rack
#8
IDU 1
IDU 2
Figure 68: RFU-D-HP Fully Assembled All-Indoor Terminal
Each sub-rack includes an RFU-D-HP with all of its branching components,

including channel filters and circulators. The sub-racks can be connected in
various combinations providing support for a very large number of possible
configurations. Supported configurations include up to 16+0, Space Diversity,
East-West, and XPIC.
An all-indoor RFU-D-HP configuration is delivered as a pre-assembled, fully tested
terminal, including all branching components, RFUs, IDUs, and pre-installed
activation keys.
Page 103 of 468

The following all-indoor branching configurations are available for RFU-D-HP. Note
that CeraOS feature support and software configuration for the all-indoor
configurations are the same as for split-mount configurations.
Note: Adjacent channels are available for all configurations.
Table 27: All-Indoor Radio Configuration Options for RFU-D-HP
Configuration Notes
16 X 1+0
8 X 1+0
4 X 1+0
2+0 Single Polarization Planned for future release.
2+0 Dual Polarization (XPIC)
2+0 XPIC with BBC Space Diversity
1+0 to 8+0 East-West
Note the following limitations:

• Configurations with more than eight RFUs require two IDUs.
• With 112 MHz channels, up to 6 radio carriers are supported per IDU.
Page 104 of 468

4.4.5 RFU-D-HP Marketing Models

This section explains how to read RFU-D-HP marketing models, including
marketing models for the radio unit, and marketing models for the branching unit,
either diplexer or OCB-based branching. Constructing a marketing model for the
purpose of ordering equipment should always be done using a configurator.
Note: Not all fields are always necessary to define a valid marketing
model. If a specific field is not applicable, it should be omitted.
4.4.5.1 RFU-D-HP Marketing Models – Radio Unit

Table 28 lists and describes the available RFU-D-HP marketing models for the
radio unit, which is sub-band generic. The same radio units are used for both split-
mount and all-indoor configurations.
Table 28: RFU-D-HP Marketing Models – Radio Unit
Marketing Model Description Supported Frequency Bands
RFU-D-HP-04L RFU-D-HP 4GHz lower band Split Mount Radio Unit 3.4 to 3.9 GHz16
RFU-D-HP-04H RFU-D-HP 4GHz higher band Split Mount Radio Unit 3.7 to 4.2 GHz16
RFU-D-HP-05 RFU-D-HP 5GHz Split Mount Radio Unit 4.4 to 5.0 GHz
4.4.5.2 RFU-D-HP Marketing Models – Diplexer Unit

This section explains how to read marketing models for the RFU-D-HP DXU.
Constructing a marketing model for the purpose of equipment order should
always be done using a configurator.
Table 29: DXDHff-xxxY-ccWdd-eeWgg-t

Marketing Model
ff Frequency band 04, 05, L6,U6,7,8,10,11
16
For 4 GHz, these numbers refer to the TX operating frequencies. The RX operating frequencies cover
3.4 to 4.2 GHz.
Page 105 of 468


Marketing Model

H – TX high
Table 30 provides examples of specific RFU-D-HP DXU marketing models based on the syntax described above.
Table 30: RFU-D-HP Diplexers Unit Marketing Model Example
DXDH08-119A-01W03-L RFU-D-HP Diplexers Unit, 8GHz, TRS=119MHz, two identical Diplexers

Uniting channels 1 to 3, TX low
DXDHL6-252A-05W06-01W02-H RFU-D-HP Diplexers Unit, L6GHz, 252MHz TRS, different Diplexers Uniting
channels 5 to 6 and 1 to 2, TX high
Page 106 of 468

4.4.5.3 RFU-D-HP Marketing Models – Mediation Device

Table 31 lists and describes the available RFU-D-HP MCMD marketing models.
Table 31: RFU-D-HP MCMD Marketing Models
DXDH-MD-OMT-ff RFU-D-HP Diplexers Based Branching OMT Unit, ff GHz

DXDH-MD-DUAL-CPLR-ff RFU-D-HP Diplexers Based Branching Dual Coupler Unit,
ff GHz
DXDH-MD-SPLITTER-ff RFU-D-HP Diplexers Based Branching Splitter Unit, ff
GHz
DXDH-MD-DUAL-SPLTR-ff RFU-D-HP Diplexers Based Branching Dual Splitter Unit,
ff GHz
DXDH-MD-DUAL-CIRC-ff RFU-D-HP Diplexers Based Branching Dual Circulator
Unit, ff GHz
DXDH-MD-SD-ff RFU-D-HP Diplexers Based Branching Space Diversity
Unit, ff GHz
DXDH-RM-MOUNT-kit RFU-D-HP RM kit for Direct Mount Mediation Dev.
DXDH-RM-MOUNT-ADPT-ff RFU-D-HP DC Adaptor Remote Mount Kit, ff GHz
DXDH-RM-OMT-ADPT-ff RFU-D-HP DC OMT Adaptor, ff GHz
Where
Place Holder in Marketing Model Possible Values
ff 04, 05, 06, 7-8, 11
Page 107 of 468

4.4.5.4 RFU-D-HP Marketing Models – OCU

This section explains how to read marketing models for the RFU-D-HP OCU.
Constructing a marketing model for the purpose of equipment order should
always be done using a configurator.
The OCU uses the following marketing model structure:
FXDHff-xxxYZccT-mmmNZddT-t
Table 32: Marketing Model Structure – OCU

Marketing Model
ff Frequency band L6,U6,07,08,11

xxxY, mmmN 1st Channel Filter TRS and xxx - TRS 3 figures in [MHz].
block indication (Ceragon Y - Letter to indicate frequency block.
Z, N Indicating the Channel Filter Channel Filters Channel Bandwidth Designator
channel bandwidth {A/B/C/D/E}
designator A = 28 MHz
B = 40 MHz
C = 56MHz
D = 80 MHz
E = 112 MHz
Cc, dd Indicating the Channel
Number in the Block
T Indicating the filter type Filter Type {N/A}
N = Standard Filter
A = Adjacent Channel Filter
H – TX high
The following are some examples of specific RFU-D-HP OCU marketing models based on the syntax specified
above.
Table 33: RFU-D-HP OCU Marketing Model Example
FXDH6H-340FA02A-310AB04N-H Channel Filters cover for RFU-D-HP, Upper 6 GHz with 1st Filters block
TRS block 340F, 28 MHz channels number 02 Adjacent and 2nd Filters
block TRS block 310A, 40 MHz channels number 04 Narrow, High
Page 108 of 468

4.4.5.5 Channel Filter-Based Branching Components

The following is a list of RFU-D-HP Channel Filter Branching units. These Branching
units are used to build various RFU-D-HP configurations.
Table 34: RFU-D-HP Branching Unit Marketing Models
FXDH-RM-MOUNT-kit RFU-D-HP Filters Remote Mount Kit

FXDH-RM-U-Bend-ff RFU-D-HP Filters Cover Branching U Bend
FXDH-RM-LU-Bend-ff RFU-D-HP FLT Cover Branch. Long U Bend
FXDH-RM-Term-ff RFU-D-HP PDR100/CPR90G WG 50ohm termination kit
FXDH-RM-MD-SPLTR-ff RFU-D-HP Filters Cover Branching Splitter MD Unit, ff GHz
FXDH-RM-MD-CPLR-ff RFU-D-HP Filters Cover Branching Coupler MD Unit, ff GHz
In these marketing models, ff represents the frequency. Possible values are: 04,
05, 06, 7-8, and 11.
Page 109 of 468

4.4.6 RFU-D-HP Marketing Models – All-Indoor Terminals

For all-indoor configurations, the IDU, the RFUs, and the channel filter-based
branching system are ordered as a single item that is delivered pre-assembled and
pre-tested in a rack. Each terminal or site has a unique marketing model.
Figure 69 shows the marketing model structure for RFU-D-HP all-indoor terminals,
including the default values per field.
1-4 5 6 7 8 9-10 11 12 13 14-15 16 17 18 19 ……………. 24
AIDH 1 N B - L6 A B - L6 A B - 1 2 3 4 5 6
Figure 69: RFU-D-HP All-Indoor Marketing Model Structure
Table 35 describes the fields of the RFU-D-HP all-indoor marketing model and
their possible values. When applicable, the default value is indicated:
Table 35: RFU-D-HP All-Indoor Marketing Model Structure
Field Description
1-4 System Type:

AIDH – All-Indoor, Long Haul, High Power system based on RFU-D-HP (default)
5 Number of Directions:
1 – One direction in the rack (default)
2 – Two directions in the rack (East-West)
6 System Type:
N – Normal installation (default)
A – Second system in an existing rack (in this case locations 14 to 17 cannot appear)
E – Expansion
S – Special system
7 Number and type of IDU:
A – One IP-20N 1RU
B – Two IP-20N 1RU
C – One IP-20N 2RU
D – One IP-20N 1RU and one IP-20N 2RU
E – Two IP-20N 2RU
Z – No IDU
9-10, 14-15 Frequency Band (fields 9-10 for the first system, fields 14-15 for the second system):
04 – 3.6 to 4.0 GHz
05 – 4.4 to 5.0 GHz
06 – 5.9 to 7.1 GHz
07 – 7.1 to 7.9 GHz
08 – 7.7 to 8.5 GHz
Page 110 of 468

Field Description
10 – 10.0 to 10.7 GHz
11 – 10.7 to 11.7 GHz
11,16 System Configuration:
A = 1+0 B = 1+1
C = 2+0 D = 2+2
E = 3+0 F = 3+3
G = 4+0 H = 4+4
K = 5+0
L = 6+0
M = 7+0
N = 8+0
P = 9+0
R = 10+0
12, 17 Carrier Arrangement:
A – Non-Space Diversity, Single Polarization
B – Space Diversity, Single Polarization
C- - Non-Space Diversity, Dual Polarization
D – Space Diversity, Dual Polarization
19-24 Terminal Number:
Sequential terminal number. Unique to each terminal.
Page 111 of 468

4.5 RFU-E
RFU-E is a compact and versatile RFU that operates in the E-Band frequency range
(71-86 and 81-86 GHz). Its light weight and small footprint make it versatile for
many different applications. Thanks to its small footprint, low power
consumption, and simple installation, RFU-E can be installed in many different
types of remote locations.
RFU-E operates over 14, 28, 62.5, 125, 250, and 500 MHz channels to deliver up to
2.5 Gbps of Ethernet throughput in several system configurations.
RFU-E is connected to the IDU via a single radio interface on the RIC-D. RFU-E
supports low to high capacities for traditional voice and Ethernet services, as well
as PDH/ or hybrid Ethernet and TDM interfaces.
With RFU-E provides a range of modulations from BPSK to 1028 QAM.
4.5.1 Main Features of RFU-E

• Frequency range – Operates in the frequency range 71-86 and 81-86 GHz
• Transmit power – Up to 18 dBm
• Configurable Modulation – BPSK to 1028 QAM
• Configurable Channel Bandwidth – 14 to 500 MHz
costs
antenna types
4.5.2 RFU-E Functional Block Diagram

RFU-E is designed to provide a high-capacity RF module, with a variety of low-loss
The following block diagram illustrates the functional modules of an RFU-S in a
1+0 configuration.
The RFU-E is designed to provide a split-mount solution for the E-Band frequency
range.
The following block diagram illustrates the functional modules of an RFU-E in a
1+0 configuration.
Page 112 of 468

RSL Source Sharing


DC
Input
Supply Power
Diplexer
RSL
MIMO/MU/ Ref VCO
Ext XPIC
Modem Clock unit
Ti
MIMO ADC
TX
DAC Tx Converter Driver
PA
10Gbps Mux
2.5Gbps
SFP
RX
GbE
ref
FPGA
PHY Clks PLL TCXO
GbE
DC Phy
(Traffic+MNG)
POE
ADC
Modulator
Main DAC
2.5Gbps
+ POE
Mod-De ADC
CPU Radio
Figure 70: RFU-E Functional Block Diagram – 1+0 Configuration
Page 113 of 468

4.5.3 RFU-E Radio Interfaces

The following figures show the RFU-E TX and RX interfaces.
Figure 71: RFU-E Antenna Interfaces
Figure 72: RFU-D Front Side Interfaces
Page 114 of 468

Figure 73: RFU-E Interfaces
Table 36: RFU-E Interfaces

P3 Reserved for future use
4.5.4 RFU-E Marketing Models

The RFU-E is offered in two main configurations:
• Integrated Antenna
• Standalone RFU
The following table lists and describes the available RFU-E marketing models.
Table 37: RFU-E Marketing Models
RFU-E-{H/L}-Ant RFU-E, Split Mount, E-Band, Integrated Antenna. RFU-E-{H/L}-Ant

RFU-E-{H/L} RFU-E, Split Mount, E-Band. RFU-E-{H/L}
Page 115 of 468

4.6 RFU-S
RFU-S is a state-of-the-art RFU that supports a broad range of capacities. RFU-S
operates in the frequency range of 6-42 GHz.
RFU-S is connected to the IDU via a single radio interface on the RIC-D. RFU-S
supports low to high capacities for traditional voice and Ethernet services, as well
as PDH/ or hybrid Ethernet and TDM interfaces.
With RFU-S, traffic capacity throughput and spectral efficiency are optimized with
modulations. RFU-S provides a range of modulations from BPSK to 4096 QAM.
4.6.1 Main Features of RFU-S

• More power in a smaller package - Up to 28 dBm, ideal for long-range
applications
costs
antenna types

• Specifications
4.6.2 RFU-S Functional Block Diagram

RFU-S is designed to provide a high-capacity RF module, with a variety of low-loss
The following block diagram illustrates the functional modules of an RFU-S in a
1+0 configuration.
Page 116 of 468

RSL Source Sharing


Cover
DC
Input
Supply Power
Diplexer
RSL
MIMO Module
Ref VCO
MIMO
Modem
Interface SFP Ti Clock unit
10Gbps
ADC
Modulator
TX
Mux DAC Tx Converter Driver
PA
2.5Gbps
SFP
RX
GbE
ref
FPGA 40MHz
PHY Clks PLL
GbE TCXO
DC (Traffic+MNG)
Phy
POE
ADC
Modulator
Main DAC
2.5Gbps
+ POE
Mod-De ADC
CPU Radio
Figure 74: RFU-S Functional Block Diagram – 1+0 Configuration
4.6.3 RFU-S Interfaces

The following figures show the RFU-S interfaces.
Figure 75: RFU-S Front Side Interfaces
Page 117 of 468

Figure 76: RFU-S Data and Power Interfaces
Table 38: RFU-S Interfaces

4.6.4 RFU-S Marketing Models

For frequencies of 6 to 15 GHz, RFU-S uses the Easy Set technology in which two
individual units are ordered: a generic radio unit and a diplexer unit.
For frequencies of 18 to 42 GHz, a single RFU-S unit is ordered, consisting of both
the radio and the diplexers.
This section explains how to read RFU-S marketing models, including marketing
models for the diplexer unit for 6-15 GHz links. Constructing a marketing model
for the purpose of ordering equipment should always be done using a
configurator.
Page 118 of 468

4.6.4.1 Marketing Models for Easy Set RFU-S Radio and Diplexer Units, 6 to 15 GHz
For frequencies of 6 to 15 GHz, the RFU-S radio unit and diplexer unit are ordered
separately. Using Easy Set technology, the diplexer unit is assembled on the RFU-S
radio unit during link installation in the field. The radio unit is generic; only the
diplexer unit (DXU) is sub-band specific, which facilities link planning, ordering,
and maintenance as described above.
Table 39 provides the marketing model syntax for the RFU-S Easy Set radio unit.
Table 40 provides the marketing model syntax for the RFU-S Easy Set diplexer
unit.
Table 39: RFU-S Marketing Model Syntax, 6 to 15 GHz (Radio Unit)
RFU-S-ff RFU-S, Single Core, High Capacity, Split Mount Radio only, ff GHz
Table 40: RFU-S Marketing Model Syntax, 6 to 15 GHz (Diplexer Unit)
DXSff-xxxY-ccWdd-t RFU-S Diplexers Unit, ff GHz, Block xxxY, ccWdd, High/Low
Page 119 of 468

Figure 77: RFU-S Radio Unit and Diplexers Unit (Separate) Figure 78: RFU-S Radio Unit and Diplexers Unit (Attached)
Table 41: RFU-S Marketing Model Structure– Possible Values (Easy Set - Radio Unit
Only)

Marketing Model
ff Frequency band 06,07,08,10,11,13,15
Table 42: : RFU-S Marketing Model Structure– Possible Values (Easy Set - Diplexer
Unit Only)

Marketing Model
ff Frequency band L6,U6,07,08,10,11,13,15

Page 120 of 468


Marketing Model
ccWdd Channel indication or {Start ch}W{End ch} Example: 10W15

LOW/HIGH or blank
H – TX high
Table 43 provides examples of specific RFU-S diplexer unit marketing models based on the syntax described
above.
Table 43: RFU-S Diplexer Unit Marketing Model Example
DXSU6-160A-13W16-L Diplexer Cover Assembly for RFU-S, Upper 6 GHz. TRS block 160A, Ch 13
to 16, Tx low
4.6.4.2 Marketing Model for RFU-S Unit, 18-42 GHz

When ordering an RFU-S, a single unit is ordered according to the following
marketing model syntax: RFU-S-xxxY-ccWdd-t.
Table 44: RFU-S Marketing Model Structure,18 to 42 GHz
RFU-S, Single Core, High Capacity, Split Mount Radio, ff

RFU-S-xxxY-ccWdd-t
GHz, Block xxxY, ccWdd High/Low
Table 45: RFU-S Marketing Model Structure– Possible Values

Marketing Model
ff Frequency band 18, 23, 24, 26, 28, 32, 36, 38, 42
ccWdd Channel indication or {Start ch}W{End ch} Example: 10W15
LOW/HIGH or blank
H – TX high
Page 121 of 468

The following are some examples of specific RFU-S 18 to 42 GHz marketing models based on the syntax
specified above.
Table 46: RFU-S Marketing Model Examples (18-42 GHz)
RFU-S-08-119A-01W03-L RFU-S Diplexers Unit, 8GHz, TRS=119MHz, covering channels 1 to 3, TX

low
RFU-S-L6-252A-05W06-H RFU-S-HP Diplexers Unit, L6GHz, 252MHz TRS, covering channels 5 to 6,
TX high
4.6.5 RFU-S Mediation Devices

RFU-S requires a Coupler/Splitter for 1+1 configurations and an OMT for 2+2
configurations.
Figure 79: RFU-S Coupler/Splitter Figure 80: RFU-S OMT
Page 122 of 468

4.7 RFU-C
RFU-C is a fully software configurable, state-of-the-art RFU that supports a broad
range of 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/ or hybrid Ethernet and TDM
interfaces.
With RFU-C, traffic capacity throughput and spectral efficiency are optimized with
bandwidths from 3.5-56 MHz can be selected together with a range of
modulations. RFU-C provides a range of modulations from QPSK to 2048 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.
4.7.1 Main Features of RFU-C

• More power in a smaller package - Up to 26 dBm for extended distance,
enhanced availability, use of smaller antennas
• Configurable Modulation – QPSK – 2048 QAM
• Configurable Channel Bandwidth – 3.5 MHz – 56MHz
costs
• Supported configurations17:
 1+0 – direct and remote mount
 2+2 – remote mount
 4+0 – remote mount
• IDU Interface – RMC-B or RMC-A
antenna types
17
Remote mount configuration is not supported for 42 GHz.
Page 123 of 468

4.7.2 RFU-C Functional Block Diagram

RFU-C is designed to provide a high-capacity RF module, with a variety of low-loss
The following block diagram illustrates the functional modules of an RFU-C in a
1+0 configuration.
350 MHz VCO
IF TX TX
EMM
FSK Chain
Controller and
(N-Type Connector)
Peripherals
IDU Connection
Quadplexer
Connector
Connector
-48V
PSU Section
(BNC Connector)
RSL Indication
IF RX RX
LNA
Chain
140 MHz
VCO
PSC Board (Frequency Independent) TRX Board (Frequency Dependent) Diplexer
RFU-C Chassis (Frequency Independent)
Figure 81: RFU-C Functional Block Diagram – 1+0 Configuration

• Specifications
Page 124 of 468

4.8 1500HP/RFU-HP
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 2048 QAM.
4.8.1 Main Features of 1500HP/RFU-HP18

• Frequency range –
 1500HP 2RX: 6-11GHz
 1500HP 1RX: 11 GHz
 RFU-HP: 6-8GHz
• Frequency source – Synthesizer
• Installation type – Split mount – remote mount, all indoor (No direct mount)
• Diversity – Optional innovative IF Combining Space Diversity for improved
system gain (for 1500HP 2RX), as well as BBS Space Diversity (all models)
• High transmit power – Up to 33dBm in all indoor and split mount installations
• Configurable Modulation – QPSK – 2048 QAM
• IDU Interface – RMC-B or RMC-A
• Configurable Channel Bandwidth –
 1500HP 2RX (6-11 GHz): 10-30 MHz
 1500HP 2 RX (6 and 11 GHz wide option): 40 MHz
 1500HP 1RX (11 GHz): 10-30 MHz
 1500HP 1RX (11 GHz wide option): 40 MHz
 RFU-HP 1RX (6-8GHz): 3.5-56 MHz
18
For guidance on the differences between 1500HP and RFU-HP, refer to RFU Selection Guide on page 57.
Page 125 of 468

• System Configurations – Non-Protected (1+0), Protected (1+1), Space

Diversity, 2+0/2+2 XPIC, N+0, N+1
• XPIC and CCDP – Built-in XPIC (Cross Polarization Interference Canceller) and
Co-Channel Dual Polarization (CCDP) feature for double transmission capacity,
and more bandwidth efficiency
• Power Saving Mode option - Enables the microwave system to automatically
detect when link conditions allow it to use less power (for RFU-HP)
• Tx Range (Manual/ATPC) – The dynamic TX range with ATPC is the same as
the manual TX range, and depends on the RFU type, the frequency, and the
ACM profile. The maximum TX power with ATPC is no higher than the
maximum manually configured TX power.
• ATPC (Automatic Tx Power Control)
• RF Channel Selection – Via EMS/NMS
• NEBS – Level 3 NEBS compliance
Page 126 of 468

4.8.2 1500HP/RFU-HP Functional Block Diagram and Concept of Operation

The RFU handles RF signal processing. The RFU encompasses the RF transmitter
and receiver with all their related functions.
The 1500HP/RFU-HP product line was designed to answer the need for a high
power RF module together with IF combining functionality and the ability to
concatenate several carriers with minimal RF branching loss.
This section briefly describes the basic block diagrams for the various types of
RFUs included in the 1500HP/RFU-HP product line.
Antenna
TX Board
OCB main
VCO
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.)
Figure 82: 1500HP 2RX in 1+0 SD Configuration
Page 127 of 468

Antenna
TX Board
OCB main
VCO
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.)
Figure 83: 1500HP 1RX in 1+0 SD Configuration
Antenna
OCB main
VCO
TX
350MHz IF
TX
TX Pre-
RFIC PA
chain Amp
C C
(BMA conn.)
o o
IDU
FSK Controller and

peripherals
n n DC / CTRL
Quadplexer
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.)
Figure 84: RFU-HP 1RX in 1+0 SD Configuration
Each of these RFU types must be connected to an OCB (Outdoor Circulator Block)
which serves as both a narrow diplexer and a mediation device to facilitate
antenna connection.

• 1500HP/RFU-HP OCBs
Page 128 of 468

4.8.3 1500HP/RFU-HP Comparison Table

The following table summarizes the differences between the 1500HP 2RX and 1RX
and the RFU-HP.
Table 47: 1500HP/RFU-HP Comparison Table
Feature 1500HP 2RX 1500HP 1RX RFU-HP Notes
Frequency Bands 6L,6H,7,8,11GHz 11 GHz 6L,6H,7,8GHz

Support
Channel Spacing Up to 40 MHz Up to 40 MHz Up to 56
Support MHz
Split-Mount √ √ √ All are compatible
with OCBs from both
generations
All-Indoor √ √ √ All are compatible
with ICBs
Space Diversity BBS and IFC BBS BBS IFC - IF Combining
BBS - Base Band
Switching
Frequency Diversity √ √ √
1+0/2+0/1+1/2+2 √ √ √
N+1 √ √ √
N+0 ( N>2) √ √ √
High Power √ √ √
Remote Mount √ √ √
Antenna
Power Saving Mode -- -- √ Power consumption
changes with TX
power
Note that the main differences between the 1500HP 1RX and RFU-HP 1RX are:
• The RFU-HP offers full support for 3.5M-56MHz channels.
• The RFU-HP supports the green-mode feature
Both systems are fully compatible with all OCB and ICB devices.
Page 129 of 468

4.8.4 1500HP/RFU-HP System Configurations
4.8.4.1 Split Mount and All indoor

The 1500HP/RFU-HP radios can be installed either in split mount or in all indoor
configurations.
The following configurations are applicable for Split-Mount or all indoor
installations:
• Unprotected N+0 - 1+0 to 10+0 – Data is transmitted through N channels,
without redundancy (protection)
• Hot Standby - 1+1 HSB, 2+2 HSB – Two RFUs use the same RF channel
connected via an asymmetrical coupler. One channel transmits (Active) and
the other acts as a backup (Standby). A 2+2 HSB configuration uses two RFUs
which are chained using two frequencies and connected via an asymmetrical
coupler to the other pair of RFUs.
• Protected N+0 – (2+0 to 8+0) with Frequency Diversity – Data is transmitted
through N channels. If failure or signal degradation occurs in one of the N
channels, traffic is distributed across the remaining channel. Additional
configurations, such as 14+2, can be achieved using two racks.
Notes:
• Space Diversity can be used in each of the configurations with RFU-HP 2RX.
• When the 1500HP/RFU-HP is mounted in a Split-Mount configuration, up to five
RFUs can be chained on one pole mount
• Up to 10 carriers can be placed in an ETSI rack.19
• Compact assembly – up to two radio carriers in horizontal placement (without
a subrack).
Two types of branching options are available for all indoor configurations:
• Using ICBs – Vertical assembly, up to 10 carriers per rack (five carriers per
subrack)
• Using OCBs – Compact horizontal assembly, up to 2 carriers per subrack
4.8.5 Split Mount Configuration and Branching Network

For multiple carriers, up to five carriers can be cascaded and circulated together
to the antenna port.
Branching networks are the units which perform this function and route the
signals from the RFUs to the antenna. The branching network can contain multiple
OCBs or ICBs. When using a Split-Mount or All-Indoor compact (horizontal)
19
A 19” open rack can also be used, holding a single subrack with up to four or five radio carriers,
depending on the configuration.
Page 130 of 468

configuration, the OCB branching network is used. When using an All-Indoor

vertical configuration, the ICB branching network is used.
The main differences in branching concept between the OCB and the ICB relate to
how the signals are circulated.
• 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 131.
• 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.
Figure 85: All-Indoor Vertical Figure 86: Split-Mount Branching and

Branching All-Indoor Compact
4.8.5.1 1500HP/RFU-HP OCBs

The OCB (Outdoor Circulator Block) has the following main purposes:
• Hosts the circulators and the attached filters.
• Routes the RF signal in the correct direction, through the filters and
circulators.
Page 131 of 468

• Enables RFU connection to the Main and Diversity antennas.

1500HP and RFU-HP supports two types of OCBs:
• OCB (Older Type)
• OCB (Current Type)
Figure 87: Old OCB Figure 88: OCB
Note: This document describes the newer type OCB.

The OCB is optimized for configurations that do not use IFC Space Diversity. To
support IFC Space Diversity, a diversity block is added.
The OCB has only one type, and can be connected to an antenna via a flexible
waveguide.
The OCB connection is at the rear of the OCB. It includes proprietary accessories
(different than those used for the older OCB).
Each OCB has three waveguide ports: The In/Out port is located at the rear of the
OCB.
The OCB ports include:
• Tx port
• Rx Port
• Diversity port
If the system is not configured for diversity, all the relevant ports on the OCB must
be terminated using waveguide shorts. Unused Rx ports are terminated with a
waveguide termination.
Page 132 of 468

main
Antenna
OCB OCB
(back side) (back side)
Next Radio
diversity
Antenna
Next Radio
DCB
Front side
P2 P1
OCB-2 OCB-1
Circ. A
Circ. B
P2 P1
Div. Antenna Port Div. Ext. Port
Rear side
Figure 89: OCB and DCB Block Diagrams
Page 133 of 468

OCB components include the following:

RF Filters
RF Filters are used for specific frequency channels and Tx/Rx separation. The
filters are attached to the OCB, and each RFU contains one Rx and one Tx filter. In
an IFC Space Diversity configuration, each RFU contains two Rx filters (which
combine the IF signals) and one Tx filter. The filters can be replaced without
removing the OCB.
DCB (Diversity Circulator Block)
The DCB is an external block which is added for IFC Space Diversity configurations.
The DCB is connected to the diversity port and can chain two OCBs.
Asymmetrical Coupler Kit
The asymmetrical coupler kit is used for 1+1 Hot Standby (HSB) configurations.
Symmetrical Coupler Kit
The symmetrical coupler kit used for adjacent channel configurations for which
the adjacent channel OCBs are not supported.
Note: Asymmetrical and symmetrical couplers are not interchangeable.
Make sure to order the appropriate type of coupler for your
configuration.
U Bend
The U Bend connects the chained DCB (Diversity Circulator Block) in N+1/N+0
configurations.
S Bend
The S Bend connects the chained OCB (Outdoor Circulator Block) in N+1 /N+ 0
configurations.
Pole Mount Kit
The Pole Mount Kit can attach up to five OCBs and the RFUs to the pole. The kit
enables fast and easy pole mount installation.
Page 134 of 468

4.8.5.2 OCB Component Summary
Table 48: OCB Component Summary
Component Marketing Model Marketing Description Picture

Name
DCB DCBf DCB Diversity Block f GHz kit
Asymmetrical OCB-CPLR-f OCB Coupler f GHz

Coupler
Symmetrical OCB-CPLR_SYM-f OCB symmetrical Coupler fGHz

Coupler
U Bend DCB-UBend DCB Ubend connection f GHz
S Bend OCB-SBend OCB SBend connection f GHz
Pole Mount OCB-Pole Mount OCB-Pole Mount
Note: f= 6L, 6H, 7, 8, 11 GHz
4.8.5.3 Upgrade Procedure

The following components need to be added when upgrading from a 1+0 to an
N+1 Split-Mount configuration:
• • OCBs
• • RFUs
• • IDU/IDMs
• • Flexible waveguides
When adding RF channels or carriers, RFUs and OCBs with specific filters need to
be added as well.
The OCBs are chained together using couplers (for the same frequency) or
U bends/S bends (for different frequencies), in accordance with the specific
configuration.
Open ports on the OCBs are terminated with waveguide terminations.
Detailed upgrade procedure documents are available for specific configurations.
Please note that legacy OCBs can be upgraded and cascaded with the new OCB.
Page 135 of 468

4.8.6 1500HP/RFU-HP Models and Part Numbers

The following table lists and describes the available 1500HP/RFU-HP models. All
RFU models are suited to operate in indoor and outdoor environments.
Table 49: RFU Models – 1RX Units
RFU-HP-1R-6L RFU-HP 6LG 1Rx up to 56M SM / All Indoor

RFU-HP-1R-6H RFU-HP 6HG 1Rx up to 56M SM / All Indoor
RFU-HP-1R-7 RFU-HP 7G 1Rx up to 56M SM / All Indoor
RFU-HP-1R-8 RFU-HP 8G 1Rx up to 56M SM / All Indoor
15HPA-1R-RFU-11 1500HP 11G 1RX SM / All Indoor Up to 30 MHz
15HPA-1R-RFU-11w 1500HP 11G 1RX SM / All Indoor 40 MHz
Table 50: RFU Models – 2RX Units
15HPA-2R-RFU-6L 1500HP 6LG 2RX SM / All Indoor Up to 30 MHz

15HPA-2R-RFU-6Lw 1500HP 6LG 2RX SM / All Indoor 40 MHz
15HPA-2R-RFU-6H 1500HP 6HG 2RX SM / All Indoor Up to 30 MHz
15HPA-2R-RFU-6Hw 1500HP 6HG 2RX SM / All Indoor 40 MHz
15HPA-2R-RFU-7 1500HP 7G 2RX SM / All Indoor
15HPA-2R-RFU-8 1500HP 8G 2RX SM / All Indoor
15HPA-2R-RFU-11 1500HP 11G 2RX SM / All Indoor Up to 30 MHz
15HPA-2R-RFU-11w 1500HP 11G 2RX SM / All Indoor 40 MHz
Page 136 of 468

4.8.7 OCB Part Numbers

The following table presents the various RFU options and the configurations in
which they are used. This table is applicable for all OCB configurations (Split
Mount and Compact All Indoor).
Note: For adjacent channel configurations in which adjacent channel
OCBs are not supported, symmetrical couplers can be used to
connect the OCBs.
Table 51: OCB Part Numbers
Band CHBW IFC Adjacent Marketing Model
6, 7 and 8 28/30 MHz No No 15OCBf-xxxy-nn-L/H

GHz
No Yes 15OCBf-xxxy-nnA-L/H
Yes No 15OCBf-SD-xxxy-nn-L/H
Yes Yes 15OCBf-SD-xxxy-nnA-L/H
40 MHz No No 15OCBf-xxxy-40N-nn-L/H
No Yes 15OCBf-xxxy-40N-nnA-L/H
Yes No 15OCBf-SD-xxxy-40N-nn-L/H
Yes Yes 15OCBf-SD-xxxy-40N-nnA-L/H
56 MHz No No 15OCBf-xxxy-56N-nn-L/H
No No 15OCBf-xxxy-56N-n-m-L/H
11 GHz 28/30 MHz No No 15OCBf-xxxy-nn-L/H
Yes No 15OCBf-SD-xxxy-nn-L/H
40 MHz No No 15OCB11w-xxxy-nn-L/H
Yes No 15OCB11w-SD-xxxy-nn-L/H
Page 137 of 468

4.8.8 OCB Part Number Format

Place Holder in Possible Values Description and Remarks
Marketing Model
f 6L,6H,7,8,11
xxx 000-999 [MHz] TRS in MHz
Y A…Z Ceragon TRS block
designation
ZZZ Examples: Designation of the channels
1W3 – “Wide” filters covering channels 1-3 the OCB is covering
03 – Only channel 03, 28MHz channel
3-5 – 56MHz “Narrow” filters allowing
concatenation using OCBs covering channels 3
and 4.
03A – For Channel 03, 28 and 40 MHz adjacent
channels
H/L H or L Designating TX High and TX
low
Page 138 of 468

5. Activation Keys
This chapter describes IP-20N’s activation key model. IP-20N offers a pay as-you-
grow concept in which future capacity growth and additional functionality can be
enabled with activation keys. For purposes of the activation keys, each IP-20N
chassis is considered a distinct device, regardless of which cards are included in
the chassis. Each device contains a single unified activation key cipher.
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.
An HSB configuration requires the same set of activation keys for the active and
the protected radio carriers.

• Working with Activation Keys
• Demo Mode
• Activation Key Reclaim
• Activation Key-Enabled Features
5.1 Working with Activation Keys

Ceragon provides a web-based system for managing activation keys. This system
enables authorized users to generate activation keys, which are generated per
IDU serial number.
In order to upgrade an activation key, the activation key must be entered into the
IP-20N. The system checks and implements the new activation key, enabling
access to new capacities and/or features.
In the event that the activation-key-enabled capacity and feature set is exceeded,
an Activation Key Violation alarm occurs and the Web EMS displays a yellow
background and an activation key violation warning. After a 48-hour grace period,
all other alarms are hidden until the capacity and features in use are brought
within the activation key’s capacity and feature set.
5.2 Demo Mode

The system can be used in demo mode, which enables all features for 60 days.
Demo mode expires 60 days from the time it was activated, at which time the
most recent valid activation key cipher goes into effect. The 60-day period is only
counted when the system is powered up. Ten days before demo mode expires, an
alarm is raised indicating to the user that demo mode is about to expire.
Note: Demo mode does not include AES radio encryption functionality
unless a valid AES activation key has been applied for at least one
carrier when demo mode is activated.
Page 139 of 468

5.3 Activation Key Reclaim

If a customer needs to deactivate an IP-20 device, whether to return it for repairs
or for any other reason, the customer can reclaim the device’s activation key and
obtain a credit that can be applied to activation keys for other devices.
Where the customer has purchased upgrade activation keys, credit is given for the
full feature or capacity, not for each individual upgrade. For example, if the
customer purchased five capacity activation keys for 300M and later purchased
three upgrade activation keys to 350M, credit is given as if the customer had
purchased three activation keys for 350M and two activation keys for 300M.
Note: Activation Key Reclaim is only available for IP-20 devices running
CeraOS 9.2 or later.
5.4 Activation Key-Enabled Features

The default (base) activation key provides each carrier with a capacity of 10 Mbps.
In addition, the default activation key provides:
• A single management service, with MSTP available for this service.
• A Smart Pipe (L1) service per each GbE port covered by the activation key.
• A single 1 x GbE port for traffic.
• Unlimited Native TDM services (but no TDM pseudowire services)
• Full QoS with basic queue buffer management (fixed queues with 1 Mbit
buffer size limit, tail-drop only).
• LAG
• No synchronization
• No TCC redundancy
Note: As described in more detail below, a CET Node activation key
allows all CET service/EVC types including Smart Pipe, Point-to-
Point, and Multipoint, and MSTP for all services, as well as an
additional GbE traffic port for a total of 2 x GbE traffic ports.
Page 140 of 468

As your network expands and additional functionality is desired, activation keys

can be purchased for the features described in the following table.
Table 52: Activation Key Types
Marketing Model Type Description For Additional Information
Refer to Capacity Per Carrier Enables you to increase your system’s radio Capacity Summary
Activation Key Levels on capacity in gradual steps by upgrading your
page 144. capacity activation key level. Without a
capacity activation key, each carrier has a
capacity of 10 Mbps. Activation-key-
enabled capacity is available from 50 Mbps
to 650 Mbps. Each RMC or RIC can be
activation-key-enabled for a different
capacity.
SL-RFU-2nd-Core-Act. Per RFU Enables use of second carrier on a Unique MultiCore
MultiCore RFU-D. Architecture of RFU-D and
RFU-D-HP
SL-2nd-Core-Act-HP Per RFU Enables use of second carrier on a Unique MultiCore
MultiCore RFU-D-HP. Architecture of RFU-D and
RFU-D-HP
IP-20-SL-IDU-Radio-Port- Per RIC-D Enables use of the second RFU port on a Radio Interface Cards (RIC)
Act. RIC-D. 20
SL-LLF Per Device Enables you to use Link Loss Forwarding Automatic State Propagation
(LLF) with Automatic State Propagation and Link Loss Forwarding
(ASP). Without the activation key, only one
LLF ID can be configured. This means that
only one ASP pair can be configured per
radio interface or radio group.
SL-ACM Per Carrier Enables the use of Adaptive Coding and Adaptive Coding Modulation
Modulation (ACM) scripts. (ACM)
SL-MC-ABC Per Carrier21 Enables Multi-Carrier ABC. Hybrid Multi-Carrier
Adaptive Bandwidth Control
(Hybrid MC-ABC)
SL-Header-DeDuplication Per Carrier Enables the use of Header De-Duplication, Header De-Duplication
which can be configured to operate at L2
through L4.
20
In CeraOS 10.3, only one RFU port (RFU1) is available per RIC-D. This port is included with the default
activation key.
21
Note that STM-1-RST interfaces are not considered carriers and do not require an SL-MC-ABC
activation key.
Page 141 of 468

SL-XPIC Per Carrier Enables the use of Cross Polarization Cross Polarization
Interference Canceller (XPIC). Each carrier Interference Canceller (XPIC)
in the XPIC pair must be activation-key-
enabled.
SL-SD Per Carrier Enables the use of BBC Space Diversity for BBC Space Diversity
RFU-D and RFU-D-HP. A separate activation
key is required for each carrier in the Space
Diversity group. This means that for a single
2+0 SD link, four SD activation keys are
required for each side of the link.
SL-Encryption-AES256 Per Carrier Enables the use of AES-256 encryption for AES-256 Payload Encryption
full radio payload encryption. Note that:
• If no AES activation key is configured
for the unit and the user attempts to
enable AES on a radio carrier, in
addition to an Activation Key Violation
alarm the feature will remain inactive
and no encryption will be performed.
• After entering an AES activation key,
the user must reset the unit before AES
can be activated. Unit reset is only
necessary for the first AES activation
key. If AES activation keys are acquired
later for additional radio carriers, unit
reset is not necessary.
SL-GE-Port Per Port Enables the use of a TCC/LIC Ethernet Traffic Control Cards (TCC)
traffic port in GbE mode
(10/100/1000baseT or 1000baseX). An
activation key is required for each
additional Ethernet traffic port that is used
on the device, beyond the one GbE traffic
port that is enabled via the default
activation key. An activation key can be
installed multiple times with dynamic
allocation inside the unit to enable multiple
GbE ports.
Note: Two Ethernet ports are enabled in
FE mode (10/100baseT) by default without
requiring any activation key.
SL-10GE-Port Per Port Enables the use of the 10G optical interface Ethernet Line Cards (LIC-X)
on an LIC-X-E10.
Page 142 of 468

Refer to CET Node Per Device Enables Carrier Ethernet Transport (CET) • Ethernet Service Model
Activation Key Levels on and a number of Ethernet services (EVCs), • Quality of Service (QoS)
page 146. depending on the type of CET Node
activation key:
• Edge CET Node – Up to 8 EVCs.
• Aggregation Level 1 CET Node – Up to
64 EVCs.
• Aggregation Level 2 CET Node – Up to
1024 EVCs.
A CET Node activation key also enables the
following:
• A GbE traffic port in addition to the
port provided by the default activation
key, for a total of 2 GbE traffic ports.
• Network resiliency (MSTP/RSTP) for all
services.
• Full QoS for all services including basic
queue buffer management (fixed
queues buffer size limit, tail-drop only)
and eight queues per port, no H-QoS.
SL-Network-Resiliency Per Device Enables the following protocols for Network Resiliency
improving network resiliency:
• G.8032
• TDM Services 1:1/1+1 path protection
SL-H-QoS Per Device Enables H-QoS.22 This activation key is Quality of Service (QoS)
required to add service-bundles with
dedicated queues to interfaces. Without
this activation key, only the default eight
queues per port are supported.
SL-Enh-Packet-Buffer Per Device Enables configurable (non-default) queue Quality of Service (QoS)
buffer size limit for Green and Yellow
frames. Also enables WRED. The default
queue buffer size limit is 1Mbits for Green
frames and 0.5 Mbits for Yellow frames.
SL-Sync-Unit Per Device Enables the G.8262 synchronization unit. Synchronization
This activation key is required in order to
provide end-to-end synchronization
distribution on the physical layer. This
activation key is also required to use
Synchronous Ethernet (SyncE).
22
H-QoS support is planned for future release.
Page 143 of 468

SL-IEEE-1588-TC Per Device Enables IEEE-1588 Transparent Clock. IEEE-1588v2 PTP Optimized
Transport
SL-IEEE-1588-BC Per Device Enables IEEE-1588 Boundary Clock. IEEE-1588v2 PTP Optimized
Transport
SL-Frame-Cut-Through Per Device Enables Frame Cut-Through. Frame Cut-Through
SL-Main-Card- Per Device Enables the use of a second TCC in a 2RU TCC Redundancy
Redundancy chassis for TCC Redundancy.
SL-TDM-PW Per Device Enables TDM pseudowire services on units TDM Pseudowire Services
with TDM interfaces. Without this
activation key, only native TDM services are
supported.
SL-Secure-Management Per Device Enables secure management protocols Secure Communication
(SSH, HTTPS, SFTP, SNMPv3, and RADIUS). Channels
SL-Eth-OAM-FM Per Device Enables Connectivity Fault Management Connectivity Fault
(FM) per Y.1731 (CET mode only). Management (FM)
SL-Eth-OAM-PM Per Device Enables performance monitoring pursuant
to Y.1731 (CET mode only).23
SL-LACP Per Device Enables Link Aggregation Control Protocol Link Aggregation Groups
(LACP). (LAG) and LACP
Table 53: Capacity Activation Key Levels
Marketing Model Description Notes
SL-Capacity-50M IP-20 SL - Capacity 50M, per carrier

23
PM support is planned for future release.
Page 144 of 468

Marketing Model Description Notes

SL-Capacity-1G IP-20 SL - Capacity 1G RFU-E only.
SL-Capacity-1.6G IP-20 SL - Capacity 1.6G RFU-E only. Max capacity for RFU-E using 250MHz
SL-Capacity-2G IP-20 SL - Capacity 2G RFU-E only.
SL-Capacity-2.5G IP-20 SL - Capacity 2.5G RFU-E only. Max capacity for RFU-E using 500MHz
SL-Upg-50M-100M IP-20 SL - Upg 50M - 100M, per carrier
SL-Upg-650M-1G IP-20 SL - Upg 650M - 1G
SL-Upg-1G-1.6G IP-20 SL - Upg 1G - 1.6G
SL-Upg-1.6G-2G IP-20 SL - Upg 1.6G - 2G
SL-Upg-2G-2.5G IP-20 SL - Upg 2G - 2.5G
Page 145 of 468

Table 54: CET Node Activation Key Levels
Marketing Model # of Bundled GbE Management # of Pipe (L1) # of CET (L2) # of Native
Ports for User Service Ethernet Services Ethernet Services24 TDM Services
Traffic
Default (No Activation Key) 1 Yes Unlimited - 512

SL-Edge-CET-Node 2 Yes Unlimited 8 512
SL-Agg-Lvl-1-CET-Node 2 Yes Unlimited 64 512
SL-Agg-Lvl-2-CET-Node 2 Yes Unlimited 1024 512
If a CET activation key is not generated on the IP-20 device upon initial configuration,
the device uses by default a base smart pipe activation key (SL-0311-0). If the
operator later wants to upgrade from the base smart pipe activation key to a CET
activation key, the customer must simply choose the appropriate activation key from
the options listed in Table 54.
24
Including Point-to-Point, Multipoint, and TDM Pseudowire services. An SL-TDM-PW activation key is
also required to enable TDM Pseudowire services.
Page 146 of 468

6. Feature Description
This chapter describes the main IP-20N features. The feature descriptions are
divided into the categories listed below.

• Innovative Techniques to Boost Capacity and Reduce Latency
• Radio Features
• Ethernet Features
• Synchronization
• TDM Services
• Radio Payload Encryption and FIPS
Page 147 of 468

6.1 Innovative Techniques to Boost Capacity and Reduce Latency

IP-20N utilizes Ceragon’s innovative technology to provide a high-capacity low-
latency solution. IP-20N’s Header De-Duplication option is one of the innovative
techniques that enables IP-20N to boost capacity and provide operators with
efficient spectrum utilization, with no disruption of traffic and no addition of
latency.
IP-20N also utilizes established Ceragon technology to provide low latency
representing a 50% latency reduction for Ethernet services compared to the
industry benchmark for wireless backhaul.
Another of Ceragon’s innovative features is Frame Cut-Through, which provides
unique delay and delay-variation control for delay-sensitive services. Frame Cut-
Through enables high-priority frames to bypass lower priority frames even when
the lower-priority frames have already begun to be transmitted. Once the high-
priority frames are transmitted, transmission of the lower-priority frames is
resumed with no capacity loss and no re-transmission required.
This section includes:

• Capacity Summary
• Unique MultiCore Architecture of RFU-D and RFU-D-HP
• Header De-Duplication
• Latency
• Frame Cut-Through
Page 148 of 468

6.1.1 Capacity Summary

Each carrier in an IP-20N chassis provides the following capacity:
• Supported Microwave Channels – 3.5/7/14/28/40/56/80/112 MHz channels.
• Supported E-Band Channels – 14/28/62.5/125/250/500 MHz channels.
• Microwave Frequency Bands – 4, 5, L6, U6, 7, 8, 10, 11, 13, 15, 18, 23, 26, 28,
32, 38, 42 GHz
• E-Band Frequency Bands – 71-76 GHz, 81-86 GHz
• High scalability – From 10 Mbps to 2.5 Gbps, using the same hardware.
• Modulations
 RIC-D with Microwave – BPSK to 4096 QAM
 RIC-D with E-Band – BPSK to 1024 QAM
 RMC-A – QPSK to 256 QAM
 RMC-B – QPSK to 2048 QAM

• Radio Capacity Specifications
Page 149 of 468

6.1.2 Unique MultiCore Architecture of RFU-D and RFU-D-HP

RFU-D and RFU-D-HP are MultiCore microwave radios. MultiCore radio
architecture marks the beginning of a new era in wireless communications,
boosting microwave to new levels of capacity previously reserved to fiber optic
cable.
RFU-D and RFU-D-HP’s unique MultiCore radio architecture is based on an
advanced parallel radio processing engine built around Ceragon’s proprietary
baseband modem and RFIC chipsets. This architecture is optimized for parallel
processing of multiple radio signal flows, and enables RFU-D and RFU-D-HP to
multiply capacity and increase system gain in comparison with current
technology.
Utilizing common processing resources at the kernel of the radio terminal, the
MultiCore system reduces power consumption and maintains a small form-factor.
This makes RFU-D/RFU-D-HP an advantageous choice for deployment in
numerous heterogeneous network scenarios, such as small cells and fronthaul.
Figure 90: RFU-D/RFU-D-HP MultiCore Modem and RFIC Chipsets
RFU-D/RFU-D-HP’s parallel radio processing engine is what differentiates RFU-

D/RFU-D-HP from other multiple-core solutions, which are really nothing more
than multiple radio systems compacted into a single box. RFU-D/RFU-D-HP’s
MultiCore architecture enables RFU-D/RFU-D-HP to provide significant
improvements in capacity and link distance, as well as low power consumption,
smaller antennas, more efficient frequency utilization, less expensive frequency
use, and a small form factor.
Page 150 of 468

6.1.2.1 Radio Script Configuration for Multiple Cores

When operating with two cores in a single RFU-D/RFU-D-HP RFU, users can
configure different scripts independently for each carrier. Configuring a script in
one core has no impact on the other carrier’s traffic. When the carrier is reset
following configuration of a script in that carrier, only that carrier is reset
following the script’s configuration. No general reset is performed.
During script configuration, the core being configured is set to mute. The mute is
released once the script configuration is completed.
6.1.2.2 Flexible Operating Modes with MultiCore Architecture

RFU-D/RFU-D-HP’s MultiCore architecture is inherently versatile and suitable for
many different network deployment scenarios. An IP-20N node using RFU-D/RFU-
D-HP can operate as a high-capacity, single-carrier solution. At any time in the
network’s growth cycle, the second carrier can be activated remotely for
optimized performance.
To illustrate the many advantages of RFU-D/RFU-D-HP’s MultiCore architecture,
consider a generic, 1+0 single-carrier radio with high performance in terms of
capacity, link distance, and antenna size.
Figure 91: Performance Characteristics of Generic, 1+0 Single-Carrier Radio
RFU-D/RFU-D-HP can operate in single-carrier mode, with similar parameters to a

standard radio, but with additional capacity due to its ability to operate at
4096 QAM modulation.
Activating the second carrier does not simply double the capacity of the RFU-
D/RFU-D-HP, but rather, provides a package of options for improved performance
that can be utilized in a number of ways, according to the requirements of the
specific deployment scenario.
Doubling the Capacity

Turning on the RFU-D/RFU-D-HP ‘s second core automatically doubles the RFU’s
capacity. This doubling of capacity is achieved without affecting system gain or
availability, since it results from the use of an additional core with the same
modulation, Tx power, and Rx sensitivity. The RFU-D/RFU-D-HP also maintains the
same small form-factor. Effectively, activating the second core provides a pure
doubling of capacity without any tradeoffs.
Page 151 of 468

Figure 92: Doubling RFU-D/RFU-D-HP’s Capacity by Activating Second Core
Doubling the Link Distance

The increased performance that RFU-D/RFU-D-HP’s MultiCore architecture
provides can be leveraged to increase link distance. An IP-20N node with an RFU-
D/RFU-D-HP can split the bitstream between the two cores of the RFU using
Multi-Carrier Adaptive Bandwidth Control (ABC). This makes it possible to utilize a
lower modulation scheme that significantly increases system gain for Tx power
and Rx sensitivity. This enables the node to support longer signal spans, enabling
operators to as much as double their link spans.
For example, consider an RFU-D/RFU-D-HP in a 1+0 configuration with only one
core activated, transmitting 280 Mbps over a 28 MHz channel with 4096 QAM
modulation. Activating the second core makes it possible to reduce the
modulation to 64 QAM and maintain the same capacity of 280 Mbps, consisting of
2 x 140 Mbps over the 28 MHz channel. Reducing the modulation from 4096 QAM
to 64 QAM delivers a 5 dB improvement in Tx power and an 18 dB improvement
in Rx sensitivity, for a total increase of23 dB in system gain. This improved system
gain enables the operator to double the link distance.
Reducing Antenna Size by Half

The increased system gain that RFU-D/RFU-D-HP’s antenna size by as much as
half. In general, each doubling of antenna size on one side of the link translates
into 6dB in additional link budget. The 23 dB increase in system gain that RFU-
D/RFU-D-HP’s MultiCore architecture can provide can be exploited to halve the
antenna size. This uses 12dB of the 23 dB system gain, leaving 11 dB to further
reduce antenna size on either side of the link. This enables the operator to realize
CAPEX savings from the MultiCore deployment.
Frequency Decongestion and Lower License Fees

Another way in which the increased system gain that RFU-D/RFU-D-HP’s
MultiCore architecture makes possible can be leveraged is by taking advantage of
the increased system gain to shift from congested and expensive frequency bands
to uncongested and less costly higher frequency bands. The loss in link budget
incurred by moving to higher frequencies is absorbed by the increased system
gain provided by RFU-D/RFU-D-HP’s MultiCore architecture. Relatively long-span
links, which previously required operation in lower, more congested, and more
Page 152 of 468

expensive frequencies such as 6, 7, and 8 GHz, can be shifted to higher, less

congested, and less expensive frequency bands such as 11 GHz with the help of
RFU-D/RFU-D-HP’s MultiCore architecture.

• Cross Polarization Interference Canceller (XPIC)
6.1.2.3 TCO Savings as a Result of MultiCore Architecture

The various ways described above in which RFU-D/RFU-D-HP’s MultiCore
architecture can be leveraged to provide additional capacity, longer link distances,
and smaller antenna side, all carry significant cost savings for operators.
Consider the common and practical scenario of a 1+0 link that must be upgraded
to MultiCore 2+0 in order to accommodate growing demand for capacity. For a
single-carrier node, the upgrade is a complicated process that requires:
• Purchasing a new radio unit.
• Sending an installation team to the site.
• Dismantling the existing radio unit.
• Replacing the single-mount radio-antenna interface with a coupler (for single
polarization) or OMT (for dual polarization) to accommodate the two units.
• Re-installing the original radio unit along with the new radio unit.
• Connecting both radios to a switch in order to provide Layer 2 link aggregation
(LAG), necessary to achieve a MultiCore 2+0 link.
These steps incur a high initial cost for re-installing and re-configuring the link, as
well as high site leasing fees due to the additional equipment required, the larger
footprint, and additional ongoing power consumption. The upgrade process
involves hours of link down-time, incurring loss of revenue and impaired customer
Quality of Experience (QoE) throughput the upgrade process. During its lifetime,
the upgraded 2+0 single-carrier system will consume 100% more power than the
1+0 system and will be virtually twice as likely to require on-site maintenance.
With IP-20N using RFU-D/RFU-D-HP, network operators can initially install the
MultiCore RFU-D/RFU-D-HP RFU in single-carrier mode, with enough network
capacity to meet current needs and the ability to expand capacity on the fly in the
future. When an upgrade to MultiCore 2+0 becomes necessary, the operator
merely needs to perform the following steps:
• Purchase an activation key for the second core.
• Remotely upload the activation key and activate the second core.
No site visits are required, and virtually no downtime is incurred, enabling
customers to enjoy continuous, uninterrupted service. No additional switch is
necessary, because IP-20N can use Multi-Carrier ABC internally between the two
cores to utilize the multi-channel capacity, in a much more efficient manner than
with Layer 2 LAG. Network operators benefit from much lower power
consumption than 2+0 systems made up of separate, single-carrier radio units,
and site leasing fees do not increase since no additional hardware is required.
Page 153 of 468

The following table summarizes the cost benefits of RFU-D/RFU-D-HP’s MultiCore

technology in terms of TCO.
Table 55: TCO Comparison Between Single-Carrier and MultiCore Systems
Single-Carrier system MultiCore system
Initial Installation 1+0 link with 1+0 antenna mediation device 2+0 installation (remote or direct mount). Only
(remote or direct mount). one core has an activation key and is activated.
Upgrade to 2+0 • Obtain new radio equipment • Obtain activation key for second core.
• Send technical team to both ends of • Activate second core remotely.
the link (at least two site visits). • Remotely define the link as 2+0 with L1
• Dismantle existing radio and mediation Multi-Carrier ABC (more efficient than
device. LAG).
• Install new mediation device (OMT or
splitter).
• Re-install old radio with new radio.
• Obtain and install Ethernet switch for
2+0 L2 LAG.
Downtime Hours of downtime for complete Negligible downtime.
reconfiguration of the link.
Negative impact on end-user QoE.
Power 100% more than 1+0 link (even more with Only 55% more power consumption than 1+0
consumption external switch). configuration (single core).
Site leasing fees Approximately double, since equipment is No impact, MultiCore system within same
doubled. small form factor unit
Warehouse Complicated, with different equipment for Simple with single-spare, versatile radio for
management different deployment scenarios many deployment scenarios.
(standard/high power, low/high capacity).
Page 154 of 468

6.1.3 Header De-Duplication

IP-20N offers the option of Header De-Duplication, enabling operators to
significantly improve Ethernet throughput over the radio link without affecting
user traffic. Header De-Duplication can be configured to operate on various layers
of the protocol stack, saving bandwidth by reducing unnecessary header
overhead. Header De-duplication is also sometimes known as header
compression.
Note: Without Header De-Duplication, IP-20N still removes the IFG and
Preamble fields. This mechanism operates automatically, even if
Header De-Duplication is not selected by the user.
Figure 93: Header De-Duplication
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.
Page 155 of 468

• Tunnel-Layer4 – Header De-Duplication operates on Layer 2, Layer 3, and on

the Tunnel, T-3, and T-4 layers for packets carrying GTP or GRE frames.
Operators must balance the depth of De-Duplication against the number of flows
in order to ensure maximum efficiency. Up to 256 concurrent flows are
supported.
The following graphic illustrates how Header De-Duplication can save up to 148
bytes per frame.
IP-20N
Layer 2 | Untagged/C/S Tag/Double Tag

Up to 22 bytes compressed
Layer 2.5 | MPLS: up to 7 Tunnels (Untagged/C-Tag)

Up to 28 bytes compressed
Layer 3 | IPv4/IPv6
18/40 bytes compressed
Layer 4 | TCP/UDP
Tunneling Layer | GTP (LTE) / GRE

6 bytes compressed
End User Inner Layer 3 | IPv4/IPv6

End User Inner Layer 4 | TCP/UDP

End User
Figure 94: Header De-Duplication Potential Throughput Savings per Layer
Depending on the packet size and network topology, Header De-Duplication can
increase capacity by up to:
• 50% (256 byte packets)
Page 156 of 468

6.1.3.1 Header De-Duplication Counters

In order to help operators optimize Header De-Duplication, IP-20N provides
counters when Header De-Duplication is enabled. These counters include real-
time information, such as the number of currently active flows and the number of
flows by specific flow type. This information can be used by operators to monitor
network usage and capacity, and optimize the Header De-Duplication settings. By
monitoring the effectiveness of the Header De-Duplication settings, the operator
can adjust these settings to ensure that the network achieves the highest possible
effective throughput.
6.1.4 Latency
IP-20N provides best-in-class latency (RFC-2544) for all channels, making it the
obvious choice for LTE (Long-Term Evolution) networks.
IP-20N’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
Page 157 of 468

6.1.5 Frame Cut-Through
Related topics:
• 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.
Figure 95: Propagation Delay with and without Frame Cut-Through
Page 158 of 468

6.1.5.1 Frame Cut-Through Basic Operation

Using Frame Cut-Through, frames assigned to high priority queues can pre-empt
frames already in transmission over the radio from other queues. Transmission of
the preempted frames is resumed after the cut-through with no capacity loss or
re-transmission required. This feature provides services that are sensitive to delay
and delay variation, such as VoIP and Pseudowires, with true transparency to
lower priority services, by enabling the transmission of a high-priority, low-delay
traffic stream.
Frame 4 Frame 4
Frame 1 Frame 2 Frame 3 Frame Cut-Through Frame 5
Start End
Figure 96: Frame Cut-Through
When enabled, Frame Cut-Through applies to all the high priority frames, i.e., all
frames that are classified to a CoS queue with 4th (highest) priority.
Figure 97: Frame Cut-Through Operation
Page 159 of 468

6.2 Radio Features

This chapter describes the main IP-20N radio features.
Multi-Carrier ABC enables separate radio carriers to be shared by a single
Ethernet port. This provides an Ethernet link over the radio with multiple capacity,
while still behaving as a single Ethernet interface.
Ceragon was the first to introduce hitless and errorless Adaptive Coding
Modulation (ACM) to provide dynamic adjustment of the radio’s modulation. ACM
shifts modulations instantaneously in response to changes in fading conditions. IP-
20N utilizes Ceragon’s advanced ACM technology, and extends it to the range of
BPSK to 4096 QAM when using RFU-S, RFU-D, or RFU-D-HP, and BPSK to 1024
QAM when using RFU-E.
IP-20N also supports Cross Polarization Interference Canceller (XPIC). XPIC enables
operators to double their capacity by utilizing dual-polarization radio over a
single-frequency channel, thereby transmitting two separate carrier waves over
the same frequency, but with alternating polarities.
The MultiCore RFU-D and RFU-D-HP support multiple-carrier features such as
Multi-Carrier ABC and XPIC, utilizing their two radio carriers to enable links of up
to 8+0 with only four slots.

• Hybrid Multi-Carrier Adaptive Bandwidth Control (Hybrid MC-ABC)
• Space Diversity
• HSB Protection
• Adaptive Coding Modulation (ACM)
• ATPC
• Radio Signal Quality PMs
• Radio Utilization PMs
Page 160 of 468

6.2.1 Hybrid Multi-Carrier Adaptive Bandwidth Control (Hybrid MC-ABC)

Hybrid Multi-Carrier Adaptive Bandwidth Control (Hybrid MC-ABC) is an
innovative technology that creates logical bundles of multiple radio links
optimized for wireless backhaul applications. Hybrid Multi-Carrier ABC enables
separate radio carriers to be combined into a virtual transport pipe for a high
capacity Ethernet link and individual TDM links. Both the Ethernet link and the
TDM links will be available over radios with individual variable capacity, and
handled by a prioritizing scheme.
In Hybrid Multi-Carrier ABC mode, traffic is split over the available carriers
optimally at the radio frame level irrespectively of the traffic type.
For Ethernet traffic, Hybrid MC-ABC eliminates the need for Ethernet link
aggregation (LAG). Load balancing is performed regardless of the number of MAC
addresses or number of traffic flows.
During fading events which cause ACM modulation changes, each carrier
fluctuates independently with hitless switchovers between modulations,
increasing capacity over a given bandwidth and maximizing spectrum utilization.
In such conditions, the TDM links can be preserved by a sophisticated prioritizing
scheme configured by the user. The result is 100% utilization of radio resources in
which traffic load is balanced based on instantaneous radio capacity per carrier.
Page 161 of 468

6.2.1.1 TCC and RFU-Based Multi-Carrier ABC

Multi-Carrier ABC can be implemented via the TCC or the RFU.
• For RMC-B, Multi-Carrier ABC is always implemented via the TCC.
• For RIC-D, 2+0 Multi-Carrier ABC can be implemented via the TCC or the RFU.
RFU-based Multi-Carrier ABC utilizes the two radios in a MultiCore RFU-D or RFU-
D-HP. It is supported from CeraOS 10.0, and can be used with any TCC.
TCC-based Multi-Carrier ABC requires TCC-B-MC or TCC-B2-XG-MC. Multiple
groups in a single unit and high-capacity groups require TCC-B2-XG-MC. For RIC-D
cards, TCC-based Multi-Carrier ABC requires CeraOS 10.5 or higher and TCC-B2-
XG-MC. The Multi-Carrier ABC processing is performed in the TCC, as shown in the
following diagram.
TCC
Service Engine
Ethernet Interface
IF
RMC-B or Eth LIC Ethernet Interface
RIC-D
Ethernet Interface
Network Processor Ethernet Interface
IF
RMC-B or Ethernet Interface
RIC-D
Hybrid
Multicarrier ABC PW
TDM E1/CH-STM1
Engine E1
LIC
Srv
TDM Crossconnect
E1 Services
PW
TDM E1/CH-STM1
E1
Srv
LIC
STM1- STM1-RST
RST LIC
RMC-B or
IF
RIC-D STM1-
RST LIC
STM1- STM1-RST
RST LIC
Figure 98: TCC-Based Multi-Carrier ABC Traffic Flow
6.2.1.2 Multi-Carrier ABC with RIC-D

The following restrictions apply to TCC-based Multi-Carrier ABC with RIC-D cards:
• The RIC-D cards must be placed in Slots 3, 4, 5, and/or 6. This is true for both
1RU and 2RU chassis.
• As with RMC-B, a TCC-based Multi-Carrier ABC group with RIC-D cards can
include up to eight radio and STM1/OC3-RST members in total.
Note: LIC-STM1/OC3-RST cards cannot be used in RFU-based Multi-
Carrier ABC groups.
Page 162 of 468

• The maximum Ethernet capacity of a TCC-based Multi-Carrier ABC group is 2.5

Gbps.
• The total aggregated radio capacity of all the carriers in a TCC-based Multi-
Carrier ABC group cannot exceed 3 Gbps.
If you want to use one or more 2+0 Multi-Carrier ABC groups with RFU-D or
RFU-D-HP, TCC-based and RFU-based Multi-Carrier ABC each have certain
advantages:
• TCC-based Multi-Carrier ABC enables you to use LIC-STM1/OC3-RST cards with
the group. These cards cannot be used with RFU-based Multi-Carrier ABC.
• RFU-based 2+0 Multi-Carrier ABC groups can have capacity of up to 2.5 Gbps,
whereas TCC-based 2+0 Multi-Carrier ABC groups have capacity of up to 1.2
Gbps. For more details about high-capacity Multi-Carrier ABC groups, see Slot
Sections and 2.5 Gbps Mode on page 53.
For a full comparison between the advantages and requirements of TCC-based
and RFU-based Multi-Carrier ABC, see Table 56: RIC-D Multi-Carrier ABC – RFU-
Based vs. TCC-Based.
The following table sets forth the differences between RFU-based and TCC-based Multi-Carrier ABC.
Table 56: RIC-D Multi-Carrier ABC – RFU-Based vs. TCC-Based
RFU-Based Multi-Carrier ABC TCC-Based Multi-Carrier ABC
Supported Configurations Up to 4 X 2+0 Up to 4 X 2+0, Up to 2 X 4+0, Up to 8+0

Supported RFUs RFU-D, RFU-D-HP RFU-D, RFU-D-HP
Minimum CeraOS Version 10.0 10.5
TCC Requirement Any TCC TCC-B2-XG-MC
XPIC Support Yes Yes
Permitted Slots Any slot that supports RIC-D 3, 4, 5, 6
LIC-STM1/OC3-RST No Yes, up to a limit of 8 total radio carriers and
RST cards. For example, a group that includes
2 LIC-STM1/OC3-RST cards cannot include
more than 6 radio carriers.
Maximum Group Capacity 2.5 Gbps 1.2 Gbps for 2+0 groups. For larger groups, up
to 2.5 Gbps.
Page 163 of 468

6.2.1.3 Multi-Carrier Configurations

In Hybrid MC-ABC mode, IP-20N supports the following configurations. For a
detailed list of configurations supported by each RFU, see Supported IP-20N Radio
Configurations on page 33.
• Supported with both TCC-B-MC and TCC-B2-XG-MC, and RMC-B:
 1 X up to 8+0 Multi-Carrier ABC (2RU chassis)
 1 X 4+0 Multi-Carrier ABC (1RU chassis)
 1 X 1+1 HSB Protection with BBS Space Diversity
 1 X 2+2 Multi-Carrier ABC with HSB Protection and BBS Space Diversity
 1 X 2+0 Multi-Carrier ABC Frequency Diversity
• Supported with TCC-B2-XG-MC only:
 2 X 2+0 Multi Carrier ABC (1RU chassis)
 4 X 1+1 HSB Protection with BBS Space Diversity (2RU chassis)
 2 X 1+1 HSB Protection with BBS Space Diversity (1RU chassis)
 2 X 2+0 BBC Space Diversity
 2 X 4+0 BBC Space Diversity
• Supported with RIC-D and all TCCs, using two carriers in a single MultiCore
RFU (RFU-D or RFU-D-HP):
 4 X 2+0 (XPIC)
 4 X 1+1 HSB/SD25
Note: When using more than one Multi-Carrier ABC group, LIC-
STM1/OC3-RST cards can only be assigned to Multi-Carrier ABC
Groups 1 and 3.
6.2.1.4 Multi-Carrier ABC Operation

The MC-ABC engine divides the data flows into blocks of data. Each radio carrier is
assigned blocks at a rate which is based on the ACM profile of the carrier. Once
the ACM profile of a carrier changes, the rate at which the data blocks are
delivered to this carrier changes. The higher the ACM profile of a certain carrier,
the higher the block rate assigned to this carrier.
On the receiving side of the link, all blocks are synchronized, meaning that blocks
are delayed based on the last arriving block. The latency of the aggregated data
flow is determined by the slowest arriving block.
25
4 X 1+1 HSB/SD is planned for future release.
Page 164 of 468

A low ACM profile means more latency compared to a higher ACM profile. When
all channels run the same radio script, the latency variation for the aggregated
data stream is determined by the latency variation of one radio channel. This
latency variation is slightly more complicated to predict when the radio carriers
runs at different radio scripts, since each radio script has a unique delay
distribution. Multi-Carrier ABC can tolerate a large delay variance between the
slowest and the fastest arriving blocks.
6.2.1.5 Graceful Degradation of Service

Multi-Carrier ABC provides graceful degradation and protection of service in the
event of RFU failure or carrier fading. In the case of carrier fading, the system
reduces the number of data blocks assigned to this carrier, until the carrier losses
the connection with the other end of the link. In this case, no data blocks will be
assigned to this carrier. In case of sudden hardware failure, only data in data
blocks that have already been transferred to the radio will be lost. Once the
carrier is lost, the system will stop assigning data blocks to this carrier.
The system determines which radio carriers contribute to the aggregated MC-ABC
link, based on the received channel qualities. Other criteria, such as ACM profile
and latency, are also considered. Adding or removing a carrier is hitless.
When all carriers are up and running, MC-ABC provides the maximum available
aggregated capacity. Even when one or more carriers are operating at limited
capacity or are totally down, the data path remains error free. In the event of
degradation in a particular carrier, the carrier is removed from the aggregated link
before bit errors occur, so the aggregated data flow is hitless.
6.2.1.6 Multi-Carrier ABC Minimum Bandwidth Override Option

A Multi-Carrier ABC group can be configured to be placed in Down state if the
group’s aggregated capacity falls beneath a user-defined threshold. This option is
used in conjunction with the LAG override option (see Link Aggregation Groups
(LAG) on page 237) in cases where the operator wants traffic from an upstream
switch connected to another IP-20 unit to be re-routed whenever the link is
providing less than a certain capacity.
External
Switch LAG
Ethernet Link Ethernet Link Multi-Carrier ABC Link
Upstream IP-20 Unit IP-20N
Alternate Link
Figure 99: Multi-Carrier ABC Minimum Bandwidth Override
Page 165 of 468

By default, the Multi-Carrier ABC minimum bandwidth override option is disabled.

When enabled, the Multi-Carrier ABC group is automatically placed in a Down
state in the event that the group’s aggregated capacity falls beneath the user-
configured threshold. The group is returned to an Up state when the capacity
goes above the threshold.
The Multi-Carrier ABC minimum bandwidth override option is available for both
TCC-based and RFU-based Multi-Carrier ABC. It is available with RMC-B and RIC-D,
but not with RMC-A.
The Multi-Carrier ABC minimum bandwidth override option can be used with TCC
protection, but not with HSB radio protection.
6.2.1.7 Multi-Carrier ABC and ACM

Multi-Carrier ABC automatically adapts to capacity changes that result from changes in
the current ACM profile. When an ACM profile change takes place on a specific carrier,
MC-ABC responds by changing the block size of that channel. The process of changing
the block size is performed dynamically and is hitless. Since the ACM profile changes are
also hitless, the overall Multi-Carrier ABC traffic is hitless.
6.2.1.8 Ethernet Traffic Handling

Ethernet traffic, either from the Ethernet LICs (LIC-X-E4-Elec, LIC-X-E4-Opt, or LIC-
X-10) or from the Ethernet ports on the TCC, are forwarded to the Network
Processor module on the TCC. The Network Processor implements the Ethernet
features described elsewhere in this document.
6.2.1.9 TDM Traffic Handling

Three types of TDM services are supported by the system:
• STM-1-RST Services
• Native E1 Trails
• E1 Pseudowire Services
STM-1 RST Traffic

The Hybrid MC-ABC engine converts the Native TDM trails into dedicated blocks.
These Native TDM blocks are assigned higher priority than standard blocks and
are transmitted first, giving high priority to the Native TDM traffic. In case of
decrease in the link performance, the Hybrid-MC-ABC continues to transmit
Native TDM blocks while blocking other types of traffic. This priority mechanism
ensures the high availability of Native TDM trails.
Native TDM trails are forwarded directly from the STM-1 RST interface to the
Hybrid-MC-ABC engine.
Hybrid MC-ABC requires that one side of the link be defined as the
synchronization source for STM-1 RST traffic.
Any cross connect of the SDH traffic should be done externally.
Page 166 of 468

Native E1 Trails
E1 services are implemented by the LIC-T16 or LIC-T155. The E1 services enable
use of the internal Cross Connect functionality of the system. E1 Service trails are
passed from the TDM LICs to the Cross Connect function of the system. From the
Cross Connect function of the system, the E1 service trails are forwarded to the
Hybrid MC-ABC with specific VC marking.
E1 Pseudowire Services
Pseudowire E1 services using LIC-T16 or LIC-T155 LICs are handled by the Hybrid
MC-ABC as Ethernet frames.
6.2.1.10 Frequency Diversity

In Hybrid Multi-Carrier ABC mode, traffic is split over the available carriers
optimally at the radio frame level irrespective of the traffic type. When using 2+0
MC-ABC, the link provides Frequency Diversity protection while having several
advantages over standard 1+1 Frequency Diversity configurations:
• Higher traffic resiliency in a fading environment
With a 1+1 FD link, throughput is limited by the link with the lowest
modulation. With 2+0 MC-ABC, the traffic is aggregated over the two carriers.
• Higher available capacity (combined capacity of the two carriers)
• Additional link resiliency when using Space Diversity (IFC) for each of the
carriers
Page 167 of 468

6.2.2 Space Diversity

In long distance wireless links, multipath phenomena are common. Both direct
and reflected signals are received, which can cause distortion of the signal
resulting in signal fade. The impact of this distortion can vary over time, space,
and frequency. This fading phenomenon depends mainly on the link geometry
and is more severe at long distance links and over flat surfaces or water. It is also
affected by air turbulence and water vapor, and can vary quickly during
temperature changes due to rapid changes in the reflections phase.
Fading can be flat or dispersive. In flat fading, all frequency components of the
signal experience the same magnitude of fading. In dispersive, or frequency
selective fading, different frequency components of the signal experience
decorrelated fading.
Figure 100: Direct and Reflected Signals
Space Diversity is a common way to negate the effects of fading caused by

multipath phenomena. Space Diversity is implemented by placing two separate
antennas at a distance from one another that makes it statistically likely that if
one antenna suffers from fading caused by signal reflection, the other antenna
will continue to receive a viable signal.
FibeAir IP-20N supports several methods for implementing Space Diversity:
• Baseband Combining (BBC) – The received signals of two carriers in each of
the Master and Slave RFUs are shared and combined to produce an optimized
received signal. Supported with RFU-D and RFU-D-HP.
• Baseband Switching (BBS) – The IDU chooses, at any given moment, the best
received signal from between two radio carriers. Supported with RFU-C and
1500HP/RFU-HP.
• IF Combining – A single RFU with two receivers receives and processes both
signals, and combines them into a single, optimized signal. Supported with
1500HP 2RX.
Page 168 of 468

Table 57: Space Diversity Methods
Baseband Switching (BBS) Baseband Combining (BBC) IF Combining
Supported Configurations 1+1, 2+2 2+0, 2x(2+0), 4+0, 2x(4+0) >8+0, 2+2
(XPIC only)
Supported RFUs RFU-C, RFU-HP, 1500HP RFU-D, RFU-D-HP 1500HP 2RX
Minimum CeraOS Version All 10.7 All
Radio Card Requirements RMC-B RIC-D RMC-B
TCC Requirement TCC-B-MC, TCC B2-XG-MC TCC-B2-XG-MC TCC-B-MC, TCC B2-XG-MC
XPIC Option Yes Yes (only XPIC) Yes
Permitted Slots All slots that support radio All slots that support All slots that support
cards radio cards. radio cards
LIC-STM1/OC3-RST Yes Yes Yes
Page 169 of 468

6.2.2.1 BBC Space Diversity

Note: BBC Space Diversity requires RIC-D, RFU-D or RFU-D-HP, and
TCC-B2-XG-MC.
RFU-D and RFU-D-HP can perform Space Diversity via Baseband Combining (BBC).
The BBC mechanism provides up to 3 dB in system gain.
BBC Space Diversity is available in the following configurations:
• 2+0 SD
• 2 X 2+0 SD
• 4+0 SD
• 2 X 4+0 SD
The basic building block of each of these Space Diversity configurations is a 2+0 SD
configuration that consists of two RFU-D or RFU-D-HP units, a Master RFU and a
Slave RFU.
• The Master RFU is connected to the Main antenna with a direct-mount dual
polarization configuration, using an OMT. In 4+0 SD configurations, two
Master RFUs are connected to the Main antenna using an OMT and a Dual
Splitter or a Dual Circulator.
• The Slave RFU is connected to the Diversity antenna with a direct-mount dual
polarization configuration, using an OMT. In 4+0 SD configurations, two Slave
RFUs are connected to the Main antenna using an OMT and a Dual Splitter or
a Dual Circulator.
Each RFU is connected to the IP-20N chassis via a separate RIC-D. Traffic is passed
only to and from the Master RFU. The units are also connected to each other via a
source sharing and a data sharing cable. No management connection is necessary,
since management is handled via the IDU.
In 2+0 SD configurations, the two carriers on the Master RFU are configured as a
Multi-Carrier ABC group. Multi-Carrier ABC is not configured on the Slave unit. The
Master RFU processes and combines the radio signals from both RFUs and
forwards an optimized, combined 2+0 data stream to the IDU via a RIC-D.
BBC Space Diversity configurations can include STM1/OC3-RST members, which
are added to the Multi-Carrier ABC group that connects the radio carriers in the
Master RFUs.
Note: In CeraOS 10.9, Multi-Carrier ABC must be implemented via TCC-
based Multi-Carrier ABC.
In 4+0 configurations, the two carriers of each Master RFU are configured as a
single Multi-Carrier ABC group. Each Master RFU processes and combines the
radio signals from itself and its Slave unit and forwards an optimized, combined
data stream to the IDU via its RIC-D.
Page 170 of 468

Master RFU
IDU
Tx1
V
Traffic (including Modem 1 OMT Main Antenna Main Antenna
combined RF) Rx1
RIC-D f1 f1
Tx2
Modem 2
Rx2
Source Sharing
Data Sharing
Network
Processor
Tx1
V
Modem 1 OMT
Rx1
RIC-D
Management
f1 f1
Tx2
Only Modem 2
Rx2 Diversity Antenna Diversity Antenna
H
Slave RFU
Figure 101: 2+0 BBC Space Diversity
BBC Space Diversity MRMC Scripts

The following MRMC scripts can be used for BBC Space Diversity with RFU-D and
RFU-D-HP:
• MRMC Script 4901 – 28MHz
• MRMC Script 4902 – 40 MHz
Using these scripts, XPIC runs in the background.
For details, see MRMC Scripts Supported with RIC-D and RFU-D, RFU-D-HP, and
RFU-S on page 346.
BBC Space Diversity Slot Placement and Use Cases

In order to best utilize the IDU’s resources, it is recommended to place the RIC-D
cards as follows:
• Master RFU: Slots 3, 4, 5, 6
• Slave RFU: Slots 7, 8, 9, 10
Page 171 of 468

Figure 102 illustrates a recommended slot placement use case for 2+0 BBC Space
Diversity. In this example:
• The RIC-D in Slot 3 is connected to the Master RFU.
• The RIC-D in Slot 7 is connected to the Slave RFU.
• TCC-Based Multi-Carrier ABC is configured between the two carriers
connected to Slot 3, and an RST card in Slot 4.

(Optional)
7 – RIC-D 8 - Traffic 9 - Traffic 10 -Traffic
(Slave)
Filter
Fans
3 -RIC-D 4 -RST 5 - Traffic 6 - Traffic
(Master)
Figure 102: Sample Chassis Configuration – 2+0 BBC Space Diversity
Figure 103 illustrates a recommended slot placement use case for 4+0 BBC Space
Diversity. In this example:
• The RIC-D in Slot 3 is connected to a Master RFU.
• The RIC-D in Slot 7 is connected to a Slave RFU.
• TCC- Based Multi-Carrier ABC is configured between the four carriers
connected to Slot 3 and Slot 4.

(Optional)
7 – RIC-D 8 – RIC-D 9 - Traffic 10 -Traffic
(Slave) (Slave)
Filter
Fans
3 -RIC-D 84--RIC-D
Traffic 5 - Traffic 6 - Traffic
(Master) (Master)
Figure 103: Sample Chassis Configuration – 4+0 BBC Space Diversity
Page 172 of 468

Figure 104 illustrates a recommended slot placement use case for 2X 2+0 BBC
Space Diversity. In this example:
• A Multi-Carrier ABC group is configured between the two carriers connected
to Slot 3.
• A Multi-Carrier ABC group is configured between the two carriers connected
to Slot 4.

(Optional)
7 – RIC-D 8 – RIC-D 9 - Traffic 10 -Traffic
(Slave) (Slave)
Filter
Fans
3 -RIC-D 4--RIC-D
(Master) 8(Master)
Traffic 5 - Traffic 6 - Traffic
Figure 104: Sample Chassis Configuration – 2 X 2+0 BBC Space Diversity
Page 173 of 468

Figure 105 illustrates a recommended slot placement use case for 2X 2+0 BBC
Space Diversity. In this example:
• A Multi-Carrier ABC group is configured between the four carriers connected
to Slots 3 and 4.
• A Multi-Carrier ABC group is configured between the four carriers connected
to Slots 5 and 6.

(Optional)
7 – RIC-D 8 – RIC-D 99 -–Traffic
RIC-D 1010 –-Traffic
RIC-D
(Slave) (Slave) (Slave) (Slave)
Filter
Fans
3 -RIC-D 84--RIC-D
Traffic 5 -RIC-D 6 -RIC-D
(Master) (Master) (Master) (Master)
Figure 105: Sample Chassis Configuration – 2 X 4+0 BBC Space Diversity
Page 174 of 468

6.2.2.2 BBS Space Diversity

Note: BBS Space Diversity requires RMC-B and TCC-B-MC or TCC-B2-
XG-MC.
BBS Space Diversity requires two antennas and RFUs. The antennas must be
separated by approximately 15 to 20 meters. Any RFU type supported by IP-20N
can be used in a BBS Space Diversity configuration.
One RFU sends its signal to the active RMC, while the other RFU sends its signal to
the standby RMC. The RMCs share these signals through the backplane, such that
each RMC receives data from both RFUs.
BBS Space Diversity requires a 1+1 configuration in which there are two RMCs and
two RFUs protecting each other at both ends of the link. In the event of RMC
failure, Space Diversity is lost until recovery, but the system remains protected
through the ordinary switchover mechanism.
Figure 106: BBS Space Diversity
2+2 BBS with Multi-Carrier ABC is also supported with optional XPIC.
6.2.2.3 IF Combining
Note: IF Combing requires 1500HP 2RX and TCC-B-MC or
TCC-B2-XG-MC.
1500HP 2RX has two receivers, enabling it to perform Space Diversity via IF
Combining. The RFU receives and processes both signals, and combines them into
a single, optimized signal. The IFC mechanism gains up to 2.5 dB in system gain.
IF Combining can be used in configurations of up to 8+0, as well as 2+2 HSB. It can
be used with or without XPIC, and requires Multi-Carrier ABC.
Page 175 of 468

6.2.3 HSB Protection

IP-20N offers radio redundancy via the RMCs or RICs, which can be configured in
1+1 Hot Standby (HSB) pairs. 1+1 HSB protection provides full protection in the
event of RMC, RIC, or RFU failure.
Note: For RIC-D, HSB protection is planned for future release.
2+2 HSB with Multi-Carrier ABC is also supported with optional XPIC.
The RMCs or RICs in a protected pair operate in active and standby mode. If there
is a failure in the active RMC or RFU, the standby RMC and RFU pair switches to
active mode.
Each RMC in a protected pair reports its status to the TCC. The TCC is responsible
for determining when a switchover takes place.
In a 1+1 HSB configuration:
• The RMCs must have the same configuration.
• The RFUs must be the same type and must have the same configuration.
IP-20N includes a mismatch mechanism that detects if there is a mismatch
between the radio configurations of the local and mate RMCs and RFUs. This
mechanism is activated by the system periodically and independently of other
protection mechanisms, at fixed intervals. It is activated asynchronously for both
the active and the standby RMCs. Once the mismatch mechanism detects a
configuration mismatch, it raises a Mate Configuration Mismatch alarm. When the
configuration of the active and standby RMCs is changed to be identical, the
mechanism clears the Mate Configuration Mismatch alarm.
In order to align the configuration between the active and standby RMCs, the user
must first complete the required configuration of the active RMC, and then
perform a copy to mate command. This command copies the entire configuration
of the active RMC to the standby RMC to achieve full configuration alignment
between the active and standby RMCs. The command also initiates a reset of the
standby RMC. As soon as the standby RMC is up and running, its configuration is
aligned to the configuration of the active RMC. This operation has no effect on the
active RMC.
When a pair of RMCs and RFUs are defined as a 1+1 HSB pair, any configuration
performed on the active RMC will be automatically copied to the standby RMC, in
order to maintain the RMC configuration alignment. This makes it unnecessary to
perform a copy-to-mate command when a configuration change is made.
Page 176 of 468

6.2.3.1 Revertive HSB Protection

In an HSB protection scheme, the active and standby radios are usually
connected to the antenna with an asymmetric coupler. This causes a 6dB loss
on one of the radios on each side of the link, which may result (depending on
the active/standby status of each radio) in up to12dB total path loss for the
link. This additional path loss will either reduce link fade margin or increase
the power consumption of the Power Amplifier (PA) in order to compensate
for the additional path loss.
Revertive HSB protection ensures that the radios with no loss are active as long as
no failures are present, resulting in the best possible link budget (0 dB loss).
Coupler Coupler
B -6d
-6d B
Primary Radio Primary Radio
Main Path Main Path
Coupling Path
Coupling Path
Secondary Radio Secondary Radio
Figure 107: Path Loss on Secondary Path of 1+1 HSB Protection Link
IP-20N supports revertive HSB protection for both 1+1 and 2+2 HSB
configurations using RMC-B. In revertive HSB protection mode, user defines
the primary radio on each side of the link. The primary radio should be the
radio on the coupler’s main path and the secondary radio should be the radio
on the coupling path.
The system monitors the availability of the primary path at all times. Whenever
the primary path is operational and available, without any alarms, but the
secondary path is active, a ten-minute timer is activated. If the primary path
remains operational and available for ten minutes, the system initiates a revertive
protection switch. Every revertive protection switch is recorded as an event in the
event log.
Note: Each protection switch causes traffic disruption.
6.2.3.2 Switchover Triggers

The following events trigger switchover for 1+1 HSB protection according to their
priority, with the highest priority triggers listed first.
1 Card missing
2 Lockout
3 Force switch
4 Traffic failures
5 Manual switch
Page 177 of 468

6.2.4 Adaptive Coding Modulation (ACM)
This feature requires:

• ACM script
Related topics:
• Quality of Service (QoS)
FibeAir IP-20N employs full-range dynamic ACM. IP-20N’s ACM mechanism copes
with 90 dB per second fading in order to ensure high transmission quality. IP-
20N’s ACM mechanism is designed to work with IP-20N’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-20N’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.
Page 178 of 468

6.2.4.1 Up to 13 Working Points

IP-20N implements ACM with up to 13 available working points. The number of
working points depends on the type of RFU or RMC used.
Table 58: ACM Working Points (Profiles) – RIC-D with Microwave RFUs
Working Point (Profile) Modulation
Profile 0 BPSK
Profile 1 QPSK
Profile 2 8 PSK
Profile 3 16 QAM
Profile 4 32 QAM
Profile 5 64 QAM
Profile 6 128 QAM
Profile 7 256 QAM
Profile 8 512 QAM
Profile 9 1024 QAM (Strong FEC)
Profile 10 1024 QAM (Light FEC)
Profile 11 2048 QAM
Profile 12 4096 QAM
Table 59: ACM Working Points (Profiles) – RIC-D with E-Band RFU (RFU-E)
Profile 0 BPSK
Profile 1 QPSK
Profile 2 8 PSK
Profile 3 16 QAM
Profile 4 32 QAM
Profile 5 64 QAM
Profile 6 128 QAM
Profile 7 256 QAM
Profile 8 512 QAM
Profile 9 1024 QAM
Page 179 of 468

Table 60: ACM Working Points (Profiles) – RMC-A
Profile 0 QPSK
Profile 1 8 PSK
Profile 2 16 QAM
Profile 3 32 QAM
Profile 4 64 QAM
Profile 5 128 QAM
Table 61: ACM Working Points (Profiles) – RMC-B
Profile 0 QPSK
Profile 1 8 PSK
Profile 2 16 QAM
Profile 3 32 QAM
Profile 4 64 QAM
Profile 5 128 QAM
Profile 6 256 QAM
Profile 7 512 QAM
Profile 10 2048 QAM
Page 180 of 468

1024 1024 1024 1024

2048 512 256 128 64 32 16 8 8 16 32 64 128 256 512 2048
4096 QAM QAM QAM QPSK BPSK QPSK QAM QAM QAM 4096 QAM
QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM
Light FEC Strong FEC Strong FEC Light FEC
Figure 108: Adaptive Coding and Modulation with 13 Working Points
6.2.4.2 Hitless and Errorless Step-by Step Adjustments

ACM works as follows. Assuming a system configured for 128 QAM with ~170
Mbps capacity over a 28 MHz channel, when the receive signal Bit Error Ratio
(BER) level reaches a predetermined threshold, the system preemptively switches
to 64 QAM and the throughput is stepped down to ~140 Mbps. This is an
errorless, virtually instantaneous switch. The system continues to operate at 64
QAM until the fading condition either intensifies or disappears. If the fade
intensifies, another switch takes the system down to 32 QAM. If, on the other
hand, the weather condition improves, the modulation is switched back to the
next higher step (e.g., 128 QAM) and so on, step by step. The switching continues
automatically and as quickly as needed, and can reach all the way down to QPSK
during extreme conditions.
6.2.4.3 ACM Radio Scripts

An ACM radio script is constructed of a set of profiles. Each profile is defined by a
modulation order (QAM) and coding rate, and defines the profile’s capacity (bps).
When an ACM script is activated, the system automatically chooses which profile
to use according to the channel fading conditions.
The ACM TX profile can be different from the ACM RX profile.
The ACM TX profile is determined by remote RX MSE performance. The RX end is
the one that initiates an ACM profile upgrade or downgrade. When MSE improves
above a predefined threshold, RX generates a request to the remote TX to
upgrade its profile. If MSE degrades below a predefined threshold, RX generates a
request to the remote TX to downgrade its profile.
ACM profiles are decreased or increased in an errorless operation, without
affecting traffic.
For ACM to be active, the ACM script must be run in Adaptive mode. In this mode,
the ACM engine is running, which means that the radio adapts its profile
according to the channel fading conditions. Adaptive mode requires an ACM
activation key.
Page 181 of 468

Users also have the option of running an ACM script in Fixed mode. In this mode,
ACM is not active. Instead, the user can select the specific profile from all
available profiles in the script. The selected profile is the only profile that will be
valid, and the ACM engine will be forced to be OFF. This mode can be chosen
without an ACM activation key.
In the case of XPIC/ACM scripts, all the required conditions for XPIC apply.
The user can define a minimum and maximum profile. For example, if the user
selects a maximum profile of 5, the system will not climb above the profile 5, even
if channel fading conditions allow it.
6.2.4.4 ACM Benefits

The advantages of IP-20N’s dynamic ACM include:
• Maximized spectrum usage
• Increased capacity over a given bandwidth
• 8 to 13 modulation/coding work points (~3 db system gain for each point
change)
• Hitless and errorless modulation/coding changes, based on signal quality
• Adaptive Radio Tx Power per modulation for maximal system gain per working
point
• An integrated QoS mechanism that enables intelligent congestion
management to ensure that high priority traffic is not affected during link
fading
6.2.4.5 ACM and Built-In QoS

IP-20N’s ACM mechanism is designed to work with IP-20N’s QoS mechanism to
ensure that high priority voice and data frames are never dropped, thus
maintaining even the most stringent SLAs. Since QoS provides priority support for
different classes of service, according to a wide range of criteria, you can
configure IP-20N to discard only low priority frames as conditions deteriorate.
If you want to rely on an external switch’s QoS, ACM can work with them via the
flow control mechanism supported in the radio.
6.2.4.6 ACM and 1+1 HSB

When ACM is activated together with 1+1 HSB protection, it is essential to feed
the active RFU via the main channel of the coupler (lossless channel), and to feed
the standby RFU via the secondary channel of the coupler (-6db attenuated
channel). This maximizes system gain and optimizes ACM behavior for the
following reasons:
• In the TX direction, the power will experience minimal attenuation.
• In the RX direction, the received signal will be minimally attenuated. Thus, the
receiver will be able to lock on a higher ACM profile (according to what is
dictated by the RF channel conditions).
Page 182 of 468

The following ACM behavior should be expected in a 1+1 or 2+2 configuration:

• In the TX direction, the Active TX will follow the remote Active RX ACM
requests (according to the remote Active Rx MSE performance).
• The Standby TX might have the same profile as the Active TX, or might stay at
the lowest profile (profile-0). That depends on whether the Standby TX was
able to follow the remote RX Active unit’s ACM requests (only the active
remote RX sends ACM request messages).
• In the RX direction, both the active and the standby carriers follow the remote
Active TX profile (which is the only active transmitter).
Page 183 of 468

6.2.4.7 ACM with Adaptive Transmit Power

• ACM script
• When working with RFU-C, requires RFU software version 2.17 or above
• When working with RFU-HP, requires RFU software version 5.14 or above
• When working with 1500HP, requires RFU software version 8.13a2 or above.
• Not supported with RMC-A.
ACM with Adaptive Transmit Power enables operators to benefit from the higher
transmit power of the radios when fading conditions occur while at the same time
benefiting from lower power consumption when the high transmit power is not
required.
When planning ACM-based radio links, the radio planner attempts to apply the
lowest transmit power that will perform satisfactorily at the highest level of
modulation. During fade conditions requiring a modulation drop, most radio
systems cannot increase transmit power to compensate for the signal
degradation, resulting in a deeper reduction in capacity. IP-20N is capable of
adjusting the transmit power on the fly, and optimizing the available capacity at
every modulation point.
The following figure contrasts the transmit output power achieved by using ACM
with Adaptive Power to the transmit output power at a fixed power level, over an
18-23 GHz link. This figure shows how without Adaptive Transmit Power,
operators that want to use ACM to benefit from high levels of modulation (e.g.,
2048 QAM) must settle for low system gain, in this case, 16 dB, for all the other
modulations as well. In contrast, with IP-20N’s Adaptive Transmit Power feature,
operators can automatically adjust power levels, achieving the extra system gain
that is required to maintain optimal throughput levels under all conditions.
Page 184 of 468

Figure 109: ACM with Adaptive Power Contrasted to Other ACM Implementations
Page 185 of 468

6.2.5 Cross Polarization Interference Canceller (XPIC)

• 2+0/2+2 configuration
• XPIC script
XPIC is one of the best ways to break the barriers of spectral efficiency. Using
dual-polarization radio over a single-frequency channel, a dual polarization radio
transmits two separate carrier waves over the same frequency, but using
alternating polarities. Despite the obvious advantages of dual-polarization, one
must also keep in mind that typical antennas cannot completely isolate the two
polarizations. In addition, propagation effects such as rain can cause polarization
rotation, making cross-polarization interference unavoidable.
Figure 110: Dual Polarization
The relative level of interference is referred to as cross-polarization discrimination

(XPD). While lower spectral efficiency systems (with low SNR requirements such
as QPSK) can easily tolerate such interference, higher modulation schemes cannot
and require XPIC. IP-20N’s XPIC algorithm enables detection of both streams even
under the worst levels of XPD such as 10 dB. IP-20N accomplishes this by
adaptively subtracting from each carrier the interfering cross carrier, at the right
phase and level. For high-modulation schemes such as 2048 QAM, operating at a
frequency of 28 GHz, an improvement factor of more than 20 dB is required so
that cross-interference does not adversely affect performance.
For RFU-C and 1500HP/RFU-HP, XPIC is implemented using two different RMCs
and RFUs. For slot placement guidelines, see Adjacent Pair Guidelines on page 52.
For RIC-D, XPIC is supported with MultiCore RFUs only (RFU-D and RFU-D-HP),
using the two carriers in a single RFU as the XPIC pair.
6.2.5.1 XPIC Benefits

The advantages of FibeAir IP-20N’s XPIC option include BER of 10e-6 at a co-
channel sensitivity of 5 dB.
Page 186 of 468

6.2.5.2 XPIC Implementation

The XPIC mechanism utilizes the received signals from the V and H modems to
extract the V and H signals and cancel the cross polarization interference due to
physical signal leakage between V and H polarizations.
The following figure is a basic graphic representation of the signals involved in this
process.
V V+h V
Modem Modem
h
v
Modem Modem
H H+v H
IP-20N IP-20N
Figure 111: XPIC Implementation – RFU-C and 1500HP/RFU-HP
V V+h V
Modem Modem
h
v
Modem Modem
H H+v H
RFU-D or RFU-D or
RFU-D-HP RFU-D-HP
Figure 112: XPIC Implementation – RIC-D with RFU-D or RFU-D-HP
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.
Page 187 of 468

Figure 113: XPIC – Impact of Misalignments and Channel Degradation
IP-20N’s XPIC reaches a BER of 10e-6 at a co-channel sensitivity of 5 dB. The

improvement factor in an XPIC system is defined as the SNR@threshold of 10e-6,
with or without the XPIC mechanism.
6.2.5.3 XPIC Recovery Mechanism

The XPIC mechanism is based on signal cancellation and assumes that both
transmitted signals are received (with a degree of polarity separation). If for some
reason, such as hardware failure, one of the carriers stops receiving a signal, the
working carrier may be negatively affected by the received signals, which cannot
be canceled in this condition.
The purpose of the XPIC recovery mechanism is to preserve the working link while
attempting to recover the faulty polarization.
The mechanism works as follows:
• The recovery mechanism is automatically activated when the unit detects that
one carrier is down (RMC or RIC power failure, RFU power failure, carrier
drawer extraction, carrier reset, etc.). When activated, the system switches to
“Single Carrier” state.
• The recovery mechanism causes the remote transmitter of the faulty carrier
to mute, thus eliminating the disturbing signal and preserving the working
link.
• As soon as the failed carrier goes back into service, the XPIC recovery
mechanism adds it back and XPIC operation resumes with both carriers.
The XPIC recovery mechanism is enabled by default, and cannot be disabled by
the user.
Page 188 of 468

6.2.5.4 Conditions for XPIC

XPIC is enabled by selecting an XPIC script for each carrier. In order for XPIC to be
operational, all the following conditions must be met:
• The radio card must be RMC-B or RIC-D
• Communications with the RFU are established in both RMCs.
• RFU type must be the same for both carriers.
• The frequency of both radios should be equal.
• The same script must be loaded in both carriers.
• The script must support XPIC
If any of these conditions is not met, an alarm will alert the user. In addition,
events will inform the user which conditions are not met.
Page 189 of 468

6.2.6 ATPC
ATPC is a closed-loop mechanism by which each carrier changes the TX 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, TX power is increased as needed until the
maximum is reached.
The ATPC mechanism has several potential advantages, including less 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.
6.2.6.1 ATPC Override Timer

Note: ATPC Override Timer is not supported with RMC-A.
This feature complies with NSMA Recommendation WG 18.91.032. With ATPC
enabled, if the radio automatically increases its TX power up to the configured
maximum it can lead to a period of sustained transmission at maximum power,
resulting in unacceptable interference with other systems.
To minimize interference, IP-20N provides an ATPC override mechanism. When
ATPC override is enabled, a timer begins when ATPC raises the TX power to its
maximum. When the timer expires, the ATPC maximum TX power is overridden by
the user-configured ATPC override TX power level until the user manually cancels
the ATPC override. The unit then returns to normal ATPC operation.
The following parameters can be configured:
• ATPC Override Admin – Determines whether the ATPC override mechanism is
enabled.
• Override TX Level – The TX power, in dBm, used when the unit is in an ATPC
override state.
• Override Timeout – The amount of time, in seconds, the timer counts from
the moment the radio reaches its maximum configured TX power until ATPC
override goes into effect.
When the radio enters ATPC override state, the radio transmits no higher than the
pre-determined ATPC override TX level, and an ATPC override alarm is raised. The
radio remains in ATPC override state until the ATPC override state is manually
cancelled by the user (or the unit is reset).
In a configuration with TCC redundancy or radio protection, the ATPC override
state is propagated to the standby TCC or radio in the event of switchover.
Note: When canceling an ATPC override state, the user should ensure
that the underlying problem has been corrected. Otherwise,
ATPC may be overridden again.
Page 190 of 468

6.2.7 Radio Signal Quality PMs

IP-20N supports the following radio signal quality PMs. For each of these PM
types, users can display the minimum and maximum values, per radio, for every
15-minute interval. Users can also define thresholds and display the number of
seconds during which the radio was not within the defined threshold.
• RSL (users can define two RSL thresholds)
• TSL
• MSE
• XPI
Users can display BER PMs, including the current BER per radio, and define
thresholds for Excessive BER and Signal Degrade BER. Alarms are issued if these
thresholds are exceeded. See Configurable BER Threshold Alarms and Traps on
page 327. Users can also configure an alarm that is raised if the RSL falls beneath a
user-defined threshold. See RSL Threshold Alarm on page 327.
6.2.8 Radio Utilization PMs

IP-20N supports the following counters, as well as additional PMs based on these
counters:
• Radio Traffic Utilization – Measures the percentage of radio capacity
utilization, and used to generate the following PMs for every 15-minute
interval:
 Peak Utilization (%)
 Average Utilization (%)
 Over-Threshold Utilization (seconds). The utilization threshold can be defined by
the user (0-100%).
• Radio Traffic Throughput – Measures the total effective Layer 2 traffic sent
through the radio (Mbps), and used to generate the following PMs for every
15-minute interval:
 Peak Throughput
 Average Throughput
 Over-Threshold Utilization (seconds). The threshold is defined as 0.
• Radio Traffic Capacity – Measures the total L1 bandwidth (payload plus
overheads) sent through the radio (Mbps), and used to generate the following
PMs for every 15-minute interval:
 Peak Capacity
 Average Capacity
 Over-Threshold Utilization (seconds). The threshold is defined as 0.
• Frame Error Rate – Measures the frame error rate (%), and used to generate
Frame Error Rate PMs for every 15-minute interval.
Page 191 of 468

6.3 Ethernet Features

IP-20N features a service-oriented Ethernet switching fabric. The number of
Ethernet interfaces is scalable, with a minimum of two GbE combo interfaces
(optical or electrical) and one or two FE interfaces for management on the TCC.
Additional interfaces can be added by adding Ethernet LICs.
IP-20N’s service-oriented Ethernet paradigm enables operators to configure
VLANs, CoS, security, and network resiliency on a service, service-point, and
interface level.
IP-20N provides personalized and granular QoS that enables operators to
customize traffic management parameters per customer, application, service
type, or in any other way that reflects the operator’s business and network
requirements.

• Ethernet Services Overview
• IP-20N’s Ethernet Capabilities
• Supported Standards
• Ethernet Service Model
• Ethernet Interfaces
• Quality of Service (QoS)
• Global Switch Configuration
• Automatic State Propagation and Link Loss Forwarding
• Network Resiliency
• OAM
Page 192 of 468

6.3.1 Ethernet Services Overview

The IP-20N services model is premised on supporting the standard MEF services
(MEF 6, 10), and builds upon this support by the use of very high granularity and
flexibility. Operationally, the IP-20N Ethernet services model is designed to offer a
rich feature set combined with simple and user-friendly configuration, enabling
users to plan, activate, and maintain any packet-based network scenario.
This section first describes the basic Ethernet services model as it is defined by the
MEF, then goes on to provide a basic overview of IP-20N’s Ethernet services
implementation.
The following figure illustrates the basic MEF Ethernet services model.
Figure 114: Basic Ethernet Service Model
In this illustration, the Ethernet service is conveyed by the Metro Ethernet

Network (MEN) provider. Customer Equipment (CE) is connected to the network
at the User Network Interface (UNI) using a standard Ethernet interface
(10/100 Mbps, 1 Gbps). The CE may be a router, bridge/switch, or host (end
system). A NI is defined as the demarcation point between the customer
(subscriber) and provider network, with a standard IEEE 802.3 Ethernet PHY and
MAC.
The services are defined from the point of view of the network’s subscribers
(users). Ethernet services can be supported over a variety of transport
technologies and protocols in the MEN, such as SDH, Ethernet, ATM, MPLS, and
GFP. However, from the user’s perspective, the network connection at the user
side of the UNI is only Ethernet.
Page 193 of 468

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.
Figure 115: 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.
Page 194 of 468

The MEF has defined three types of EVCs:

1 Point to Point EVC – Each EVC contains exactly two UNIs. The following figure
shows two point-to-point EVCs connecting one site to two other sites.
Figure 116: Point to Point EVC
2 Multipoint (Multipoint-to-Multipoint) EVC – Each EVC contains two or more

UNIs. In the figure below, three sites belong to a single Multipoint EVC and
can forward Ethernet frames to each other.
Figure 117: Multipoint to Multipoint EVC
3 Rooted Multipoint EVC (Point-to-Multipoint) – Each EVC contains one or more

UNIs, with one or more UNIs defined as Roots, and the others defined as
Leaves. The Roots can forward frames to the Leaves. Leaves can only forward
frames to the Roots, but not to other Leaves.
Figure 118: Rooted Multipoint EVC
Page 195 of 468

In the IP-20N, an EVC is defined by either a VLAN or by Layer 1 connectivity (Pipe

Mode).
6.3.1.2 Bandwidth Profile

The bandwidth profile (BW profile) is a set of traffic parameters that define the
maximum limits of the customer’s traffic.
At ingress, the bandwidth profile limits the traffic transmitted into the network:
• Each service frame is checked against the profile for compliance with the
profile.
• Bandwidth profiles can be defined separately for each UNI (MEF 10.2).
• Service frames that comply with the bandwidth profile are forwarded.
• Service frames that do not comply with the bandwidth profile are dropped at
the ingress interface.
The MEF has defined the following three bandwidth profile service attributes:
• Ingress BW profile per ingress UNI
• Ingress BW profile per EVC
• Ingress BW profile per CoS identifier
The BW profile service attribute consists of four traffic parameters:
• CIR (Committed Information Rate)
• CBS (Committed Burst Size)
• EIR (Excess Information Rate)
• EBS (Excess Burst Size)
Bandwidth profiles can be applied per UNI, per EVC at the UNI, or per CoS
identifier for a specified EVC at the UNI.
The Color of the service frame is used to determine its bandwidth profile. If the
service frame complies with the CIR and EIR defined in the bandwidth profile, it is
marked Green. In this case, the average and maximum service frame rates are less
than or equal to the CIR and CBS, respectively.
If the service frame does not comply with the CIR defined in the bandwidth
profile, but does comply with the EIR and EBS, it is marked Yellow. In this case, the
average service frame rate is greater than the CIR but less than the EIR, and the
maximum service frame size is less than the EBS.
If the service frame fails to comply with both the CIR and the EIR defined in the
bandwidth profile, it is marked Red and discarded.
In the IP-20N, bandwidth profiles are constructed using a full standardized TrTCM
policer mechanism.
6.3.1.3 Ethernet Services Definitions

The MEF provides a model for defining Ethernet services. The purpose of the MEF
model is to help subscribers better understand the variations among different
Page 196 of 468

types of Ethernet services. IP-20N supports a variety of service types defined by

the MEF. All of these service types share some common attributes, but there are
also differences as explained below.
Ethernet service types are generic constructs used to create a broad range of
services. Each Ethernet service type has a set of Ethernet service attributes that
define the characteristics of the service. These Ethernet service attributes in turn
are associated with a set of parameters that provide various options for the
various service attributes.
Figure 119: MEF Ethernet Services Definition Framework
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.
Table 62: MEF-Defined Ethernet Service Types
Service Type Port Based VLAN-BASED

(All to One Bundling) (EVC identified by VLAN ID)
E-Line (Point-to-Point EVC) Ethernet Private Line (EPL) Ethernet Virtual Private Line
(EVPL)
E-LAN (Multipoint-to- Ethernet Private LAN Ethernet Virtual Private LAN (EVP-
Multipoint EVC) (EP-LAN) LAN)
E-Tree (Rooted Multipoint EVC) Ethernet Private Tree Ethernet Virtual Private Tree (EVP-
(EP-Tree) Tree)
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.
Page 197 of 468

To fully specify an Ethernet service, additional service attributes must be defined

in addition to the UNI and EVC service attributes. These service attributes can be
grouped under the following categories:
• Ethernet physical interfaces
• Traffic parameters
• Performance parameters
• Class of service
• Service frame delivery
• VLAN tag support
• Service multiplexing
• Bundling
• Security filters
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.
Figure 120: E-Line Service Type Using Point-to-Point EVC
Page 198 of 468

Ethernet Private Line Service

An Ethernet Private Line (EPL) service is specified using an E-Line Service type. An
EPL service uses a point-to-point EVC between two UNIs and provides a high
degree of transparency for service frames between the UNIs that it interconnects
such that the service frame’s header and payload are identical at both the source
and destination UNI when the service frame is delivered (L1 service). A dedicated
UNI (physical interface) is used for the service and service multiplexing is not
allowed. All service frames are mapped 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.
Figure 121: EPL Application Example
Ethernet Virtual Private Line Service

An Ethernet Virtual Private Line (EVPL) is created using an E-Line service type. An
EVPL can be used to create services similar to EPL services. However, several
characteristics differ between EPL and EVPL services.
First, an EVPL provides for service multiplexing at the UNI, which means it enables
multiple EVCs to be delivered to customer premises over a single physical
connection (UNI). In contrast, an EPL only enables a single service to be delivered
over a single physical connection.
Second, the degree of transparency for service frames is lower in an EVPL than in
an EPL.
Since service multiplexing is permitted in EVPL services, some service frames may
be sent to one EVC while others may be sent to other EVCs. EVPL services can be
used to replace Frame Relay and ATM L2 VPN services, in order to deliver higher
bandwidth, end-to-end services.
Page 199 of 468

Figure 122: EVPL 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.
Figure 123: 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
Page 200 of 468

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.
For example, consider a point-to-point network configuration implemented using
E-Line services. If a new site (UNI) is added, it is necessary to add a new, separate
EVC to all of the other sites in order to enable the new UNI to communicate with
the other UNIs, as shown in the following figure.
Figure 124: Adding a Site Using an E-Line service
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.
Figure 125: 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.
Page 201 of 468

Ethernet Private LAN Service

It is often desirable to interconnect multiple sites using a Local Area Network
(LAN) protocol model and have equivalent performance and access to resources
such as servers and storage. Customers commonly require a highly transparent
service that connects multiple UNIs. The Ethernet Private LAN (EP-LAN) service is
defined with this in mind, using the E-LAN service type. The EP-LAN is a Layer 2
service in which each UNI is dedicated to the EP-LAN service. A typical use case for
EP-LAN services is Transparent LAN.
The following figure shows an example of an EP-LAN service in which the service is
defined to provide Customer Edge VLAN (CE-VLAN) tag preservation and tunneling
for key Layer 2 control protocols. Customers can use this service to configure
VLANs across the sites without the need to coordinate with the service provider.
Each interface is configured for All-to-One Bundling, which enables the EP-LAN
service to support CE-VLAN ID preservation. In addition, EP-LAN supports CE-VLAN
CoS preservation.
Figure 126: MEF Ethernet Private LAN Example
Ethernet Virtual Private LAN Service

Customers often use an E-LAN service type to connect their UNIs in an MEN, while
at the same time accessing other services from one or more of those UNIs. For
example, a customer might want to access a public or private IP service from a
UNI at the customer site that is also used to provide E-LAN service among the
customer’s several metro locations. The Ethernet Virtual Private LAN (EVP-LAN)
service is defined to address this need. EVP-LAN is actually a combination of EVPL
and E-LAN.
Bundling can be used on the UNIs in the Multipoint-to-Multipoint EVC, but is not
mandatory. As such, CE-VLAN tag preservation and tunneling of certain Layer 2
control protocols may or may not be provided. Service multiplexing is allowed on
each UNI. A typical use case would be to provide Internet access a corporate VPN
via one UNI.
Page 202 of 468

The following figure provides an example of an EVP-LAN service.
Figure 127: MEF Ethernet Virtual Private LAN Example
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.
Figure 128: 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
Page 203 of 468

can also be provided, effectively allowing for enhanced service reliability and
flexibility.
Figure 129: E-Tree Service Type Using Multiple Roots
Service multiplexing is optional and may occur on any combination of UNIs in the
EVC. For example, an E-Tree service type using a Rooted-Multipoint EVC, and an E-
Line service type using a Point-to-Point EVC, can be service multiplexed on the
same UNI. In this example, the E-Tree service type can be used to support a
specific application at the Subscriber UNI, e.g., ISP access to redundant PoPs
(multiple Roots at ISP PoPs), while the E-Line Service type is used to connect to
another enterprise site with a Point-to-Point EVC.
Ethernet Private Tree Service

The Ethernet Private Tree service (EP-Tree) is designed to supply the flexibility for
configuring multiple sites so that the services are distributed from a centralized
site, or from a few centralized sites. In this setup, the centralized site or sites are
designed as Roots, while the remaining sites are designated as Leaves. CE-VLAN
tags are preserved and key Layer 2 control protocols are tunneled. The advantage
of such a configuration is that the customer can configure VLANs across its sites
without the need to coordinate with the service provider. Each interface is
configured for All-to-One Bundling, which means that EP-Tree services support CE-
VLAN ID preservation. EP-Tree also supports CE-VLAN CoS preservation. EP-Tree
requires dedication of the UNIs to the single EP-Tree service.
Page 204 of 468

The following figure provides an example of an EP-Tree service.
Figure 130: MEF Ethernet Private Tree Example
Ethernet Virtual Private Tree Service

In order to access several applications and services from well-defined access
points (Root), the UNIs are attached to the service in a Rooted Multipoint
connection. Customer UNIs can also support other services, such as EVPL and EVP-
LAN services. An EVP-Tree service is used in such cases. Bundling can be used on
the UNIs in the Rooted Multipoint EVC, but it is not mandatory. As such, CE-VLAN
tag preservation and tunneling of certain Layer 2 Control Protocols may or may
not be provided. EVP-Tree enables each UNI to support multiple services. A good
example would be a customer that has an EVP-LAN service providing data
connectivity among three UNIs, while using an EVP-Tree service to provide video
broadcast from a video hub location. The following figure provides an example of
a Virtual Private Tree service.
Page 205 of 468

Figure 131: Ethernet Virtual Private Tree Example
IP-20N enables network connectivity for Mobile Backhaul cellular infrastructure,

fixed networks, private networks and enterprises.
Mobile Backhaul refers to the network between the Base Station sites and the
Network Controller/Gateway sites for all generations of mobile technologies.
Mobile equipment and networks with ETH service layer functions can support
MEF Carrier Ethernet services using the service attributes defined by the MEF.
Figure 132: Mobile Backhaul Reference Model
The IP-20N 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
Page 206 of 468

(as well as in MEF 10). E-Line, E-LAN and E-Tree services are well defined as the
standard services.
6.3.1.4 IP-20N Universal Packet Backhaul Services Core

IP-20N addresses the customer demand for multiple services of any of the
aforementioned types (EPL, EVPL, EP –LAN, EVP-LAN, EP-Tree, and EVP-Tree)
through its rich service model capabilities and flexible integrated switch
application. Additional Layer 1 point-based services are supported as well, as
explained in more detail below.
Services support in the mobile backhaul environment is provided using the IP-20N
services core, which is structured around the building blocks shown in the figure
below. IP-20N provides rich and secure packet backhaul services over any
transport type with unified, simple, and error-free operation.
Figure 133: Packet Service Core Building Blocks
Any Service
• Ethernet services (EVCs)
 E-Line (Point-to-Point)
 E-LAN (Multipoint)
 E-Tree (Point-to-Multipoint)26
• Port based (Smart Pipe) services
Any Transport
• Native Ethernet Transport (802.1q or Q-in-Q)
26
E-Tree services are planned for future release.
Page 207 of 468

• 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)
Virtual Switching/Forwarding Engine

• Clear distinction between user facing service interfaces (UNI) and intra-
network interfaces
• Fully flexible C-VLAN and S-VLAN encapsulation (classification and
preservation)
• Improved security/isolation without limiting C-VLAN reuse by different
customers
• Per-service MAC learning with 128K MAC addresses support
Fully Programmable and Future-Proof

• Network-processor-based services core
• Ready today to support emerging and future standards and networking
protocols
Rich Policies and Tools with Unified and Simplified Management

• Personalized QoS (H-QoS)27
• Superb service OAM (CFM, PM)
• Carrier-grade service resiliency (G.8032, MSTP)
27
H-QoS support is planned for future release.
Page 208 of 468

6.3.2 IP-20N’s Ethernet Capabilities

IP-20N is built upon a service-based paradigm that provides rich and secure frame
backhaul services over any type of transport, with unified, simple, and error-free
operation. IP-20N’s services core includes a rich set of tools that includes:
• Service-based Quality of Service (QoS).
• Service OAM, including CFM, granular PMs, and service activation.
• Carrier-grade service resiliency using G.8032 and MSTP.
The following are IP-20N’s main Carrier Ethernet transport features. This rich
feature set provides a future-proof architecture to support backhaul evolution for
emerging services.
• Up to 1024 services
• Up to 32 service points per service
• All service types:28
 Multipoint (E-LAN)
 Point-to-Point (E-Line)
 Smart Pipe
 Management
• 128K MAC learning table, with separate learning per service (including
limiters)
• Flexible transport and encapsulation via 802.1q, 802.1ad (Q-in-Q) with VLAN
tag manipulation
• High precision, flexible frame synchronization solution combining SyncE and
1588v2
• Hierarchical QoS with 8K service level queues, deep buffering, hierarchical
scheduling via WFQ and Strict priority, and shaping at each level
• 1K hierarchical two-rate three-Color policers
 Port based – Unicast, Multicast, Broadcast, Ethertype
 Service-based
 CoS-based
• Up to four link aggregation groups (LAG)
 Hashing based on L2, L3, MPLS, and L4
• Enhanced <50msec network level resiliency (G.8032) for ring/mesh support
28
E-Tree service support is planned for future release.
Page 209 of 468

6.3.3 Supported Standards

IP-20N is fully MEF-9 and MEF-14 certified for all Carrier Ethernet services. For a
full list of standards and certifications supported by IP-20N, refer to the following
section:
• Supported Ethernet Standards
Page 210 of 468

6.3.4 Ethernet Service Model

IP-20N’s service-oriented Ethernet paradigm is based on Carrier-Ethernet
Transport (CET), and provides a highly flexible and granular switching fabric for
Ethernet services.
IP-20N’s virtual switching/forwarding engine is based on a clear distinction
between user-facing service interfaces and intra-network service interfaces. User-
facing interfaces (UNIs) are configured as Service Access Points (SAPs), while intra-
network interfaces (E-NNIs or NNIs) are configured as Service Network Points
(SNPs).
P2P
Service
SNP SNP
UNI
P2P
NNI
Service
SAP SAP
Multipoint SNP SNP Multipoint
SN
SA Service Service
SNP SNP
PP SNP SNP
IP-20N
SAP SAP
SNP SNP
Multipoint Multipoint
Service Service
SNP
SNP
SAP
P2P
Service
SNP
SNP
SNP SNP
IP-20N IP-20N
Multipoint
Service
SNP
SNP SAP
IP-20N
Figure 134: IP-20N Services Model
The IP-20N services core provides for fully flexible C-VLAN and S-VLAN
encapsulation, with a full range of classification and preservation options
available. Service security and isolation is provided without limiting the C-VLAN
reuse capabilities of different customers.
Page 211 of 468

Users can define up to 1,024 services on a single IP-20N. Each service constitutes a
virtual bridge that defines the connectivity and behavior among the network
element interfaces for the specific virtual bridge. In addition to user-defined
services, IP-20N contains a pre-defined management service (Service ID 1025). If
needed, users can activate the management service and use it for in-band
management.
To define a service, the user must configure virtual connections among the
interfaces that belong to the service. This is done by configuring service points
(SPs) on these interfaces.
A service can hold up to 32 service points. A service point is a logical entity
attached to a physical or logical interface. Service points define the movement of
frames through the service. Each service point includes both ingress and egress
attributes.
Note: Management services can hold up to 30 SPs.
The following figure illustrates the IP-20N services model, with traffic entering and
leaving the network element. IP-20N’s switching fabric is designed to provide a
high degree of flexibility in the definition of services and the treatment of data
flows as they pass through the switching fabric.
Page 212 of 468

P2P Service
Port 1 C-ta 00 Port 7

g=20
SP C-tag=30
SP
SAP SAP
00
C-
ta 20
g= to
Port 2 10 00 Port 8
10
g=
ta
C-
Multipoint Service
Un
ta
SP
SAP SP
SAP
g
Port 3 Port 9
,3
g= 2
S C-ta
SP
SAP SP
SAP
Port 4 Port 10
C-ta
g=2
0
SP
SAP SP
SAP S-tag
=2 00
Port 5 Port 11
Smart Pipe Service
Port 6 SP SP
SAP Port 12
SAP
Figure 135: IP-20N Services Core
6.3.4.1 Frame Classification to Service Points and Services

Each arriving frame is classified to a specific service point, based on a key that
consists of:
• The Interface ID of the interface through which the frame entered the IP-20N.
• The frame’s C-VLAN and/or S-VLAN tags.
If the classification mechanism finds a match between the key of the arriving
frame and a specific service point, the frame is associated to the specific service to
which the service point belongs. That service point is called the ingress service
point for the frame, and the other service points in the service are optional egress
service points for the frame. The frame is then forwarded from the ingress service
point to an egress service point by means of flooding or dynamic address learning
in the specific service. Services include a MAC entry table of up to 131,072 entries,
with a global aging timer and a maximum learning limiter that are configurable
per-service.
Page 213 of 468

P2P Service
User Port
GE/FE Port SAP

SAP SNP
SAP
P2P Service Network

User Port
Port
GE/FE Port SAP

SAP SNP
SAP Port Ethernet Ethernet
traffic Radio
Multipoint Service
SAP SNP Network

User Port Port
GE/FE Port Port Ethernet Ethernet

traffic Radio
SAP SNP
Figure 136: IP-20N Services Flow
6.3.4.2 Service Types

IP-20N supports the following service types:
• Point-to-Point Service (P2P)
• MultiPoint Service (MP)
• Management Service
Point to Point Service (P2P)

Point-to-point services are used to provide connectivity between two interfaces of
the network element. When traffic ingresses via one side of the service, it is
immediately directed to the other side according to ingress and egress tunneling
rules. This type of service contains exactly two service points and does not require
MAC address-based learning or forwarding. Since the route is clear, the traffic is
tunneled from one side of the service to the other and vice versa.
Page 214 of 468

The following figure illustrates a P2P service.
P2P Service
Port 1 Port 4
SP SP
SAP
SAP
Port 2 Port 5
P2P Service
SP
SAP SP
SAP
Port 3 Port 6
Figure 137: Point-to-Point Service
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 (MP)

Multipoint services are used to provide connectivity between two or more service
points. When traffic ingresses via one service point, it is directed to one of the
service points in the service, other than the ingress service point, according to
ingress and egress tunneling rules, and based on the learning and forwarding
mechanism. If the destination MAC address is not known by the learning and
forwarding mechanism, the arriving frame is flooded to all the other service points
in the service except the ingress service point.
Page 215 of 468

The following figure illustrates a Multipoint service.
Multipoint Service
Port 1 SP SP Port 4
SAP SAP
SP
SAP
Port 2 Port 5
SP SP
SAP
SAP
Port 3 Port 6
Figure 138: Multipoint Service
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.
Learning and Forwarding Mechanism

IP-20N can learn up to 131,072 Ethernet source MAC addresses. IP-20N performs
learning per service in order to enable the use of 1025 virtual bridges in the
network element. If necessary due to security issues or resource limitations, users
can limit the size of the MAC forwarding table. The maximum size of the MAC
forwarding table is configurable per service in granularity of 16 entries.
When a frame arrives via a specific service point, the learning mechanism checks
the MAC forwarding table for the service to which the service point belongs to
determine whether that MAC address is known to the service. If the MAC address
is not found, the learning mechanism adds it to the table under the specific
service.
In parallel with the learning process, the forwarding mechanism searches the
service’s MAC forwarding table for the frame’s destination MAC address. If a
match is found, the frame is forwarded to the service point associated with the
MAC address. If not, the frame is flooded to all service points in the service.
Page 216 of 468

The following table illustrates the operation of the learning and forwarding
mechanism.
Table 63: Ethernet Services Learning and Forwarding
MAC Forwarding Table
Input Key for learning / forwarding (search) operation Result Entry type
Service ID MAC address Service Point
95 00:34:67:3a:aa:10 15 dynamic
95 00:0a:25:33:22:12 31 dynamic
128 00:0a:25:11:12:55 31 static
357 00:0a:25:33:22:12 15 dynamic
357 00:c3:20:57:14:89 31 dynamic
357 00:0a:25:11:12:55 31 dynamic
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 (MNG)

The management service connects the two local management ports, the network
element host CPU, and the traffic ports into a single service. The service behavior
is same as the Multipoint service behavior.
The management service is pre-defined in the system, with Service ID 1025. The
pre-defined management service has a single service point that connects the
service to the network element host CPU and the two local management
interfaces. To configure in-band management over multiple network elements,
the user must connect the management service to the network by adding a
service point on an interface that provides the required network connectivity.
Users can modify the attributes of the management service, but cannot delete it.
The CPU service point is read-only and cannot be modified. The local management
ports are also connected to the service, but their service points are not visible to
users. The first management interface is enabled by default. The second
management interface must be manually enabled by the user. The management
Page 217 of 468

ports can be used to manage the network element or to access a remote network
element. They can also be used to manage third-party devices. Users can enable
or disable these ports.
The following figure illustrates a management service.
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
Figure 139: Management Service
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-20N services have the following attributes:
• Service ID – A running number from 1 to 1025 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
reserved 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.
Page 218 of 468

• 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.
• Maximum Dynamic MAC Address Learning per Service – Defines the
maximum number of dynamic Ethernet MAC address that the service can
learn. This parameter is configured with a granularity of 16, and only applies
to dynamic, not static, MAC addresses.
• Static MAC Address Configuration – Users can add static entries to the MAC
forwarding table. The global aging time does not apply to static entries, and
they are not counted with respect to the Maximum Dynamic MAC Address
Learning. It is the responsibility of the user not to use all the 131,072 entries in
the table if the user also wants to utilize dynamic MAC address learning.
• CoS Mode – Defines whether the service inherits ingress classification
decisions made at previous stages or overwrites previous decisions and uses
the default CoS defined for the service. For more details on IP-20N’s
hierarchical classification mechanism, refer to Classification on page 241.
• Default CoS – The default CoS value at the service level. If the CoS Mode is set
to overwrite previous classification decisions, this is the CoS value used for
frames entering the service.
• xSTP Instance (0-46, 4095) – The spanning tree instance ID to which the
service belongs. The service can be a traffic engineering service (instance ID
4095) or can be managed by the xSTP engines of the network element.
6.3.4.3 Service Points

Service points are logical entities attached to the interfaces that make up the
service. Service points define the movement of frames through the service.
Without service points, a service is simply a virtual bridge with no ingress or
egress interfaces.
IP-20N supports several types of service points:
• Management (MNG) Service Point – Only used for management services. The
following figure shows a management service used for in-band management
among four network elements in a ring. In this example, each service contains
three MNG service points, two for East-West management connectivity in the
ring, and one serving as the network gateway.
Page 219 of 468

MNG
MNG MNG
MNG
MNG
MNG MNG
MNG MNG
MNG MNG
MNG
Figure 140: Management Service and its Service Points
• Service Access Point (SAP) Service Point – An SAP is equivalent to a UNI in

MEF terminology and defines the connection of the user network with its
access points. SAPs are used for Point-to-Point and Multipoint traffic services.
• Service Network Point (SNP) Service Point – An SNP is equivalent to an NNI or
E-NNI in MEF terminology and defines the connection between the network
elements in the user network. SNPs are used for Point-to-Point and Multipoint
traffic services.
The following figure shows four network elements in ring. An MP Service with
three service points provides the connectivity over the network. The SNPs
Page 220 of 468

provide the connectivity among the network elements in the user network
while the SAPs provide the access points for the network.
SAP
SNP SNP
SNP
SNP
SAP SAP
SNP SNP
SNP SNP
SAP
Figure 141: SAPs and SNPs
• Pipe Service Point – Used to create traffic connectivity between two points in
a port-based manner (Smart Pipe). In other words, all the traffic from one port
passes to the other port. Pipe service points are used in Point-to-Point
services
The following figure shows a Point-to-Point service with Pipe service points
that create a Smart Pipe between Port 1 of the network element on the left
and Port 2 of the network element on the right.
Pipe Pipe Pipe Pipe
Figure 142: Pipe Service Points
Page 221 of 468

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.
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
Figure 143: SAP, SNP and Pipe Service Points in a Microwave Network
Page 222 of 468

The following table summarizes the service point types available per service type.
Table 64: Service Point Types per Service Type
Service point type
MNG SAP SNP Pipe
Service Type Management Yes No No No

Point-to-Point No Yes Yes Yes
Multipoint No Yes Yes No
Service Point Classification

As explained above, service points connect the service to the network element
interfaces. It is crucial that the network element have a means to classify
incoming frames to the proper service point. This classification process is
implemented by means of a parsing encapsulation rule for the interface
associated with the service point. This rule is called the Attached Interface Type,
and is based on a three-part key consisting of:
• The Interface ID of the interface through which the frame entered.
• The frame’s C-VLAN and/or S-VLAN tags.
The Attached Interface Type provides a definitive mapping of each arriving frame
to a specific service point in a specific service. Since more than one service point
may be associated with a single interface, frames are assigned to the earliest
defined service point in case of conflict.
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.
Page 223 of 468

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.
Table 65: Service Point Types that can Co-Exist on the Same Interface
MNG SP SAP SP SNP SP Pipe SP
MNG SP Only one MNG SP is Yes Yes Yes

allowed per interface.
SAP SP Yes Yes No No
SNP SP Yes No Yes No
PIPE SP Yes No No Only one Pipe SP
is allowed per
interface.
The following table shows in more detail which service point – Attached Interface
Type combinations can co-exist on the same interface.
Page 224 of 468

Table 66: Service Point Type-Attached Interface Type Combinations that can Co-Exist on the Same Interface
SP Type SAP SNP Pipe MNG
SP Attached 802.1q Bundle Bundle All to One QinQ 802.1q S-Tag 802.1q S-Tag 802.1q QinQ S-Tag
Type Interface Type C-Tag S-Tag
SAP 802.1q Yes Yes No No No No No Only for P2P Service No Yes No No
Bundle C-Tag Yes Yes No No No No No Only for P2P Service No Yes No No
Bundle S-Tag No No Yes No Yes No No No No No Yes No
All to One No No No Only 1 All to One No No No No No No No No

SP Per Interface
QinQ No No Yes No Yes No No No No No Yes No
SNP 802.1q No No No No No Yes No Only for P2P Service No Yes No No
S-Tag No No No No No No Yes No Only for P2P No No Yes

Service
Pipe 802.1q Only for Only for No No No Only for No Only one Pipe SP Per No Yes No No
P2P P2P P2P Service Interface
Service Service
S-Tag No No No No No No Only for No Only one Pipe No No Yes

P2P SP Per
Service Interface
MNG 802.1q Yes Yes No No No Yes No Yes No No No No
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
Page 225 of 468

Service Point Attributes

As described above, traffic ingresses and egresses the service via service points.
The service point attributes are divided into two types:
• Ingress Attributes – Define how frames are handled upon ingress, e.g.,
policing and MAC address learning.
• Egress Attributes – Define how frames are handled upon egress, e.g.,
preservation of the ingress CoS value upon egress, VLAN swapping.
The following figure shows the ingress and egress path relationship on a point-to-
point service path. When traffic arrives via port 1, the system handles it using
service point 1 ingress attributes then forwards it to service point 2 and handles it
using the SP2 egress attributes:
SP1 SP2
Ingress Ingress
Port 1 Port 2
Egress Egress
Figure 144: Service Path Relationship on Point-to-Point Service Path
Service points have the following attributes:
General Service Point Attributes

• Service Point ID – Users can define up to 32 service points per service, except
for management services which are limited to 30 service points in addition to
the pre-defined management system service point.
• Service Point Name – A descriptive name, which can be up to 20 characters.
• Service Point Type – The type of service point, as described above.
• S-VLAN Encapsulation – The S-VLAN ID associated with the service point.
• C-VLAN Encapsulation – The C-VLAN ID associated with the service point.
• Attached C VLAN – For service points with an Attached Interface Type of
Bundle C-Tag, this attribute is used to create a list of C-VLANs associated with
the service point.
• Attached S-VLAN – For service points with an Attached Interface Type of
Bundle S-Tag, this attribute is used to create a list of S-VLANs associated with
the service point.
Page 226 of 468

Ingress Service Point Attributes

The ingress attributes are attributes that operate upon frames when they ingress
via the service point.
• Attached Interface Type – The interface type to which the service point is
attached, as described above. Permitted values depend on the service point
type.
• Learning Administration – Enables or disables MAC address learning for traffic
that ingresses via the service point. This option enables users to enable or
disable MAC address learning for specific service points.
• Allow Broadcast – Determines whether to allow frames to ingress the service
via the service point when the frame has a broadcast destination MAC
address.
• Allow Flooding – Determines whether incoming frames with unknown MAC
addresses are forwarded to other service points via flooding.
• CoS Mode – Determines whether the service point preserves the CoS decision
made at the interface level, overwrites the CoS with the default CoS for the
service point.
• Default CoS – The service point CoS. If the CoS Mode is set to overwrite the
CoS decision made at the interface level, this is the CoS value assigned to
frames that ingress the service point.
• Token Bucket Profile – This attribute can be used to attach a rate meter
profile to the service point. Permitted values are 1– 250.
• CoS Token Bucket Profile – This attribute can be used to attach a rate meter
profile to the service point at the CoS level. Users can define a rate meter for
each of the eight CoS values of the service point. Permitted values are 1-250
for CoS 0–7.
• CoS Token Bucket Admin – Enables or disables the rate meter at the service
point CoS level.
Egress Service Point Attributes

The egress attributes are attributes that operate upon frames egressing via the
service point.
• C-VLAN ID Egress Preservation – If enabled, C-VLAN frames egressing the
service point retain the same C-VLAN ID they had when they entered the
service.
• C-VLAN CoS Egress Preservation – If enabled, the C-VLAN CoS value of frames
egressing the service point is the same as the value when the frame entered
the service.
• S-VLAN CoS Egress Preservation – If enabled, the S-VLAN CoS value of frames
egressing the service point is the same as the value when the frame entered
the service.
Page 227 of 468

• Marking – Marking refers to the ability to overwrite the outgoing priority bits
and Color of the outer VLAN of the egress frame, either the C-VLAN or the S-
VLAN. If marking is enabled, the service point overwrites the outgoing priority
bits and Color of the outer VLAN of the egress frame. Marking mode is only
relevant if either the outer frame is S-VLAN and S-VLAN CoS preservation is
disabled, or the outer frame is C-VLAN and C-VLAN CoS preservation is
disabled. When marking is enabled and active, marking is performed
according to global mapping tables that map the 802.1p-UP bits and the DEI or
CFI bit to a defined CoS and Color value.
• Service Bundle ID – This attribute can be used to assign one of the available
service bundles from the H-QoS hierarchy queues to the service point. This
enables users to personalize the QoS egress path. For details, refer to
Standard QoS and Hierarchical QoS (H-QoS)on page 255.
Page 228 of 468

6.3.5 Ethernet Interfaces

The IP-20N switching fabric distinguishes between physical interfaces and logical
interfaces. Physical and logical interfaces serve different purposes in the switching
fabric.
The concept of a physical interface refers to the physical characteristics of the
interface, such as speed, duplex, auto-negotiation, master/slave, and standard
RMON statistics.
A logical interface can consist of a single physical interface or a group of physical
interfaces that share the same function. Examples of the latter are Multi-Carrier
ABC groups, protection groups, and link aggregation (LAG) groups. Switching and
QoS functionality are implemented on the logical interface level.
It is important to understand that the IP-20N switching fabric regards all traffic
interfaces as regular physical interfaces, distinguished only by the media type the
interface uses, e.g., RJ-45, SFP, or Radio.
From the user’s point of view, the creation of the logical interface is simultaneous
with the creation of the physical interface. For example, when the user inserts an
RMC or RIC in the chassis and enables it, both the physical and the logical radio
interface come into being at the same time.
Once the interface is created, the user configures both the physical and the logical
interface. In other words, the user configures the same interface on two levels,
the physical level and the logical level.
The following figure shows physical and logical interfaces in a one-to-one
relationship in which each physical interface is connected to a single logical
interface, without grouping.
Physical Interface 1 Logical Interface SP SP Logical Interface Physical Interface 3
Physical Interface 2 Logical Interface SP SP Logical Interface Physical Interface 4

Service
Figure 145: Physical and Logical Interfaces
Note: For simplicity only, this figure represents a uni-directional rather

than a bi-directional traffic flow.
The next figure illustrates the grouping of two or more physical interfaces into a
logical interface, a link aggregation group (LAG) in this example. The two physical
interfaces on the ingress side send traffic into a single logical interface. The user
configures each physical interface separately, and configures the logical interface
as a single logical entity. For example, the user might configure each physical
interface to 100 Mbps, full duplex, with auto-negotiation off. On the group level,
the user might limit the group to a rate of 200 Mbps by configuring the rate meter
on the logical interface level.
Page 229 of 468

When physical interfaces are grouped into a logical interface, IP-20N 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.
Physical Interface 1 SP Logical Interface Physical Interface 3

SP
fa ce
Inter
Log ical
LAG
Physical Interface 2
SP SP Logical Interface Physical Interface 4

Service
Figure 146: Grouped Interfaces as a Single Logical Interface on Ingress Side

The following figure shows the logical interface at the egress side. In this case, the
user can configure the egress traffic characteristics, such as scheduling, for the
group as a whole as part of the logical interface attributes.
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
Figure 147: Grouped Interfaces as a Single Logical Interface on Egress Side

6.3.5.1 Physical Interfaces

The physical interfaces refer to the real traffic ports (layer 1) that are connected
to the network. The Media Type attribute defines the Layer 1 physical traffic
interface type, which can be:
• Radio interface from an RMC or RIC.
• RJ-45 or SFP from an Ethernet LIC or from one of the Ethernet ports on the
TCC.
• TDM from a TDM LIC.
Page 230 of 468

Physical Interface Attributes

The following physical interface parameters can be configured by users:
• Admin – Enables or disables the physical interface. This attribute is set via the
Interface Manager section of the Web EMS.
• Auto Negotiation – Enables or disables auto-negotiation on the physical
interface. Auto Negotiation is always off for radio, SFP, and TDM (pseudowire)
interfaces.
• Speed and Duplex – The physical interface speed and duplex mode. Permitted
values are:
 Ethernet RJ-45 interfaces: 10Mbps HD, 10Mbps FD, 100Mbps HD, 100Mbps FD,
and 1000Mbps FD.
 Ethernet SFP interfaces: Only 1000FD is supported
 Radio and TDM (pseudowire) interfaces: The parameter is read-only and set by
the system to 1000FD.
• Flow Control – The physical port flow control capability. Permitted values are:
Symmetrical Pause and/or Asymmetrical Pause. This parameter is only
relevant in Full Duplex mode.29
• Media Type – The physical interface Layer 1 media type. This attribute is only
relevant for Ethernet traffic ports (RJ-45 or SFP). Permitted values are Auto
Detect, RJ-45, and SFP. When Auto Detect is selected, the system detects
whether the optical or electrical port is being used. Auto Detect can only be
used when the interface speed is set to 1000 Mbps.
• IFG – The physical port Inter-frame gap. Although users can modify the IFG
field length, it is strongly recommended not to modify the default value of 12
bytes without a thorough understanding of how the modification will impact
traffic. Permitted values are 6 to 15 bytes.
• Preamble – The physical port preamble value. Although users can modify the
preamble field length, it is strongly recommended not to modify the default
values of 8 bytes without a thorough understanding of how the modification
will impact traffic. Permitted values are 6 to 15 bytes.
• Interface description – A text description of the interface, up to 40 characters.
The following read-only physical interface status parameters can be viewed by
users:
• Operational State – The operational state of the physical interface (Up or
Down).
• Actual Speed and Duplex – The actual speed and duplex value for the
Ethernet link as agreed by the two sides of the link after the auto negotiation
process.
• Actual Flow Control State – The actual flow control state values for the
Ethernet link as agreed by the two sides after the auto negotiation process.
29
This functionality is planned for future release.
Page 231 of 468

• Actual Physical Mode (only relevant for RJ-45 interfaces) – The actual physical
mode (master or slave) for the Ethernet link, as agreed by the two sides after
the auto negotiation process.
Ethernet Statistics
The FibeAir IP-20N 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 512-1023 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)
Page 232 of 468

• 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
• 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
6.3.5.2 Logical Interfaces

A logical interface consists of one or more physical interfaces that share the same
traffic ingress and egress characteristics. From the user’s point of view, it is more
convenient to define interface behavior for the group as a whole than for each
individual physical interface that makes up the group. Therefore, classification,
QoS, and resiliency attributes are configured and implemented on the logical
interface level, in contrast to attributes such as interface speed and duplex mode,
which are configured on the physical interface level.
It is important to understand that the user relates to logical interfaces in the same
way in both a one-to-one scenario in which a single physical interface corresponds
to a single logical interface, and a grouping scenario such as a Multi-Carrier ABC
group, a link aggregation (LAG) group, or a radio protection group, in which
several physical interfaces correspond to a single logical interface.
The following figure illustrates the relationship of a 1+1 HSB radio protection
group to the switching fabric. From the point of view of the user configuring the
logical interface attributes, the fact that there are two radios is not relevant. The
user configures and manages the logical interface just as if it represented a single
1+0 radio.
Page 233 of 468

SP SP Logical Interface Physical Interface 3
Radio
Interface 1 Physical Interface 1
HSB Radio Protection Group 1 SP SP Logical Interface Physical Interface 4

Service
Radio Physical Interface 2
Interface 2
Figure 148: Relationship of Logical Interfaces to the Switching Fabric
Logical Interface Attributes

The following logical interface attributes can be configured by users:
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.
Ingress Path Classification at Logical Interface Level

These attributes represent part of the hierarchical classification mechanism, in
which the logical interface is the lowest point in the hierarchy.
• VLAN ID – Users can specify a specific CoS and Color for a specific VLAN ID. In
the case of double-tagged frames, the match must be with the frame’s outer
VLAN. Permitted values are CoS 0 to 7 and Color Green or Yellow per VLAN ID.
This is the highest classification priority on the logical interface level, and
overwrites any other classification criteria at the logical interface level.
• 802.1p Trust Mode – When this attribute is set to Trust mode and the arriving
packet is 802.1Q or 802.1AD, the interface performs QoS and Color
classification according to user-configurable tables for 802.1q UP bit (C-VLAN
frames) or 802.1AD UP bit (S-VLAN frames) to CoS and Color classification.
• MPLS Trust Mode – When this attribute is set to Trust mode and the arriving
packet has MPLS EXP priority bits, the interface performs QoS and Color
classification according to a user-configurable MPLS EXP bit to CoS and Color
classification table. Both 802.1p and DSCP classification have priority over
MPLS Trust Mode, so that if a match is found on either the 802.1p or DSCP
levels, MPLS bits are not considered.
• IP DSCP Trust Mode –When this attribute is set to Trust mode and the arriving
packet has IP priority bits, the interface performs QoS and Color classification
according to a user-configurable DSCP bit to CoS and Color classification table.
802.1p classification has priority over DSCP Trust Mode, so that if a match is
found on the 802.1p level, DSCP bits are not considered.
Page 234 of 468

• 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 242.
Ingress Path Rate Meters at Logical Interface Level

• Unicast Traffic Rate Meter Admin – Enables or disables the unicast rate meter
(policer) on the logical interface.
• Unicast Traffic Rate Meter Profile – Associates the rate meter (policer) with a
specific rate meter (policer) profile.
• Multicast Traffic Rate Meter Admin – Enables or disables the multicast rate
meter (policer) on the logical interface.
• Multicast Traffic Rate Meter Profile – Associates the rate meter (policer) with
a specific rate meter (policer) profile.
• Broadcast Traffic Rate Meter Admin – Enables or disables the broadcast rate
• Broadcast Traffic Rate Meter Profile – Associates the rate meter (policer) with
a specific rate meter (policer) profile.
• Ethertype 1 Rate Meter Admin – Enables or disables the Ethertype 1 rate
• Ethertype 1 Rate Meter Profile – Associates the rate meter (policer) with a
• Ethertype 1 Value – The Ethertype value to which the user wants to apply this
rate meter (policer). The field length is 4 nibbles (for example, 0x0806 - ARP).
• Ethertype 2 Value – The Ethertype value to which the user wants to apply the
• Ethertype 3 Value – The Ethertype value to which the user wants to apply the
• Inline Compensation – The logical interface’s ingress compensation value. The
rate meter (policer) attached to the logical interface uses this value to
compensate for Layer 1 non-effective traffic bytes.
Page 235 of 468

Egress Path Shapers at Logical Interface Level

• Logical Port Shaper Profile – Users can assign a single leaky bucket shaper to
each interface. The shaper on the interface level stops traffic from the
interface if a specific user-defined peak information rate (PIR) has been
exceeded.30
• Outline Compensation – The logical interface’s egress compensation value.
Any shaper attached to this interface, in any layer, uses this value to
compensate for Layer 1 non-effective traffic bytes. Permitted values are even
numbers between 0 and 26 bytes. The default value is 0 bytes.
Egress Path Scheduler at Logical Interface Level

• Logical Interface Priority Profile – This attribute is used to attach an egress
scheduling priority profile to the logical interface.
• Logical Port WFQ Profile – This attribute is used to attach an egress
scheduling WFQ profile to the logical interface. The WFQ profile provides a
means of allocating traffic among queues with the same priority.
The following read-only logical interface status parameters can be viewed by
users:
• Traffic Flow Operational Status – Indicates whether or not the logical
interface is currently functional.
Logical Interface Statistics
RMON Statistics at Logical Interface Level

As discussed in Ethernet Statistics on page 232, if the logical interface represents a
group, such as a LAG or a 1+1 HSB pair, the IP-20N platform stores and displays
RMON and RMON2 statistics for the logical interface.
Rate Meter (Policer) Statistics at Logical Interface Level

For the rate meter (policer) at the logical interface level, users can view the
following statistics counters:
• Green Frames
• Green Bytes
• Yellow Frames
• Yellow Bytes
• Red Frames
• Red Bytes
Note: Rate meter (policer) counters are 64 bits wide.
30
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.
Page 236 of 468

Link Aggregation Groups (LAG) and LACP

Link aggregation (LAG) enables users to group several physical interfaces into a
single logical interface bound to a single MAC address. This logical interface is
known as a LAG group. Traffic sent to the interfaces in a LAG group is distributed
by means of a load balancing function. IP-20N uses a distribution function of up to
Layer 4 in order to generate the most efficient distribution among the LAG
physical ports, taking into account:
• MAC DA and MAC SA
• IP DA and IP SA
• C-VLAN
• S-VLAN
• Layer 3 Protocol Field
• UDP/TCP Source Port and Destination Port
• MPLS Label
For LAG groups that consist of exactly two interfaces, users can change the
distribution function by selecting from ten pre-defined LAG distribution schemes.
The feature includes a display of the TX throughput for each interface in the LAG,
to help users identify the best LAG distribution scheme for their specific link.
LAG can be used to provide redundancy for Ethernet interfaces, both on the same
card (line protection) and on separate cards (line protection and equipment
protection). LAGs can also be used to provide redundancy for radio links.
LAG can also be used to aggregate several interfaces in order to create a wider
(aggregate) Ethernet link. For example, LAG can be used to create a 4 Gbps
channel.
A LAG group can be configured to be automatically closed in the event of LAG
degradation. This option is used if the customer wants traffic from the switch to
be re-routed during such time as the link is providing less than a certain capacity.
When enabled, the LAG is automatically closed in the event that any one or more
ports in the LAG fail. When all ports in the LAG are again operational, the LAG is
automatically re-opened.
Up to four LAG groups can be created.
Note: A LIC-X-E10 can be used in a LAG group with another LIC-X-E-10,
but not with other Ethernet interfaces.
Optionally, if an RX failure occurs in a LAG configuration using an RMC-B, the TX
side of the link is notified immediately and muted automatically, and traffic is
redistributed to the other members of the LAG until the RX failure is corrected.
Additionally, a Radio Remote Fault Indication (RFI) alarm is generated, with Alarm
ID 1783 (Minor). This feature includes a timeout, so that when the RX failure is
corrected, transmission is not resumed until expiration of the timeout. This
eliminates the possibility of a flapping link that could occur in the event of a
recurring radio condition. The timeout can be configured by the user to a value of
10 to 900 seconds. By default, the timeout is 300 seconds.
Page 237 of 468

Link Aggregation Control Protocol (LACP) expands the capabilities of static LAG,
and provides interoperability with third-party equipment that uses LACP. LACP
improves the communication between LAG members. This improves error
detection capabilities in situations such as improper LAG configuration or
improper cabling. It also enables the LAG to detect uni-directional failure and
remove the link from the LAG, preventing packet loss.
IP-20’s LACP implementation does not include write parameters or churn
detection.
Note: LACP is not supported with TCC Redundancy.
LACP can only be used with Ethernet interfaces.
LACP cannot be used with Enhanced LAG Distribution or with the
LAG Group Shutdown in Case of Degradation Event feature.
LAG groups can include interfaces with the following constraints:
• Only physical interfaces (including radio interfaces), not logical interfaces, can
belong to a LAG group.
• Interfaces can only be added to the LAG group if no services or service points
are attached to the interface.
• Any classification rules defined for the interface are overridden by the
classification rules defined for the LAG group.
• When removing an interface from a LAG group, the removed interface is
assigned the default interface values.
IP-20N enables users to select the LAG members without limitations, such as
interface speed and interface type. Proper configuration of a LAG group is the
responsibility of the user.
Page 238 of 468

6.3.6 Quality of Service (QoS)
Related topics:
• Ethernet Service Model
• 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-20N’s personalized QoS enables operators to handle a wide and diverse range
of scenarios. IP-20N’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-20N’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.”
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)
Manager Shaper
Port GE/Radio
(Optional)
Standard QoS/ H-QoS
Egress
Ingress CET/Pipe Marker
Rate Limit Services (Optional)
Manager Shaper
Port GE/Radio
(Optional)
Standard QoS/ H-QoS
Figure 149: QoS Block Diagram
The ingress path consists of the following QoS building blocks:

• Ingress Classifier – A hierarchical mechanism that deals with ingress traffic on
three different levels: interface, service point, and service. The classifier
determines the exact traffic stream and associates it with the appropriate
service. It also calculates an ingress frame CoS and Color. CoS and Color
classification can be performed on three levels, according to the user’s
configuration.
Page 239 of 468

• Ingress Rate Metering – A hierarchical mechanism that deals with ingress

traffic on three different levels: interface, service point, and service point CoS.
The rate metering mechanism enables the system to measure the incoming
frame rate on different levels using a TrTCM standard MEF rate meter, and to
determine whether to modify the color calculated during the classification
stage.
The egress path consists of the following QoS building blocks:
• Queue Manager – This is the mechanism responsible for managing the
transmission queues, utilizing smart WRED per queue and per packet color
(Green or Yellow).
• Scheduling and Shaping – A hierarchical mechanism that is responsible for
scheduling the transmission of frames from the transmission queues, based
on priority among queues, Weighted Fair Queuing (WFQ) in bytes per each
transmission queue, and eligibility to transmit based on required shaping on
several different levels (per queue, per service bundle, and per port).
• Marker – This mechanism provides the ability to modify priority bits in frames
based on the calculated CoS and Color.
The following two modes of operation are available on the egress path:
• Standard QoS – This mode provides eight transmission queues per port.
• Hierarchical QoS (H-QoS) – In this mode, users can associate services from the
service model to configurable groups of eight transmission queues (service
bundles), from a total 8K queues. In H-QoS mode, IP-20N performs QoS in a
hierarchical manner in which the egress path is managed on three levels:
ports, service bundles, and specific queues. This enables users to fully
distinguish between streams, therefore providing a true SLA to customers.
The following figure illustrates the difference between how standard QoS and H-
QoS handle traffic:
Page 240 of 468

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
Figure 150: Standard QoS and H-QoS Comparison
6.3.6.1 QoS on the Ingress Path
Classification
IP-20N 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
Page 241 of 468

The following figure illustrates the hierarchical classification model. In this figure,
traffic enters the system via the port depicted on the left and enters the service
via the SAP depicted on the upper left of the service. The classification can take
place at the logical interface level, the service point level, and/or the service level.
Service point level

• Preserve previous decision
• Default CoS
• Destination MAC Address (MAC DA)
Port Logical Interface
SAP SNP
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
Figure 151: Hierarchical Classification
Logical Interface-Level Classification

Logical interface-level classification enables users to configure classification on a
single interface or on a number of interfaces grouped tougher, such as a LAG
group.
The classifier at the logical interface level supports the following classification
methods, listed from highest to lowest priority. A higher level classification
method supersedes a lower level classification method:
 VLAN ID
 802.1p bits.
 MPLS EXP field.
 DSCP bits.
 Default CoS
IP-20N performs the classification on each frame ingressing the system via the
logical interface. Classification is performed step by step from the highest priority
to the lowest priority classification method. Once a match is found, the classifier
determines the CoS and Color decision for the frame for the logical interface-level.
For example, if the frame is an untagged IP Ethernet frame, a match will not be
found until the third priority level (DSCP priority bits). The CoS and Color values
defined for the frame’s DSCP priority bits will be applied to the frame.
Users can disable some of these classification methods by configuring them as un-
trusted. For example, if 802.1p classification is configured as un-trusted for a
specific interface, the classification mechanism does not perform classification by
VLAN UP bits. This is useful, for example, if the required classification is based on
DSCP priority bits.
Page 242 of 468

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.
Highest
Priority
VLAN ID 802.1p DSCP MPLS EXP Default CoS
Lowest
Priority
Figure 152: Classification Method Priorities
Interface-level classification is configured as part of the logical interface

configuration. For details, refer to Ingress Path Classification at Logical Interface
Level on page 234.
The following tables show the default values for logical interface-level
classification. The key values for these tables are the priority bits of the respective
frame encapsulation layers (VLAN, IP, and MPLS), while the key results are the CoS
and Colors calculated for incoming frames. These results are user-configurable,
but it is recommended that only advanced users should modify the default values.
Table 67: C-VLAN 802.1 UP and CFI Default Mapping to CoS and Color
802.1 UP CFI CoS (configurable) Color (configurable)
0 0 0 Green
0 1 0 Yellow
1 0 1 Green
1 1 1 Yellow
2 0 2 Green
2 1 2 Yellow
3 0 3 Green
3 1 3 Yellow
4 0 4 Green
4 1 4 Yellow
5 0 5 Green
5 1 5 Yellow
6 0 6 Green
Page 243 of 468

802.1 UP CFI CoS (configurable) Color (configurable)
6 1 6 Yellow
7 0 7 Green
7 1 7 Yellow
Table 68: S-VLAN 802.1 UP and DEI Default Mapping to CoS and Color
802.1 UP DEI CoS (Configurable) Color (Configurable)
0 0 0 Green
0 1 0 Yellow
1 0 1 Green
1 1 1 Yellow
2 0 2 Green
2 1 2 Yellow
3 0 3 Green
3 1 3 Yellow
4 0 4 Green
4 1 4 Yellow
5 0 5 Green
5 1 5 Yellow
6 0 6 Green
6 1 6 Yellow
7 0 7 Green
7 1 7 Yellow
Table 69: MPLS EXP Default Mapping to CoS and Color
MPLS EXP bits CoS (configurable) Color (configurable)
0 0 Yellow
1 1 Green
2 2 Yellow
3 3 Green
4 4 Yellow
5 5 Green
6 6 Green
7 7 Green
Page 244 of 468

Table 70: DSCP Default Mapping to CoS and Color
DSCP DSCP (bin) Description CoS (Configurable) Color (Configurable)
0 (default) 000000 BE (CS0) 0 Green

10 001010 AF11 1 Green
12 001100 AF12 1 Yellow
14 001110 AF13 1 Yellow
18 010010 AF21 2 Green
20 010100 AF22 2 Yellow
22 010110 AF23 2 Yellow
26 011010 AF31 3 Green
28 011100 AF32 3 Yellow
30 011110 AF33 3 Yellow
34 100010 AF41 4 Green
36 100100 AF42 4 Yellow
38 100110 AF43 4 Yellow
46 101110 EF 7 Green
8 001000 CS1 1 Green
16 010000 CS2 2 Green
24 011000 CS3 3 Green
32 100000 CS4 4 Green
40 101000 CS5 5 Green
48 110000 CS6 6 Green
51 110011 DSCP_51 6 Green
52 110100 DSCP_52 6 Green
54 110110 DSCP_54 6 Green
56 111000 CS7 7 Green
Default value is CoS equal best effort and Color equal Green.
Service Point-Level Classification

Classification at the service point level enables users to give special treatment, in
higher resolution, to specific traffic flows using a single interface to which the
service point is attached. The following classification modes are supported at the
service point level. Users can configure these modes by means of the service point
CoS mode.
 Preserve previous CoS decision (logical interface level)
Page 245 of 468

 Default service point CoS

 MAC DA
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.
If the service point CoS mode is configured as MAC DA, frames ingressing the
service point are classified according to their Destination MAC Address (MAC DA).
This gives IP-20N the ability to identify and give priority to frames that lack priority
information, such as untagged non-IP frames.
Two common scenarios in which non-IP frames require prioritization are:
• Networks using IS-IS link state protocol
• Business enterprises using untagged traffic
Up to 64 MAC addresses can be defined per device, including four predefined
MAC addresses. Users can assign each of these MAC addresses a CoS value and a
color.
The following MAC addresses are predefined, with a high priority (CoS=7,
Color=Green). Users can edit or delete these MAC addresses:
• 09:00:2B:00:00:04
• 09:00:2B:00:00:05
• 01:80:C2:00:00:14
• 01:80:C2:00:00:15
These are protocol MAC addresses used to transport IS-IS frames as defined in ISO
9542 and ISO/IEC 10589.
When MAC DA is selected, the MAC DA is the first criterion used to classify frames
ingressing the interface on which the service point is defined.
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.
Page 246 of 468

Rate Meter (Policing)

IP-20N’s TrTCM rate meter mechanism complies with MEF 10.2, and is based on a
dual leaky bucket mechanism. The TrTCM rate meter can change a frame’s CoS
settings based on CIR/EIR+CBS/EBS, which makes the rate meter mechanism a key
tool for implementing bandwidth profiles and enabling operators to meet strict
SLA requirements.
The IP-20N hierarchical rate metering mechanism is part of the QoS performed on
the ingress path, and consists of the following levels:
• Logical interface-level rate meter
• Service point-level rate meter31
• Service point CoS-level rate meter32
MEF 10.2 is the de-facto standard for SLA definitions, and IP-20N’s QoS
implementation provides the granularity necessary to implement service-oriented
solutions.
Hierarchical rate metering enables users to define rate meter policing for
incoming traffic at any resolution point, from the interface level to the service
point level, and even at the level of a specific CoS within a specific service point.
This option enables users to customize a set of eight policers for a variety of traffic
flows within a single service point in a service.
Another important function of rate metering is to protect resources in the
network element from malicious users sending traffic at an unexpectedly high
rate. To prevent this, the rate meter can cut off traffic from a user that passes the
expected ingress rate.
TrTCM rate meters use a leaky bucket mechanism to determine whether frames
are marked Green, Yellow, or Red. Frames within the Committed Information Rate
(CIR) or Committed Burst Size (CBS) are marked Green. Frames within the Excess
Information Rate (EIR) or Excess Burst Size (EBS) are marked Yellow. Frames that
do not fall within the CIR/CBS+EIR/EBS are marked Red and dropped, without
being sent any further.
IP-20N provides up to 1120 user-defined TrTCM rate meters. The rate meters
implement a bandwidth profile, based on CIR/EIR, CBS/EBS, Color Mode (CM), and
Coupling flag (CF). Up to 250 different profiles can be configured.
Ingress rate meters operate at three levels:
• Logical Interface:
 Per frame type (unicast, multicast, and broadcast)
 Per frame ethertype
• Per Service Point
• Per Service Point CoS
31
Service point-level rate metering is planned for future release.
32
Service point and CoS-level rate metering is planned for future release.
Page 247 of 468

CoS 1
Service Frame
CoS 2 Ethertype
Point Type
CoS 3
Figure 153: Ingress Policing Model
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.
Global Rate Meter Profiles

Users can define up to 250 rate meter user profiles. The following parameters can
be defined for each profile:
• Committed Information Rate (CIR) – Frames within the defined CIR are
marked Green and passed through the QoS module. Frames that exceed the
CIR rate are marked Yellow. The CIR defines the average rate in bits/s of
Service Frames up to which the network delivers service frames and meets the
performance objectives. Permitted values are 0 to 1 Gbps, with a minimum
granularity of 32Kbps.
• 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 0 to 8192 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 0 to 8192 Kbytes, with a minimum granularity of 2 Kbytes.
Page 248 of 468

• 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 233.
• 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.
Rate Metering (Policing) at the Logical Interface Level

Rate metering at the logical interface level supports the following:
• Unicast rate meter
• Multicast rate meter
• Broadcast rate mete
• User defined Ethertype 1 rate meter
For each rate meter, the following statistics are available:
• Green Frames (64 bits)
• Green Bytes (64 bits)
• Yellow Frames (64 bits)
• Yellow Bytes (64 bits)
• Red Frames (64 bits)
• Red Bytes (64 bits)
Page 249 of 468

Rate Metering (Policing) at the Service Point Level

Users can define a single rate meter on each service point, up to a total number of
1024 rate meters per network element at the service point and CoS per service
point levels.
The following statistics are available for each service point rate meter:
Rate Metering (Policing) at the Service Point + CoS Level

Users can define a single rate meter for each CoS on a specific service point, up to
a total number of 1024 rate meters per network element at the service point and
CoS per service point levels.
The following statistics are available for each service point + CoS rate meter:
6.3.6.2 QoS on the Egress Path
Queue Manager
The queue manager (QM) is responsible for managing the output transmission
queues. IP-20N supports up to 8192 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
4 Gigabits.
The following considerations should be taken into account in determining the
proper buffer size:
• Latency considerations – If low latency is required (users would rather drop
frames in the queue than increase latency) small buffer sizes are preferable.
• Throughput immunity to fast bursts – When traffic is characterized by fast
bursts, it is recommended to increase the buffer sizes to prevent packet loss.
Of course, this comes at the cost of a possible increase in latency.
Users can configure burst size as a tradeoff between latency and immunity to
bursts, according the application requirements.
Page 250 of 468

The 8192 queues are ordered in groups of eight queues. These eight queues
correspond to CoS values, from 0 to 7; in other words, eight priority queues.
The following figure depicts the queue manager. Physically, the queue manager is
located between the ingress path and the egress path.
Traffic Flow CoS0

CoS1
SP1 CoS2
SP3
CoS3 Service Bundle 1
CoS4 (8 Queues)
Multipoint
Service CoS5
CoS6
SP2 SP7 CoS7
CoS0
CoS1
SP2 SP3
CoS2

Multipoint SP1 SP5 (8 Queues)
CoS4
Service
CoS5
WRED
SP7 SP6 CoS6
CoS7
CoS0
SP1
Drop Ratio CoS1
(%) CoS2
Queue
Multipoint SP3 CoS3 Service Bundle 3
Occupancy (KB)
Service CoS4 (8 Queues)
SP2 CoS5
CoS6
CoS7
Point to Point SP1

SP2
Service
CoS0
CoS1
CoS2

SP1 (8 Queues)
CoS4
CoS5
Multipoint SP3 CoS6
Service CoS7
SP2
Figure 154: IP-20N Queue Manager
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.
Page 251 of 468

The 8192 queues share a single memory of 4 Gbits. IP-20N 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 252.
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.
Figure 155: Synchronized Packet Loss
WRED eliminates the occurrence of traffic congestion peaks by restraining the

transmission rate of the TCP flows. Each queue occupancy level is monitored by
the WRED mechanism and randomly selected frames are dropped before the
queue becomes overcrowded. Each TCP flow recognizes a frame loss and restrains
its transmission rate (basically by reducing the window size). Since the frames are
dropped randomly, statistically each time another flow has to restrain its
transmission rate as a result of frame loss (before the real congestion occurs). In
this way, the overall aggregated load on the radio link remains stable while the
transmission rate of each individual flow continues to fluctuate similarly. The
following figure demonstrates the transmission rate of two TCP flows and the
aggregated load over time when WRED is enabled.
Page 252 of 468

Figure 156: Random Packet Loss with Increased Capacity Utilization Using WRED
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-20N 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-20N 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-20N also includes two pre-defined read-only WRED profiles:
• Profile number 31 defines a tail-drop curve and is configured with the
following values:
 100% Yellow traffic drop after 64kbytes occupancy.
 100% Green traffic drop after 128kbytes occupancy.
 Yellow maximum drop is 100%
 Green maximum drop is 100%
• Profile number 32 defines a profile in which all will be dropped. It is for
internal use and should not be applied to traffic.
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.
Page 253 of 468

The following figure provides an example of a WRED profile.

Probability to drop [%]
Yellow max Green max

threshold threshold
100
Yellow max
drop ratio
Green max
drop ratio
Queue depth [bytes]
Yellow min Green min
threshold threshold
Figure 157: WRED Profile Curve
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.
Global WRED Profile Configuration

IP-20N supports 30 user-configurable WRED profiles and one pre-defined (default)
profile. The following are the WRED profile attributes:
• Green Minimum Threshold – Permitted values are 0 Kbytes to 8 Mbytes, with
• Green Maximum Threshold – Permitted values are 0 Kbytes to 8 Mbytes, with
• Green-Maximum Drop – Permitted values are 1% to 100%, with 1% drop
granularity.
• Yellow Minimum Threshold – Permitted values are 0 Kbytes to 8 Mbytes, with
• Yellow Maximum Threshold – Permitted values are 0 Kbytes to 8 Mbytes,
with granularity of 8 Kbytes.
• Yellow Maximum Drop – Permitted values are 1% to 100%, with 1% drop
granularity.
Notes: K is equal to 1024.
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.
Page 254 of 468

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.
Standard QoS and Hierarchical QoS (H-QoS)

In a standard QoS mechanism, egress data is mapped to a single egress interface.
This single interface supports up to eight priority queues, which correspond to the
CoS of the data. Since all traffic for the interface egresses via these queues, there
is no way to distinguish between different services and traffic streams within the
same priority.
The figure below shows three services, each with three distinct types of traffic
streams:
• Voice – high priority
• Data – medium priority
• Streaming – lower priority
While the benefits of QoS on the egress path can be applied to the aggregate
streams, without H-QoS they will not be able to distinguish between the various
services included in these aggregate streams. Moreover, different behavior
among the different traffic streams that constitute the aggregate stream can
cause unpredictable behavior between the streams. For example, in a situation in
which one traffic stream can transmit 50 Mbps in a shaped manner while another
can transmit 50 Mbits in a burst, frames may be dropped in an unexpected way
due to a lack of space in the queue resulting from a long burst.
Hierarchical QoS (H-QoS) solves this problem by enabling users to create a real
egress tunnel for each stream, or for a group of streams that are bundled
together. This enables the system to fully perform H-QoS with a top-down
resolution, and to fully control the required SLA for each stream.
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 8192
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.
Page 255 of 468

The service bundle level represents the groups of eight priority queues. Every
eight queues are managed as a single service bundle. There are a total number of
1024 service bundles.
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 16 physical interfaces
• One service bundle per interface in standard QoS / 1024 service bundles in H-
QoS.
• Eight queues per service bundle
H-QoS on the Interface Level

Users can assign a single leaky bucket shaper to each interface. The shaper on the
interface level stops traffic from the interface if a specific user-defined peak
information rate (PIR) has been exceeded.
In addition, users can configure scheduling rules for the priority queues, as
follows:
• Scheduling (serve) priorities among the eight priority queues.
• Weighted Fair Queuing (WFQ) among queues with the same priority.
Note: The system assigns the rules for all service bundles under the
interface.
RMON counters are valid on the interface level.
H-QoS on the Service Bundle Level

Users can assign a dual leaky bucket shaper to each service bundle. On the service
bundle level, the shaper changes the scheduling priority if traffic via the service
bundle is above the user-defined CIR and below the PIR. If traffic is above the PIR,
the scheduler stops transmission for the service bundle.
Service bundle traffic counters are valid on this level.
Note: With standard QoS, users assign the egress traffic to a single
service bundle (Service Bundle ID 1).
H-QoS on the Queue Level

The egress service point points to a specific service bundle. Depending on the user
application, the user can connect either a single service point or multiple service
points to a service bundle. Usually, if multiple service points are connected to a
service bundle, the service points will share the same traffic type and
characteristics. Mapping to the eight priority queues is based on the CoS
calculated on the ingress path, before any marking operation, which only changes
the egress CoS and Color.
Users can assign a single leaky bucket to each queue. The shaper on the queue
level stops traffic from leaving the queue if a specific user-defined PIR has been
exceeded.
Page 256 of 468

Traffic counters are valid on this level.

The following figure provides a detailed depiction of the H-QoS levels.
Priority 4 (Highest)
Priority 3
Priority 2
Priority 1 (Lowest)
Queues (CoS) Service Bundle Port

Service Point
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
Figure 158: Detailed H-QoS Diagram
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.
Page 257 of 468

Shaping on the Egress Path

Egress shaping determines the traffic profile for each queue. IP-20N performs
egress shaping on the following three levels:
• Queue level – Single leaky bucket shaping.
• Service Bundle level – Dual leaky bucket shaping
• Interface level – Single leaky bucket shaping
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
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.
Service Bundle Shapers

Users can configure up to 255 dual leaky bucket shaper profiles. The profiles can
be configured as follows:
• Valid CIR values are:
 0 – 32,000,000 bps – granularity of 16,000 bps
 32,000,000 – 1,000,000,000 bps – granularity of 64,000 bps
• Valid PIR values are:
 16,000 – 32,000,000 bps – granularity of 16,000 bps
 32,000,000 – 1,000,000,000 bps – granularity of 64,000 bps
Users can attach one of the configured service bundle shaper profiles to each
service bundle. If no profile is attached to the service bundle, no egress shaping is
performed on that service bundle.
Page 258 of 468

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
• 131,072,000 – 999,424,000 bps – granularity of 8,192,000 bps
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.
Line Compensation for Shaping

Users can configure a line compensation value for all the shapers under a specific
logical interface. For more information, refer to Global Rate Meter Profiles on
page 248.
Egress Scheduling
Egress scheduling is responsible for transmission from the priority queues. IP-20N
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 64 per port)
are valid.
Page 259 of 468

Figure 159: Scheduling Mechanism for a Single Service Bundle
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.
The following table provides a sample of an interface priority profile. This profile is
also used as the default interface priority profile.
Page 260 of 468

Table 71: QoS Priority Profile Example
Profile ID (1-9)
CoS Green Priority Yellow Priority (read Description

(user defined) only)
0 1 1 Best Effort
1 2 1 Data Service 4
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.
The following interface priority profile parameters can be configured by users:
• Profile ID – Profile ID number. Permitted values are 1 to 8.
• CoS 0 Priority – CoS 0 queue priority, from 4 (highest) to 1 (lowest).
• CoS 0 Description – CoS 0 user description field, up to 20 characters.
Page 261 of 468


Users can attach one of the configured interface priority profiles to each interface.
By default, the interface is assigned Profile ID 9, the pre-defined system profile.
Weighted Fair Queuing (WFQ)

As described above, the scheduler serves the queues based on their priority, but
when two or more queues have data to transmit and their priority is the same,
the scheduler uses Weighted Fair Queuing (WFQ) to determine the priorities
within each priority. WFQ defines the transmission ratio, in bytes, between the
queues. All the service bundles under the interface inherit the WFQ profile
attached to the interface.
The system supports up to six WFQ interface profiles. Profile ID 1 is a pre-defined
read-only profile, and is used as the default profile. Profiles 2 to 6 are user-
defined profiles.
The following table provides an example of a WFQ profile.
Table 72: WFQ Profile Example
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
For each CoS, the user can define;

• Profile ID – Profile ID number. Permitted values are 2 to 6.
• Weight – Transmission quota in bytes. Permitted values are 1 to 20.
Users can attach one of the configured interface WFQ profiles to each interface.
By default, the interface is assigned Profile ID 1, the pre-defined system profile.
Page 262 of 468

Egress PMs and Statistics
Queue-Level Statistics
IP-20N 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)
Service Bundle-Level Statistics

IP-20N supports the following counters per service bundle at the service bundle
level:
• Transmitted Green Packets (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)
Page 263 of 468

PMs for Queue Traffic

For each logical interface, users can configure thresholds for Green and Yellow
traffic per queue. Users can then display the following PMs for 15-minute and 24-
hour intervals, per queue and color:
• Maximum bytes passed per second
• Minimum bytes passed per second
• Average bytes passed per second
• Maximum bytes dropped per second
• Minimum bytes dropped per second
• Average bytes dropped per second
• Maximum packets passed per second
• Minimum packets passed per second
• Average packets passed per second
• Maximum packets dropped per second
• Minimum packets dropped per second
• Average packets dropped per second
• Seconds bytes per second were over the configured threshold per interval
Interface-Level Statistics
For information on statistics at the interface level, refer to Ethernet Statistics on
page 232.
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.
Page 264 of 468

Table 73: 802.1q UP Marking Table (C-VLAN)
CoS Color 802.1q UP (Configurable) CFI Color (Configurable)
0 Green 0 0
0 Yellow 0 1
1 Green 1 0
1 Yellow 1 1
2 Green 2 0
2 Yellow 2 1
3 Green 3 0
3 Yellow 3 1
4 Green 4 0
4 Yellow 4 1
5 Green 5 0
5 Yellow 5 1
6 Green 6 0
6 Yellow 6 1
7 Green 7 0
7 Yellow 7 1
Table 74: 802.1ad UP Marking Table (S-VLAN)
CoS Color 802.1ad UP (configurable) DEI Color (configurable)
0 Green 0 0
0 Yellow 0 1
1 Green 1 0
1 Yellow 1 1
2 Green 2 0
2 Yellow 2 1
3 Green 3 0
3 Yellow 3 1
4 Green 4 0
4 Yellow 4 1
5 Green 5 0
5 Yellow 5 1
Page 265 of 468

CoS Color 802.1ad UP (configurable) DEI Color (configurable)
6 Green 6 0
6 Yellow 6 1
7 Green 7 0
7 Yellow 7 1
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.
Standard QoS and Hierarchical QoS (H-QoS) Summary

The following table summarizes and compares the capabilities of standard QoS
and H-QoS.
Table 75: Summary and Comparison of Standard QoS and H-QoS
Capability Standard QoS Hierarchical QoS
Number of transmission queues 8 512

per port
Number of service bundles 1 (always service bundle id equal 64
1)
WRED Per queue (two curves – for Per queue (two curves – for green traffic
green traffic and for yellow traffic and for yellow traffic via the queue)
via the queue)
Shaping at queue level Single leaky bucket Single leaky bucket
Shaping at service bundle level Dual leaky bucket Dual leaky bucket
Shaping at port level Single leaky bucket (this level is Single leaky bucket
not relevant since it is
recommended to use service
bundle level with dual leaky
bucket)
Transmission queues priority Per queue priority (4 priorities). Per queue priority (4 priorities). All
service bundles for a specific port inherit
the 8-queues priority settings.
Weighted fair Queue (WFQ) Queue level (between queues) Queue level (between queues)
Service Bundle level (between service
bundles)
Marker Supported Supported
Statistics Queue level (8 queues) Queue level (512 queues)
Service bundle level (1 service Service bundle level (64 service bundles)
bundle) Port level
Port level
Page 266 of 468

6.3.7 Global Switch Configuration

The following parameters are configured globally for the IP-20N switch:
• S- VLAN Ethertype –Defines the ethertype recognized by the system as the S-
VLAN ethertype. IP-20N supports the following S-VLAN ethertypes:
 0x8100
 0x88A8 (default)
 0x9100
 0x9200
• C-VLAN Ethertype – Defines the ethertype recognized by the system as the C-
VLAN ethertype. IP-20N supports 0x8100 as the C-VLAN ethertype.
• MRU – The maximum segment size defines the maximum receive unit (MRU)
capability and the maximum transmit capability (MTU) of the system. Users
can configure a global MRU for the system. Permitted values are 64 bytes to
9612 bytes.
6.3.8 Automatic State Propagation and Link Loss Forwarding
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.
6.3.8.1 Automatic State Propagation Operation

Automatic state propagation is configured as pairs of interfaces. Each interface
pair includes one Monitored Interface and one Controlled Interface. Multiple pairs
can be configured using the same Monitored Interface and multiple Controlled
Interfaces.
The Monitored Interface is a radio interface, a radio protection group, or a Multi-
Carrier ABC group. The Controlled Interface is an Ethernet interface or LAG. An
Ethernet interface can only be assigned to one Monitored interface.
Each Controlled Interface is assigned an LLF ID. If ASP trigger by remote fault is
enabled on the remote side of the link, the ASP state of the Controlled Interface is
propagated to the Controlled Interface with the same LLF ID at the remote side of
the link. This means if ASP is triggered locally, it is propagated to the remote side
of the link, but only to Controlled Interfaces with LLF IDs that match the LLF IDs of
the affected Controlled Interfaces on the local side of the link.
Page 267 of 468

The following events in the Monitored Interface trigger ASP:

• Radio LOF
• Radio Excessive BER
• Remote Radio LOF
• Remote Excessive BER
• Remote LOC
The user can also configure the ASP pair so that Radio LOF, Radio Excessive BER,
or loss of the Ethernet connection at the remote side of the link will also trigger
ASP.
When a triggering event takes place:
• If the Controlled Interface is an electrical GbE port, the port is closed.
• If the Controlled Interface is an optical GbE port, the port is muted.
The Controlled Interface remains closed or muted until all triggering events are
cleared.
In addition, when a local triggering event takes place, the ASP mechanism sends
an indication to the remote side of the link. Even when no triggering event has
taken place, the ASP mechanism sends periodic update messages indicating that
no triggering event has taken place.
Users can configure a trigger delay time, so that when a triggering event takes
place, the ASP mechanism does not propagate the event until this delay time has
elapsed.
6.3.8.2 Automatic State Propagation and Protection

When the Controlled Interface is part of a 1+1 protection pair, a port shutdown
message is only sent to the remote side of the link if both of the protected
interfaces are shut down.
When the Monitored interface is part of a 1+1 HSB configuration, ASP is only
triggered if both interfaces fail.
Closing an Ethernet port because of ASP does not trigger a protection switch.
6.3.9 Network Resiliency

IP-20N provides carrier-grade service resiliency using the following protocols:
• G.8032 Ethernet Ring Protection Switching (ERPS)
• Multiple Spanning Tree Protocol (MSTP)
These protocols are designed to prevent loops in ring/mesh topologies.
Page 268 of 468

6.3.9.1 G.8032 Ethernet Ring Protection Switching (ERPS)

ERPS, as defined in the G.8032 ITU standard, is currently the most advanced ring
protection protocol, providing convergence times of sub-50ms. ERPS prevents
loops in an Ethernet ring by guaranteeing that at any time, traffic can flow on all
except one link in the ring. This link is called the Ring Protection Link (RPL). Under
normal conditions, the RPL is blocked, i.e., not used for traffic. One designated
Ethernet Ring Node, the RPL Owner Node, is responsible for blocking traffic at one
end of the RPL. When an Ethernet ring failure occurs, the RPL Owner unblocks its
end of the RPL, allowing the RPL to be used for traffic. The other Ethernet Ring
Node adjacent to the RPL, the RPL Neighbor Node, may also participate in
blocking or unblocking its end of the RPL. A number of ERP instances (ERPIs) can
be created on the same ring.
Note: P2P services are not affected by G.8032, and continue to traverse
ports that are blocked by G.8032.
G.8032 ERPS Benefits

ERPS, as the most advanced ring protection protocol, provides the following
benefits:
• Provides sub-50ms convergence times.
• Provides service-based granularity for load balancing, based on the ability to
configure multiple ERPIs on a single physical ring.
• Provides configurable timers to control switching and convergence
parameters per ERPI.
G.8032 ERPS Operation

The ring protection mechanism utilizes an APS protocol to implement the
protection switching actions. Forced and manual protection switches can also be
initiated by the user, provided the user-initiated switch has a higher priority than
any other local or far-end request.
Ring protection switching is based on the detection of defects in the transport
entity of each link in the ring. For purposes of the protection switching process,
each transport entity within the protected domain has a state of either Signal Fail
(SF) or Non-Failed (OK). R-APS control messages are forwarded by each node in
the ring to update the other nodes about the status of the links.
Note: An additional state, Signal Degrade (SD), is planned for future
release. The SD state is similar to SF, but with lower priority.
Users can configure up to 16 ERPIs. Each ERPI is associated with an Ethernet
service defined in the system. This enables operators to define a specific set of
G.8032 characteristics for individual services or groups of services within the 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.
Page 269 of 468

• 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.
RPL
IP-20N
(Blocked)
Ring Node 1
Wireless Ring IP-20N

Ring Node 4
(RPL Owner)
IP-20N
Ring Node 2
IP-20N
Ring Node 3
R-APS Messages
Traffic
Figure 160: G.8032 Ring in Idle (Normal) State
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.
Page 270 of 468

IP-20N RPL
(Unblocked)
Ring Node 1
Signal
Failure

Ring Node 4
(RPL Owner)
IP-20N
Ring Node 2
IP-20N
Ring Node 3
R-APS Messages
Traffic
Figure 161: G.8032 Ring in Protecting State
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.
RPL for
IP-20N
ERPI 1
Ring Node 1
RPL for
ERPI 2
Ring Node 4
RPL for
RPL for
ERPI 4
ERPI 3
IP-20N
Ring Node 2
IP-20N
Ring Node 3
ERPI 1 Traffic
ERPI 2 Traffic
ERPI 3 Traffic
ERPI 4 Traffic
Figure 162: Load Balancing Example in G.8032 Ring
Page 271 of 468

G.8032 Interoperability
G.8032 in IP-20N units is interoperable with IP-20G units running G.8032, as well
as third-party bridges running standard implementations of G.8032.
6.3.9.2 Multiple Spanning Tree Protocol (MSTP)

MSTP, as defined in IEEE 802.1q, provides full connectivity for frames assigned to
any given VLAN throughout a bridged LAN consisting of arbitrarily interconnected
bridges.
With MSTP, an independent multiple spanning tree instance (MSTI) is configured
for each group of services, and only one path is made available (unblocked) per
spanning tree instance. This prevents network loops and provides load balancing
capability. It also enables operators to differentiate among Ethernet services by
mapping them to different, specific MSTIs. The maximum number of MSTIs is
configurable, from 2 to 16.
Note: P2P services are not affected by MSTP, and continue to traverse
ports that are blocked by MSTP.
MSTP is an extension of, and is backwards compatible with, Rapid Spanning Tree
Protocol (RSTP).
IP-20N supports MSTP according to the following IEEE standards:
• 802.1q
• 802.1ad amendment (Q-in-Q)
• 802.1ah (TE instance)
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.
Page 272 of 468

• 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.
Page 273 of 468

• 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-20N units is interoperable with:
• FibeAir IP-20G units running MSTP.
• Third-party bridges running MSTP.
• FibeAir IP-10 units running RSTP.
• Third-party bridges running RSTP.
Page 274 of 468

6.3.10 OAM
FibeAir IP-20N 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-20N is fully compliant with G.8013/Y.1731, MEF-17, MEF-20, MEF-30, and
MEF-31.
Figure 163: IP-20N End-to-End Service Management
6.3.10.1 Connectivity Fault Management (FM)

The Y.1731 standard and the, MEF-30 specifications define SOAM. SOAM is
concerned with detecting, isolating, and reporting connectivity faults spanning
networks comprising multiple LANs, including LANs other than IEEE 802.3 media.
Y.1731 Ethernet FM (Connectivity Fault Management) consists of three protocols
that operate together to aid in fault management:
• Continuity check
• Link trace
• Loopback
Note: Link trace is planned for future release.
FibeAir IP-20N utilizes these protocols to maintain smooth system operation and
non-stop data flow.
Page 275 of 468

The following are the basic building blocks of FM:

• Maintenance domains, their constituent maintenance points, and the
managed objects required to create and administer them.
Figure 164: SOAM Maintenance Entities (Example)
• Protocols and procedures used by maintenance points to maintain and

diagnose connectivity faults within a maintenance domain.
 CCM (Continuity Check Message): CCM can detect Connectivity Faults (loss of
connectivity or failure in the remote MEP).
 Loopback: LBM/LBR mechanism is an on-demand mechanism. It is used to verify
connectivity from any MEP to any certain Maintenance Point in the MA/MEG. A
session of loopback messages can include up to 1024 messages with varying
intervals ranging from 1 to 60 seconds. Message size can reach jumbo frame size.
 Linktrace: The LTM/LTR mechanism is an on-demand mechanism. It can detect the
route of the data from any MEP to any other MEP in the MA/MEG. It can be used
for the following purposes:
◦ Adjacent relation retrieval – The ETH-LT function can be used to
retrieve the adjacency relationship between an MEP and a remote
MEP or MIP. The result of running ETH-LT function is a sequence of
MIPs from the source MEP until the target MIP or MEP.
◦ Fault localization – The ETH-LT function can be used for fault
localization. When a fault occurs, the sequence of MIPs and/or MEP
will probably be different from the expected sequence. The difference
between the sequences provides information about the fault location.
◦ AIS: AIS (defined in Y.1731) is the Ethernet alarm indication signal
function used to suppress alarms following detection of defect
conditions at the server (sub) layer.
Page 276 of 468

6.3.10.2 Ethernet Line Interface Loopback

FibeAir IP-20N supports loopback testing for its radio and TDM interfaces, which
enables loopback testing of the radio and TDM traffic interfaces as well as the
IDU-RFU connection.
Note: To perform radio loopback, the radio must be set to its maximum
TX power.
In addition, the Ethernet Line Interface Loopback feature provides the ability to
run loopbacks over the link. When Ethernet loopback is enabled on an interface,
the system loops back all packets ingressing the interface. This enables loopbacks
to be performed over the link from other points in the network.
For example, as shown in the figure below, a loopback can be performed from
test equipment over the line to an Ethernet interface. A loopback can also be
performed from the other side of the radio link.
Loopback on
Radio Link
IP-20N IP-20N
Loopback from Test

Equipment to IP-20N
Ethernet Interface
Test
Equipment
Figure 165: Ethernet Line Interface Loopback – Application Examples
Ethernet loopbacks can be performed on any logical interface. This includes

optical and electrical GbE interfaces, radio interfaces, Multi-Carrier ABC groups,
LAGS, and 1+1 HSB groups. Ethernet loopbacks cannot be performed on the
management interfaces.
The following parameters can be configured for an Ethernet loopback:
• The interface can be configured to swap DA and SA MAC addresses during the
loopback. This prevents Ethernet loops from occurring. It is recommended to
enable MAC address swapping if MSTP or LLDP is enabled.
• Ethernet loopback has a configurable duration period of up to 15 minutes, but
can be disabled manually before the duration period ends. Permanent
loopback is not supported.
Ethernet loopbacks can be configured on more than one interface simultaneously.
When an Ethernet loopback is active, network resiliency protocols (G.8032 and
MSTP) will detect interface failure due to the failure to receive BPDUs.
Page 277 of 468

In a system using in-band management, Ethernet loopback activation on the

remote side of the link causes loss of management to the remote unit. The
duration period of the loopback should take this into account.
Page 278 of 468

6.4 Synchronization
This section describes IP-20N’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 GbE, FE, E1, T3 sync
interface, and/or STM-1 input and output.
• SyncE PRC Pipe Regenerator mode, providing PRC grade (G.811) performance
for pipe (“regenerator”) applications.
• IEEE-1588v2 PTP Optimized Transport, providing both frequency and phase
synchronization for compliance with rigorous LTE and LTE-A requirements.

• Synchronization Overview
• IP-20N Synchronization Solution
• Native Sync Distribution Mode
• SyncE PRC Pipe Regenerator Mode
• IEEE-1588v2 PTP Optimized Transport
6.4.1 Synchronization Overview

Synchronization is essential to ensuring optimal performance in
telecommunications networks. Proper synchronization prevents packet loss,
dropped frames, and degradation of quality of experience that can adversely
affect end-user services.
Synchronization is particularly critical to mobile networks in order to ensure
successful call-signal handoff and proper transmission between base stations, as
well as for the transport of real-time services. If individual base stations drift
outside specified frequencies, this can cause mobile handoff delays, resulting in
high dropped-call rates, impaired data services, and, ultimately, lost subscribers.
Mobile base stations require a highly accurate timing signal that must be shared
across the entire network. If any base station drifts outside of the specified +/- 50
ppb threshold, mobile handoff performance degrades, resulting in a high
disconnect rate and poor data-service quality.
6.4.1.1 Types of Synchronization in Mobile Networks

Synchronization in a mobile network involves frequency and phase (time)
synchronization.
Frequency synchronization maintains consistency between the frequencies of
clock signals to ensure that all devices operate at the same rate. Information is
coded into discrete pulses through pulse code modulation (PCM) and transmitted
on the data communication network. If the clock frequencies of two digital
switching devices are different, the bits in the buffer of the digital switching
system may be lost or duplicated, resulting in a slip in the bit stream.
Phase synchronization, also known as time synchronization, adjusts the internal
clock of a local device according to received time information. In contrast to
Page 279 of 468

frequency synchronization, time synchronization adjusts the clock at irregular

intervals.
Phase synchronization involves two major functions: time service and time
keeping. Time service adjusts the clock according to the standard time. By
adjusting the clock at irregular intervals, a device synchronizes its phase with the
standard reference time. Time keeping refers to frequency synchronization, and
ensures that the difference between the time on the local device and the
standard reference time is within a reasonable range during the interval of clock
adjustment.
6.4.1.2 Additional Synchronization Requirements of LTE Networks

LTE imposes additional challenges with respect to synchronization.
Synchronization solutions must meet the rigorous LTE timing and delivery
requirements that ensure network quality and availability.
While TDM networks were able to exploit GPS for synchronization purposes, LTE
enables deployment of small cells in locations where access to GPS is not reliable.
Without the GPS signals that are traditionally used to provide accurate frequency
and time-of-day synchronization information, LTE networks must find other
means for synchronization.
There are additional difficulties with ensuring proper synchronization in LTE
networks. For example, the LTE downlink radio interface relies on an OFDMA
transmission technique in the downlink. OFDMA presents tremendous benefits in
terms of high spectral efficiency, support of advanced features such as frequency
selective scheduling, immunity to multipath interference, and interference
coordination. However, these advantages require that the orthogonality between
OFDMA subcarriers be strictly preserved. The orthogonality between the
subcarriers prevents overlapping of the subcarriers’ spectra which would result in
interference between subcarriers.
A frequency offset can also lead to dropped calls during handover between base
stations. During the handover procedure, user equipment (UE) must determine
the timing and frequency parameters of the base station in order to be able to
demodulate the downlink signal and also to transmit correctly on the uplink. The
frequency-stability tolerance of the UE oscillator is typically maintained at 0.1
ppm to minimize cost. Its stability is maintained by tracking the base station
carrier frequency, a critical synchronization requirement.
In addition, in LTE-TDD systems, downlink and uplink transmission occur in the
same channel but in different time slots. Both frequency and phase
synchronization are required in LTE-TDD to avoid interference between the uplink
and the downlink transmissions on neighboring base stations.
6.4.2 IP-20N Synchronization Solution

Ceragon’s synchronization solution ensures maximum flexibility by enabling the
operator to select any combination of techniques suitable for the operator’s
network and migration strategy.
• Native Sync Distribution
Page 280 of 468

 End-to-End Native Synchronization distribution

 GbE/FE/E133/T3/STM-134 input
 GbE/FE/E135/T4/STM-136 output
 Supports any radio link configuration and network topology
 Synchronization Status Messages (SSM) to prevent loops and enable use of most
reliable clock source
 User-defined clock source priority and quality level
 Automated determination of relative clock source quality levels
• SyncE PRC Pipe Regenerator mode
 PRC grade (G.811) performance for pipe (“regenerator”) applications
• IEEE-1588v2 PTP Optimized Transport37
 Transparent Clock – Resides between master and slave nodes, and measurers and
adjusts for delay variation to guarantee ultra-low PDV.
 Boundary Clock – Regenerates frequency and phase synchronization, providing,
increasing the scalability of the synchronization network while rigorously
maintaining timing accuracy.
33
E1 input is planned for future release. However, E1 via T3 input from the synchronization interface on
the TCC is supported.
34
A LIC-STM1/OC3-RST (1 x STM-1) card cannot be used as a synchronization source.
35
E1 output is planned for future release. However, E1 via T4 output from the synchronization interface
on the TCC is supported.
36
37
IEEE-1588v2 PTP Optimized Transport with RIC-D is planned for future release.
Page 281 of 468

6.4.3 Native Sync Distribution Mode

In this mode, synchronization is distributed end-to-end over the radio links in the
network. No TDM trails or E1 interfaces at the tail sites are required.
Synchronization is typically provided by one or more clock sources (SSU/GPS) at
fiber hub sites.
Eth
E1
STM1
Eth IP-20N
E1
STM1 IP-20N
Eth
E1
STM1 IP-20N
Figure 166: Native Sync Distribution Mode
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 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.
IP-20N’s Native Sync Distribution mechanism enables users to define a priority
level for each possible clock source. Synchronization Status Messages (SSM) are
sent regularly through each interface involved in frequency distribution, enabling
the network to gather and maintain a synchronization status for each interface
according to the system’s best knowledge about the frequency quality that can be
conveyed by that interface.
Based on these parameters, the network assigns each interface a quality level and
determines which interface to use as the current clock source. The network does
this by evaluating the clock quality of the available source interfaces and selecting,
from those interfaces with the highest quality, the interface with the highest user-
defined priority.
The synchronization is re-evaluated whenever one of the following occurs:
• Any synchronization source is added, edited, or deleted by a user.
• The clock quality status changes for any source interface.
• The synchronization reference is changed for the node.
Page 282 of 468

6.4.3.1 Available Interfaces for Native Sync Distribution

Frequency signals can be taken by the system from a number of different
interfaces (one reference at a time). The reference frequency may also be
conveyed to external equipment through different interfaces.
Table 76: Native Sync Interface Options
Interface Available for Input Available for Output
STM-1 Signal38 Yes Yes

Ethernet Interfaces Yes Yes
Traffic E1 No No
2MHz via T3 input from Sync Interface on TCC, Yes n/a
supporting both 2048 Kbp/s and 2048 KHz
E1 via T3 input from Sync Interface on TCC Yes n/a
2MHz via T4 output from Sync interface on n/a Yes
TCC
E1 via T4 output from Sync Interface on TCC n/a Yes
Radio Carrier Yes Yes
It is possible to configure up to 16 synchronization sources in the system. At any

given moment, only one of these sources is active; the clock is taken from the
active source onto all other appropriately configured interfaces.
6.4.3.2 Configuring Native Sync Distribution

Frequency is distributed by configuring the following parameters in each node:
• System synchronization sources. These are the interfaces from which the
frequency is taken and distributed to other interfaces. Up to 16 sources can be
configured in each node. A revertive timer can be configured. For each
interface, user must configure:
 Its clock quality level. The quality level may be fixed (according to ITU-T G.781
option I) or automatic. When the quality level is automatic, it is determined by
SSM messages.
 Its priority (1-16). No two interfaces may have the same priority.
• For each interface, the source of its outgoing signal clock. This can be:
 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.
38
Page 283 of 468

• 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.39
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.
Sync Source
Radio Link
IP-20N Node
Ethernet Interface Signal Clock = Reference
E1 Interface Sync Source
IP-20N Node
Signal Clock = Reference Signal Clock = Reference
Sync Source Sync Source

Signal Clock = Reference IP-20N IP-20N
BTS Converter Converter
Signal Clock = Reference Signal Clock = Reference Signal Clock = Reference
Sync Source Sync Source Sync Source

IP-20N IP-20N IP-20N
Converter Converter Converter
Signal Clock = Reference Signal Clock = Reference Signal Clock = Reference
BTS BTS BTS
Figure 167: Synchronization Configuration
The following restrictions apply for frequency distribution configuration:

• An interface can either be used as a synchronization source or can take its
signal from the system reference, but not both (no loop timing available,
except locally in SDH interfaces).
• The clock taken from a line interface (E1, SDH, VC-11/12, Ethernet) cannot be
conveyed to another line interface in the same card.
• The clock taken from a radio channel cannot be conveyed to another radio
channel in the same radio.
If the signal driving the synchronization fails, an alarm will alert the user and the
system will enter holdover mode until another synchronization source signal is
found.
39
Force mode is planned for future release.
Page 284 of 468

6.4.3.3 SSM Support and Loop Prevention

In order to provide topological resiliency for synchronization transfer, IP-20N
implements the passing of SSM messages over the radio interfaces. SSM timing in
IP-20N complies with ITU-T G.781.
In addition, the SSM mechanism provides reference source resiliency, since a
network may have more than one source clock.
The following are the principles of operation:
• At all times, each source interface has a “quality status” which is determined
as follows:
 If quality is configured as fixed, then the quality status becomes “failure” upon
interface failure (such as LOS, LOC, LOF, etc.).
 If quality is automatic, then the quality is determined by the received SSMs or
becomes “failure” upon interface failure (such as LOS, LOC, LOF, etc.).
• Each unit holds a parameter which indicates the quality of its reference clock.
This is the quality of the current synchronization source interface.
• The reference source quality is transmitted through SSM messages to all
relevant radio interfaces.
• Each unit determines the current active clock reference source interface:
 The interface with the highest available quality is selected.
 From among interfaces with identical quality, the interface with the highest
priority is selected.
• 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)
6.4.3.4 Native Sync Distribution Examples

The figure below provides a Native Sync Distribution mode usage example in
which synchronization is provided to all-frame Node-Bs using SyncE. In this
illustration, an IP-20N at a fiber node is synchronized to:
• SyncE input from an Ethernet uplink
Page 285 of 468

• External synchronization input via an E1 or STM-1 interface

Ethernet
Node-B
Services
Eth.
Sync
IP-20N
Node-B
Eth.
Sync
Sync Input
IP-20N
GPS/SSU
IP-20N
Node-B Eth
(with SyncE)
Native
sync distribution
Eth.
Sync
IP-20N
RNC or
Aggregation
switch/router
IP-20N 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.)
Figure 168: Native Sync Distribution Mode Usage Example
The following figure illustrates Native Sync Distribution in a tree scenario.
IP-20N with SyncE and Native

Sync Distribution support.
IP-20N
Packet Based
Aggregation
Network
MW Radio link
IP-20N IP-20N IP-20N

PRC
BNC/RNC
FE/GE interface with SyncE
IP-20N
Tail Site #3 Aggregation Site Fiber Site
Figure 169: Native Sync Distribution Mode – Tree Scenario
Page 286 of 468

The following figure illustrates Native Sync Distribution in a ring scenario, during
normal operation.
PRC
IP-20N
Tail site #1 Packet Based

Aggregation
Network
IP-20N
IP-20N
Tail site #2 Ring site #1
Wireless
Carrier Ethernet Ring BNC/RNC
IP-20N
Fiber site
2
Native
1+0
IP-20N FE/GE interface
with SyncE
Ring site #2
IP-20N
Ring site #3
IP-20N
Tail site #3
Figure 170: Native Sync Distribution Mode – Ring Scenario (Normal Operation)
The following figure illustrates Native Sync Distribution in a ring scenario, where a
link has failed and the Native Sync timing distribution has been restored over an
alternate path by using SSM messages.
IP-20N
Tail site #1 Packet Based

Aggregation
Network
IP-20N
IP-20N
Tail site #2 Ring site #1
Wireless
Carrier Ethernet Ring IP-20N BNC/RNC
Fiber site PRC

Native2
1+0
IP-20N FE/GE interface
with SyncE
Ring site #2
Alternate path using IP-20N
SSM messages
Ring site #3
IP-20N
Tail site #3
Figure 171: Native Sync Distribution Mode – Ring Scenario (Link Failure)
Page 287 of 468

6.4.4 SyncE PRC Pipe Regenerator Mode

Synchronous Ethernet (SyncE) is standardized in ITU-T G.8261 and G.8262, and
refers to a method whereby the frequency is delivered on the physical layer.
SyncE delivers a frequency reference, but not ToD or phase synchronization. It is
used to distribute timing to applications that rely on precise frequency
synchronization, such as wireless backhaul.
SyncE is based on SDH/TDM timing, with similar performance, and does not
change the basic Ethernet standards. The SyncE technique supports synchronized
Ethernet outputs as the timing source to an all-IP BTS/NodeB. This method offers
the same synchronization quality provided over E1 interfaces to legacy
BTS/NodeB. SyncE is not affected by Path Delay Variation (PDV) and Packet Jitter,
which are inherent in Ethernet networks.
The primary disadvantage of SyncE is that it since it is a physical-layer technology,
it cannot be deployed in legacy Ethernet networks without upgrade of all
hardware and interfaces in the network, since synchronous timing circuitry is
necessary at every node.
Figure 172: Synchronous Ethernet (SyncE)
IP-20N supports SyncE PRC pipe regenerator. In SyncE PRC pipe regenerator
mode, frequency is transported between two GbE interfaces through the radio
link.
Note: SyncE PRC Pipe Regenerator Mode is not supported with RMC-A.
PRC pipe regenerator mode makes use of the fact that the system is acting as a
simple link (so no distribution mechanism is necessary) in order to achieve the
following:
• Improved frequency distribution performance, with PRC quality.
• Simplified configuration
Page 288 of 468

In PRC pipe regenerator mode, frequency is taken from the incoming GbE
Ethernet or radio interface signal, and used as a reference for the radio frame. On
the receiver side, the radio frame frequency is used as the reference signal for the
outgoing Ethernet PHY.
Note: You can only configure a SyncE pipe on one interface per card.
Frequency distribution behaves in a different way for optical and electrical GbE
interfaces, because of the way these interfaces are implemented:
• For optical interfaces, separate and independent frequencies are transported
in each direction.
• For electrical interfaces, each PHY must act either as clock master or as clock
slave in its own link. For this reason, frequency can only be distributed in one
direction, determined by the user.
6.4.5 IEEE-1588v2 PTP Optimized Transport

Note: IEEE-1588v2 PTP Optimized Transport with RIC-D, RFU-D,
RFU-D-HP, RFU-E, and RFU-S is planned for future release.
Precision Timing Protocol (PTP) refers to the distribution of frequency and phase
information across a packet-switched network.
IP-20N supports IEEE-1588v2 PTP optimized transport, a message-based protocol
that can be implemented across packet-based networks. IEEE-1588v2 provides
phase synchronization, and is designed to provide higher accuracy and precision,
to the scale of nanoseconds.
IEEE-1588v2 PTP synchronization is based on a master-slave architecture in which
the master and slave exchange PTP packets carrying clock information. The
master is connected to a reference clock, and the slave synchronizes itself to the
master.
Sync GPS/SSU
Input
Packet Switched Network

Master Slave
Figure 173: IEEE-1588v2 PTP Optimized Transport – General Architecture
Accurate synchronization requires a determination of the propagation delay for

PTP packets. Propagation delay is determined by a series of messages between
the master and slave.
Page 289 of 468

Sync GPS/
SSU
Input
Packet Switched Network

Master Slave
t1
Syn c
(t1)
Follow
-up (t t2
1)
t3
reque st (t3)
Delay_
t4
Delay
_resp
o n se
(t4)
Figure 174: Calculating the Propagation Delay for PTP Packets
In this information exchange:

1 The master sends a Sync message to the slave and notes the time (t1) the
message was sent.
2 The slave receives the Sync message and notes the time the message was
received (t2).
3 The master conveys the t1 timestamp to the slave, in one of the following
ways:
 One-Step – Embedding the t1 timestamp in the Sync message.
 Two-Step – Embedding the t1 timestamp in a Follow-up message.
4 The slave sends a Delay_request message to the master and notes the time
the message was sent (t3).
5 The master receives the Delay_request message and notes the time the
message was received (t4).
6 The master conveys the t4 timestamp to the slave by embedding the t4
timestamp in a Delay_response message.
Based on this message exchange, the protocol calculates both the clock offset
between the master and slave and the propagation delay, based on the following
formulas:
Page 290 of 468

Offset = [(t2 – t1) – (t4 – t3)]/2

Propagation Delay = [(t2 – t1) + (t4 – t3)]/2
The calculation is based on the assumption that packet delay is constant and that
delays are the same in each direction. For information on the factors that may
undermine these assumptions and how IP-20N’s IEEE-1588v2 implementations
mitigate these factors, see Mitigating PDV on page 291.
6.4.5.1 IEEE-1588v2 Characteristics

IEEE-1588v2 provides packet-based synchronization that can transmit both
frequency accuracy and phase information. This is essential for LTE applications,
and adds the ability to transmit phase information to SyncE.
The main IEEE-1588v2 benefits include:
• Nanosecond precession.
• Meets strict LTE-A requirements for rigorous frequency and phase timing.
• Hardware time stamping of PTP packets.
• Standard protocol compatible with third-party equipment.
• Short frame and higher message rates.
• Supports unicast as well as multicast.
• Enables smooth transition from unsupported networks.
• Mitigates PDV issues by using Transparent Clock and Boundary Clock (see
Mitigating PDV on page 291).
• Minimal consumption of bandwidth and processing power.
• Simple configuration.
6.4.5.2 Mitigating PDV

To get the most out of PTP and minimize PDV, IP-20N supports Transparent Clock and
Boundary Clock.
PTP calculates path delay based on the assumption that packet delay is constant and
that delays are the same in each direction. Delay variation invalidates this assumption.
High PDV in wireless transport for synchronization over packet protocols, such as IEEE-
1588, can dramatically affect the quality of the recovered clock. Slow variations are the
most harmful, since in most cases it is more difficult for the receiver to average out
such variations.
PDV can arise from both packet processing delay variation and radio link delay
variation.
Packet processing delay variation can be caused by:
• Queuing Delay – Delay associated with incoming and outgoing packet buffer
queuing.
• Head of Line Blocking – Occurs when a high priority frame, such as a frame
that contains IEEE-1588 information, is forced to wait until a lower-priority
frame that has already started to be transmitted completes its transmission.
Page 291 of 468

• Store and Forward – Used to determine where to send individual packets.

Incoming packets are stored in local memory while the MAC address table is
searched and the packet’s cyclic redundancy field is checked before the
packet is sent out on the appropriate port. This process introduces variations
in the time latency of packet forwarding due to packet size, flow control, MAC
address table searches, and CRC calculations.
Radio link delay variation is caused by the effect of ACM, which enables dynamic
modulation changes to accommodate radio path fading, typically due to weather
changes. Lowering modulation reduces link capacity, causing traffic to accumulate
in the buffers and producing transmission delay.
Note: When bandwidth is reduced due to lowering of the ACM
modulation point, it is essential that high priority traffic carrying
IEEE-1588 packets be given the highest priority using IP-20N’s
enhanced QoS mechanism, so that this traffic will not be subject
to delays or discards.
These factors can combine to produce a minimum and maximum delay, as follows:
• Minimum frame delay can occur when the link operates at a high modulation
and no other frame has started transmission when the IEEE-1588 frame is
ready for transmission.
• Maximum frame delay can occur when the link is operating at QPSK
modulation and a large (e.g., 1518 bytes) frame has just started transmission
when the IEEE-1588 frame is ready for transmission.
The worst case PDV is defined as the greatest difference between the minimum
and maximum frame delays. The worst case can occur not just in the radio
equipment itself but in every switch across the network.
To ensure minimal packet delay variation (PDV), IP-20N’s synchronization solution
includes 1588v2-compliant Transparent Clock and Boundary Clock synchronization
protocols. The following two sections describe these protocols and how they
counter PDV.
Page 292 of 468

6.4.5.3 Transparent Clock

IP-20N supports end-to-end Transparent Clock, which updates the correction field
for the delay associated with individual packet transfers. End-to-End Transparent
Clock is the most appropriate option for microwave radio links.
A Transparent Clock node resides between a master and a slave node, and
updates the packets passing between the master and slave to compensate for
delay, enabling the terminating clock in the slave node to remove the delay
accrued in the Transparent Clock node. The Transparent Clock node is itself
neither a master nor a slave node, but rather, serves as a bridge between master
and slave nodes.
Entrance Leaving Time
Time (Update Timestamp)
Sync GPS/SSU
Input
Transparent
Clock
Slave
Master
Leaving Time Entrance

(Update Timestamp) Time
Figure 175: Transparent Clock – General Architecture
IP-20N uses 1588v2-compliant Transparent Clock to counter the effects of

asymmetrical delay and delay variation. Transparent Clock measures and adjusts
for delay variation, enabling the IP-20N to guarantee ultra-low PDV.
The Transparent Clock algorithm forwards and adjusts the messages to reflect the
residency time associated with the Sync and Delay_Request messages as they
pass through the device. The delays are inserted in the 64-bit time-interval
correction field.
As shown in the figure below, IP-20N measures and updates PTP messages based
on both the radio link delay, and the packet processing delay that results from the
network processor (switch operation).
Page 293 of 468

Radio Link
Delay = ∆y
Correction Time
∆x + ∆y + ∆z
1588 1588
Master Slave
IP-20N IP-20N
Packet Processing Packet Processing

Delay = ∆z Delay = ∆x
Figure 176: Transparent Clock Delay Compensation
6.4.5.4 Boundary Clock

IEEE-1588v2 Boundary Clock enables the IP-20N to regenerate phase
synchronization via standard Ethernet. Boundary Clock complies with ITU-T
Telecom Profile G.8275.1. This enables IP-20N, with Boundary Clock, to meet the
rigorous synchronization requirements of LTE-Advanced (LTE-A) networks.
In Boundary Clock, a single node can include up to four ports; master ports for
time stamp distribution and one slave port that is locked onto a grandmaster.
The Boundary Clock node terminates the PTP flow on the slave port, recovers the
clock and timestamp, and regenerates the PTP flow on the master ports. The
Boundary Clock node selects the best synchronization source available in the
domain and regenerates PTP towards the slave clocks. This reduces the processing
load from grandmaster clocks and increases the scalability of the synchronization
network, while rigorously maintaining timing accuracy.
Page 294 of 468

1588
Master
Slave 1588
Port Slave
IP-20N IP-20N
Slave Master Master

Port Port Port
Figure 177: Boundary Clock – General Architecture
Boundary Clock uses the Best Master Clock Algorithm (BMCA) to determine which
of the clocks in the network has the highest quality. This clock is designated the
grandmaster, and it synchronizes all other clocks (slave clocks) in the network. If
the grandmaster is removed from the network, or the BMCA determines that
another clock has superior quality, the BMCA defines a new grandmaster and
adjusts all other clocks accordingly. This process is fault tolerant, and no user
input is required.
A node running as master clock can use the following inputs and outputs.
Table 77: Boundary Clock Input Options
Synchronization Input Frequency/Phase
Ethernet packets from PTP 1588 Remote Master via Phase

radio or Ethernet interface
SyncE (including ESMC) via radio or Ethernet Frequency
interface
Table 78: Boundary Clock Output Options
Synchronization Input Frequency/Phase
Ethernet packets towards PTP 1588 slaves via radio Phase

or Ethernet interface
SyncE (including ESMC) via radio or Ethernet Frequency
interface
IP-20N uses multicast Ethernet messages, per IEEE-1588 Annex F.

•
Page 295 of 468

6.5 TDM Services

• LIC-T16 (16x E1) line card
• LIC-T155 (1x ch-STM-1) line card
IP-20N provides integrated support for transportation of TDM (E1) services with
integrated E1 and ch-STM-1 interfaces.
Two types of TDM services are supported using the same hardware:
• Native TDM trails
• TDM Pseudowire services (enabling interoperability with third party
packet/PW equipment)
IP-20N also offers hybrid Ethernet and TDM services. Hybrid services can utilize
either Native TDM or pseudowire.
Services engine
TDM cross-connect (VCs)

E1
ch-STM-1 TDM
Traffic
Hybrid
TDM Radio
PW
Network processor (EVCs)
Packet
Traffic
GE/FE
Figure 178: Hybrid Ethernet and TDM Services
Hybrid Ethernet and TDM services can also be transported via cascading
interfaces. This enables the creation of links among multiple IP-20N and IP-20G
units in a node for multi-carrier and multi-directional applications.
Page 296 of 468

TDM cross-connect
- (VCs)
SAP
Cascading Port TDM
Traffic
Hybrid
Port Radio
Packet
Traffic
Ethernet Services (EVCs)
SNP SNP
SAP
E1
ch-STM-1 Port SAP
Cascading Port
Port
User Port Ethernet Services (EVCs)

(UNI)
GE/FE Port SAP

SAP SNP
SAP
Figure 179: Hybrid Ethernet and TDM Services Carried Over Cascading Interfaces
Note: In addition, native STM-1/VC4 traffic can be carried via an LIC-

STM1/OC3-RST (1 x STM-1) and IP-20N’s Hybrid-MC-ABC engine.
For details, see Hybrid Multi-Carrier Adaptive Bandwidth Control
(Hybrid MC-ABC) on page 161.
6.5.1 Native TDM Trails

IP-20N provides native TDM support, utilizing a cross-connect module to support
up to 512 TDM trails.
IP-20N also supports hybrid Ethernet and native TDM services, utilizing cascading
ports. The following figure shows an example of a hybrid service package that
includes a Point-to-Point and a Multipoint Ethernet service, along with a TDM trail
utilizing virtual connections (VCs) via IP-20N’s cross-connect.
Page 297 of 468

E1/ch-STM-1 Port SAP
User Port PtP Service

(UNI) TDM
Traffic Hybrid
GE/FE Port SAP SNP Radio
SAP SAP Packet
Traffic
Multipoint Service
User Port SAP SNP Network

(UNI) Port
GE/FE Port Port GE/FE
SAP SNP
Figure 180: Hybrid Ethernet and Native TDM Services
6.5.1.1 Native TDM Trails Provisioning

The IP-20N Web EMS provides a simple and easy-to-use GUI that enables users to
provision end-to-end TDM trails. The Services Provisioning GUI includes the
following trail-creation end points:
• TDM interface
• Radio interface
• Cascading interface
6.5.1.2 TDM Trails and Synchronization
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.
• System Reference Clock – Trails are synchronized to the system reference
clock.
Page 298 of 468

6.5.1.3 TDM Path Protection

TDM path protection enables the operator to define two separate network paths
for a single TDM service. Two different kinds of path protection are available, each
suitable for a different network topology:
• 1:1 TDM path protection is suitable for ring networks that consist entirely of
IP-20N and/or IP-20G elements with two end-point interfaces for the TDM
trail.
• 1+1 TDM path protection is suitable for dual homing topologies in which the
IP-20N and/or IP-20G elements are set up as a chain connected to the third
party networks at two different sites. The ring is closed on one side by the IP-
20N and/or IP-20G elements, and on the other by third party equipment
supporting standard SNCP. In this case, there are three end-point interfaces in
the IP-20N and/or IP-20G section of the network.
Third Party
Equipment
End-Point
Interface
Path 2
IP-20N
Path 1
IP-20N IP-20N
End-Point IP-20N
Interface
Third Party
Equipment
Figure 181: 1:1 TDM Path Protection – Ring Topology
Page 299 of 468

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-20N IP-20N
Path 1 Path 2
End-Point IP-20N
Interface
Third Party
Equipment
Figure 182: 1+1TDM Path Protection – Dual Homing Topology
1:1 TDM Path Protection

1:1 TDM path protection enables the operator to define two separate network
paths for a single TDM trail. Each trail has the same TDM interface end points, but
traffic flows to the destination via different paths. Bandwidth is utilized only on
the active path, freeing up resources on the standby path.
For native TDM services TDM path protection is done by means of configuring
active and backup path at the TDM service end-points.
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.
1+1 TDM Path Protection

1+1 TDM path protection is used for dual homing topologies in which the IP-20N
and/or IP-20G network elements are set up as a chain connected to third party
networks at two different sites, where one end-point is located on an IP-20N
Page 300 of 468

and/or IP-20G unit and the other end-point is located on third-party equipment
supporting standard SNCP.
As with 1:1 TDM path protection, the operator defines two separate network
paths for a single TDM trail. However, unlike 1:1 path protection, traffic flows
through both paths simultaneously, thereby supporting standard SNCP in the third
party equipment.
6.5.1.4 TDM Performance Monitoring

The following monitoring features are available for TDM trails and interfaces. PMs
are computed at the TDM card and reported at 15-minute intervals, with one
second granularity.
• PMs for the outgoing TDM trail:
 Errored seconds
 Severely errored seconds
 Unavailable seconds
• PMs for incoming native E1 signal:
 Errored seconds
• PMs for incoming SDH 155MHz signal:
 Errored seconds
 Severely errored framing seconds
 Coding Violations
Page 301 of 468

6.5.2 TDM Pseudowire

IP-20N’s TDM Pseudowire provides TDM-over-packet capabilities by means of
optional TDM line cards that process TDM data, send the data through the system
in frame format that can be processed by the IP-20N’s Ethernet ports, and convert
the data back to TDM format.
IP-20N offers the following TDM line card options:
• E1 TDM Card – LIC-T16 (16x E1)
• Ch-STM-1 TDM Card – LIC-T155 (1x ch- STM-1)
The front of the LIC-T16 includes an MDR69 interface for 16 E1 lines.
The front of the LIC-T155 card includes an SFP interface for a 155MHz optical
connection.
IP-20N also supports all-packet Ethernet and TDM pseudowire services. The
following figure shows an example of an all-packet service package that includes
two Point-to-Point services and one Multipoint Ethernet service, where the first
Point-to-Point service carries E1/STM-1 pseudowire traffic. This service package
can be carried on any of the IP-20N’s Ethernet ports.

TDM
PtP Service
PW
E1/ch-STM-1 Port SAP SNP

SAP SAP
User Port PtP Service

(UNI)
S- VLAN =
200 Packet Packet
GE/FE Port SAP SNP Traffic
SAP SAP Radio
Multipoint
Service
User Port SAP SNP Network
(UNI) Port
GE/FE Port Port GE/FE
SAP SNP
Figure 183: All-Packet Ethernet and TDM Pseudowire Services
Page 302 of 468

6.5.2.1 TDM Pseudowire Supported Standards

TDM Pseudowire supports the following standards:
• SAToP – RFC 4553
• CESoP – RFC 508640
TDM Pseudowire is compliant with the following encapsulations:
• Ethernet VLAN (MEF-8)
• IP/UDP (IETF)41
• MPLS (MFA8)42
6.5.2.2 TDM Pseudowire Services

A Pseudowire service is a user-defined, bidirectional flow of information between
a TDM signal and a packed flow, which is always transported over Layer 2
Ethernet. Such a service interconnects and makes use of the following elements:
• TDM Signal
 The TDM signal may be an entire E1 or a subset of DS0s (or E1 time-slots).43
• PSN Tunnel
 A PSN tunnel is the means by which the frames containing the TDM information
are sent and received through a PSN network. The type of tunnel to be used
should match the relevant transport network.
 Three types of PSN tunnels are supported: MEF-8 (Ethernet), UDP/IP, and MPLS
(MFA8).44
 For IP tunnels, the pseudowire services make use of the TDM LIC’s IP address,
which is user-configurable. For MEF-8 tunnels, the addressing is done through the
TDM LIC’s MAC address, which is fixed, but readable by users. MAC addresses are
fixed per slot in each unit, so that replacing a TDM LIC in a certain slot does not
change the MAC address.
• PSN Tunnel Group
 A PSN tunnel group is a grouping of two TDM tunnels, one of which will carry the
pseudowire service frames at any given time.
 A PSN tunnel group is used when path protection is required for a pseudowire
service.
 One of the tunnels is designated as “primary.” The primary tunnel carries the
pseudowire frames in the absence of any failures. The other tunnel is designated
as “secondary.” The secondary tunnel is used whenever the primary path fails.
• Pseudowire Profile
40
CESoP mode is planned for future release.
41
IP/UDP (IETF) encapsulation is planned for future release.
42
MPLS (MFA8) encapsulation is planned for future release.
43
A subset of DS0 is supported in CESoP, which is planned for a future release.
44
UDP/IP and MPLS are planned for future release.
Page 303 of 468

 A profile is a set of parameters that determine various operational settings of a

PW service. A single profile can be used for any number of services.
 The following is a short explanation of the main parameters:
• Payload size – In terms of E1 frames per frame.
• Jitter buffer – In milliseconds.
• LOPS detection thresholds.
• RTP timestamp usage details (for adaptive clock recovery).
• Payload suppression and transmission patterns in case of errors.
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 LIC IP address and subnet mask
• Clock distribution
6.5.2.3 Pseudowire Services Provisioning

The IP-20N Web EMS provides a simple and easy-to-use GUI that enables users to
provision end-to-end pseudowire services. The Services Provisioning GUI includes
the following service-creation end points:
• TDM interface
• Radio interface
• Cascading interface
Page 304 of 468

6.5.2.4 TDM Pseudowire and Synchronization
Related topics:
• Synchronization
A key requirement of pseudowire technology is managing the synchronization of
TDM signals. IP-20N’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.45
• Loop Timing – The pseudowire output signal uses the clock of the incoming E1
lines Timing will be independent for each E1 line.
6.5.2.5 TDM Pseudowire Path Protection

For TDM pseudowire traffic redundancy, IP-20N offers 1:1 TDM path protection,
which protects the traffic along the path.
Note: Alternatively, protection for the traffic along the path can be
achieved using 1+1HSB protection for the radios.
1:1 TDM path protection requires the use of SOAM (CFM) at both end-point TDM-
LICs. The TDM LIC sends two data streams to the TCC. Only the data stream for
the active path contains actual traffic. Both data streams contain continuity
messages (CCMs). This enables the TDM LIC to monitor the status of both paths
without doubling the amount of data being sent over the network. The TDM LIC
determines when a switchover is necessary based on the monitored network
status.
In order to achieve TDM pseudowire path protection, different provisioning
should be made for the Ethernet service corresponding to each of the two data
streams. In order to do this, it is recommended to map the corresponding
Ethernet services to MSTP instance number 63, which is meant for Traffic
Engineering (ports are always forwarding) and to map the two different transport
VLANs over two different paths.
45
Differential Clock Recovery is planned for future release.
Page 305 of 468

1:1 TDM pseudowire path protection uses SOAM to monitor the network paths.
Because SOAM is configured on the TDM LIC level, the TDM LIC can determine the
status of the entire network path, up to and including the LIC’s TDM interface.
6.5.2.6 TDM Pseudowire Performance Monitoring

The following monitoring features are available for TDM Pseudowire services and
interfaces:
TDM Pseudowire 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)
TDM Pseudowire Signal PMs46

PMs are computed at the PW card and reported at 15-minute intervals, with one
second granularity.
• PMs for the recovered E1:
 Errored seconds
• PMs for the pseudowire Ethernet connection:
 Frame Error Ratio (FER) performance
• RFC 5604 PMs:
 Lost frames
 Reordered frames
 Buffer underruns
46
Support for TDM signal PMs is planned for future release.
Page 306 of 468

 Misordered frames dropped

 Malformed frames
• PMs for incoming native E1 signal:
 Errored seconds
• PMs for incoming SDH 155MHz signal:
 Errored seconds
 Severely errored framing seconds
 Coding Violations
6.5.3 STM-1 Interfaces

The LIC-T155 (1x ch-STM-1) card is meant to provide a convenient interface for
numerous TDM signals (E1).
In the ingress direction the SDH signals and headers are all terminated at the card,
and the E1 signals contained within the SDH signals are extracted. From this point
on, they are treated the same as the TDM signals in the LIC-T16 (16x E1) card.
In the egress direction, the E1 signals are mapped onto SDH signals which are
generated at the card.
The following standard signal mappings are used for SDH configurations: VC4
mapping (VC-12->TU-12->TUG-2->TUG-3->VC-4->AU-4->AUG).
The following SDH functionality is supported by the LIC-T155 (1x ch-STM-1) card:
• J0 and J2 trace identifier support (transmitted, received, expected) for all
standard lengths.
• VC-12 VT-AIS standard signaling and detection.
• SSM (S1) support (transmitted and received value)47
• SDH – Level LOS, LOF, excessive BER, Signal Degrade alarms.
• SFP alarms: SFP exist, SFP tx failure.
• SFP mute/unmute support.
47
SSM (S1) support for the LIC-T155 (1x ch-STM-1) card is planned for future release.
Page 307 of 468

6.5.4 TDM Card and Interface Protection

Two different schemes are available for card and interface protection:
• 1+1 HSB Card Protection – Available for LIC-T155 (1x ch-STM-1), LIC-
STM1/OC3-RST, and LIC-T16 (1x E1) cards.
• Uni-Directional MSP Card Protection – Available for LIC-T155 (1x ch-STM-1)
cards only.
Both schemes provide full protection against hardware failure. Uni-Directional
MSP also provides full protection against interface failure due to cable
disconnection or failure of the far-end equipment, while 1+1 HSB card protection
provides protection against interface failure due to cable disconnection at the IP-
20N side of the link.
In both schemes, configuration of the active card is automatically copied to the
standby card. The entire configuration can also be copied and stored for
maintenance purposes.
Up to four TDM protection groups can be configured per 2RU IP-20N unit. Up to
two TDM protection groups can be configured per 1RU IP-20N unit.
1+1 HSB Card Protection

1+1 HSB card protection offers full redundancy for LIC-T16, LIC-T155, and LIC-
STM1/OC3-RST cards. This form of redundancy is appropriate for connections with
third party equipment at which a single E1 or STM-1 interface is available.
E1 Active Interface
Port
E1
Port Y-Cable
E1 Standby Interface
Port (TX Muted)
Third Party
IP-20N
Equipment
Figure 184: 1+1 HSB Card Protection for LIC-T16 (E1) Cards
Page 308 of 468

STM-1 Active Interface

Port
STM-1 Optical
Port Splitter
STM-1 Standby Interface
Port (TX Muted)
Third Party
IP-20N
Equipment
Figure 185: 1+1 HSB Protection for LIC-T155 (STM-1) and LIC-STM1/OC3-RST Cards
In a 1+1 HSB card protection configuration, the single port on the third party
equipment is connected to two E1 or STM-1 interfaces on the IP-20N. A 1+1 HSB
E1 configuration uses a Y-cable to connect the two interfaces. A 1+1 HSB STM-1
configuration uses an optical splitter cable to connect the two interfaces. This
ensures that an identical signal is received by each E1 or STM-1 interface on the
IP-20N. The IP-20N determines which interface is active, based on traffic loss
indications such as LOS, LOF, or other errors.
While both interfaces on the IP-20N receive traffic, only the active interface
transmits. The standby interface is automatically muted.
The following table shows the Part Number and Marketing Model of the Y-cable
required for 1+1 HSB protection of an LIC-T16 card.
Table 79: Y-Cable for LIC-T16 Card Protection
Part Number Marketing Model Description
wa-0391-0 IP-10 16E1 protection Y-cable, MDR68 CABLE,2xSCSI68 LEFT ANGL

SCSI68,0.6M,120
OHM,ADAP
Uni-Directional MSP
Uni-directional Multiplex Section Protection (MSP) is implemented in the LIC-T155
card.
Uni-directional MSP is a standard procedure which provides equipment protection
for LIC-T155 cards, as well as for the STM-1 interfaces in third party equipment.
Uni-directional MSP requires two STM-1 ports in the third party equipment, each
of which must be connected to the IP-20N.
Page 309 of 468

STM-1 STM-1
Port Port
STM-1 STM-1
Port Port
Third Party
IP-20N
Equipment
Figure 186: Uni-directional MSP for LIC-T155 (STM-1) Cards
In Uni-directional Multiplex Section Protection (MSP), the element at each end of

the STM-1 link transmits traffic through both connections. On the receiving side,
each IP-20N element unilaterally decides, based on traffic loss indications such as
LOS, LOF, or other errors, from which interface to receive the traffic, and declares
that interface the active interface. There is no need for a protocol between the
two connected elements.
Each LIC-T155 is connected directly to separate ports in the third party network
element. There is no need for a splitter or Y-cable. This ensures protection to the
optical ports in the third party equipment and to the optical fiber cable, as well as
to the LIC-T155 in the IP-20N.
Page 310 of 468

6.5.5 TDM Reference Solutions

This section provides several examples of how IP-20N’s end-to-end TDM service
solutions can be used in various migration scenarios.
Native TDM Trail
Native E1 Trail (VC12)
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
Figure 187: Native TDM Trail Interoperability with Optical SDH Equipment
Native TDM Trail TDM PW
Hybrid Hybrid
Radio Radio
Fiber Packet
Aggregation
Network
FibeAir IP-10/20 FibeAir IP-20 FibeAir IP-20
BNC/RNC
Figure 188: Native TDM Trail Interoperability with TDM Pseudowire-over-Packet Aggregation
Native E1 Trail (VC12)

TDM Pseudowire
All-Packet All-Packet
Radio Radio
SDH Optical
Aggregation
Network
BNC/RNC
Figure 189: TDM Pseudowire Interoperability with Optical SDH Equipment
Page 311 of 468

TDM Pseudowire
All-Packet All-Packet
Radio Radio
Fiber Packet
Aggregation
Network
BNC/RNC
Figure 190: TDM Pseudowire Interoperability with Third-Party Packet Aggregation

Equipment
Page 312 of 468

6.6 Radio Payload Encryption and FIPS
6.6.1 AES-256 Payload Encryption

• RMC-B
IP-20N supports AES-256 payload encryption.
The Advanced Encryption Standard (AES) is defined in Federal Information
Processing Standard Publication 197 (FIPS 197) for symmetric encryption. AES-256
is widely considered to be secure and efficient and is therefore broadly accepted
as the standard for both government and industry applications.
AES-256 Encrypted Link
Encryption Module in IDU
Figure 191: AES-256 Encrypted Link
Note: The AES-256 payload encryption feature is a controlled item

under applicable Export Laws. Please contact your Ceragon
representative to confirm that the encryption feature can be
delivered.
6.6.1.1 AES Benefits

• Provides protection against eavesdropping and man-in-the-middle attacks on
the radio
• Full encryption for all radio traffic
• Wire-speed, lowest latency encryption
• Eliminates the need for external encryption devices:
 Cost effective encryption solution
 Low Capex and operational costs; fast and simple deployment
Page 313 of 468

6.6.1.2 IP-20N AES Implementation

In IP-20N, AES provides full payload encryption for all L1 radio traffic. It also
encrypts control data passing through the radio link, such as the Link ID, ATPC
data, and SSM messages. AES encryption operates on a point-to-point radio link
level. AES is enabled and configured separately for each radio carrier.
IP-20N uses a dual-key encryption mechanism for AES.
• The user provides a master key. The master key can also be generated by the
system upon user command. The master key is a 32-byte symmetric
encryption key. The same master key must be manually configured on both
ends of the encrypted link.
• The session key is a 32-byte symmetric encryption key used to encrypt the
actual data. Each link uses two session keys, one for each direction. For each
direction, the session key is generated by the transmit side unit and
propagated automatically to the other side of the link via a Key Exchange
Protocol. The Key Exchange Protocol exchanges session keys by encrypting
them with the master key, using the AES-256 encryption algorithm. Session
keys are regenerated at user-configured intervals.
AES key generation is completely hitless, and has no effect on ACM operation.
Once AES encryption has been enabled on both sides of the link, the Key Exchange
Protocol periodically verifies that both ends of the link have the same master key.
If a mismatch is detected, an alarm is raised and traffic transmission is stopped for
the mismatched carrier at both sides of the link. The link becomes non-valid and
traffic stops being forwarded.
6.6.1.3 AES Interoperability

IP-20’s AES implementation is interoperable among IP-20 products that support
AES. This means that for all IP-20 products that are otherwise interoperable with
each other, AES can be used in links between two such products.
Page 314 of 468

6.6.2 FIPS 140-2 Compliance

FibeAir IP-20N can be configured to be FIPS 140-2 level-2 compliant, in specific
hardware and software configurations, as described in this section. FIPS is only
available with the FibeAir IP-20 Assured platform.48
6.6.2.1 FIPS Overview

The objective of FIPS 140-2 is to provide a standard for secured communication
devices, with an emphasis on encryption and cryptographic methods. The FIPS
standards are promulgated by the National Institute of Standards and Technology
(NIST), and provide an extensive set of requirements for both hardware and
software. For a full list of FIPS requirements, refer to the Ceragon IP-20 FIPS 140-2
Security Policy, available upon request.
It is the responsibility of the user to ensure that the above FIPS requirements are
met.
6.6.2.2 Hardware Requirements

In order for an IP-20N node to be FIPS-compliant, the following components must
be FIPS-compliant:
• The IP-20N chassis – The IP-20N chassis must be FIPS-compliant. FIPS-
compliant chassis are available for 2RU nodes. The FIPS compliant chassis
includes, among other things:
 A FIPS-compliant fan tray and filter, to ensure that the internal content of the
chassis is opaque from external visibility.
 Tamper-evident labels.
• RMC-B – Only FIPS-compliant RMC-Bs can be used in a FIPS-compliant IP-20N
unit.
• TCC – Only a FIPS-compliant TCC or TCCs (for an IP-20N with TCC redundancy)
can be used in a FIPS-compliant IP-20N unit.
FIPS-compliant IP-20N components have unique part numbers ending in the
letters AF, as shown in the following table.
Table 80: FIPS-Compliant Marketing Models
IP-20A-2RU/10-Slot-Bs-2x48v-AF IP-20A 2RU/10-slot base package w/ 2x48v, FIPS

IP-20-TCC-B2-XG-MC+SD-AF IP-20 TCC-B2-XG-MC, w/ SD-Card, FIPS
IP-20-RMC-B-AF IP-20 RMC-B , FIPS
48
CeraOS 10.3 does not support the FibeAir IP-20 Assured platform. The latest release to support FibeAir
IP-20 Assured, including FIPS, is CeraOS 8.3. CeraOS 10.3 does support AES-256 Radio Payload
Encryption.
Page 315 of 468

Other IP-20N components do not need to be FIPS-compliant in order to be used in

a FIPS-compliant IP-20N node. These are:
• LIC-X-E4-Elec (4x GbE)
• LIC-X-E4-Opt (4x GbE)
• LIC-T16 (16 x E1)
• LIC-T155 (1 x ch-STM-1)
• LIC-STM1/OC3-RST (1 x STM-1)
Note: FIPS-compliant TCCs and RMC-Bs can operate with a non-FIPS
chassis in non-FIPS mode. Non-FIPS TCCs, RMC-Bs, and RIC-Ds
can operate in a FIPS chassis as long as FIPS mode is not enabled.
Special labels must be affixed to a FIPS-compliant IP-20N unit. These labels are
tamper-evident and must be applied in such a way that it is not possible to
remove either a single card or a group of cards without also removing a label and
leaving evidence that the label was tampered with. These labels must be replaced
whenever components are added to or removed from the unit. Replacement
labels can be ordered from Ceragon Networks, part number BS-0341-0. Tamper-
evident labels should be inspected for integrity at least once every six months. For
further details, refer to the FibeAir IP-20N Installation Guide.
6.6.2.3 Software Requirements

FIPS compliance requires the user to operate the IP-20N in FIPS mode. FIPS mode
must be enabled by the user. It can be enabled via the Web EMS, the CLI, or
SNMPv3. Enabling FIPS mode requires a system reset.
Page 316 of 468

7. FibeAir IP-20N Management

• Management Overview
• Automatic Network Topology Discovery with LLDP Protocol
• Management Communication Channels and Protocols
• Web-Based Element Management System (Web EMS)
• Command Line Interface (CLI)
• Slot Management and Card Configuration
• Configuration Management
• Software Management
• CeraPlan Service for Creating Pre-Defined Configuration Files
• IPv6 Support
• In-Band Management
• Local Management
• Alarms
• External Alarms
• NTP Support
• UTC Support
• System Security Features
Page 317 of 468

7.1 Management Overview

The Ceragon management solution is built on several layers of management:
• NEL – Network Element-level CLI
• EMS – HTTP web-based EMS
• NMS and SML –PolyView/NetMaster platform
Every FibeAir IP-10 and IP-20 network element includes an HTTP web-based
element manager (CeraWeb) that enables the operator to perform element
configuration, performance monitoring, remote diagnostics, alarm reports, and
more.
In addition, Ceragon provides an SNMP v1/v2c/v3 northbound interface on the IP-
20N.
Ceragon offers the NetMaster network management system (NMS), which
provides centralized operation and maintenance capability for the complete range
of network elements in an IP-20N system. IP-20N and other Ceragon network
elements can also be managed via Ceragon’s PolyView NMS. To facilitate
automated network topology discovery via NMS, IP-20N supports the Link Layer
Discovery Protocol (LLDP).
In addition, management, configuration, and maintenance tasks can be
performed directly via the IP-20N Command Line Interface (CLI). The CLI can be
used to perform configuration operations for IP-20N units, as well as to configure
several IP-20N units in a single batch command.
Northbound OSS/NMS
SNMP
NetAct
CLI Interface
NMS
Client NMS
TCP, Secured
SSL Channel Platform
REST
Over
HTTP
Web EMS
SNMP
HTTP/HTTPS HTTP/HTTPS
FTP/SFTP FTP/SFTP
CLI
HTTP
Craft IP-20N
Figure 192: Integrated IP-20N Management Tools
Page 318 of 468

7.2 Automatic Network Topology Discovery with LLDP Protocol

FibeAir IP-20N supports the Link Layer Discovery Protocol (LLDP), a vendor-neutral
layer 2 protocol that can be used by a station attached to a specific LAN segment
to advertise its identity and capabilities and to receive identity and capacity
information from physically adjacent layer 2 peers. IP-20N’s LLDP implementation
is based on the IEEE 802.1AB – 2009 standard.
LLDP provides automatic network connectivity discovery by means of a port
identity information exchange between each port and its peer. The port
exchanges information with its peer and advertises this information to the NMS
managing the unit. This enables the NMS to quickly identify changes to the
network topology.
Enabling LLDP on IP-20 units enables the NMS to:
• Automatically detect the IP-20 unit neighboring the managed IP-20 unit, and
determine the connectivity state between the two units.
• Automatically detect a third-party switch or router neighboring the managed
IP-20 unit, and determine the connectivity state between the IP-20 unit and
the switch or router.
Page 319 of 468

7.3 Management Communication Channels and Protocols

Related Topics:
• Secure Communication Channels
Network Elements can be accessed locally via serial or Ethernet management
interfaces, or remotely through the standard Ethernet LAN. The application layer
is indifferent to the access channel used.
The NMS can be accessed through its GUI interface application, which may run
locally or in a separate platform; it also has an SNMP-based northbound interface
to communicate with other management systems.
Table 81: Dedicated Management Ports
Port number Protocol Frame structure Details
161 SNMP UDP Sends SNMP Requests to the network elements

162 Configurable SNMP (traps) UDP Sends SNMP traps forwarding (optional)
80 HTTP TCP Manages devices
443 HTTPS TCP Manages devices (optional)
From port 21 (default) FTP Control TCP Downloads software and configuration files,
to any remote port Port uploads security and configuration logs, and unit
(>1023). info files.
Initial port (21) is (FTP Server responds to client's control port)
configurable. (optional)
From Any port (>1023) FTP Data Port TCP Downloads software and configuration files,
to any remote port uploads security and configuration logs, and unit
(>1023) info files.
The FTP server sends ACKs (and data) to client's
data port.
From port 22 (default) SFTP Control TCP Downloads software and configuration files, and
to any remote port Port CSR certificates, uploads security and
(>1023). configuration logs, and unit info files.
Initial port (22) is (SFTP Server responds to client's control port)
configurable. (optional)
From Any port (>1023) SFTP Data Port TCP Downloads software and configuration files, and
to any remote port CSR certificates, uploads security and
(>1023) configuration logs, and unit info files.
The SFTP server sends ACKs (and data) to client's
data port.
23 telnet TCP Remote CLI access (optional)
22 SSH TCP Secure remote CLI access (optional)
All remote system management is carried out through standard IP

communications. Each NE behaves as a host with a single IP address.
Page 320 of 468

The communications protocol used depends on the management channel being

accessed.
As a baseline, these are the protocols in use:
• Standard HTTP for web-based management
• Standard telnet for CLI-based management
Page 321 of 468

7.4 Web-Based Element Management System (Web EMS)

The IP-20N Element Management System (Web EMS) is an HTTP web-based
element manager that enables the operator to perform configuration operations
and obtain statistical and performance information related to the system,
including:
• Configuration Management – Enables you to view and define configuration
data for the IP-20N system.
• Fault Monitoring – Enables you to view active alarms.
• Performance Monitoring – Enables you to view and clear performance
monitoring values and counters.
• Diagnostics and Maintenance – Enables you to define and perform loopback
tests, software updates, and IDU-RFU interface monitoring.
• Security Configuration – Enables you to configure IP-20N security features.
• User Management – Enables you to define users and user profiles.
A Web-Based EMS connection to the IP-20N can be opened using an HTTP
Browser (Explorer or Mozilla Firefox). The Web EMS uses a graphical interface.
Most system configurations and statuses are available via the Web EMS. However,
some advanced configuration options are only available via CLI.
Note: For optimal Web EMS performance, it is recommended to ensure
that the network speed is at least 100 Kbps for most operations,
and at least 5 Mbps for software download operations.
The Web EMS shows the actual chassis configuration and provides easy access to
any card and interface in the chassis. The Web EMS opens to a Unit and Radio
Summary page that displays the key unit, link, and radio parameters on a single
page for quick viewing. This page can be customized to include only specific
columns and tables, enabling the user to hide information that he does not need
in order to focus on the information that is most relevant to his needs in
monitoring and managing the unit.
The Web EMS includes a Quick Platform Setup page designed to simplify initial
configuration and minimize the time it takes to configure a working link.
The Web EMS also includes quick link configuration wizards that guide the user,
step-by-step, through the creation of:
• 1+0 links with Pipe services
• 1+0 repeater links (radio to radio) with Pipe services
• 1+1 HSB links with Pipe services
• 1+1 HSB links with Space Diversity and Pipe services
• 2+2 HSB links with Space Diversity and Pipe services
• N+0 Multi-Carrier ABC groups
• 2+0 BBC Space Diversity links with Pipe services
• 4+0 BBC Space Diversity links with Pipe services
• TDM services
• Pseudowire services
Page 322 of 468

7.5 Command Line Interface (CLI)

A CLI connection to the IP-20N can be opened via terminal (serial COM, speed:
115200, Data: 8 bits, Stop: 1 bit, Flow-Control: None), or via telnet. The Terminal
format should be VT-100 with a screen definition of 80 columns X 24 rows.
Note: Telnet access can be blocked by user configuration.
All parameter configurations can be performed via CLI.
7.6 Slot Management and Card Configuration

Card configuration is stored by the slot. This means that card configuration can be
performed even before the card has been inserted into the chassis by configuring
the slot and setting the slot to disable mode. When the card is inserted into the
chassis, the configuration is automatically applied to the card. In the event that a
card is replaced by the same type of card, the configuration of the previous card is
automatically applied to the new card.
7.7 Configuration Management

The system configuration file consists of a set of all the configurable system
parameters and their current values.
IP-20N configuration files can be imported and exported. This enables you to copy
the system configuration to multiple IP-20N units.
System configuration files consist of a zip file that contains three components:
• A binary configuration file which is used by the system to restore the
configuration.
• A text file which enables users to examine the system configuration in a
readable format. The file includes the value of all system parameters at the
time of creation of the backup file.
• An additional text file which enables users to write CLI scripts in order to make
desired changes in the backed-up configuration. This file is executed by the
system after restoring the configuration.49
The system provides three restore points to manage different configuration files.
Each restore point contains a single configuration file. Files can be added to
restore points by creating backups of the current system state or by importing
them from an external server.
Note: In the Web EMS, these restore points are referred to as “file
numbers.”
For example, a user may want to use one restore point to keep a last good
configuration, another to import changes from an external server, and the third to
store the current configuration.
Any of the restore points can be used to apply a configuration file to the system.
49
The option to edit the backup configuration is planned for future release.
Page 323 of 468

The user can determine whether or not to include security-related settings, such
as users and user profiles, in the exported configuration file. By default, security
settings are included.
Note: The option to enable or disable import and export of security
parameters is planned for future release.
7.8 Software Management

The IP-20N software installation and upgrade process includes the following steps:
• Download – The files required for the installation or upgrade are downloaded
from a remote server.
• Installation – The files are installed in the appropriate modules and
components of the IP-20N.
• Reset – The IP-20N is restarted in order to boot the new software and
firmware versions.
IP-20N software and firmware releases are provided in a single bundle that
includes software and firmware for all components and card types supported by
the system, including RFUs. When the user downloads a software bundle, the
system verifies the validity of the bundle. The system also compares the files in
the bundle to the files currently installed in the IP-20N and its components, so
that only files that differ between the new version bundle and the current version
in the system are actually downloaded. A message is displayed to the user for
each file that is actually downloaded.
Note: When downloading an older version, all files in the bundle may
be downloaded, including files that are already installed.
Software bundles can be downloaded via FTP, SFTP, HTTP, or HTTPS. When
downloading software via HTTP or HTTPS, the IP-20N unit acts as an HTTP server,
and the software can be downloaded directly to the unit. When downloading
software via FTP or SFTP, the IP-20N functions as an FTP or SFTP client, and FTP or
SFTP server software must be installed on the PC or laptop being using to perform
the upgrade.
After the software download is complete, the user initiates the installation. A
timer can be used to perform the installation after a defined time interval. When
an installation timer is used, the system performs an automatic reset after the
installation.
Although RFU software is included in the standard installation bundle, the current
software version is not automatically updated in the radio slots when an
installation is performed. To upgrade the software in an RFU, you must perform
the upgrade manually, per slot. This enables users to manage IDU and RFU
software versions separately.
7.8.1 Backup Software Version

Note: Backup software version support is planned for future release.
IP-20N maintains a backup copy of the software bundle. In the event that the
working software version cannot be found, or the operating system fails to start
Page 324 of 468

properly, the system automatically boots from the backup version, and the previously
active version becomes the backup version.
Users can also update the backup version manually. The Web EMS includes a field
that indicates whether or not the active and backup software versions are identical.
7.9 CeraPlan Service for Creating Pre-Defined Configuration Files

IP-20 units running CeraOS 9.2 or higher can be configured from the Web EMS in a
single step by applying a pre-defined configuration file. This drastically reduces
the initial installation and setup time in the field.
Using pre-defined configuration files also reduces the risk of configuration errors
and enables operators to invest less time and money training installation
personnel. Installers can focus on hardware configuration, relying on the pre-
defined configuration file to implement the proper software configuration on
each device.
The pre-defined configuration file is generated by Ceragon Professional Services
and provided as a service.
A pre-defined configuration file can be prepared for multiple IP-20 units, with the
relevant configuration details specified and differentiated per-unit. This simplifies
administration, since a single file can be used with multiple devices.
Pre-defined configuration files can include all the parameters necessary to
configure basic links, including:
• ETSI to ANSI conversion
• Activation Key (or Demo mode) configuration
• Radio Parameters
• Interface Groups (LAG, Multi-Carrier ABC, XPIC)
• Management Service
All configurations that can be implemented via the Web EMS Quick Configuration
wizards can also be configured using pre-defined configuration files.
Pre-defined configuration files can be created by Ceragon Professional Services,
according to customer specifications. For further information on CeraPlan, consult
your Ceragon representative.
7.10 IPv6 Support

FibeAir IP-20N management communications can use both IPv4 and IPv6. The unit
IP address for management can be configured in either or both formats.
Additionally, other management communications can utilize either IPv4 or IPv6.
This includes:
• Software file downloads
• Configuration file import and export
• Trap forwarding
• Unit information file export (used primarily for maintenance and
troubleshooting)
Page 325 of 468

7.11 In-Band Management

FibeAir IP-20N can optionally be managed In-Band, via its radio and Ethernet
interfaces. This method of management eliminates the need for a dedicated
management interface. For more information, refer to Management Service
(MNG) on page 217.
7.12 Local Management

IP-20N provides one or two FE ports on the TCC for local management. TCC-B and
TCC-B-MC include two FE management ports. TCC-B2 and TCC-B2-XG-MC include
two FE management interfaces, which connect to a single RJ-45 physical
connector on the front panel. The first port is enabled by default. The second port
can be enabled manually.
The two management ports give users the ability not only to manage the IP-20N
directly via a laptop or PC, but also to manage other devices via the second
management port of the IP-20N.
Page 326 of 468

7.13 Alarms
7.13.1 Configurable BER Threshold Alarms and Traps

Users can configure alarm and trap generation in the event of Excessive BER and
Signal Degrade BER above user-defined thresholds. Users have the option to
configure whether or not excessive BER is propagated as a fault and considered a
system event.
7.13.2 RSL Threshold Alarm

Users can configure an alarm that is raised if the RSL falls beneath a user-defined
threshold. This feature can be enabled or disabled per radio carrier. By default, it
is disabled. The RSL threshold alarm provides a preventative maintenance tool for
monitoring the health of the link and ensuring that problems can be identified and
corrected quickly.
7.13.3 Editing and Disabling Alarms and Events

Users can change the description text (by appending extra text to the existing
description) or the severity of any alarm in the system. Users can also choose to
disable specific alarms and events. Any alarm or event can be disabled, so that no
indication of the alarm or event is displayed, and no traps are sent for the alarm
or event.
This is performed as follows:
• Each alarm and event in the system is identified by a unique name (see
separate list of system alarms and events).
• The user can perform the following operations on any alarm:
◦ View current description and severity
◦ Define the text to be appended to the description and/or severity
◦ Return the alarm to its default values
◦ Disable or re-enable the alarm (or event)
• The user can also return all alarms and events to their default values.
7.13.4 Timeout for Trap Generation

Users can configure a wait time of 0 to 120 seconds after an alarm is cleared in
the system before the alarm is actually reported as being cleared. This prevents
traps flooding the NMS in the event that some external condition causes the
alarm to be raised and cleared continuously.
This means that when the alarm is cleared, the alarm continues to be displayed
and no clear alarm trap is sent until the timeout period is finished.
The timeout for trap generation can be configured via CLI. By default, the timeout
is 10 seconds.
Page 327 of 468

7.14 External Alarms

IP-20N includes a DB9 dry contact external alarms interface. The external alarms
interface supports five input alarms. For each alarm input, the user can configure
the following:
1 Alarm administration (On or Off)
2 Alarm text
3 Alarm severity
Alarm severity can be configured to:
1 Indeterminate
2 Critical
3 Major
4 Minor
5 Warning
7.15 NTP Support

IP-20N supports Network Time Protocol (NTP). NTP distributes Coordinated
Universal Time (UTC) throughout the system, using a jitter buffer to neutralize the
effects of variable latency.
IP-20N supports NTPv3 and NTPv4. NTPv4 provides interoperability with NTPv3
and with SNTP.
7.16 UTC Support

IP-20N uses the Coordinated Universal Time (UTC) standard for time and date
configuration. UTC is a more updated and accurate method of date coordination
than the earlier date standard, Greenwich Mean Time (GMT).
Every IP-20N unit holds the UTC offset and daylight savings time information for
the location of the unit. Each management unit presenting the information (CLI
and Web EMS) uses its own UTC offset to present the information in the correct
time.
7.17 System Security Features

To guarantee proper performance and availability of a network as well as the data
integrity of the traffic, it is imperative to protect it from all potential threats, both
internal (misuse by operators and administrators) and external (attacks
originating outside the network).
System security is based on making attacks difficult (in the sense that the effort
required to carry them out is not worth the possible gain) by putting technical and
operational barriers in every layer along the way, from the access outside the
network, through the authentication process, up to every data link in the network.
Page 328 of 468

7.17.1 Ceragon’s Layered Security Concept

Each layer protects against one or more threats. However, it is the combination of
them that provides adequate protection to the network. In most cases, no single
layer protection provides a complete solution to threats.
The layered security concept is presented in the following figure. Each layer
presents the security features and the threats addressed by it. Unless stated
otherwise, requirements refer to both network elements and the NMS.
Figure 193: Security Solution Architecture Concept
7.17.2 Defenses in Management Communication Channels

Since network equipment can be managed from any location, it is necessary to
protect the communication channels’ contents end to end.
These defenses are based on existing and proven cryptographic techniques and
libraries, thus providing standard secure means to manage the network, with
minimal impact on usability.
They provide defense at any point (including public networks and radio
aggregation networks) of communications.
While these features are implemented in Ceragon equipment, it is the
responsibility of the operator to have the proper capabilities in any external
devices used to manage the network.
In addition, inside Ceragon networking equipment it is possible to control physical
channels used for management. This can greatly help deal with all sorts of DoS
attacks.
Page 329 of 468

Operators can use secure channels instead or in addition to the existing

management channels:
• SNMPv3 for all SNMP-based protocols for both NEs and NMS
• HTTPS for access to the NE’s web server
• SSH-2 for all CLI access SFTP for all software and configuration download
between NMS and NEs
All protocols run with secure settings using strong encryption techniques.
Unencrypted modes are not allowed, and algorithms used must meet modern and
client standards.
Users are allowed to disable all insecure channels.
In the network elements, the bandwidth of physical channels transporting
management communications is limited to the appropriate magnitude, in
particular, channels carrying management frames to the CPU.
Attack types addressed
• Tempering with management flows
• Management traffic analysis
• Unauthorized software installation
• Attacks on protocols (by providing secrecy and integrity to messages)
• Traffic interfaces eavesdropping (by making it harder to change configuration)
• DoS through flooding
7.17.3 Defenses in User and System Authentication Procedures
7.17.3.1 User Configuration and User Profiles

User configuration is based on the Role-Based Access Control (RBAC) model.
According to the RBAC model, permissions to perform certain operations are
assigned to specific roles. Users are assigned to particular roles, and through
those role assignments acquire the permissions to perform particular system
functions.
In the IP-20N GUI, these roles are called user profiles. Up to 50 user profiles can
be configured. Each profile contains a set of privilege levels per functionality
group, and defines the management protocols (access channels) that can be used
to access the system by users to whom the user profile is assigned.
The system parameters are divided into the following functional groups:
• Security
• Management
• Radio
• TDM
• Ethernet
• Synchronization
Page 330 of 468

A user profile defines the permitted access level per functionality group. For each
functionality group, the access level is defined separately for read and write
operations. The following access levels can be assigned:
• None – No access to this functional group.
• Normal – The user has access to parameters that require basic knowledge
about the functional group.
• Advance – The user has access to parameters that require advanced
knowledge about the functional group, as well as parameters that have a
significant impact on the system as a whole, such as restoring the
configuration to factory default settings.
7.17.3.2 User Identification

IP-20N supports the following user identification features:
• Configurable inactivity time-out for automatically closing unused management
channels
• Optional password strength enforcement. When password strength
enforcement is enabled; passwords must comply with the following rules:
 Password must be at least eight characters long.
 Password must include at least three of the following categories: lower-case
characters, upper-case characters, digits, and special characters.
 When calculating the number of character categories, upper-case letters used as
the first character and digits used as the last character of a password are not
counted.
 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.17.3.3 Remote Authentication

Note: Remote authorization is planned for future release.
Certificate-based strong standard encryption techniques are used for remote
authentication. Users may choose to use this feature or not for all secure
communication channels.
Since different operators may have different certificate-based authentication
policies (for example, issuing its own certificates vs. using an external CA or
allowing the NMS system to be a CA), NEs and NMS software provide the tools
required for operators to enforce their policy and create certificates according to
their established processes.
Server authentication capabilities are provided.
Page 331 of 468

7.17.3.4 RADIUS Support

The RADIUS protocol provides centralized user management services. IP-20N
supports RADIUS server and provides a RADIUS client for authentication and
authorization.
RADIUS can be enabled or disabled. When RADIUS is enabled, a user attempting
to log into the system from any access channel (CLI, WEB, NMS) is not
authenticated locally. Instead, the user’s credentials are sent to a centralized
standard RADIUS server which indicates to the IP-20N whether the user is known,
and which privilege is to be given to the user. RADIUS uses the same user
attributes and privileges defined for the user locally.
Note: When using RADIUS for user authentication and authorization,
the access channels configured per IP-20 user profile are not
applicable. Instead, the access channels must be configured as
part of the RADIUS server configuration.
RADIUS login works as follows:
• If the RADIUS server is reachable, the system expects authorization to be
received from the server:
 The server sends the appropriate user privilege to the IP-20N, or notifies the IP-
20N that the user was rejected.
 If rejected, the user will be unable to log in. Otherwise, the user will log in with the
appropriate privilege and will continue to operate normally.
• If the RADIUS server is unavailable, the IP-20N will attempt to authenticate
the user locally, according to the existing list of defined users.
Note: Local login authentication is provided in order to enable users to
manage the system in the event that RADIUS server is
unavailable. This requires previous definition of users in the
system. If the user is only defined in the RADIUS server, the user
will be unable to login locally in case the RADIUS server is
unavailable.
In order to support IP-20N - specific privilege levels, the vendor-specific field is
used. Ceragon’s IANA number for this field is 2281.
The following RADIUS servers are supported:
• FreeRADIUS
• RADIUS on Windows Server (IAS)
 Windows Server 2008
7.17.4 Secure Communication Channels

IP-20N supports a variety of standard encryption protocols and algorithms, as
described in the following sections.
Page 332 of 468

7.17.4.1 SSH (Secured Shell)

SSH protocol can be used as a secured alternative to Telnet. In IP-20N:
• SSHv2 is supported.
• SSH protocol will always be operational. Admin users can choose whether to
disable Telnet protocol, which is enabled by default. Server authentication is
based on IP-20N’s public key.
• RSA and DSA key types are supported.
• MAC (Message Authentication Code): SHA-1-96 (MAC length = 96 bits, key
length = 160 bit). Supported MAC: hmac-md5, hmac-sha1, hmac-ripemd160,
hmac-sha1-96, hmac-md5-96'
• The server authenticates the user based on user name and password. The
number of failed authentication attempts is not limited.
• The server timeout for authentication is 10 minutes. This value cannot be
changed.
7.17.4.2 HTTPS (Hypertext Transfer Protocol Secure)

HTTPS combines the Hypertext Transfer protocol with the SSLv3/TLS (1.0, 1.1, 1.2)
protocol to provide encrypted communication and secure identification of a
network web server. IP-20N enables administrators to configure secure access via
HTTPS protocol.
Users can configure the IP-20 to operate in HTTPS strong mode. In HTTPS strong
mode, SSLv3, TLSv1.0, and TLSv1.1 are disabled completely and only certain
ciphers are supported for TLSv1.2.
For a list of supported HTTPS ciphers, including an indication of which ciphers are
supported in HTTPS strong mode, see Annex B – Supported Ciphers for Secured
Communication Protocols in the Release Notes for the CeraOS version you are
using.
7.17.4.3 SFTP (Secure FTP)

SFTP can be used for the following operations:
• Configuration upload and download,
• Uploading unit information
• Uploading a public key
• Downloading certificate files
• Downloading software
7.17.4.4 Creation of Certificate Signing Request (CSR) File

In order to create a digital certificate for the NE, a Certificate Signing Request
(CSR) file should be created by the NE. The CSR contains information that will be
included in the NE's certificate such as the organization name, common name
(domain name), locality, and country. It also contains the public key that will be
included in the certificate. Certificate authority (CA) will use the CSR to create the
desired certificate for the NE.
Page 333 of 468

While creating the CSR file, the user will be asked to input the following
parameters that should be known to the operator who applies the command:
• Common name – The identify name of the element in the network (e.g., the IP
address). The common name can be a network IP or the FQDN of the element.
• Organization – The legal name of the organization.
• Organizational Unit - The division of the organization handling the certificate.
• City/Locality - The city where the organization is located.
• State/County/Region - The state/region where the organization is located.
• Country - The two-letter ISO code for the country where the organization is
location.
• Email address - An email address used to contact the organization.
7.17.4.5 SNMP
IP-20N 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-20N 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.

• FibeAir IP-20 Series MIB Reference
7.17.4.6 Server Authentication (SSLv3/TLS (1.0, 1.1, 1.1))

• All protocols making use of SSL (such as HTTPS) use SLLv3/TLS (1.0, 1.1, 1.2)
and support X.509 certificates-based server authentication.
• Users with type of “administrator” or above can perform the following server
(IDU) authentication operations for certificates handling:
 Generate server key pairs (private + public)
 Export public key (as a file to a user-specified address)
 Install third-party certificates
◦The Admin user is responsible for obtaining a valid certificate.
 Load a server RSA key pair that was generated externally for use by protocols
making use of SSL.
• Non-SSL protocols using asymmetric encryption, such as SSH and SFTP, can
make use of public-key based authentication.
 Users can load trusted public keys for this purpose.
Page 334 of 468

7.17.5 Security Log

The security log is an internal system file which records all changes performed to
any security feature, as well as all security related events.
Note: In order to read the security log, the user must upload the log to
his or her server.
The security log file has the following attributes:
• The file is of a “cyclic” nature (fixed size, newest events overwrite oldest).
• The log can only be read by users with "admin" or above privilege.
• The contents of the log file are cryptographically protected and digitally
signed.
 In the event of an attempt to modify the file, an alarm will be raised.
• Users may not overwrite, delete, or modify the log file.
The security log records:
• Changes in security configuration
 Carrying out “security configuration copy to mate”
 Management channels time-out
 Password aging time
 Number of unsuccessful login attempts for user suspension
 Warning banner change
 Adding/deleting of users
 Password changed
 SNMP enable/disable
 SNMP version used (v1/v3) change
 SNMPv3 parameters change
◦ Security mode
◦ Authentication algorithm
◦ User
◦ Password
 SNMPv1 parameters change
◦ Read community
◦ Write community
◦ Trap community for any manager
 HTTP/HTTPS change
 FTP/SFTP change
 Telnet and web interface enable/disable
 FTP enable/disable
 Loading certificates
 RADIUS server
 Radius enable/disable
 Remote logging enable/disable (for security and configuration logs)
Page 335 of 468

 System clock change

 NTP enable/disable
• Security events
• Successful and unsuccessful login attempts
• N consecutive unsuccessful login attempts (blocking)
• Configuration change failure due to insufficient permissions
• SNMPv3/PV authentication failures
• User logout
• User account expired
For each recorded event the following information is available:
• User ID
• Communication channel (WEB, terminal, telnet/SSH, SNMP, NMS, etc.)
• IP address, if applicable
• Date and time
Page 336 of 468

8. Standards and Certifications

• Supported Ethernet Standards
• MEF Certifications for Ethernet Services
• Supported TDM Pseudowire Encapsulations
• Standards Compliance
• Network Management, Diagnostics, Status, and Alarms
Page 337 of 468

8.1 Supported Ethernet Standards

Table 82: Supported Ethernet Standards
Standard Description
802.3 10base-T
802.3u 100base-T
802.3ab 1000base-T
802.3z 1000base-X
802.3ae 10GBase-LR
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
Page 338 of 468

8.2 MEF Certifications for Ethernet Services
Table 83: Supported MEF Specifications
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
Table 84: 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 1st 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)
Page 339 of 468

8.3 Supported TDM Pseudowire Encapsulations

Certification Description Availability
VLAN (MEF-8) Circuit Emulation Services over Available.

native Ethernet frames
IP/UDP (IETF) Layer 3 encapsulation over Planned for future
Ethernet release.
MPLS (MFA8) MPLS encapsulation over Ethernet Planned for future
release.
8.4 Standards Compliance

Specification Standard
Radio EN 302 217-2

EMC EN 301 489-4
EN 301 489-1
FCC 47 CFR, part 15, subpart B
ICES-003
Safety EN 60950-1
IEC 60950-1
UL 60950-1
CSA-C22.2 No.60950-1
EN 60950-22 (RFU only)
UL 60950-22 (RFU only)
CSA C22.2.60950-22 (RFU only)
IEC 60950-22 (RFU only)
Ingress Protection (RFUs) RFU-D: IP67
RFU-D-HP: IP67
RFU-E: IP67
RFU-S: IP67
RFU-C: IP66
1500HP/RFU-HP: IP56
Operation IDU: ETSI EN 300 019-1-3 Class 3.2
RFU: ETSI EN 300 019-1-4 Class 4.1
Storage ETSI EN 300 019-1-1 Class 1.2
Transportation ETSI EN 300 019-1-2 Class 2
Page 340 of 468

8.5 Network Management, Diagnostics, Status, and Alarms

Network Management NetMaster/PolyView
System
NMS Interface protocol SNMPv1/v2c/v3

XML over HTTP/HTTPS toward the NMS
Element Management Web based EMS, CLI
Management Channels & HTTP/HTTPS
Protocols Telnet/SSH-2
FTP/SFTP
Authentication, User access control
Authorization & Accounting X-509 Certificate
Management Interface Dedicated Ethernet interfaces or in-band in traffic ports
In-Band Management Support dedicated VLAN for management
TMN The NMS functions are in accordance with ITU-T
recommendations for TMN
RSL Indication Power reading (dBm) available at RFU50, and NMS
Performance Monitoring Integral with onboard memory per ITU-T G.826/G.828
50
Note that the voltage measured at the BNC port is not accurate and should be used only as an aid.
Page 341 of 468

9. Specifications
• General Radio Specifications
• Radio Scripts
• Radio Capacity Specifications
• Transmit Power Specifications (dBm)
• Receiver Threshold Specifications
• Frequency Bands
• Ethernet Latency Specifications
• Mediation Device and Branching Network Losses
• Ethernet Specifications
• TDM 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.
Page 342 of 468

9.1 General Radio Specifications

9.1.1 General Radio Specifications for Microwave RFUs
Note: The 4-5 GHz bands are only relevant for RFU-D-HP. Bands above
11 GHz are not relevant for RFU-D-HP or 1500HP/RFU-HP.
Table 85: Radio Frequencies
Frequency (GHz) Operating Frequency Range (GHz) Tx/Rx Spacing (MHz)
4 3.4-4.2 213, 266, 320

5 4.4-5.0 100, 300, 312
6L,6H 5.85-6.45, 6.4-7.125 252.04, 240, 266, 300, 340, 160, 170, 500
7,8 7.1-7.9, 7.7-8.5 154, 119, 161, 168, 182, 196, 208, 245,
250, 266, 300,310, 311.312, 500, 530
10 10.0-10.7 91, 168,350, 550
11 10.7-11.7 490, 520, 530
13 12.75-13.3 266
15 14.4-15.35 315, 420, 475, 644, 490, 728
18 17.7-19.7 1010, 1120, 1008, 1560
23 21.2-23.65 1008, 1200, 1232
24UL 24.0-24.25 Customer-defined
26 24.2-26.5 800, 1008
28 27.35-29.5 350, 450, 490, 1008
32 31.8-33.4 812
36 36.0-37.0 700
38 37-40 1000, 1260, 700
42 40.55-43.45 1500
Table 86: General Radio Specifications – Microwave RFUs
Standards ETSI, ITU-R, CEPT

Frequency Stability +0.001%
Frequency Source Synthesizer
RF Channel Selection Via EMS/NMS
Tx Range (Manual/ATPC) The dynamic TX range with ATPC is the same as the manual TX
range, and depends on the RFU type, the frequency, and the
ACM profile. The maximum TX power with ATPC is no higher
than the maximum manually configured TX power.
Page 343 of 468

9.1.2 General Radio Specifications for E-Band
Table 87: Radio Frequencies and General Radio Specifications – RFU-E
Specification Description
Standards ETSI, ITU-R, CEPT

Operating mode FDD
Operating Frequency Range 71-76GHz, 81-86GHz
Channel Spacing 14 MHz, 28 MHz, 62.5 MHz, 125 MHz, 250 MHz, 500 MHz
Frequency Stability +0.001%
Table 88: Frequency Tuning Range for RFU-E
Low Range [MHz] High Range [MHz] TX-RX Separation [MHz] Low BW [MHz] High BW [MHz]
71,000 - 76000 81,000 – 86,000 10,000 5000 5000
Page 344 of 468

9.2 Radio Scripts

Designated ETSI System Class Explanation:
ACCP ACAP CCDP

(Adjacent Channel Co (Adjacent Channel (Co Channel Dual
Polarization) Alternate Polarization) Polarization)
H H
V V
Figure 194: Designated ETSI System Class Explanation
Note that:
LIC-STM1/OC3-RST is not supported when the radio’s profile is
set to 2048 QAM profile 10.
XPIC scripts (all scripts with Script ID 12XX) are not supported in
1+1 HSB radio protection mode.
Although in some cases it may be possible to configure higher

profiles, the maximum supported profiles are those listed in the
tables below.
Page 345 of 468

9.2.1 MRMC Scripts Supported with RIC-D and RFU-D, RFU-D-HP, and RFU-S
Note: Profile 12 (4096 QAM) is not supported for 112 MHz channels.
For detailed specifications of maximum profile per frequency and
channel bandwidth, consult your Ceragon representative.
XPIC is only supported with RFU-D and RFU-D-HP.
Indications of supported System Classes in the following table

refer to the script characteristics only. Regulatory issues must be
determined under the applicable local standards.
Table 89: MRMC Scripts Supported with RIC-D and RFU-D, RFU-D-HP, and RFU-S
Script ID Channel Occupied System XPIC BBC-SD Highest Spectral Max Profile (ACM) Max Profile
BW BW Class (CCDP) Efficiency Class (Fixed)
4509 14 13.3 ACCP Yes No 7B 10 (1024 QAM 9 (1024 QAM

Light FEC) Strong FEC)
4504 28 26.5 ACCP Yes No 8B 12 (4096 QAM) 11
4505 28 28 ACAP No No 8A 12 11
4514 28 26 ACCP Yes Yes 8B 12 11
490151 28 26.5 ACCP Yes No 8B 12 11
4507 40 37.4 ACCP Yes No 8B 12 11
4517 40 33.5 ACCP Yes No 8B 12 11
490251 40 37.6 ACCP Yes Yes 8B 12 11
4502 56 53 ACCP Yes No 8B 12 11
4506 56 55.7 ACAP Yes No 8A 12 11
490351 56 53 ACCP Yes Yes 8B 12 11
4501 80 74 ACCP Yes No 8B 11 10
490551 80 74.1 ACCP Yes Yes 8B 11 10
4511 112 106 ACCP Yes No 8B 11 10
491151 112 106 ACCP Yes Yes 8B 11 10
51
MRMC scripts 4901 and 4905 are exclusively to be used for BBC Space Diversity with IP-20N/IP-20A and
RFU-D/RFU-D-HP.
Page 346 of 468

9.2.2 MRMC Scripts Supported with RIC-D and RFU-E

Table 90: MRMC Scripts Supported with RIC-D and RFU-E
Script ID Channel BW Occupied BW Maximum Profile Maximum Profile

(ACM) (Fixed)
4509 14 MHz 13.3 MHz 2 (8 QAM) 2 (8 QAM)

4504 28 MHz 26.5 MHz 8 (512 QAM) 4 (32 QAM)
4701 62.5 MHz 57 MHz 9 (1024 QAM) 7 (256 QAM)
4700 125 MHz 115 MHz 8 (512 QAM) 7 (256 QAM)
4702 250 MHz 230 MHz 7 (256 QAM) 6 (128 QAM)
4704 500 MHz 460 MHz 5 (64 QAM) ACM mode only
Page 347 of 468

9.2.3 MRMC Scripts Supported with RMC-B

The MRMC scripts listed in the following table are used with RMC-B.
Note: Indications of supported System Classes in the following table
refer to the script characteristics only. Regulatory issues must be
determined under the applicable local standards.
Table 91: MRMC Scripts Supported with RMC-B
Script Channel Occupied RFU-C System RFU-HP/1500HP XPIC Highest Spectral Max Profile Max Profile
ID BW BW Class System Class (CCDP) Efficiency Class (ACM) (Fixed)
1023 3.5 3.267 ACCP ACAP No 6L 5 (256 QAM) 4 (128 QAM)

1008 7 6.5 ACCP ACAP No 7B 9 8
1009 14 13.3 ACCP ACAP No 7B 9 8
1209 14 13.3 ACCP ACAP Yes 7B 9 8
1004 28 26.5 ACCP ACAP No 8B 10 9
1204 28 26.5 ACCP ACAP Yes 7B 9 8
52
1214 28 26 - ACCP Yes 7B 9 8
1005 28 28 ACAP ACAP No 8A 10 9
1205 28 28 ACAP ACAP Yes 7A 9 8
121753 40 33.5 - ACCP Yes 7B 9 8
1007 40 37.4 ACCP ACAP No 8B 10 9
1207 40 37.4 ACCP ACAP Yes 7B 9 8
1003 56 53 ACCP ACAP No 8B 10 9
1006 56 55.7 ACAP ACAP No 8A 10 9
1203 56 53 ACCP ACAP Yes 7B 9 8
1206 56 55.7 ACAP ACAP Yes 7A 9 8
52
MRMC script 1214 provides smaller bandwidth than MRMC script 1204. Script 1214 can be used for
interoperability with existing equipment in the field. It is an Adjacent Channel script, for use with RFU-
HP and 1500HP only.
53
MRMC script 1217 provides smaller bandwidth than MRMC script 1207. Script 1217 can be used for
interoperability with existing equipment in the field. It is an Adjacent Channel script, for use with RFU-
HP and 1500HP only.
Page 348 of 468

9.2.4 MRMC Scripts Supported with RMC-A

The MRMC scripts listed in the following table are used with RMC-A. The highest
modulation supported by these scripts is 256 QAM.
Table 92: MRMC Scripts Supported with RMC-A
Script Channel Occupied System Highest Spectral ACM XPIC

ID BW BW Class Efficiency Class (CCDP)
33 7 6.5 ACCP 5B Yes No

23 14 13 ACCP 2,4,5B Yes No
22 28 27 ACCP 5B Yes No
16 40 36 ACAP 5B Yes No
13 56 52 ACAP 5B Yes No
Page 349 of 468

9.3 Radio Capacity Specifications

Each table in this section includes ranges of capacity specifications according to
frame size, with ranges given for no Header De-Duplication, Layer-2 Header De-
Duplication, and LTE-optimized Header De-Duplication. Actual values may differ
from these ranges by up to 3 Mbps.
Each table provides the capacity specifications for a specific MRMC script, as
indicated in the table caption.
Notes: The figures in this section are indicative only. Exact results will
depend on multiple factors, such as packet size, type of traffic,
headers, etc.
Ethernet capacity depends on average frame size.
For LTE-Optimized Header De-Duplication, the capacity figures
are for LTE packets encapsulated inside GTP tunnels with
IPv4/UDP encapsulation and double VLAN tagging (QinQ).
Capacity for IPv6 encapsulation is higher.
9.3.1 Radio Capacity Specifications – RIC-D with RFU-D, RFU-D-HP, and RFU-S
9.3.1.1 14 MHz – Script ID 4509
Table 93: Radio Capacity for 14 MHz
Profile Modulation Minimum Max # of Ethernet throughput

required capacity supported
activation key E1s No Header De- L2 Header De- LTE-Optimized
Duplication Duplication Header De-
Duplication
0 BPSK 10 4 6-8 7-10 7-25

1 QPSK 50 8 17-20 17-24 17-63
2 8 QAM 50 12 26-32 27-39 28-100
3 16 QAM 50 17 38-46 38-55 39-143
4 32 QAM 50 23 50-62 51-75 53-192
5 64 QAM 50 28 63-77 63-93 66-238
6 128 QAM 100 33 76-93 77-113 80-290
7 256 QAM 100 38 87-107 88-129 92-333
8 512 QAM 100 42 97-119 98-143 102-369
9 1024 QAM (Strong FEC) 100 45 103-126 103-152 108-391
10 1024 QAM (Light FEC) 100 47 109-133 110-161 115-415
Page 350 of 468

9.3.1.2 28 MHz – Script ID 4504

Duplication
0 BPSK 50 8 17-21 17-25 18-64

1 QPSK 50 17 38-46 38-55 39-143
2 8 QAM 50 25 57-70 58-85 60-218
3 16 QAM 100 35 79-97 80-117 83-302
4 32 QAM 100 46 106-129 106-156 111-401
5 64 QAM 150 56 131-160 132-193 137-497
6 128 QAM 150 68 158-193 159-233 166-600
7 256 QAM 200 77 180-220 181-266 189-685
8 512 QAM 200 85 199-244 201-294 209-758
9 1024 QAM (Strong FEC) 225 91 212-259 214-313 223-806
10 1024 QAM (Light FEC) 225 96 225-275 227-333 236-856
11 2048 QAM 250 103 242-295 243-357 254-919
12 4096 QAM 250 112 262-320 264-386 275-995
Page 351 of 468

9.3.1.3 28 MHz – Script ID 4505

Duplication
0 BPSK 50 9 18-22 18-26 19-68

1 QPSK 50 18 40-49 40-59 42-152
2 8 QAM 50 26 59-72 60-88 62-225
3 16 QAM 100 37 84-103 85-125 89-321
4 32 QAM 100 49 112-137 113-166 118-426
5 64 QAM 150 60 139-170 140-205 146-527
6 128 QAM 150 72 167-205 169-247 176-637
7 256 QAM 200 83 193-236 194-285 203-734
8 512 QAM 200 88 206-251 207-304 216-782
9 1024 QAM (Strong FEC) 225 96 225-274 226-332 236-854
10 1024 QAM (Light FEC) 225 102 238-291 240-352 250-906
11 2048 QAM 250 111 260-318 262-384 273-989
12 4096 QAM 300 118 277-339 279-410 291-1026
Page 352 of 468

9.3.1.4 28 MHz – Script ID 4514

Duplication
0 BPSK 50 8 16-20 16-24 17-61

1 QPSK 50 16 36-44 36-54 38-138
2 8 QAM 50 24 55-68 56-82 58-211
3 16 QAM 100 33 77-94 77-114 81-292
4 32 QAM 100 43 102-125 103-151 107-389
5 64 QAM 150 53 126-155 127-187 133-481
6 128 QAM 150 64 153-187 154-226 160-581
7 256 QAM 150 74 174-213 176-258 183-663
8 512 QAM 200 82 193-236 194-285 202-733
9 1024 QAM (Strong FEC) 200 87 205-251 207-303 215-780
10 1024 QAM (Light FEC) 225 92 218-266 220-322 229-829
11 2048 QAM 225 100 234-286 236-346 246-890
12 4096 QAM 250 107 253-310 255-374 266-963
Page 353 of 468

9.3.1.5 28 MHz – Script ID 4901

Duplication
0 BPSK 50 8 15-18 15-22 15-56

1 QPSK 50 16 35-43 35-52 37-134
2 8 QAM 50 24 55-67 55-81 57-208
3 16 QAM 100 33 76-93 76-112 80-288
4 32 QAM 100 45 103-126 104-152 108-392
5 64 QAM 150 55 126-154 127-186 132-479
6 128 QAM 150 67 155-189 156-229 163-589
7 256 QAM 200 76 177-217 179-262 186-674
8 512 QAM 200 79 180-220 182-266 189-686
9 1024 QAM (Strong FEC) 200 87 203-248 204-300 213-771
10 1024 QAM (Light FEC) 225 95 222-271 223-328 233-843
11 2048 QAM 250 102 239-292 241-353 251-909
12 4096 QAM 250 110 259-317 261-383 272-986
Page 354 of 468

9.3.1.6 40 MHz – Script ID 4507

Duplication
0 BPSK 50 12 26-31 26-38 27-97

1 QPSK 50 24 55-67 55-81 58-209
2 8 QAM 100 36 83-102 84-123 87-317
3 16 QAM 100 50 114-140 115-169 120-435
4 32 QAM 150 65 152-185 153-224 159-577
5 64 QAM 200 80 187-228 188-276 196-710
6 128 QAM 225 97 227-277 228-335 238-862
7 256 QAM 250 104 244-298 246-360 256-927
8 512 QAM 300 114 267-327 269-395 281-1016
9 1024 QAM (Strong FEC) 300 130 303-371 306-448 319-1026
10 1024 QAM (Light FEC) 300 138 323-394 325-477 339-1026
11 2048 QAM 350 149 349-427 352-516 367-1026
12 4096 QAM 400 156 369-451 372-546 388-1026
Page 355 of 468

9.3.1.7 40 MHz – Script ID 4517

Duplication
0 BPSK 50 10 23-28 23-33 24-86

1 QPSK 50 21 49-60 50-73 52-187
2 8 QAM 100 32 75-91 75-110 79-284
3 16 QAM 100 43 103-126 104-152 108-392
4 32 QAM 150 57 136-167 137-201 143-519
5 64 QAM 150 70 168-206 169-248 177-640
6 128 QAM 200 85 204-250 206-302 214-776
7 256 QAM 225 92 220-268 221-325 231-835
8 512 QAM 250 106 241-294 243-356 253-916
9 1024 QAM (Strong FEC) 300 115 274-335 276-404 287-1026
10 1024 QAM (Light FEC) 300 122 291-355 293-430 305-1026
11 2048 QAM 300 132 315-385 317-465 330-1026
12 4096 QAM 350 141 333-407 336-492 350-1026
Page 356 of 468

9.3.1.8 40 MHz – Script ID 4902

Duplication
0 BPSK 50 11 23-28 23-33 24-86

1 QPSK 50 23 51-63 52-76 54-195
2 8 QAM 100 35 80-98 81-118 84-304
3 16 QAM 100 50 115-140 115-169 120-436
4 32 QAM 150 66 153-188 155-227 161-584
5 64 QAM 200 78 182-223 184-269 191-693
6 128 QAM 225 92 215-263 217-318 226-820
7 256 QAM 250 104 244-298 246-361 256-928
8 512 QAM 300 114 268-327 270-396 281-1018
9 1024 QAM (Strong FEC) 300 129 303-370 305-448 318-1026
10 1024 QAM (Light FEC) 300 134 315-385 317-465 331-1026
11 2048 QAM 350 146 341-417 344-505 359-1026
12 4096 QAM 350 153 358-438 361-529 376-1026
Page 357 of 468

9.3.1.9 56 MHz – Script ID 4502

Duplication
0 BPSK 50 17 38-46 38-56 40-144

1 QPSK 100 35 80-97 80-118 84-303
2 8 QAM 100 52 120-147 121-177 126-457
3 16 QAM 150 71 165-201 166-243 173-626
4 32 QAM 225 93 217-266 219-321 228-827
5 64 QAM 300 114 267-327 270-395 281-1017
6 128 QAM 300 138 324-396 327-479 340-1026
7 256 QAM 400 158 371-453 374-548 390-1026
8 512 QAM 400 172 403-493 406-596 423-1026
9 1024 QAM (Strong FEC) 450 187 438-536 442-648 461-1026
10 1024 QAM (Light FEC) 450 198 466-569 469-688 489-1026
11 2048 QAM 500 209 490-600 494-725 515-1026
12 4096 QAM 500 221 520-636 524-768 546-1026
Page 358 of 468

9.3.1.10 56 MHz – Script ID 4506

Duplication
0 BPSK 50 18 40-49 40-59 42-153

1 QPSK 100 37 84-103 85-124 88-320
2 8 QAM 150 54 124-151 125-183 130-471
3 16 QAM 200 74 173-212 174-256 182-658
4 32 QAM 225 98 229-280 230-338 240-870
5 64 QAM 300 120 281-344 284-416 296-1026
6 128 QAM 350 145 341-416 343-503 358-1026
7 256 QAM 400 168 394-481 397-582 414-1026
8 512 QAM 450 180 424-518 427-626 445-1026
9 1024 QAM (Strong FEC) 450 196 461-564 465-681 484-1026
10 1024 QAM (Light FEC) 500 208 490-599 494-724 515-1026
11 2048 QAM 500 226 531-649 535-785 558-1026
12 4096 QAM 500 232 547-668 551-808 574-1026
Page 359 of 468

9.3.1.11 56 MHz – Script ID 4903

Duplication
0 BPSK 50 16 38-46 38-56 40-149

1 QPSK 100 33 77-94 78-114 81-302
2 8 QAM 100 51 121-148 122-180 128-476
3 16 QAM 150 71 169-206 170-250 177-661
4 32 QAM 225 94 223-273 225-331 234-874
5 64 QAM 250 111 262-321 265-389 276-1029
6 128 QAM 300 132 313-382 315-464 329-1225
7 256 QAM 350 151 358-437 360-530 376-1401
8 512 QAM 400 169 400-489 403-593 420-1566
9 1024 QAM (Strong FEC) 450 180 425-519 428-630 446-1664
10 1024 QAM (Light FEC) 450 191 451-551 454-668 474-1767
11 2048 QAM 500 211 498-609 502-739 524-1953
12 4096 QAM 500 218 515-629 519-763 541-2000
Page 360 of 468

9.3.1.12 80 MHz – Script ID 4501

Duplication
0 BPSK 50 24 55-67 55-81 57-208

1 QPSK 100 48 111-136 112-165 117-424
2 8 QAM 150 69 159-195 161-235 167-606
3 16 QAM 225 98 228-279 230-338 240-869
4 32 QAM 300 128 301-367 303-444 316-1026
5 64 QAM 400 157 369-451 372-545 387-1026
6 128 QAM 450 186 436-533 439-644 458-1026
7 256 QAM 500 214 502-614 506-742 528-1026
8 512 QAM 500 235 552-675 557-816 580-1026
9 1024 QAM (Strong FEC) 650 255 601-735 606-888 631-1026
10 1024 QAM (Light FEC) 650 271 638-780 643-943 670-1026
11 2048 QAM 650 287 676-826 681-999 710-1026
Page 361 of 468

9.3.1.13 112 MHz – Script ID 4511

Duplication
0 BPSK 100 35 80-97 80-118 84-303

1 QPSK 150 70 163-200 165-242 172-622
2 8 QAM 250 104 244-299 246-361 256-929
3 16 QAM 350 142 333-407 336-492 350-1026
4 32 QAM 450 187 439-536 442-648 461-1026
5 64 QAM 500 229 539-659 543-797 566-1026
6 128 QAM 650 277 652-797 657-964 685-1026
7 256 QAM 1000 317 746-912 752-1037 784-1026
8 512 QAM 1000 344 810-990 817-1037 851-1026
9 1024 QAM (Strong FEC) 1000 373 879-1037 886-1037 923-1026
10 1024 QAM (Light FEC) 1000 396 933-1037 941-1037 980-1026
11 2048 QAM 1000 427 1002-1037 1002-1037 1002-1026
Page 362 of 468

9.3.1.14 112 MHz – Script ID 4911

Duplication
0 BPSK 50 22 65-79 65-96 68-254

1 QPSK 150 51 157-192 158-233 165-615
2 8 QAM 250 80 248-303 250-368 261-972
3 16 QAM 350 111 345-422 348-512 363-1353
4 32 QAM 450 147 457-559 461-678 481-1792
5 64 QAM 500 173 538-658 543-798 566-2000
6 128 QAM 650 206 642-785 647-952 675-2000
7 256 QAM 1000 235 734-897 740-1089 771-2000
8 512 QAM 1000 261 814-995 820-1207 855-2000
9 1024 QAM (Strong FEC) 1000 279 872-1066 879-1293 917-2000
10 1024 QAM (Light FEC) 1000 291 910-1113 917-1350 957-2000
11 2048 QAM 1000 328 1024-1252 1032-1518 1076-2000
Page 363 of 468

9.3.2 Radio Capacity Specifications – RIC-D with RFU-E
9.3.2.1 14 MHz – Script ID 4509

Duplication
0 BPSK 10 3 9-11 9-14 10-36

1 QPSK 50 8 19-24 20-29 20-76
2 8 QAM 50 12 29-36 30-44 31-115
9.3.2.2 28 MHz – Script ID 4504

Duplication
0 BPSK 50 8 20-26 20-29 21-70

1 QPSK 50 17 43-52 43-63 45-162
2 8 QAM 50 24 62-76 63-92 65-236
3 16 QAM 100 35 87-107 88-129 92-332
4 32 QAM 100 46 115-140 116-170 121-437
5 64 QAM 150 56 141-173 143-209 149-538
6 128 QAM 150 68 170-208 172-252 179-648
7 256 QAM 200 78 196-239 197-289 206-745
8 512 QAM 200 83 209-255 210-308 219-794
Page 364 of 468

9.3.2.3 62.5 MHz – Script ID 4701
Table 109: Radio Capacity for 62.5 MHz

Duplication
0 BPSK 50 19 42-51 42-62 44-160

1 QPSK 100 42 93-114 94-138 98-355
2 8 QAM 150 63 139-170 140-205 146-528
3 16 QAM 200 85 188-230 190-278 198-716
4 32 QAM 250 112 247-302 249-365 259-939
5 64 QAM 300 137 301-368 303-445 316-1145
6 128 QAM 350 165 362-442 365-535 380-1377
7 256 QAM 400 187 412-504 416-609 433-1569
8 512 QAM 450 206 453-554 457-670 476-1724
9 1024 QAM 500 230 505-617 508-746 530-1920
9.3.2.4 125 MHz – Script ID 4700

Duplication
0 BPSK 100 41 90-110 90-132 94-341

1 QPSK 200 85 188-230 189-278 197-715
2 8 QAM 300 127 279-341 281-412 293-1062
3 16 QAM 400 172 379-463 382-560 398-1443
4 32 QAM 500 227 499-610 502-737 524-1898
5 64 QAM 650 278 612-748 617-904 643-2329
6 128 QAM 1000 335 737-900 742-1089 774-2500
7 256 QAM 1000 381 838-1025 845-1239 880-2500
8 512 QAM 1000 420 923-1128 930-1364 969-2500
Page 365 of 468

9.3.2.5 250 MHz – Script ID 4702

Duplication
0 BPSK 200 82 180-221 182-267 189-687

1 QPSK 400 171 377-461 380-557 396-1435
2 8 QAM 500 254 559-683 563-826 587-2128
3 16 QAM 1000 345 759-928 765-1122 797-2500
4 32 QAM 1000 454 998-1220 1006-1475 1048-2500
5 64 QAM 1600 512 1225-1497 1234-1810 1286-2500
6 128 QAM 1600 512 1474-1802 1486-2179 1548-2500
7 256 QAM 1600 512 1653-2021 1666-2443 1736-2500
9.3.2.6 500 MHz

Duplication
0 BPSK 350 165 362-442 NA NA

1 QPSK 1000 343 755-923 NA NA
2 8 QAM 1600 509 1119-1368 NA NA
3 16 QAM 1600 512 1520-1858 NA NA
4 32 QAM 2000 512 1998-2442 NA NA
5 64 QAM 2500 512 2451-2500 NA NA
Page 366 of 468

9.3.3 Radio Capacity Specifications – RMC-B
9.3.3.1 3.5 MHz – Script ID 1023
Table 113: Radio Capacity for 3.5 MHz – Script ID 1023

Duplication
0 QPSK 10 2 3-4 3-5 4-13

1 16 QAM 10 4 8-10 8-12 9-32
2 32 QAM 10 5 11-14 11-17 12-43
3 64 QAM 50 6 14-17 14-21 15-54
4 128 QAM 50 7 17-21 17-25 18-65
5 256 QAM 50 8 19-24 20-29 20-74
9.3.3.2 7 MHz – Script ID 1008
Table 114: Radio Capacity for 7 MHz – Script ID 1008

required supported
capacity E1s No Header De- L2 Header De- LTE-Optimized
activation Duplication Duplication Header De-
key Duplication
0 QPSK 10 3 8-10 9-13 9-32

1 8 PSK 10 5 13-16 13-19 13-48
2 16 QAM 50 8 18-22 18-27 19-69
3 32 QAM 50 10 24-30 24-36 26-92
4 64 QAM 50 12 30-37 30-44 32-114
5 128 QAM 50 15 36-44 36-53 38-137
6 256 QAM 50 17 42-51 42-61 44-158
7 512 QAM 50 18 45-54 45-66 47-169
8 1024 QAM (Strong FEC) 50 19 48-58 48-71 50-182
9 1024 QAM (Light FEC) 50 21 51-62 51-75 53-194
Page 367 of 468

9.3.3.3 14 MHz – Script ID 1009

required supported
key Duplication
0 QPSK 50 8 19-24 20-29 20-74

1 8 PSK 50 12 29-36 30-43 31-112
2 16 QAM 50 16 40-49 41-60 42-153
3 32 QAM 50 22 53-65 54-79 56-203
4 64 QAM 50 26 66-80 66-97 69-249
5 128 QAM 100 32 79-97 80-117 83-301
6 256 QAM 100 36 90-110 91-134 95-344
7 512 QAM 100 40 100-122 101-147 105-380
8 1024 QAM (Strong FEC) 100 42 106-129 106-156 111-402
9 1024 QAM (Light FEC) 100 45 112-137 113-166 118-426
Page 368 of 468

9.3.3.4 28 MHz – Script ID 1004

required supported
key Duplication
0 QPSK 50 16 40-49 41-59 42-153

1 8 PSK 50 24 60-74 61-89 63-229
2 16 QAM 100 33 82-101 83-122 86-313
3 32 QAM 100 44 108-132 109-160 114-412
4 64 QAM 150 54 134-163 135-197 140-508
5 128 QAM 150 65 161-196 162-237 169-612
6 256 QAM 200 74 183-224 184-270 192-696
7 512 QAM 200 81 202-247 203-298 212-769
8 1024 QAM (Strong FEC) 225 86 215-262 216-317 225-817
9 1024 QAM (Light FEC) 225 82 228-279 230-337 239-868
10 2048 QAM 250 98 245-299 246-361 257-931
Page 369 of 468

9.3.3.5 28 MHz – Script ID 1005

required supported
key Duplication
0 QPSK 50 17 43-52 43-63 45-162

1 8 PSK 50 24 62-76 63-92 65-236
2 16 QAM 100 35 87-107 88-129 92-332
3 32 QAM 100 46 115-140 116-170 121-437
4 64 QAM 150 56 141-173 143-209 149-538
5 128 QAM 150 68 170-208 172-252 179-648
6 256 QAM 200 78 196-239 197-289 206-745
7 512 QAM 200 83 209-255 210-308 219-794
8 1024 QAM (Strong FEC) 225 90 228-278 229-336 239-866
9 1024 QAM (Light FEC) 225 96 241-295 243-356 253-917
10 2048 QAM 250 105 263-321 265-389 276-1000
Page 370 of 468

9.3.3.6 40 MHz – Script ID 1007

required supported
key Duplication
0 QPSK 50 24 58-71 58-85 61-220

1 8 PSK 100 35 86-105 87-127 90-328
2 16 QAM 100 47 117-143 118-173 123-446
3 32 QAM 150 62 154-189 156-228 162-588
4 64 QAM 200 76 190-232 191-280 199-722
5 128 QAM 225 92 229-280 231-339 241-873
6 256 QAM 250 99 247-302 249-365 259-939
7 512 QAM 300 108 270-330 272-399 284-1000
8 1024 QAM (Strong FEC) 300 123 306-375 309-453 322-1000
9 1024 QAM (Light FEC) 300 130 325-398 328-481 342-1000
10 2048 QAM 350 141 352-430 355-520 370-1000
Page 371 of 468

9.3.3.7 56 MHz – Script ID 1003

required supported
key Duplication
0 QPSK 100 33 83-101 83-122 87-314

1 8 PSK 100 49 123-150 124-182 129-468
2 16 QAM 150 67 167-205 169-247 176-637
3 32 QAM 225 88 220-269 222-325 231-838
4 64 QAM 300 107 270-331 273-400 284-1000
5 128 QAM 300 130 327-400 329-483 343-1000
6 256 QAM 400 148 374-457 377-553 393-1000
7 512 QAM 400 161 406-496 409-600 426-1000
8 1024 QAM (Strong FEC) 450 175 441-540 445-652 464-1000
9 1024 QAM (Light FEC) 450 185 469-573 472-693 492-1000
10 2048 QAM 500 201 508-621 512-751 534-1000
Page 372 of 468

9.3.3.8 56 MHz – Script ID 1006

required supported
key Duplication
0 QPSK 100 35 87-106 88-128 91-331

1 8 PSK 150 51 127-155 128-187 133-482
2 16 QAM 200 71 176-215 177-260 185-670
3 32 QAM 225 93 232-283 233-342 243-881
4 64 QAM 300 114 284-348 286-420 299-1000
5 128 QAM 350 138 344-420 346-508 361-1000
6 256 QAM 400 159 397-485 400-586 416-1000
7 512 QAM 450 171 427-521 430-630 448-1000
8 1024 QAM (Strong FEC) 450 186 464-567 467-685 487-1000
9 1024 QAM (Light FEC) 500 198 493-602 497-728 517-1000
10 2048 QAM 500 214 534-653 538-789 561-1000
Page 373 of 468

9.3.4 Radio Capacity Specifications – RMC-B with XPIC
9.3.4.1 14 MHz – Script ID 1209

required supported
activation key Duplication Duplication Header De-
Duplication
0 QPSK 50 8 18-23 19-27 19-70

1 8 PSK 50 12 28-34 28-41 29-106
2 16 QAM 50 16 38-47 39-57 40-146
3 32 QAM 50 21 51-62 51-75 53-193
4 64 QAM 50 26 62-76 63-92 66-238
5 128 QAM 100 31 76-92 76-112 79-287
6 256 QAM 100 35 87-106 87-128 91-330
7 512 QAM 100 40 98-120 99-145 103-374
8 1024 QAM (Strong FEC) 100 43 106-130 107-157 112-405
9 1024 QAM (Light FEC) 100 46 114-139 114-168 119-432
Page 374 of 468

9.3.4.2 28 MHz – Script ID 1204

required supported
Duplication
0 QPSK 50 16 39-48 40-58 41-149

1 8 PSK 50 24 59-72 59-87 62-223
2 16 QAM 100 32 80-98 81-119 84-305
3 32 QAM 100 43 106-129 106-156 111-402
4 64 QAM 150 52 130-159 131-192 137-495
5 128 QAM 150 63 157-192 158-232 165-598
6 256 QAM 200 72 180-220 181-266 189-684
7 512 QAM 200 80 200-244 201-295 210-761
8 1024 QAM (Strong FEC) 225 85 212-260 214-314 223-809
9 1024 QAM (Light FEC) 225 91 226-276 227-333 237-858
Page 375 of 468

9.3.4.3 28 MHz – Script ID 1214

required supported
Duplication
0 QPSK 50 16 38-46 38-56 40-145

1 8 PSK 50 23 57-69 57-84 60-216
2 16 QAM 100 32 78-95 78-115 82-296
3 32 QAM 100 42 102-125 103-151 107-389
4 64 QAM 150 51 126-154 127-186 132-479
5 128 QAM 150 62 152-186 153-225 160-579
6 256 QAM 150 70 174-213 175-257 183-663
7 512 QAM 200 78 194-237 195-286 203-737
8 1024 QAM (Strong FEC) 200 83 206-251 207-304 216-783
9 1024 QAM (Light FEC) 225 88 218-267 220-323 229-831
Note: MRMC script 1214 provides smaller bandwidth than MRMC

script 1204. Script 1214 can be used for interoperability with
existing equipment in the field. It is an Adjacent Channel script,
for use with RFU-HP and 1500HP only.
Page 376 of 468

9.3.4.4 28 MHz – Script ID 1205

required supported
Duplication
0 QPSK 50 17 42-51 42-62 44-159

1 8 PSK 50 25 62-76 63-92 65-237
2 16 QAM 100 34 85-104 86-126 89-324
3 32 QAM 100 45 112-137 113-166 118-426
4 64 QAM 150 56 138-168 139-204 145-524
5 128 QAM 150 67 167-204 168-246 175-634
6 256 QAM 200 77 191-233 192-282 200-725
7 512 QAM 225 85 212-259 213-313 222-806
8 1024 QAM (Strong FEC) 225 90 225-275 227-333 236-856
9 1024 QAM (Light FEC) 225 96 239-292 241-353 251-909
Page 377 of 468

9.3.4.5 40 MHz – Script ID 1207

required supported
Duplication
0 QPSK 50 23 56-69 56-83 59-213

1 8 PSK 100 34 84-102 84-124 88-318
2 16 QAM 100 46 114-139 115-168 120-434
3 32 QAM 150 61 150-183 151-222 158-571
4 64 QAM 200 75 184-225 186-272 194-702
5 128 QAM 225 90 223-273 225-330 234-849
6 256 QAM 225 97 240-293 242-355 252-914
7 512 QAM 300 112 277-338 279-409 291-1000
8 1024 QAM (Strong FEC) 300 122 301-368 303-445 316-1000
9 1024 QAM (Light FEC) 300 129 320-391 322-473 336-1000
Page 378 of 468

9.3.4.6 40 MHz – Script ID 1217

required supported
Duplication
0 QPSK 50 20 50-62 51-75 53-192

1 8 PSK 100 30 75-92 76-111 79-287
2 16 QAM 100 42 103-126 104-152 108-391
3 32 QAM 150 54 135-166 136-200 142-515
4 64 QAM 150 65 166-203 168-246 175-633
5 128 QAM 200 81 201-246 203-297 211-766
6 256 QAM 225 87 217-265 218-320 228-824
7 512 QAM 250 100 250-305 252-369 262-950
8 1024 QAM (Strong FEC) 300 109 272-332 274-402 286-1000
9 1024 QAM (Light FEC) 300 116 288-353 291-426 303-1000
Note: MRMC script 1217 provides smaller bandwidth than MRMC

script 1207. Script 1217 can be used for interoperability with
existing equipment in the field. It is an Adjacent Channel script,
for use with RFU-HP and 1500HP only.
Page 379 of 468

9.3.4.7 56 MHz – Script ID 1203

required supported
Duplication
0 QPSK 100 33 81-99 82-120 85-308

1 8 PSK 100 48 120-147 121-178 126-458
2 16 QAM 150 66 164-200 165-242 172-624
3 32 QAM 225 87 216-264 217-319 227-821
4 64 QAM 250 106 265-324 267-391 278-1000
5 128 QAM 300 128 320-391 323-473 336-1000
6 256 QAM 400 147 366-448 369-541 385-1000
7 512 QAM 400 160 398-486 401-588 418-1000
8 1024 QAM (Strong FEC) 450 173 432-529 436-639 454-1000
9 1024 QAM (Light FEC) 450 184 459-561 463-678 482-1000
9.3.4.8 56 MHz – Script ID 1206

required supported
Duplication
0 QPSK 100 34 85-104 86-126 89-324

1 8 PSK 150 51 127-155 128-187 133-482
2 16 QAM 150 69 172-211 174-255 181-656
3 32 QAM 225 91 227-277 229-335 238-863
4 64 QAM 300 112 278-340 281-411 292-1000
5 128 QAM 350 135 337-412 339-498 354-1000
6 256 QAM 400 154 385-471 388-569 404-1000
7 512 QAM 400 168 418-511 421-618 439-1000
8 1024 QAM (Strong FEC) 450 182 455-556 458-672 477-1000
9 1024 QAM (Light FEC) 500 194 483-590 486-713 507-1000
Page 380 of 468

9.3.5 Radio Capacity Specifications – RMC-A
9.3.5.1 7 MHz – Script ID 33
Profile Modulation Minimum required Max # of Ethernet Throughput

capacity activation supported E1s [Mbps]
key
0 QPSK 10 4 9-12
1 8 PSK 50 6 14-18
2 16 QAM 50 8 19-24
3 32 QAM 50 10 24-30
4 64 QAM 50 12 28-35
5 128 QAM 50 13 32-41
6 256QAM (Strong FEC) 50 16 38-48
7 256 QAM (Light FEC) 50 17 40-50
9.3.5.2 14 MHz – Script ID 23

key
0 QPSK 50 8 20-25
1 8 PSK 50 12 28-36
2 16 QAM 50 18 42-53
3 32 QAM 50 20 49-62
4 64 QAM 50 24 57-72
5 128 QAM 100 29 68-86
6 256QAM (Strong FEC) 100 34 80-101
7 256 QAM (Light FEC) 100 37 87-109
Page 381 of 468

9.3.5.3 28 MHz – Script ID 22

key
0 QPSK 50 17 40-51
1 8 PSK 50 23 54-68
2 16 QAM 100 33 77-97
3 32 QAM 100 44 105-132
4 64 QAM 150 55 130-164
5 128 QAM 150 68 159-200
6 256QAM (Strong FEC) 200 76 177-223
7 256 QAM (Light FEC) 200 80 187-235
9.3.5.4 40 MHz – Script ID 16

key
0 QPSK 50 23 55-70
1 8 PSK 100 35 83-104
2 16 QAM 100 51 121-152
3 32 QAM 150 65 152-191
4 64 QAM 200 81 190-239
5 128 QAM 225 84 213-267
6 256QAM (Strong FEC) 250 84 241-303
7 256 QAM (Light FEC) 250 84 257-324
Page 382 of 468

9.3.5.5 56 MHz – Script ID 13

key
0 QPSK 100 32 76-95

1 8 PSK 150 48 114-143
2 16 QAM 150 64 151-190
3 32 QAM 200 84 201-252
4 64 QAM 250 84 249-314
5 128 QAM 300 84 299-377
6 256QAM (Strong FEC) 350 84 341-429
7 256 QAM (Light FEC) 400 84 370-465
Page 383 of 468

9.4 Transmit Power Specifications (dBm)
9.4.1 Transmit Power with RFU-D

Notes: The values listed in this section are typical. Actual values may
differ in either direction by up to 1 dB.
Transmit Power for RFU-D is measured at the Antenna Port of

the RFU (Port C’).
Table 134: Transmit power specifications for RFU-D (dBm)
Modulation 6 GHz 7 GHz 8 GHz 11 GHz 13 GHz 15 GHz 18 GHz 23 GHz 26 GHz 28- 32 GHz 38 GHz 42 GHz
BPSK 28 28 28 28 24 24 22 20 23 18 19 15
QPSK 28 28 28 28 24 24 22 20 23 18 19 15
8 PSK 28 28 28 28 24 24 22 20 23 18 18 15
16 QAM 28 27 27 28 23 24 22 20 23 17 18 15
32 QAM 28 27 26 28 23 24 22 20 23 16 17 14
64 QAM 28 26 26 27 23 24 22 20 23 16 17 13
128 QAM 27 26 26 26 22 24 22 20 23 16 17 13
256 QAM 27 26 26 26 21 22 20 20 21 14 16 13
512 QAM 27 25 24 26 21 22 20 20 21 14 14 11
1024 QAM 25 24 24 25 20 20 20 18 20 13 13 11
2048 QAM 25 23 22 24 20 20 18 17 18 12 12 10
4096 QAM 23 21 20 22 18 18 16
9.4.1.1 Pmin Power with RFU-D
Table 135: Pmin Power for RFU-D
Frequency Band Pmin Frequency Band Pmin
6-15 GHz 2 26-42 GHz -1

18-23 GHz -1
Page 384 of 468

9.4.2 Transmit Power with RFU-D-HP

differ by +2/-1 dB.
The Tx Power of the RFU-D-HP is measured at the transmitter

port (Port A’) of the RFU-D-HP. To determine the Transmit Power
at the antenna port of the radio and branching system (Port C’),
diplexer losses, branching losses, and mediation devices losses
must also be considered. See Diplexer Unit Typical Losses with
RFU-D-HP on page 385, RFU-D/RFU-D-HP Mediation Device
Losses on page 436, and RFU-D-HP Branching Losses on
page 438.
Table 136: Transmit power specifications for RFU-D-HP (dBm)
Modulation 4 GHz 5 GHz 6 GHz 7 GHz 8 GHz 11 GHz
BPSK 35 35 38 38 37 36
QPSK 35 35 37 37 37 36
8 PSK 35 35 37 37 37 36
16 QAM 35 35 37 37 37 35
32 QAM 35 35 37 37 37 35
64 QAM 35 34 36 36 35 34
128 QAM 32 34 36 35 35 33
256 QAM 32 33 35 34 33 32
512 QAM 31 33 34 33 33 32
1024 QAM 30 32 33 32 32 31
2048 QAM 30 31 33 31 31 31
4096 QAM 30 30 31 29 29 29
The Pmin for RFU-D-HP is 14 dBm.
9.4.2.1 Diplexer Unit Typical Losses with RFU-D-HP
Table 137: Diplexer Unit Typical Losses with RFU-D-HP
Frequency 4-5 GHz 6-8 GHz 10 GHz 11 GHz
Losses 2 dB 1.3 dB 1.0 dB 0.7 dB
Page 385 of 468

9.4.3 Transmit Power with RFU-S

Transmit Power for RFU-S is measured at the Antenna Port of the

RFU (Port C’).
Table 138: Transmit power specifications for RFU-S (dBm)
Modulation 6 GHz 7 GHz 8 GHz 11 GHz 13 GHz 15 GHz 18 GHz 23 GHz 26 GHz 28- 38 GHz 42 GHz
BPSK 28 27 27 28 27 24 23 24 23 18 15
QPSK 28 27 27 28 27 24 23 24 23 18 15
8 PSK 28 27 27 28 27 24 23 24 23 18 15
16 QAM 28 27 27 28 27 24 23 24 23 17 15
32 QAM 27 27 26 28 26 24 23 24 23 16 14
64 QAM 27 26 26 27 24 23 23 23 23 16 13
128 QAM 27 26 26 27 24 23 22 23 23 16 13
256 QAM 27 26 26 27 24 22 22 22 21 14 13
512 QAM 25 25 25 27 24 22 22 22 21 14 11
1024 QAM 25 24 24 25 22 20 19 21 20 13 11
2048 QAM 23 23 24 24 21 20 17 20 18 12 10
4096 QAM 21 21 22 22 19 18 15
9.4.3.1 Pmin Power with RFU-S
Table 139: Pmin Power for RFU-S
6-15 GHz 2 26-42 GHz -1

18-23 GHz -1
Page 386 of 468

9.4.4 Transmit Power with RFU-E

Note: The values listed in this section are typical. Actual values may
Table 140: Transmit power specifications for RFU-E (dBm)
Modulation 14 MHz 28 MHz 62.5 MHz 125 MHz 250 MHz 500 MHz
BPSK 18 18 18 18 18 15
QPSK 18 18 18 18 18 15
8 PSK 18 18 18 18 16 11
16 QAM – 17 17 17 15 10
32 QAM – 17 17 17 15 10
64 QAM – 16 16 16 14 9
128 QAM – 16 16 16 14 –
256 QAM – 15 15 15 13 –
512 QAM – 14 14 14 – –
1024 QAM – – 13 – – –
The Pmin for RFU-E is -2 dBm.
Page 387 of 468

9.4.5 Transmit Power with RFU-C (dBm)

Modulations of 512 QAM and higher require RMC-B.
Table 141: Transmit Power with RFU-C (dBm)
Modulation 6L-8 GHz 10-15 GHz 18-23 GHz 24GHz UL54 26 GHz 28 GHz 31 GHz 32 GHz 36 GHz 38 GHz 42 GHz
QPSK 26 24 22 0 21 14 16 18 12 18 15
8 PSK 26 24 22 0 21 14 16 18 12 18 15
16 QAM 25 23 21 0 20 14 15 17 11 17 14
32 QAM 24 22 20 0 19 14 14 16 10 16 13
64 QAM 24 22 20 0 19 14 14 16 10 16 13
128 QAM 24 22 20 0 19 14 14 16 10 16 13
256 QAM 22 20 18 0 17 12 12 14 8 14 11
512 QAM 22 20 18 -1 17 9 12 14 10 14 11
1024 QAM 21 19 17 -3 16 8 11 13 9 13 10
2048 QAM 19 17 15 0 14 6 9 11 7 11 8
9.4.5.1 Pmin Power with RFU-C

Table 142: Pmin Power with RFU-C
6 4 24 ETSI -39
7 4 26 -1
8 4 28 -2
10 2 31 5
11 2 32 -5
13 0 36 5
15 -7 38 0
18 -7 42 0
23 -7
54
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.
Page 388 of 468

9.4.6 Transmit Power with 1500HP/RFU-HP (dBm)

Transmit Power values shown in the tables below are measured

at the Antenna Port of the OCB (Port C’-C) in a 1+0 configuration.
The Transmit Power levels at the Tx Port of the RFU (Port A’) is
1.5 dB higher. For Transmit Power levels as measured at the Tx
Port of the RFU, see Annex 1: RFU-HP Transmit Power and RSL at
Radio Ports on page 463.
Modulations of 512 QAM and higher require RMC-B.

The following table provides transmit power specifications for RFU-HP 1RX (dBm).
Table 143: Transmit power specifications for RFU-HP 1RX (dBm)
Modulation 6L&H GHz 7 GHz 8 GHz 11 GHz55
QPSK 33 33 33 30
8 PSK 33 33 33 30
16 QAM 33 33 33 30
32 QAM 33 33 33 29
64 QAM 32 32 32 29
128 QAM 31 31 31 29
256 QAM 30 30 30 27
512 QAM 28 28 28 25
1024 QAM 27 27 27 24
2048 QAM 25 25 25 22
55
1500HP only.
Page 389 of 468

The following table provides transmit power specifications for RFU-HP 2RX
(1500HP) (dBm).
Table 144: Transmit power specifications for RFU-HP 2RX (1500HP) (dBm)
Modulation 6L&H GHz 7 GHz 8 GHz 11 GHz
QPSK 33 33 33 30
8 PSK 33 33 33 30
16 QAM 33 33 33 30
32 QAM 33 33 33 29
64 QAM 32 32 32 29
128 QAM 32 32 32 29
256 QAM 30 30 30 27
512 QAM 28 28 28 25
1024 QAM 27 27 27 24
2048 QAM 25 25 25 22
• 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.
• When using Adjacent Channels (ACCP) configuration with 28/30 or 40 MHz
channel filters, the Transmit Power is 1 dB lower than the values shown in the
tables above. This limitation is not applicable to other channels.
Page 390 of 468

9.5 Receiver Threshold Specifications

differ in either direction by up to 1dB.
9.5.1 Receiver Thresholds with RFU-D and RFU-S

Note: RSL values for RFU-D and RFU-S are measured at the Antenna
Port of the RFU (Port C’).
Table 145: Receiver Thresholds with RFU-D and RFU-S (6-18 GHz)
Profile Modulation Channel Spacing 6 7-8 10 11 13 15 18
0 BPSK 14 MHz -91.5 -91.0 -90.5 -91.5 -90.5 -89.5 -91
1 QPSK -90.5 -90.0 -89.5 -90.5 -89.5 -88.5 -90
2 8 PSK -84.5 -84.0 -83.5 -85.5 -83.5 -82.5 -84
3 16 QAM -83.5 -83.0 -82.5 -83.5 -82.5 -81.5 -83
4 32 QAM -80.5 -79.5 -79.5 -80.5 -79.0 -78.5 -79.5
5 64 QAM -77.5 -76.5 -76.5 -77.0 -76.0 -75.5 -76.5
6 128 QAM -74.0 -73.5 -73.0 -74.0 -73.0 -72.0 -73.5
7 256 QAM -71.5 -70.5 -70.5 -71.0 -70.0 -69.5 -70.5
8 512 QAM -68.5 -68.0 -67.5 -68.5 -67.5 -66.5 -68.0
9 1024 QAM (Strong FEC) -65.5 -65.0 -64.5 -65.5 -64.5 -63.5 -65.0
10 1024 QAM (Light FEC) -65.0 -64.0 -64.0 -64.5 -63.5 -63.0 -64.0
0 BPSK 28 MHz -88.5 -88.0 -87.5 -88.5 -87.5 -86.5 -88.0
1 QPSK -87.5 -87.0 -86.5 -87.5 -86.5 -85.5 -87.0
2 8 PSK -83.0 -82.5 -82.0 -83.0 -82.0 -81.0 -82.5
3 16 QAM -81.0 -80.5 -80.0 -81.0 -79.5 -79.0 -80.5
4 32 QAM -77.5 -77.0 -76.5 -77.5 -76.0 -75.5 -77.0
5 64 QAM -74.5 -74.0 -73.5 -74.5 -73.0 -72.5 -74.0
6 128 QAM -71.5 -70.5 -70.5 -71.0 -70.0 -69.5 -70.5
7 256 QAM -68.5 -67.5 -67.5 -68.0 -67.0 -66.5 -67.5
8 512 QAM -66.0 -65.0 -65.0 -66.0 -64.5 -64.0 -65.0
9 1024 QAM (Strong FEC) -63.0 -62.5 -62.0 -63.0 -61.5 -61.0 -62.5
10 1024 QAM (Light FEC) -62.0 -61.5 -61.0 -62.0 -60.5 -60.0 -61.5
11 2048 QAM -58.5 -58.0 -57.5 -58.5 -57.0 -56.5 -58.0
12 4096 QAM -55.5 -55.0 -54.5 -55.5 -54.0 -53.5 -55.0
Page 391 of 468

0 BPSK 40 MHz -87.0 -86.5 -86.0 -87.0 -86.0 -85.0 -86.5
1 QPSK -86.0 -85.5 -85.0 -86.0 -85.0 -84.0 -85.5
2 8 PSK -81.0 -80.5 -80.0 -81.0 -79.5 -79.0 -80.5
3 16 QAM -79.5 -79.0 -78.5 -79.5 -78.0 -77.5 -79.0
4 32 QAM -76.0 -75.0 -75.0 -75.5 -74.5 -74.0 -75.0
5 64 QAM -73.0 -72.0 -72.0 -73.0 -71.5 -71.0 -72.0
6 128 QAM -70.0 -69.0 -69.0 -70.0 -68.5 -68.0 -69.0
7 256 QAM -67.0 -66.0 -66.0 -66.5 -65.5 -65.0 -66.0
8 512 QAM -64.0 -63.5 -63.0 -64.0 -62.5 -62.0 -63.5
9 1024 QAM (Strong FEC) -61.5 -61.0 -60.5 -61.5 -60.0 -59.5 -61.0
10 1024 QAM (Light FEC) -60.5 -60.0 -59.5 -60.5 -59.5 -58.5 -60.0
11 2048 QAM -58.0 -57.0 -57.0 -58.0 -56.5 -56.0 -57.0
12 4096 QAM -55.0 -54.0 -54.0 -55.0 -53.5 -53.0 -54.0
0 BPSK 56 MHz -85.5 -85.0 -84.5 -85.5 -84.0 -83.5 -85.0
1 QPSK -84.5 -84.0 -83.5 -84.5 -83.0 -82.5 -84.0
2 8 PSK -80.0 -79.0 -79.0 -79.5 -78.5 -78.0 -79.0
3 16 QAM -77.5 -77.0 -76.5 -77.5 -76.0 -75.5 -77.0
4 32 QAM -74.0 -73.0 -73.0 -73.5 -72.5 -72.0 -73.0
5 64 QAM -70.5 -70.0 -69.5 -70.5 -69.5 -68.5 -70.0
6 128 QAM -68.0 -67.0 -67.0 -67.5 -66.5 -66.0 -67.0
7 256 QAM -64.5 -64.0 -63.5 -64.5 -63.5 -62.5 -64.0
8 512 QAM -62.5 -62.0 -61.5 -62.5 -61.5 -60.5 -62.0
9 1024 QAM (Strong FEC) -59.0 -58.5 -58.0 -59.0 -58.0 -57.0 -58.5
10 1024 QAM (Light FEC) -58.0 -57.5 -57.0 -58.0 -57.0 -56.0 -57.5
11 2048 QAM -55.5 -54.5 -54.5 -55.0 -54.0 -53.5 -54.5
12 4096 QAM -52.5 -51.5 -51.5 -52.0 -51.0 -50.5 –
Page 392 of 468

0 BPSK 80 MHz -85.0 -85.0 -84.5 -85.5 -84.5 -83.5 -85.0
1 QPSK -82.5 -82.5 -82.5 -83.0 -82.0 -81.5 -82.5
2 8 PSK -79.0 -79.0 -78.5 -79.5 -78.5 -77.5 -79.0
3 16 QAM -76.0 -76.0 -75.5 -76.5 -75.0 -74.5 -76.0
4 32 QAM -72.5 -72.5 -72.0 -73.0 -71.5 -71.0 -72.5
5 64 QAM -69.0 -69.0 -69.0 -70.0 -68.5 -68.0 -69.0
6 128 QAM -66.5 -66.5 -66.0 -67.0 -66.0 -65.0 -66.5
7 256 QAM -63.5 -63.5 -63.0 -64.0 -63.0 -62.0 -63.5
8 512 QAM -61.0 -61.0 -61.0 -62.0 -60.5 -60.0 -61.0
9 1024 QAM (Strong FEC) -58.0 -58.0 -57.5 -58.5 -57.5 -56.5 -58.0
10 1024 QAM (Light FEC) -57.0 -57.0 -57.0 -58.0 -56.5 -56.0 -57.0
11 2048 QAM -54.5 -54.5 -54.5 -55.5 -54.0 -53.5 -54.5
0 BPSK 112 MHz -82.0 -81.5 -81.0 -82.0 -80.5 -80.0 -81.5
1 QPSK -81.0 -80.5 -80.0 -81.0 -79.5 -79.0 -80.5
2 8 PSK -76.5 -75.5 -75.5 -76.0 -75.0 -74.5 -75.5
3 16 QAM -74.0 -73.5 -73.0 -74.0 -72.5 -72.0 -73.5
4 32 QAM -70.5 -69.5 -69.5 -70.0 -69.0 -68.5 -69.5
5 64 QAM -67.0 -66.5 -66.0 -67.0 -66.0 -65.0 -66.5
6 128 QAM -64.5 -63.5 -63.5 -64.0 -63.0 -62.5 -63.5
7 256 QAM -61.0 -60.5 -60.0 -61.0 -60.0 -59.0 -60.5
8 512 QAM -59.0 -58.5 -58.0 -59.0 -58.0 -57.0 -58.5
9 1024 QAM (Strong FEC) -55.5 -55.0 -54.5 -55.5 -54.5 -53.5 -55.0
10 1024 QAM (Light FEC) -54.5 -54.0 -53.5 -54.5 -53.5 -52.5 -54.0
11 2048 QAM -52.0 -51.0 -51.0 -51.5 -50.5 -50.0 -51.0
Page 393 of 468

Table 146: Receiver Thresholds with RFU-D and RFU-S (23-42 GHz)
Profile Modulation Channel Spacing 23 2456 26 28-31 32 38 42
0 BPSK 14 MHz -90.0 -89.5 -89.5 -89.5 -89.0 -89.0 -88.5
1 QPSK -89.0 -88.5 -88.5 -88.5 -88.0 -88.0 -87.5
2 8 PSK -83.0 -82.5 -82.5 -82.5 -82.0 -82.0 -81.5
3 16 QAM -82.0 -81.5 -81.5 -81.5 -81.0 -81.0 -80.5
4 32 QAM -79.0 -78.5 -78.5 -78.0 -78.0 -77.5 -77.0
5 64 QAM -76.0 -75.5 -75.5 -75.0 -75.0 -74.5 -74.0
6 128 QAM -72.5 -72.0 -72.0 -72.0 -71.5 -71.5 -71.0
7 256 QAM -69.5 -69.0 -69.5 -69.0 -69.0 -68.5 -68.0
8 512 QAM -67.0 -66.5 -66.5 -66.5 -66.0 -66.0 -65.5
9 1024 QAM (Strong FEC) -64.0 -63.5 -63.5 -63.5 -63.0 -63.0 -62.5
10 1024 QAM (Light FEC) -63.5 -63.0 -63.0 -62.5 -62.5 -62.0 -61.5
0 BPSK 28 MHz -87.0 -86.5 -86.5 -86.5 -86.0 -86.0 -85.5
1 QPSK -86.0 -85.5 -85.5 -85.5 -85.0 -85.0 -84.5
2 8 PSK -81.5 -81.0 -81.0 -81.0 -80.5 -80.5 -80.0
3 16 QAM -79.5 -79.0 -79 -79.0 -78.5 -78.0 -78.0
4 32 QAM -76.0 -75.5 -75.5 -75.5 -75.0 -74.5 -74.5
5 64 QAM -73.0 -72.5 -72.5 -72.5 -72.0 -71.5 -71.5
6 128 QAM -69.5 -69.0 -69.5 -69.0 -69.0 -68.5 -68.0
7 256 QAM -66.5 -66.0 -66.5 -66.0 -66.0 -65.5 -65.0
8 512 QAM -64.5 -64.0 -64.0 -63.5 -63.5 -63.0 -62.5
9 1024 QAM (Strong FEC) -61.5 -61.0 -61.0 -61.0 -60.5 -60.0 -60.0
10 1024 QAM (Light FEC) -60.5 -60.0 -60.0 -60.0 -59.5 -59.0 -59.0
11 2048 QAM -57.0 -56.5 -56.5 -56.5 -56.0 -55.5 -55.5
56
Page 394 of 468

0 BPSK 40 MHz -85.5 -85.0 -85.0 -85.0 -84.5 -84.5 -84.0
1 QPSK -84.5 -84.0 -84.0 -84.0 -83.5 -83.5 -83.0
2 8 PSK -79.5 -79.0 -79.0 -79.0 -78.5 -78.0 -78.0
3 16 QAM -78.0 -77.5 -77.5 -77.5 -77.0 -76.5 -76.5
4 32 QAM -74.0 -73.5 -74.0 -73.5 -73.5 -73.0 -72.5
5 64 QAM -71.5 -71.0 -71.0 -70.5 -70.5 -70.0 -69.5
6 128 QAM -68.5 -68.0 -68.0 -67.5 -67.5 -67.0 -66.5
7 256 QAM -65.0 -64.5 -65.0 -64.5 -64.5 -64.0 -63.5
8 512 QAM -62.5 -62.0 -62.0 -62.0 -61.5 -61.0 -61.0
9 1024 QAM (Strong FEC) -60.0 -59.5 -59.5 -59.5 -59.0 -58.5 -58.5
10 1024 QAM (Light FEC) -59.0 -58.5 -58.5 -58.5 -58.0 -58.0 -57.5
11 2048 QAM -56.5 -56.0 -56.0 -55.5 -55.5 -55.0 -54.5
0 BPSK 56 MHz -84.0 -83.5 -83.5 -83.5 -83.0 -82.5 -82.5
1 QPSK -83.0 -82.5 -82.5 -82.5 -82.0 -81.5 -81.5
2 8 PSK -78.0 -77.5 -78.0 -77.5 -77.5 -77.0 -76.5
3 16 QAM -76.0 -75.5 -75.5 -75.5 -75.0 -74.5 -74.5
4 32 QAM -72.0 -71.5 -72.0 -71.5 -71.5 -71.0 -70.5
5 64 QAM -69.0 -68.5 -68.5 -68.5 -68.0 -68.0 -67.5
6 128 QAM -66.0 -65.5 -66.0 -65.5 -65.5 -65.0 -64.5
7 256 QAM -63.0 -62.5 -62.5 -62.5 -62.0 -62.0 -61.5
8 512 QAM -61.0 -60.5 -60.5 -60.5 -60.0 -60.0 -59.5
9 1024 QAM (Strong FEC) -57.5 -57.0 -57.0 -57.0 -56.5 -56.5 -56.0
10 1024 QAM (Light FEC) -56.5 -56.0 -56.0 -56.0 -55.5 -55.5 -55.0
11 2048 QAM -53.5 -53.0 -53.5 -53.0 -53.0 -52.5 -52.0
Page 395 of 468

0 BPSK 80 MHz -84.0 -83.5 -83.5 -83.5 -83.0 -83.5 -82.5
1 QPSK -81.5 -81.0 -81.5 -81.0 -81.0 -81.0 -80.0
2 8 PSK -78.0 -77.5 -77.5 -77.5 -77.0 -77.5 -76.5
3 16 QAM -75.0 -74.5 -74.5 -74.5 -74.0 -74.0 -73.5
4 32 QAM -71.5 -71.0 -71.0 -71.0 -70.5 -70.5 -70.0
5 64 QAM -68.5 -68.0 -68.0 -67.5 -67.5 -67.5 -66.5
6 128 QAM -65.5 -65.0 -65.0 -65.0 -64.5 -65.0 -64.0
7 256 QAM -62.5 -62.0 -62.0 -62.0 -61.5 -62.0 -61.0
8 512 QAM -60.5 -60.0 -60.0 -59.5 -59.5 -59.5 -58.5
9 1024 QAM (Strong FEC) -57.0 -56.5 -56.5 -56.5 -56.0 -56.5 -55.5
10 1024 QAM (Light FEC) -56.5 -56.0 -56.0 -55.5 -55.5 -55.5 -54.5
11 2048 QAM -54.0 -53.5 -53.5 -53.0 -53.0
0 BPSK 112 MHz -80.5 -80.0 -80.0 -80.0 -79.5 -79.0 -79.0
1 QPSK -79.5 -79.0 -79.0 -79.0 -78.5 -78.0 -78.0
2 8 PSK -74.5 -74.0 -74.5 -74.0 -74.0 -73.5 -73.0
3 16 QAM -72.5 -72.0 -72.0 -72.0 -71.5 -71.0 -71.0
4 32 QAM -68.5 -68.0 -68.5 -68.0 -68.0 -67.5 -67.0
5 64 QAM -65.5 -65.0 -65.0 -65.0 -64.5 -64.5 -64.0
6 128 QAM -62.5 -62.0 -62.5 -62.0 -62.0 -61.5 -61.0
7 256 QAM -59.5 -59.0 -59.0 -59.0 -58.5 -58.5 -58.0
8 512 QAM -57.5 -57.0 -57.0 -57.0 -56.5 -56.5 -56.0
9 1024 QAM (Strong FEC) -54.0 -53.5 -53.5 -53.5 -53.0 -53.0 -52.5
10 1024 QAM (Light FEC) -53.0 -52.5 -52.5 -52.5 -52.0 -52.0 -51.5
11 2048 QAM -50.0 -49.5 -5.00 -49.5 -49.5
Page 396 of 468

9.5.2 Receiver Thresholds with RFU-D-HP

Note: The RSL values shown in the tables below are at the radio port
(Port A’) of the RFU-D-HP. To determine the RSL at the antenna
port of the radio and branching system (Port C’), diplexer losses,
branching losses, and mediation devices losses must also be
considered. See Diplexer Unit Typical Losses with RFU-D-HP on
page 385, RFU-D/RFU-D-HP Mediation Device Losses on
page 436, and RFU-D-HP Branching Losses on page 438.
Table 147: Receiver Thresholds with RFU-D-HP
Channel Spacing 28 MHz 40 MHz 56 MHz

Profile Modulation Frequency (GHz) 4-6 7-11 4-6 7-11 4-6 7-11
0 BPSK -92.0 -91.5 -90.5 -90.0 -88.5 -88.0

1 QPSK -90.0 -89.5 -88.5 -88.0 -86.5 -86.0
2 8 QAM -85.5 -85.0 -83.5 -83.0 -82.5 -82.0
3 16 QAM -83.5 -83.0 -82.0 -81.5 -80.0 -79.5
4 32 QAM -80.0 -79.5 -78.5 -78.0 -77.0 -76.5
5 64 QAM -77.0 -76.5 -75.5 -75.0 -73.5 -73.0
6 128 QAM -74.0 -73.5 -72.5 -72.0 -71.0 -70.5
7 256 QAM -71.0 -70.5 -69.5 -69.0 -67.5 -67.0
8 512 QAM -68.5 -68.0 -66.5 -66.0 -65.5 -65.0
9 1024 QAM (Strong FEC) -65.5 -65.0 -64.0 -63.5 -62.0 -61.5
10 1024 QAM (Light FEC) -64.5 -64.0 -63.0 -62.5 -61.0 -60.5
11 2048 QAM -61.0 -60.5 -60.5 -60.0 -56.5 -56.0
12 4096 QAM -59.0 -58.5 -58.5 -58.0 -54.5 -54.0
Page 397 of 468

Channel Spacing 80 MHz 112 MHz

Profile Modulation Frequency (GHz) 4-5 6-11 4-6 7-11
0 BPSK -88.0 -86.0 -82.5 -82.0

1 QPSK -86.0 -84.0 -80.5 -80.0
2 8 QAM -82.0 -80.0 -76.5 -76.0
3 16 QAM -79.0 -77.0 -74.0 -73.5
4 32 QAM -75.5 -73.5 -71.0 -70.5
5 64 QAM -72.5 -70.5 -67.5 -67.0
6 128 QAM -69.5 -67.5 -65.0 -64.5
7 256 QAM -66.5 -64.5 -61.5 -61.0
8 512 QAM -64.5 -62.5 -59.5 -59.0
9 1024 QAM (Strong FEC) -61.0 -59.5 -56.0 -55.5
10 1024 QAM (Light FEC) -60.5 -58.5 -55.0 -54.5
11 2048 QAM -58.0 -56.0 -50.5 -50.0
Page 398 of 468

9.5.3 Receiver Thresholds with RFU-E

Table 148: Receiver Thresholds with RFU-E
Modulation Channel Spacing [MHz]
14 28 62.5 125 250 500
BPSK -90.5 -87.5 -83.0 -80.0 -77.0 -74.0

4 QAM -87.2 -84.6 -79.5 -76.5 -73.5 -70.5
8 QAM -83.1 -80.6 -75.5 -72.5 -70.0 -67.0
16 QAM – -77.4 -73.0 -69.5 -67.0 -64.0
32 QAM – -73.9 -69.0 -66.0 -63.0 -60.0
64 QAM – -70.8 -66.0 -63.0 -60.0 -57.0
128 QAM – -67.6 -63.0 -60.0 -57.0 –
256 QAM – -64.6 -59.5 -57.0 -54.0 –
512 QAM – -62.4 -57.0 -54.0 – –
1024 QAM – – -54.0 – – –
Page 399 of 468

9.5.4 Receiver Thresholds with RMC-B and RFU-C
Table 149: Receiver Thresholds with RMC-B and RFU-C
Profile Modulation Channel 6 7-10 11-15 18 23 2457 26 28 31-42

Spacing
0 QPSK -97.5 -97.0 -97.5 -96.5 -96.0 -93.0 -95.0 -93.0 -94.0
1 16 QAM -91.0 -90.5 -91.0 -90.0 -89.5 -86.5 -88.5 -86.5 -87.5
2 32 QAM -88.0 -87.5 -88.0 -87.0 -86.5 -83.5 -85.5 -83.5 -84.5
3.5 MHz
3 64 QAM -84.5 -84.0 -84.5 -83.5 -83.0 -80.0 -82.0 -80.0 -81.0
4 128 QAM -81.0 -80.5 -81.0 -80.0 -79.5 -76.5 -78.5 -76.5 -77.5
5 256 QAM -77.5 -77.0 -77.5 -76.5 -76.0 -73.0 -75.0 -73.0 -74.0
0 QPSK -95 -94.5 -95 -94 -93.5 -90.5 -92.5 -90.5 -91.5
1 8 PSK -89 -88.5 -89 -88 -87.5 -84.5 -86.5 -84.5 -85.5
2 16 QAM -88.5 -88 -88.5 -87.5 -87 -84 -86.0 -84.0 -85.0
3 32 QAM -85 -84.5 -85 -84 -83.5 -80.5 -82.5 -80.5 -81.5
4 64 QAM -82 -81.5 -82 -81 -80.5 -77.5 -79.5 -77.5 -78.5
7 MHz
5 128 QAM -79 -78.5 -79 -78 -77.5 -74.5 -76.5 -74.5 -75.5
6 256 QAM -75.5 -75 -75.5 -74.5 -74 -71 -73.0 -71.0 -72.0
7 512 QAM -73.5 -73 -73.5 -72.5 -72 -69 -71.0 -69.0 -70.0
8 1024 QAM (Strong FEC) -70 -69.5 -70 -69 -68.5 -65.5 -67.5 -65.5 -66.5
9 1024 QAM (Light FEC) -69.5 -69 -69.5 -68.5 -68 -65 -67.0 -65.0 -66.0
0 QPSK -92.0 -91.5 -92.0 -91.0 -90.5 -87.5 -89.5 -87.5 -88.5
1 8 PSK -86.0 -85.5 -86.0 -85.0 -84.5 -81.5 -83.5 -81.5 -82.5
2 16 QAM -85.0 -84.5 -85.0 -84.0 -83.5 -80.5 -82.5 -80.5 -81.5
3 32 QAM -82.0 -81.5 -82.0 -81.0 -80.5 -77.5 -79.5 -77.5 -78.5
4 64 QAM -79.0 -78.5 -79.0 -78.0 -77.5 -74.5 -76.5 -74.5 -75.5
14 MHz
5 128 QAM -75.5 -75.0 -75.5 -74.5 -74.0 -71.0 -73.0 -71.0 -72.0
6 256 QAM -73.0 -72.5 -73.0 -72.0 -71.5 -68.5 -70.5 -68.5 -69.5
7 512 QAM -70.0 -69.5 -70.0 -69.0 -68.5 -65.5 -67.5 -65.5 -66.5
8 1024 QAM (Strong FEC) -67.0 -66.5 -67.0 -66.0 -65.5 -62.5 -64.5 -62.5 -63.5
9 1024 QAM (Light FEC) -66.5 -66.0 -66.5 -65.5 -65.0 -62.0 -64.0 -62.0 -63.0
57
Page 400 of 468


Spacing
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.0 -59.0 -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 -82.5 -82.0 -82.5 -81.5 -81.0 -75.5 -80.0 -78.0 -79.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
5 128 QAM 40 MHz -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.5 -63.0 -63.5 -62.5 -62.0 -56.5 -61.0 -59.0 -60.0
9 1024 QAM (light FEC) -62.5 -62.0 -62.5 -61.5 -61.0 -55.5 -60.0 -58.0 -59.0
10 2048 QAM -59.0 -58.5 -59.0 -58.0 -57.5 -52.0 -56.5 -54.5 -55.5
58
Page 401 of 468


Spacing
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.0 -59.5 -60.0 -59.0 -58.5 -55.5 -57.5 -55.5 -56.5
10 2048 QAM -55.5 -55.0 -55.5 -54.5 -54.0 -51.0 -53.0 -51.0 -52.0
59
Page 402 of 468

9.5.5 Receiver Thresholds with RFU-HP

RSL values shown in the tables below are measured at the Antenna Port of the
OCB (Port C’-C) in a 1+0 configuration. For RSL values as they may be measured at
the Tx Port (Port A’) and Rx Port (Port A) of the RFU, see Annex 1: RFU-HP
Transmit Power and RSL at Radio Ports on page 463.
Table 150: Receiver Thresholds with RFU-HP
Frequency (GHz)
Profile Modulation Channel Spacing 6 7 8 11
0 QPSK -91.5 -91.0 -91.0 -91.0

1 8 PSK -86.5 -86.0 -86.0 -86.0
2 16 QAM -85.0 -84.5 -84.5 -84.5
3 32 QAM -81.5 -81.0 -81.0 -81.0
4 64 QAM -78.5 -78.0 -78.0 -78.0
14 MHz
5 128 QAM -75.0 -74.5 -74.5 -74.5
6 256 QAM -72.0 -71.5 -71.5 -71.5
7 512 QAM -69.5 -69.0 -69.0 -69.0
8 1024 QAM (strong FEC) -66.5 -66.0 -66.0 -66.0
9 1024 QAM (light FEC) -65.5 -65.0 -65.0 -65.0
0 QPSK -88.5 -88.0 -88.0 -88.0
1 8 PSK -83.5 -83.0 -83.0 -83.0
2 16 QAM -82 -81.5 -81.5 -81.5
3 32 QAM -78.5 -78.0 -78.0 -78.0
4 64 QAM -75.5 -75.0 -75.0 -75.0
5 128 QAM 28 MHz -72.5 -72.0 -72.0 -72.0
6 256 QAM -69.5 -69.0 -69.0 -69.0
7 512 QAM -67 -66.5 -66.5 -66.5
8 1024 QAM (strong FEC) -64 -63.5 -63.5 -63.5
9 1024 QAM (light FEC) -63.5 -63.0 -63.0 -63.0
10 2048 QAM -59.5 -59.0 -59.0 -59.0
Page 403 of 468

Frequency (GHz)
0 QPSK -87.0 -86.5 -86.5 -86.5

1 8 PSK -82.0 -81.5 -81.5 -81.5
2 16 QAM -80.5 -80.0 -80.0 -80.0
3 32 QAM -77.0 -76.5 -76.5 -76.5
4 64 QAM -74.0 -73.5 -73.5 -73.5
5 128 QAM 40 MHz -71.0 -70.5 -70.5 -70.5
6 256 QAM -68.5 -68.0 -68.0 -68.0
7 512 QAM -66.0 -65.5 -65.5 -65.5
8 1024 QAM (strong FEC) -63.0 -62.5 -62.5 -62.5
9 1024 QAM (light FEC) -62.0 -61.5 -61.5 -61.5
10 2048 QAM -58.5 -58.0 -58.0 -58.0
0 QPSK -85.5 -85.0 -85.0 n/a
1 8 PSK -80.5 -80.0 -80.0 n/a
2 16 QAM -79.0 -78.5 -78.5 n/a
3 32 QAM -75.5 -75.0 -75.0 n/a
4 64 QAM -72.0 -71.5 -71.5 n/a
5 128 QAM 56 MHz -69.5 -69.0 -69.0 n/a
6 256 QAM -66.5 -66.0 -66.0 n/a
7 512 QAM -64.0 -63.5 -63.5 n/a
8 1024 QAM (strong FEC) -61.0 -60.5 -60.5 n/a
9 1024 QAM (light FEC) -60.0 -59.5 -59.5 n/a
10 2048 QAM -56.5 -56.0 -56.0 n/a
• The Receiver Threshold values shown in the table above are measured at the
Antenna Port of the OCB (Port C’-C) in a 1+0 configuration. The Receiver
Thresholds at the Rx Port of the RFU (Port A) are 1.5 dB lower.
channel filters, the Receiver Threshold is 1 dB higher than the values shown in
the table above. This limitation is not applicable to other channels.
Page 404 of 468

9.5.6 Receiver Thresholds with 1500HP

RSL values shown in the tables below are measured at the Antenna Port of the
OCB (Port C’-C) in a 1+0 configuration. For RSL values as they may be measured at
the Tx Port (Port A’) and Rx Port (Port A) of the RFU, see Annex 1: RFU-HP
Transmit Power and RSL at Radio Ports on page 463.
Table 151: Receiver Thresholds with 1500HP
Frequency (GHz)
0 QPSK -91.0 -91.0 -91.0 -91.0

1 8 PSK -86.0 -86.0 -86.0 -86.0
2 16 QAM -84.5 -84.5 -84.5 -84.5
3 32 QAM -81.0 -81.0 -81.0 -81.0
4 64 QAM -78.0 -78.0 -78.0 -78.0
14 MHz
5 128 QAM -74.5 -74.5 -74.5 -74.5
6 256 QAM -71.5 -71.5 -71.5 -71.5
7 512 QAM -69.0 -69.0 -69.0 -69.0
8 1024 QAM (strong FEC) -66.0 -66.0 -66.0 -66.0
9 1024 QAM (light FEC) -65.0 -65.0 -65.0 -65.0
0 QPSK -88.0 -88.0 -88.0 -88.0
1 8 PSK -83.0 -83.0 -83.0 -83.0
2 16 QAM -81.5 -81.5 -81.5 -81.5
3 32 QAM -78.0 -78.0 -78.0 -78.0
4 64 QAM -75.0 -75.0 -75.0 -75.0
5 128 QAM 28 MHz -72.0 -72.0 -72.0 -72.0
6 256 QAM -69.0 -69.0 -69.0 -69.0
7 512 QAM -66.5 -66.5 -66.5 -66.5
8 1024 QAM (strong FEC) -63.5 -63.5 -63.5 -63.5
9 1024 QAM (light FEC) -63.0 -63.0 -63.0 -63.0
10 2048 QAM -59.0 -59.0 -59.0 -59.0
Page 405 of 468

Frequency (GHz)
0 QPSK -86.5 -86.5 -86.5 -86.5

1 8 PSK -81.5 -81.5 -81.5 -81.5
2 16 QAM -80.0 -80.0 -80.0 -80.0
3 32 QAM -76.5 -76.5 -76.5 -76.5
4 64 QAM -73.5 -73.5 -73.5 -73.5
5 128 QAM 40 MHz -70.5 -70.5 -70.5 -70.5
6 256 QAM -68.0 -68.0 -68.0 -68.0
7 512 QAM -65.5 -65.5 -65.5 -65.5
8 1024 QAM (strong FEC) -62.5 -62.5 -62.5 -62.5
9 1024 QAM (light FEC) -61.5 -61.5 -61.5 -61.5
10 2048 QAM -58.0 -58.0 -58.0 -58.0
• The Receiver Threshold values shown in the tables above are measured at the
Antenna Port of the OCB (Port C’-C) in a 1+0 configuration. The Receiver
Thresholds at the Rx Ports of the RFU (Port A, AD) are 1.5 dB lower.
channel filters, the Receiver Threshold is 1 dB higher than the values shown in
the table above. This limitation is not applicable to other channels.
Page 406 of 468

9.5.7 Receiver Thresholds with RMC-A and RFU-C
Table 152: Receiver Thresholds with RMC-A and RFU-C

Spacing
0 QPSK -92.5 -92.0 -92.5 -91.5 -91.0 -88.0 -90.0 -88.0 -89.0
1 8 PSK -89.0 -88.5 -89.0 -88.0 -87.5 -84.5 -86.5 -84.5 -85.5
2 16 QAM -87.0 -86.5 -87.0 -86.0 -85.5 -82.5 -84.5 -82.5 -83.5
3 32 QAM -84.5 -84.0 -84.5 -83.5 -83.0 -80.0 -82.0 -80.0 -81.0
7 MHz
4 64 QAM -83.0 -82.5 -83.0 -82.0 -81.5 -78.5 -80.5 -78.5 -79.5
5 128 QAM -81.0 -80.5 -81.0 -80.0 -79.5 -76.5 -78.5 -76.5 -77.5
6 256 QAM (Strong FEC) -77.5 -77.0 -77.5 -76.5 -76.0 -73.0 -75.0 -73.0 -74.0
7 256 QAM (Light FEC) -74.0 -73.5 -74.0 -73.0 -72.5 -69.5 -71.5 -69.5 -70.5
0 QPSK -91.0 -90.5 -91.0 -90.0 -89.5 -86.5 -88.5 -86.5 -87.5
1 8 PSK -87.5 -87.0 -87.5 -86.5 -86.0 -83.0 -85.0 -83.0 -84.0
2 16 QAM -84.0 -83.5 -84.0 -83.0 -82.5 -79.5 -81.5 -79.5 -80.5
3 32 QAM -82.5 -82.0 -82.5 -81.5 -81.0 -78.0 -80.0 -78.0 -79.0
14 MHz
4 64 QAM -81.0 -80.5 -81.0 -80.0 -79.5 -76.5 -78.5 -76.5 -77.5
5 128 QAM -78.0 -77.5 -78.0 -77.0 -76.5 -73.5 -75.5 -73.5 -74.5
6 256 QAM (Strong FEC) -75.0 -74.5 -75.0 -74.0 -73.5 -70.5 -72.5 -70.5 -71.5
7 256 QAM (Light FEC) -72.5 -72.0 -72.5 -71.5 -71.0 -68.0 -70.0 -68.0 -69.0
Table 153: RFU-C Receiver Threshold (RSL) with RMC-A (dBm @ BER = 10-6)

Spacing
0 QPSK -89.0 -88.5 -89.0 -88.0 -87.5 -84.5 -86.5 -84.5 -85.5
1 8 PSK -85.5 -85.0 -85.5 -84.5 -84.0 -81.0 -83.0 -81.0 -82.0
2 16 QAM 28 MHz -83.0 -82.5 -83.0 -82.0 -81.5 -78.5 -80.5 -78.5 -79.5
3 32 QAM -78.5 -78.0 -78.5 -77.5 -77.0 -74.0 -76.0 -74.0 -75.0
4 64 QAM -76.0 -75.5 -76.0 -75.0 -74.5 -71.5 -73.5 -71.5 -72.5
60
61
Page 407 of 468


Spacing
5 128 QAM -71.5 -71.0 -71.5 -70.5 -70.0 -67.0 -69.0 -67.0 -68.0
6 256 QAM (Strong FEC) -70.0 -69.5 -70.0 -69.0 -68.5 -65.5 -67.5 -65.5 -66.5
7 256 QAM (Light FEC) -67.5 -67.0 -67.5 -66.5 -66.0 -63.0 -65.0 -63.0 -64.0
0 QPSK -87.5 -87.0 -87.5 -86.5 -86.0 -83.0 -85.0 -83.0 -84.0
1 8 PSK -82.0 -81.5 -82.0 -81.0 -80.5 -77.5 -79.5 -77.5 -78.5
2 16 QAM -79.5 -79.0 -79.5 -78.5 -78.0 -75.0 -77.0 -75.0 -76.0
3 32 QAM -76.0 -75.5 -76.0 -75.0 -74.5 -71.5 -73.5 -71.5 -72.5
40 MHz
4 64 QAM -72.5 -72.0 -72.5 -71.5 -71.0 -68.0 -70.0 -68.0 -69.0
5 128 QAM -71.5 -71.0 -71.5 -70.5 -70.0 -67.0 -69.0 -67.0 -68.0
6 256 QAM (Strong FEC) -69.0 -68.5 -69.0 -68.0 -67.5 -64.5 -66.5 -64.5 -65.5
7 256 QAM (Light FEC) -66.5 -66.0 -66.5 -65.5 -65.0 -62.0 -64.0 -62.0 -63.0
0 QPSK -87.0 -86.5 -87.0 -86.0 -85.5 -82.5 -84.5 -82.5 -83.5
1 8 PSK -82.0 -81.5 -82.0 -81.0 -80.5 -77.5 -79.5 -77.5 -78.5
2 16 QAM -81.0 -80.5 -81.0 -80.0 -79.5 -76.5 -78.5 -76.5 -77.5
3 32 QAM -76.5 -76.0 -76.5 -75.5 -75.0 -72.0 -74.0 -72.0 -73.0
56 MHz
4 64 QAM -74.5 -74.0 -74.5 -73.5 -73.0 -70.0 -72.0 -70.0 -71.0
5 128 QAM -71.5 -71.0 -71.5 -70.5 -70.0 -67.0 -69.0 -67.0 -68.0
6 256 QAM (Strong FEC) -69.0 -68.5 -69.0 -68.0 -67.5 -64.5 -66.5 -64.5 -65.5
7 256 QAM (Light FEC) -66.0 -65.5 -66.0 -65.0 -64.5 -61.5 -63.5 -61.5 -62.5
Page 408 of 468

9.6 Frequency Bands

This section outlines the supported tuning range of each RFU unit.
It should be noted that the RFUs are wide enough to support the entire frequency
band. For example, the RFU-A 6L tunable range is 5.85-6.45GHz. The frequency
restricting element in each system is either the diplexer (RFU-C) or an OCB (RFU-HP).
9.6.1 Frequency Bands – RFU-D, RFU-D-HP, RFU-S, and RFU-C

11 GHz are not relevant for RFU-D-HP.
Table 154: Frequency Bands – RFU-C, RFU-D, RFU-D-HP, and RFU-S
Frequency Band TX Range RX Range Tx/Rx Spacing
4 GHz 3810-3984 4023-4197 213

3702.5-3926.5 3968.5-4192.5 266
3600-3880 3920-4200 320
U4(5) GHz 4400.5-4653.5 4500.5-4753.5 100
4395-4685 4695-4985 300
4400-4680 4700-4980
4410-4690 4710-4990
4404-4684 4716-4996 312
6L GHz 6332.5-6393 5972-6093 300A
5972-6093 6332.5-6393
6191.5-6306.5 5925.5-6040.5 266A
5925.5-6040.5 6191.5-6306.5
6303.5-6418.5 6037.5-6152.5
6037.5-6152.5 6303.5-6418.5
6245-6290.5 5939.5-6030.5 260A
5939.5-6030.5 6245-6290.5
6365-6410.5 6059.5-6150.5
6059.5-6150.5 6365-6410.5
6226.89-6286.865 5914.875-6034.825 252B
5914.875-6034.825 6226.89-6286.865
6345.49-6405.465 6033.475-6153.425
6033.475-6153.425 6345.49-6405.465
6181.74-6301.69 5929.7-6049.65 252A
5929.7-6049.65 6181.74-6301.69
Page 409 of 468

6241.04-6360.99 5989-6108.95
5989-6108.95 6241.04-6360.99
6300.34-6420.29 6048.3-6168.25
6048.3-6168.25 6300.34-6420.29
6235-6290.5 5939.5-6050.5 240A
5939.5-6050.5 6235-6290.5
6355-6410.5 6059.5-6170.5
6059.5-6170.5 6355-6410.5
6H GHz 6924.5-7075.5 6424.5-6575.5 500

6424.5-6575.5 6924.5-7075.5
7032.5-7091.5 6692.5-6751.5 340C
6692.5-6751.5 7032.5-7091.5
6764.5-6915.5 6424.5-6575.5 340B
6424.5-6575.5 6764.5-6915.5
6924.5-7075.5 6584.5-6735.5
6584.5-6735.5 6924.5-7075.5
6781-6939 6441-6599 340A
6441-6599 6781-6939
6941-7099 6601-6759
6601-6759 6941-7099
6707.5-6772.5 6537.5-6612.5 160A
6537.5-6612.5 6707.5-6772.5
6767.5-6832.5 6607.5-6672.5
6607.5-6672.5 6767.5-6832.5
6827.5-6872.5 6667.5-6712.5
6667.5-6712.5 6827.5-6872.5
7 GHz 7783.5-7898.5 7538.5-7653.5

7538.5-7653.5 7783.5-7898.5
7301.5-7388.5 7105.5-7192.5 196A
Page 410 of 468

7105.5-7192.5 7301.5-7388.5
7357.5-7444.5 7161.5-7248.5
7161.5-7248.5 7357.5-7444.5
7440.5-7499.5 7622.5-7681.5
7678.5-7737.5 7496.5-7555.5
7496.5-7555.5 7678.5-7737.5
7580.5-7639.5 7412.5-7471.5 168C
7412.5-7471.5 7580.5-7639.5
7608.5-7667.5 7440.5-7499.5
7440.5-7499.5 7608.5-7667.5
7664.5-7723.5 7496.5-7555.5
7496.5-7555.5 7664.5-7723.5
7609.5-7668.5 7441.5-7500.5 168B
7441.5-7500.5 7609.5-7668.5
7637.5-7696.5 7469.5-7528.5
7469.5-7528.5 7637.5-7696.5
7693.5-7752.5 7525.5-7584.5
7525.5-7584.5 7693.5-7752.5
7273.5-7332.5 7105.5-7164.5 168A

7105.5-7164.5 7273.5-7332.5
7301.5-7360.5 7133.5-7192.5
7133.5-7192.5 7301.5-7360.5
7357.5-7416.5 7189.5-7248.5
7189.5-7248.5 7357.5-7416.5
7280.5-7339.5 7119.5-7178.5 161P
7119.5-7178.5 7280.5-7339.5
7308.5-7367.5 7147.5-7206.5
7147.5-7206.5 7308.5-7367.5
7336.5-7395.5 7175.5-7234.5
7175.5-7234.5 7336.5-7395.5
7364.5-7423.5 7203.5-7262.5
7203.5-7262.5 7364.5-7423.5
7597.5-7622.5 7436.5-7461.5 161O
Page 411 of 468

7436.5-7461.5 7597.5-7622.5
7681.5-7706.5 7520.5-7545.5
7520.5-7545.5 7681.5-7706.5
7587.5-7646.5 7426.5-7485.5 161M
7426.5-7485.5 7587.5-7646.5
7615.5-7674.5 7454.5-7513.5
7454.5-7513.5 7615.5-7674.5
7643.5-7702.5 7482.5-7541.5 161K
7482.5-7541.5 7643.5-7702.5
7671.5-7730.5 7510.5-7569.5
7510.5-7569.5 7671.5-7730.5
7580.5-7639.5 7419.5-7478.5 161J
7419.5-7478.5 7580.5-7639.5
7608.5-7667.5 7447.5-7506.5
7447.5-7506.5 7608.5-7667.5
7664.5-7723.5 7503.5-7562.5
7503.5-7562.5 7664.5-7723.5
7580.5-7639.5 7419.5-7478.5 161I
7419.5-7478.5 7580.5-7639.5
7608.5-7667.5 7447.5-7506.5
7447.5-7506.5 7608.5-7667.5
7664.5-7723.5 7503.5-7562.5
7503.5-7562.5 7664.5-7723.5
7273.5-7353.5 7112.5-7192.5 161F
7112.5-7192.5 7273.5-7353.5
7322.5-7402.5 7161.5-7241.5
7161.5-7241.5 7322.5-7402.5
7573.5-7653.5 7412.5-7492.5
7412.5-7492.5 7573.5-7653.5
7622.5-7702.5 7461.5-7541.5
7461.5-7541.5 7622.5-7702.5
7709-7768 7548-7607 161D
7548-7607 7709-7768
Page 412 of 468

7737-7796 7576-7635
7576-7635 7737-7796
7765-7824 7604-7663
7604-7663 7765-7824
7793-7852 7632-7691
7632-7691 7793-7852
7584-7643 7423-7482 161C
7423-7482 7584-7643
7612-7671 7451-7510
7451-7510 7612-7671
7640-7699 7479-7538
7479-7538 7640-7699
7668-7727 7507-7566
7507-7566 7668-7727
7409-7468 7248-7307 161B
7248-7307 7409-7468
7437-7496 7276-7335
7276-7335 7437-7496
7465-7524 7304-7363
7304-7363 7465-7524
7493-7552 7332-7391
7332-7391 7493-7552
7284-7343 7123-7182 161A
7123-7182 7284-7343
7312-7371 7151-7210
7151-7210 7312-7371
7340-7399 7179-7238
7179-7238 7340-7399
7368-7427 7207-7266
7207-7266 7368-7427
7280.5-7339.5 7126.5-7185.5 154C
7126.5-7185.5 7280.5-7339.5
7308.5-7367.5 7154.5-7213.5
Page 413 of 468

7154.5-7213.5 7308.5-7367.5
7336.5-7395.5 7182.5-7241.5
7182.5-7241.5 7336.5-7395.5
7364.5-7423.5 7210.5-7269.5
7210.5-7269.5 7364.5-7423.5
7594.5-7653.5 7440.5-7499.5 154B
7440.5-7499.5 7594.5-7653.5
7622.5-7681.5 7468.5-7527.5
7468.5-7527.5 7622.5-7681.5
7678.5-7737.5 7524.5-7583.5
7524.5-7583.5 7678.5-7737.5
7580.5-7639.5 7426.5-7485.5 154A
7426.5-7485.5 7580.5-7639.5
7608.5-7667.5 7454.5-7513.5
7454.5-7513.5 7608.5-7667.5
7636.5-7695.5 7482.5-7541.5
7482.5-7541.5 7636.5-7695.5
7664.5-7723.5 7510.5-7569.5
7510.5-7569.5 7664.5-7723.5
8 GHz 8396.5-8455.5 8277.5-8336.5 119A

8277.5-8336.5 8396.5-8455.5
8438.5 – 8497.5 8319.5 – 8378.5
8319.5 – 8378.5 8438.5 – 8497.5
8274.5-8305.5 7744.5-7775.5 530A
7744.5-7775.5 8274.5-8305.5
8304.5-8395.5 7804.5-7895.5 500A
7804.5-7895.5 8304.5-8395.5
8023-8186.32 7711.68-7875 311C-J
7711.68-7875 8023-8186.32
8028.695-8148.645 7717.375-7837.325 311B
7717.375-7837.325 8028.695-8148.645
Page 414 of 468

8147.295-8267.245 7835.975-7955.925
7835.975-7955.925 8147.295-8267.245
8043.52-8163.47 7732.2-7852.15 311A
7732.2-7852.15 8043.52-8163.47
8162.12-8282.07 7850.8-7970.75
7850.8-7970.75 8162.12-8282.07
8212-8302 7902-7992 310D
7902-7992 8212-8302
8240-8330 7930-8020
7930-8020 8240-8330
8296-8386 7986-8076
7986-8076 8296-8386
8212-8302 7902-7992 310C
7902-7992 8212-8302
8240-8330 7930-8020
7930-8020 8240-8330
8296-8386 7986-8076
7986-8076 8296-8386
8380-8470 8070-8160
8070-8160 8380-8470
8408-8498 8098-8188
8098-8188 8408-8498
8039.5-8150.5 7729.5-7840.5 310A
7729.5-7840.5 8039.5-8150.5
8159.5-8270.5 7849.5-7960.5
7849.5-7960.5 8159.5-8270.5
8024.5-8145.5 7724.5-7845.5 300A
7724.5-7845.5 8024.5-8145.5
8144.5-8265.5 7844.5-7965.5
7844.5-7965.5 8144.5-8265.5
8302.5-8389.5 8036.5-8123.5 266C
8036.5-8123.5 8302.5-8389.5
8190.5-8277.5 7924.5-8011.5 266B
Page 415 of 468

7924.5-8011.5 8190.5-8277.5
8176.5-8291.5 7910.5-8025.5 266A
7910.5-8025.5 8176.5-8291.5
8288.5-8403.5 8022.5-8137.5
8022.5-8137.5 8288.5-8403.5
8226.52-8287.52 7974.5-8035.5 252A
7974.5-8035.5 8226.52-8287.52
8270.5-8349.5 8020.5-8099.5 250A
10 GHz 10501-10563 10333-10395 168A

10333-10395 10501-10563
10529-10591 10361-10423
10361-10423 10529-10591
10585-10647 10417-10479
10417-10479 10585-10647
10501-10647 10151-10297 350A
10151-10297 10501-10647
10498-10652 10148-10302 350B
10148-10302 10498-10652
10561-10707 10011-10157 550A
10011-10157 10561-10707
10701-10847 10151-10297
10151-10297 10701-10847
10590-10622 10499-10531 91A
10499-10531 10590-10622
10618-10649 10527-10558
10527-10558 10618-10649
10646-10677 10555-10586
10555-10586 10646-10677
Page 416 of 468

11 GHz 11425-11725 10915-11207 All

10915-11207 11425-11725
11185-11485 10695-10955
10695-10955 11185-11485
13 GHz 13002-13141 12747-12866 266

12747-12866 13002-13141
13127-13246 12858-12990
12858-12990 13127-13246
12807-12919 13073-13185 266A
13073-13185 12807-12919
12700-12775 12900-13000 200
12900-13000 12700-12775
12750-12825 12950-13050
12950-13050 12750-12825
12800-12870 13000-13100
13000-13100 12800-12870
12850-12925 13050-13150
13050-13150 12850-12925

15 GHz 15110-15348 14620-14858 490
14620-14858 15110-15348
14887-15117 14397-14627
14397-14627 14887-15117
15144-15341 14500-14697 644
14500-14697 15144-15341
14975-15135 14500-14660 475
14500-14660 14975-15135
15135-15295 14660-14820
14660-14820 15135-15295
14921-15145 14501-14725 420
Page 417 of 468

14501-14725 14921-15145
15117-15341 14697-14921
14697-14921 15117-15341
14963-15075 14648-14760 315
14648-14760 14963-15075
15047-15159 14732-14844
14732-14844 15047-15159
15229-15375 14500-14647 728
14500-14647 15229-15375

18 GHz 19160-19700 18126-18690 1010
18126-18690 19160-19700
18710-19220 17700-18200
17700-18200 18710-19220
19260-19700 17700-18140 1560
17700-18140 19260-19700

23 GHz 23000-23600 22000-22600 1008
22000-22600 23000-23600
22400-23000 21200-21800 1232 /1200
21200-21800 22400-23000
23000-23600 21800-22400
21800-22400 23000-23600

62
24UL GHz 24000 - 24250 24000 - 24250 All
62
Page 418 of 468

26 GHz 25530-26030 24520-25030 1008

24520-25030 25530-26030
25980-26480 24970-25480
24970-25480 25980-26480
25266-25350 24466-24550 800
24466-24550 25266-25350
25050-25250 24250-24450
24250-24450 25050-25250
28 GHz 28150-28350 27700-27900 450

27700-27900 28150-28350
27950-28150 27500-27700
27500-27700 27950-28150
28050-28200 27700-27850 350
27700-27850 28050-28200
27960-28110 27610-27760
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
29225-29250 29100-29125
31 GHz 31000-31085 31215-31300 175

31215-31300 31000-31085
Page 419 of 468

32 GHz 31815-32207 32627-33019 812

32627-33019 31815-32207
32179-32571 32991-33383
32991-33383 32179-32571
38 GHz 39500-39600 38240-38340 1260

38240-38340 39500-39600
38820-39440 37560-38180
37560-38180 38820-39440
38316-38936 37045-37676
37045-37676 38316-38936
39650-40000 38950-39300 700
38950-39300 39500-40000
39300-39650 38600-38950
38600-38950 39300-39650
37700-38050 37000-37350
37000-37350 37700-38050
38050-38400 37350-37700
37350-37700 38050-38400
42 GHz 40550-41278 42050-42778 1500

42050-42778 40550-41278
41222-41950.5 42722-43450
42722-43450 41222-41950.5
Page 420 of 468

9.6.2 Frequency Bands – RFU-E
Table 155: Frequency Bands – RFU-E
Frequency Band Frequency range (GHz) Recommendations ITU-R Tx/Rx Spacing (MHz)
(GHz) F Series
70/80 71-76 GHz/81-86 GHz F.2006 125 MHz (pattern)

71-76 GHz/81-86 GHz F.2006, Annex 1 n  250 MHz blocks
F.2006, Annex 2 (n = 1, …, 20)
71-76 GHz/81-86 GHz F.2006, Annex 2 n  250 MHz channels
(n = 1, …, 18)
74-76 GHz/84-86 GHz n  250 MHz channels
(n = 1, …, 7)
Page 421 of 468

9.6.3 Frequency Bands – 1500HP and RFU-HP

Note: Channel spacing for 1500HP/RFU-HP is determined by the
branching network.
Table 156: Frequency Bands – 1500HP and RFU-HP
Frequency Band Frequency Range (GHz) Channel Bandwidth
L6 GHz 5.925 to 6.425 29.65/56 MHz

U6 GHz 6.425 to 7.125 20 MHz to
40/56 /60 MHz
7 GHz 7.425 to 7.900 14 MHz to 28/56 MHz
7.425 to 7.725 28/56 MHz
7.110 to 7.750 28/56 MHz
8 GHz 7.725 to 8.275 29.65 MHz
8.275 to 8.500 14 MHz to 28/56 MHz
7.900 to 8.400 14 MHz to 28/56 MHz
11 GHz 10.700 to 11.700 10 MHz to 40/56
Page 422 of 468

9.7 Ethernet Latency Specifications

The specifications in this section are for 1+0 configurations.
9.7.1 Ethernet Latency with RIC-D and RFU-D, RFU-D-HP, and RFU-S
9.7.1.1 Ethernet Latency with RIC-D and RFU-D and RFU-S – 14 MHz Channel Bandwidth
Table 157: Ethernet Latency with RIC-D and RFU-D and RFU-S – 14 MHz Channel Bandwidth
ACM Working Point Modulation Latency (µsec) with GbE Interface
Frame Size 64 128 256 512 1024 1518
0 BPSK 2012 2088 2247 2568 3223 3859

1 QPSK 898 930 995 1131 1394 1653
2 8 QAM 626 648 692 778 948 1115
3 16 QAM 468 485 516 575 705 826
4 32 QAM 388 400 425 473 572 665
5 64 QAM 337 348 369 410 491 571
6 128 QAM 301 311 329 363 433 502
7 256 QAM 272 281 298 329 392 454
8 512 QAM 280 288 304 332 391 448
9 1024 QAM (Strong FEC) 264 272 287 314 371 425
10 1024 QAM (Light FEC) 261 268 282 309 363 415
Page 423 of 468

9.7.1.2 Ethernet Latency with RIC-D and RFU-D, RFU-D-HP, and RFU-S – 28 MHz Channel
Bandwidth
Bandwidth
Frame Size 64 128 256 512 1024 1518
0 BPSK 867 901 966 1091 1356 8458

1 QPSK 441 458 490 549 679 800
2 8 QAM 322 334 357 400 489 573
3 16 QAM 250 260 278 311 379 446
4 32 QAM 212 220 235 262 318 371
5 64 QAM 189 196 209 232 281 327
6 128 QAM 172 178 190 210 253 295
7 256 QAM 158 164 175 194 234 272
8 512 QAM 163 168 178 196 234 270
9 1024 QAM (Strong FEC) 154 160 169 187 223 258
10 1024 QAM (Light FEC) 152 157 167 184 219 253
11 2048 QAM 146 151 161 177 211 243
12 4096 QAM 146 151 161 177 211 243
Page 424 of 468

Bandwidth
Bandwidth
Frame Size 64 128 256 512 1024 1518
0 BPSK 599 621 670 755 931 1102

1 QPSK 322 333 355 400 492 581
2 8 QAM 240 249 266 299 365 429
3 16 QAM 190 198 212 237 290 340
4 32 QAM 164 170 182 203 247 289
5 64 QAM 148 153 164 183 222 259
6 128 QAM 136 141 150 167 203 236
7 256 QAM 125 131 140 156 190 222
8 512 QAM 128 133 142 157 190 221
9 1024 QAM (Strong FEC) 123 128 136 151 181 211
10 1024 QAM (Light FEC) 122 126 134 149 179 207
11 2048 QAM 117 122 130 143 172 200
12 4096 QAM 117 122 130 143 172 200
Page 425 of 468

Bandwidth
Bandwidth
Frame Size 64 128 256 512 1024 1518
0 BPSK 408 423 453 512 631 747

1 QPSK 228 237 254 286 352 415
2 8 QAM 190 197 211 235 285 333
3 16 QAM 143 149 159 179 220 259
4 32 QAM 125 131 140 157 192 226
5 64 QAM 115 120 128 143 175 206
6 128 QAM 107 111 119 133 162 190
7 256 QAM 103 107 114 127 155 181
8 512 QAM 102 107 114 127 153 179
9 1024 QAM (Strong FEC) 98 103 110 122 148 173
10 1024 QAM (Light FEC) 97 101 109 120 146 170
11 2048 QAM 96 100 107 119 144 167
12 4096 QAM 96 100 107 119 144 167
Page 426 of 468

9.7.1.5 Ethernet Latency with RIC-D and RFU-D, RFU-D-HP, and RFU-S – 112 MHz
Channel Bandwidth
Bandwidth
Frame Size 64 128 256 512 1024 1518
0 BPSK 231 241 259 292 360 427

1 QPSK 141 147 158 179 221 261
2 8 QAM 114 119 128 144 178 211
3 16 QAM 97 102 110 124 153 182
4 32 QAM 88 93 100 112 139 164
5 64 QAM 83 87 94 105 130 153
6 128 QAM 79 83 89 100 123 146
7 256 QAM 76 80 86 96 119 141
8 512 QAM 78 81 87 97 119 140
9 1024 QAM (Strong FEC) 76 79 85 95 117 137
10 1024 QAM (Light FEC) 76 79 85 95 116 137
11 2048 QAM 76 79 85 95 116 137
Page 427 of 468

9.7.2 Ethernet Latency with RIC-D and RFU-E
9.7.2.1 Ethernet Latency with RIC-D and RFU-E – 14 MHz Channel Bandwidth
Table 162: Ethernet Latency with RIC-D and RFU-E – 14 MHz Channel Bandwidth
ACM Working Modulation Latency (µsec) with GbE Interface

Point
Frame 64 128 256 512 1024 1518
Size
0 BPSK 2003 2082 2239 2561 3210 3842

1 QPSK 897 928 992 1128 1383 1636
2 8 QAM 627 648 680 773 938 1099

Point
Frame 64 128 256 512 1024 1518
Size
0 BPSK 865 900 967 1085 1348 8436

1 QPSK 440 456 486 543 668 784
2 8 QAM 321 332 353 395 478 557
3 16 QAM 249 258 274 306 369 431
4 32 QAM 211 218 232 257 308 356
5 64 QAM 187 194 205 227 270 312
6 128 QAM 171 176 186 205 243 279
7 256 QAM 157 162 172 189 223 257
8 512 QAM 161 166 175 191 223 255
Page 428 of 468

9.7.2.3 Ethernet Latency with RIC-D and RFU-E – 62.5 MHz Channel Bandwidth
Table 164: Ethernet Latency with RIC-D and RFU-E – 62.5 MHz Channel Bandwidth

Point
Frame 64 128 256 512 1024 1518
Size
0 BPSK 411 424 454 513 630 741

1 QPSK 214 222 237 265 322 377
2 8 QAM 165 171 182 203 245 286
3 16 QAM 134 140 149 166 200 233
4 32 QAM 119 123 131 146 174 202
5 64 QAM 109 113 120 133 159 183
6 128 QAM 102 106 112 124 147 170
7 256 QAM 96 100 106 116 138 159
8 512 QAM 98 102 108 118 139 159
9 1024 QAM 95 98 104 114 134 153

Point
Frame 64 128 256 512 1024 1518
Size
0 BPSK 215 223 238 267 326 384

1 QPSK 128 133 143 160 194 227
2 8 QAM 105 109 117 130 157 182
3 16 QAM 90 94 100 111 134 156
4 32 QAM 82 86 92 102 122 141
5 64 QAM 78 81 86 95 114 132
6 128 QAM 75 77 82 91 109 125
7 256 QAM 72 75 79 88 104 120
8 512 QAM 74 76 81 89 105 120
Page 429 of 468


Point
Frame 64 128 256 512 1024 1518
Size
0 BPSK 129 134 144 161 196 230

1 QPSK 87 91 97 109 132 153
2 8 QAM 76 79 85 94 113 132
3 16 QAM 69 72 77 85 102 119
4 32 QAM 66 68 73 81 97 112
5 64 QAM 63 66 70 78 93 107
6 128 QAM 62 64 68 76 90 104
7 256 QAM 61 64 68 75 89 103

Point
Frame Size 64 512 1518
0 BPSK 85 103 140

1 QPSK 52 65 89
2 8 QAM 43 54 75
3 16 QAM 37 47 66
4 32 QAM 34 44 61
5 64 QAM 32 40 57
Page 430 of 468

9.7.3 Ethernet Latency with RMC-B
9.7.3.1 Ethernet Latency with RMC-B – 3.5 MHz Channel Bandwidth
Table 168: Ethernet Latency with RMC-B – 3.5 MHz Channel Bandwidth

Point
Frame 64 128 256 512 1024 1518
Size
0 QPSK 1355 1498 1785 2359 3517 4635

1 16 QAM 743 807 928 1180 1692 2186
2 32 QAM 655 701 794 981 1355 1715
3 64 QAM 600 635 708 862 1162 1452
4 128 QAM 563 593 655 783 1037 1281
5 256 QAM 508 537 592 707 931 1148
9.7.3.2 Ethernet Latency with RMC-B – 7 MHz Channel Bandwidth
Table 169: Ethernet Latency with RMC-B – 7 MHz Channel Bandwidth
ACM Modulation Latency (µsec) with GbE Interface

Working
Frame 64 128 256 512 1024 1518
Point
Size
0 QPSK 924 987 1106 1353 1840 2317

1 8 PSK 678 718 799 969 1298 1623
2 16 QAM 525 549 604 728 962 1194
3 32 QAM 446 470 515 605 787 961
4 64 QAM 399 419 456 531 679 824
5 128 QAM 369 383 416 479 603 725
6 256 QAM 366 380 408 463 573 681
7 512 QAM 371 384 411 462 566 668
8 1024 QAM (Strong FEC) 352 366 390 439 538 633
9 1024 QAM (Light FEC) 349 360 384 430 524 613
Page 431 of 468


Working
Frame 64 128 256 512 1024 1518
Point
Size
0 QPSK 460 480 534 647 867 1086

1 8 PSK 346 364 402 479 629 778
2 16 QAM 265 278 307 364 477 588
3 32 QAM 233 244 267 312 401 487
4 64 QAM 213 222 241 279 353 426
5 128 QAM 193 202 219 251 315 377
6 256 QAM 177 184 199 228 286 341
7 512 QAM 209 216 230 256 310 361
8 1024 QAM (Strong FEC) 195 202 215 241 292 341
9 1024 QAM (Light FEC) 190 197 210 234 283 330

Working
Frame 64 128 256 512 1024 1518
Point
Size
0 QPSK 154 169 198 257 373 484

1 8 PSK 130 141 162 204 286 363
2 16 QAM 109 117 133 166 231 290
3 32 QAM 105 111 125 152 204 252
4 64 QAM 101 107 119 142 187 228
5 128 QAM 95 100 110 131 171 207
6 256 QAM 89 94 103 123 160 193
7 512 QAM 113 117 126 145 179 210
8 1024 QAM (Strong FEC) 104 108 117 135 168 198
9 1024 QAM (Light FEC) 106 110 118 136 168 197
10 2048 QAM 99 104 111 127 157 182
Page 432 of 468


Point
Frame 64 128 256 512 1024 1518
Size
0 QPSK 194 206 230 278 373 465

1 8 PSK 147 156 173 208 277 342
2 16 QAM 120 126 139 165 216 267
3 32 QAM 108 113 124 144 186 226
4 64 QAM 100 104 113 131 166 201
5 128 QAM 92 96 104 120 151 181
6 256 QAM 95 100 106 120 149 177
7 512 QAM 100 104 111 124 151 178
8 1024 QAM (strong FEC) 93 96 102 116 141 166
9 1024 QAM (light FEC) 95 97 104 116 141 166
10 2048 QAM 81 85 92 105 131 153

Point
Frame 64 128 256 512 1024 1518
Size
0 QPSK 94 102 119 152 216 275

1 8 PSK 83 89 102 127 174 218
2 16 QAM 72 77 87 108 146 182
3 32 QAM 69 73 82 99 133 162
4 64 QAM 66 69 77 93 123 149
5 128 QAM 65 68 75 90 116 140
6 256 QAM 61 64 71 84 110 132
7 512 QAM 69 72 78 92 116 137
8 1024 QAM (Strong FEC) 65 68 74 87 110 131
10 2048 QAM 62 66 72 83 105 124
Page 433 of 468

9.7.4 Ethernet Latency with RMC-A
9.7.4.1 Ethernet Latency with RMC-A – 14 MHz Channel Bandwidth
Table 174: Ethernet Latency with RMC-A – 14 MHz Channel Bandwidth

Point
Frame 64 128 256 512 1024 1518
Size
0 QPSK 528 554 612 726 952 1168

1 8 PSK 396 414 454 538 701 857
2 16 QAM 288 302 330 389 505 614
3 32 QAM 255 267 293 345 446 542
4 64 QAM 315 325 348 394 484 568
5 128 QAM 306 315 335 375 452 525
6 256 QAM (Strong FEC) 295 303 320 356 425 489
7 256 QAM (Light FEC) 261 268 285 319 384 444
9.7.4.2 Ethernet Latency with RMC-A – 28 MHz Channel Bandwidth
Table 175: Ethernet Latency with RMC-A – 28 MHz Channel Bandwidth

Point
Frame 64 128 256 512 1024 1518
Size
0 QPSK 279 293 322 379 494 604

1 8 PSK 226 236 258 302 390 475
2 16 QAM 171 179 195 228 293 356
3 32 QAM 136 143 156 181 233 282
4 64 QAM 149 154 165 187 231 273
5 128 QAM 141 145 155 174 212 248
6 256 QAM (Strong FEC) 146 151 159 177 213 247
7 256 QAM (Light FEC) 137 141 149 167 201 234
Page 434 of 468

9.7.4.3 Ethernet Latency with RMC-A – 40MHz Channel Bandwidth
Table 176: Ethernet Latency with RMC-A – 40MHz Channel Bandwidth

Point
Frame 64 128 256 512 1024 1518
Size
0 QPSK 215 225 247 290 376 459

1 8 PSK 158 166 181 212 274 334
2 16 QAM 121 127 139 162 208 252
3 32 QAM 105 110 120 140 179 217
4 64 QAM 114 118 126 143 177 209
5 128 QAM 118 122 130 146 178 208
6 256 QAM (Strong FEC) 121 124 132 146 176 203
7 256 QAM (Light FEC) 111 115 122 136 164 191
9.7.4.4 Ethernet Latency with RMC-A – 56MHz Channel Bandwidth
Table 177: Ethernet Latency with RMC-A – 56MHz Channel Bandwidth

Point
Frame 64 128 256 512 1024 1518
Size
0 QPSK 255 263 280 313 380 444

1 8 PSK 194 200 212 237 285 331
2 16 QAM 166 171 181 201 241 279
3 32 QAM 145 149 157 174 207 238
4 64 QAM 164 167 175 189 218 245
5 128 QAM 163 166 173 186 211 237
6 256 QAM (Strong FEC) 167 170 176 188 212 235
7 256 QAM (Light FEC) 160 163 169 181 204 226
Page 435 of 468

9.8 Mediation Device and Branching Network Losses

Note: In general, the mediation devices per RFU are available for the
frequency bands in which the RFU is available.
9.8.1 RFU-D/RFU-D-HP Mediation Device Losses

11 GHz are not relevant for RFU-D-HP.
Table 178: RFU-D/RFU-D-HP Mediation Device Losses
Mediation Devices Signal Path / Remarks Maximum Insertion Loss [dB]
4-5 GHz 6-8 GHz 11 GHz 13-15 GHz 18 GHz 23-26 GHz 28-38 GHz 42 GHz
Size varies per

Flex WG 0.5 0.5 0.5 1.2 1.2 1.5 1.8 2.5
frequency.
Radio to antenna
OMT n/a 0.3 0.3 0.3 0.3 0.5 0.5 0.5
ports (V or H)
Splitter63 Radio to antenna port 3.6 3.6 3.7 3.7 3.7 3.7 4.0 4.0
Main Paths 1.4 1.6 1.6 1.6 1.8 1.8 2.0 2.0
Dual Coupler
Secondary Paths 6±0.7 6±0.7 6±0.7 6±0.7 6±0.8 6±0.8 6±1.0 6±1.0
Dual Splitter Radio to antenna port 3.6 3.6 3.7 3.7 3.7 3.7 4.0 4.0
High Ch radio to
0.2 0.2 0.2 0.2 0.5 0.5 0.5 0.5
antenna port
Dual Circulator
Low Ch radio to
0.2 0.2 0.2 0.2 0.5 0.5 0.5 0.5
antenna port
Notes: The antenna interface is always the RFU interface.

If other antennas are to be used, an adaptor with a 0.1 dB loss
should be considered.
The numbers above represent the typical loss per component.
63
The RFU-D-HP splitter is planned for future release.
Page 436 of 468

The following diagram explains the circulators insertion loss:
Page 437 of 468

9.8.2 RFU-D-HP Branching Losses – Channel Filters-Based Branching

When designing a link budget calculation, the branching loss (dB) should be
considered as per specific configuration, frequency, and channel bandwidth.
9.8.2.1 RFU-D-HP Filter-Based Branching Losses – Remote Mount
Table 179: RFU-D-HP Filter-Based Branching Losses – Remote Mount

6-8 GHz 11 GHz
Configuration 28 MHz 40 MHz 56 MHz 80 MHz 112 MHz 28 MHz 40 MHz 56 MHz 80 MHz 112 MHz
2+0 XPIC (CCDP) 1.8 1.8 2.3 2.6 1.8 2.3 2.3 2.3 2.6 1.8
4+0 XPIC (CCDP) 2.0 2.0 2.5 2.8 2.0 2.5 2.5 2.5 2.8 2.0
6+0 XPIC (CCDP) 2.3 2.3 2.8 3.1 2.3 2.8 2.8 2.8 3.1 2.3
8+0 XPIC (CCDP) 2.5 2.5 3.0 3.3 2.5 3.0 3.0 3.0 3.3 2.5
4+0 XPIC (ACCP)64 5.3 5.3 5.8 6.1 5.3 5.8 5.8 5.8 6.1 5.3
8+0 XPIC (ACCP)64 5.5 5.5 6.0 6.3 5.5 6.0 6.0 6.0 6.3 5.5
2+2 HSB/XPIC 3.2 3.2 3.7 4.0 3.2 3.7 3.7 3.7 4.0 3.2
2+0 SP 2.2 2.2 2.7 3 2.2 2.7 2.7 2.7 3.0 2.2
3+0 SP 2.4 2.4 2.9 3.2 2.4 2.9 2.9 2.9 3.2 2.4
4+0 SP 2.7 2.7 3.2 3.5 2.7 3.2 3.2 3.2 3.5 2.7
5+0 SP 3.0 3.0 3.5 3.8 3.0 3.5 3.5 3.5 3.8 3.0
6+0 SP 3.3 3.3 3.8 4.1 3.3 3.8 3.8 3.8 4.1 3.3
7+0 SP 3.5 3.5 4.0 4.3 3.5 4.0 4.0 4.0 4.3 3.5
8+0 SP 3.8 3.8 4.3 4.6 3.8 4.3 4.3 4.3 4.6 3.8
2+0 SP (ACCP)64 5.3 5.3 5.8 6.1 5.3 5.8 5.8 5.8 6.1 5.3
64
4+0 SP (ACCP) 5.7 5.7 6.2 6.5 5.7 6.2 6.2 6.2 6.5 5.7
6+0 SP (ACCP)64 6.2 6.2 6.7 7.0 6.2 6.7 6.7 6.7 7.0 6.2
8+0 SP (ACCP)64 6.2 6.2 6.7 7.0 6.2 6.7 6.7 6.7 7.0 6.2
2+2 HSB/SP 3.4 3.4 3.9 4.2 3.4 3.9 3.9 3.9 4.2 3.4
64
Page 438 of 468

9.8.2.2 RFU-D-HP Filter-Based Branching Losses – All-Indoor
Table 180: RFU-D-HP Filter-Based Branching Losses – All-Indoor

4/5/L6 GHz U6 GHz 7 GHz
Configuration 28 MHz 40 MHz 56 MHz 28 MHz 40 MHz 56 MHz 28 MHz 40 MHz 56 MHz
2+0 XPIC 2.5 2.3 2.3 3.0 2.7 2.7 3.1 2.9 2.9
4+0 XPIC 2.7 2.5 2.5 3.2 2.9 2.9 3.3 3.1 3.1
6+0 XPIC 3.0 2.8 2.8 3.5 3.2 3.2 3.6 3.4 3.4
8+0 XPIC 3.2 3.0 3.0 3.7 3.4 3.4 3.8 3.6 3.6
10+0 XPIC 3.3 3.1 3.1 3.8 3.5 3.5 3.9 3.7 3.7
12+0 XPIC 3.6 3.4 3.4 4.1 3.8 3.8 4.2 4.0 4.0
14+0 XPIC 3.8 3.6 3.6 4.3 4.0 4.0 4.4 4.2 4.2
2+0 SD DP 2.6 2.4 2.4 3.1 2.8 2.8 3.2 3.0 3.0
4+0 SD DP 2.8 2.6 2.6 3.3 3.0 3.0 3.4 3.2 3.2
6+0 SD DP 3.1 2.9 2.9 3.6 3.3 3.3 3.7 3.5 3.5
8+0 SD DP 3.3 3.1 3.1 3.8 3.5 3.5 3.9 3.7 3.7
8 GHz 11 GHz
Configuration 28 MHz 40 MHz 56 MHz 28 MHz 40 MHz 56 MHz
2+0 XPIC 3.4 3.0 3.0 3.9 3.4 3.2

4+0 XPIC 3.6 3.2 3.2 4.1 3.6 3.4
6+0 XPIC 3.9 3.5 3.5 4.4 3.9 3.7
8+0 XPIC 4.1 3.7 3.7 4.6 4.1 3.9
10+0 XPIC 4.2 3.8 3.8 4.7 4.2 4.0
12+0 XPIC 4.5 4.1 4.1 5.0 4.5 4.3
14+0 XPIC 4.7 4.3 4.3 5.2 4.7 4.5
2+0 SD DP 3.5 3.1 3.1 4.0 3.5 3.3
4+0 SD DP 3.7 3.3 3.3 4.2 3.7 3.5
6+0 SD DP 4.0 3.6 3.6 4.5 4.0 3.8
8+0 SD DP 4.2 3.8 3.8 4.7 4.2 4.0
4-11 GHz
Configuration 80 MHz 112 MHz
2+0 XPIC 3.5 2.7

4+0 XPIC 3.7 2.9
6+0 XPIC 4.0 3.2
8+0 XPIC 4.2 3.4
Page 439 of 468

Notes:
• (c) – Radio Carrier
• CCDP – Co-channel dual polarization
• SP – Single pole antenna
• DP – Dual pole antenna
• SD – Space Diversity
Additional losses will be added when using the items listed in Table 184.
Page 440 of 468

9.8.3 RFU-E Mediation Device Losses
Table 181: RFU-E Mediation Device Losses
Device Type Maximum Insertion Loss (Main/Secondary)
OMT 2dB
Splitter 1:2 4.5dB
Coupler 1:4 2.2dB/ 6.5±1dB
9.8.4 RFU-S and RFU-C Mediation Device Losses
Table 182: RFU-C and RFU-S Mediation Device Losses
Configuration Interfaces 5.7-8 11 13-15 18 23-26 28-38 42

GHz GHz GHz GHz GHz GHz GHz
Flex WG Remote Mount Added on remote 0.5 0.5 1.2 1.2 1.5 1.8 2.5
antenna mount
configurations
1+0 Direct Mount Integrated antenna 0.2 0.2 0.4 0.5 0.5 0.5 0.5
OMT Direct Mount Integrated antenna 0.3 0.3 0.3 0.3 0.5 0.5 0.5
Splitter Direct Mount Integrated antenna 3.6 3.7 3.7 3.7 3.7 4.0 4.0
Notes: The antenna interface is always the RFU interface.

If other antennas are to be used, an adaptor with a 0.1 dB loss
should be considered.
Page 441 of 468

9.8.5 1500HP/RFU-HP Branching Network Losses

When designing a link budget calculation, the branching loss (dB) should be
considered as per specific configuration. This section contains tables that list the
branching loss for the following Split-Mount configurations.
Table 183: 1500HP/RFU-HP Branching Network Losses
Interfaces 1+0 1+1 FD/ 2+1 3+1 4+1 5+1 6+1 7+1 8+1 9+1
2+0 3+0 4+0 5+0 6+0 7+0 8+0 9+0 10+0
CCDP with DP 0 (1c) 0 (1c) 0.5 (2c) 0.5 (2c) 1.0 (3c) 1.0 (3c) 1.5 (4c) 1.5 (4c) 2 (5c) 2 (6c)
Antenna
SP Non- 0 (1c) 0.5 (2c) 1.0 (3c) 1.5 (4c) 2.0 (5c) NA NA NA NA NA
adjacent
Channels
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:
Table 184: Added Losses
Item Where to Use Loss (dB)
Flex WG All configurations 0.5

15m Coax cable Diversity path 6-8/11 GHz 5/6.5
Symmetrical Coupler Adjacent channel configuration. 3.5
Asymmetrical coupler 1+1 HSB configurations Main: 1.6
Coupled: 6.5
9.8.5.1 Adjacent Channels Implementation (ACCP)

The use of Adjacent Channel can be implemented using two methods:
1 Using Adjacent Channel OCBs (when the specific bands and channels
bandwidth is supported)
2 Using a Symmetrical Coupler.
Note: For a listing of which bands and channels support adjacent
channel OCBs, see OCB Part Numbers on page 137.
Page 442 of 468

Branching System using Adjacent Channel OCBs

When using Adjacent Channel OCBs, the OCBs are assembled using the standard
OCB components.
Branching System
F1 F2 F3 F4 F5
Figure 195: RFU-HP Branching System using Adjacent Channel OCBs
Branching System using Symmetrical Coupler

When using a Symmetrical coupler to support Adjacent Channels, the branching
system is split into two branching sub system, each built to support ACAP
configuration according to the following channels assignment:
Branching System #1
F1 F3 F5
Branching System #2
F2 F4 F6
Figure 196: RFU-HP Branching System using Symmetrical Coupler
Page 443 of 468

The following figure shows how to build a four-Adjacent Channel configuration

using a symmetrical coupler.
Figure 197: Four-Adjacent Channel configuration using a symmetrical coupler
Page 444 of 468

9.8.5.2 1500HP/RFU-HP All-Indoor Branching Loss

ICC has a 0 dB loss, since the RFU is calibrated to Pmax, together with the filter
and 1+0 branching loss. The following table presents the branching loss per
configuration and the Elliptical wave guide (WG) losses per meter which will be
add for each installation (dependent on the WG length).
Table 185: 1500HP/RFU-HP All-Indoor Branching Loss – Part 1
Interfaces 1+0 1+1 2+1 3+1 4+1

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 3
Symmetrical Coupler
channel configuration
Tx and Rx 0.3 (1c) 0.3 (1c) 0.7 (2c) 0.7 1.1 (3c)
(2c)
CCDP with DP antenna
Diversity RX 0.2 (1c) 0.2 (1c) 0.6 (2c) 0.6 1.0 (3c)
(2c)
Tx and Rx 0.3 (1c) 0.7 (2c) 1.1 (3c) 1.5 1.9 (5c)
(4c)
SP Non adjacent channels
Diversity RX 0.2 (1c) 0.6 (2c) 1.0 (3c) 1.4 1.8 (5c)
(4c)
Tx and Rx 0.3 (1c) 0.7 (1c) 1.1 (2c) 1.1 1.5 (3c)
CCDP with DP antenna (2c)
Upgrade Ready Diversity RX 0.2 (1c) 0.6 (1c) 1.0 (2c) 1.0 1.4 (3c)
(2c)
Page 445 of 468

Table 186: 1500HP/RFU-HP All-Indoor Branching Loss – Part 2
Interfaces 5+1 6+1 7+1 8+1 9+1

6+0 7+0 8+0 9+0 10+0
6L 4
6H 4.5
WG losses per 100m
7/8GHz 6
11GHz 10
Added to adjacent channel 3

Symmetrical Coupler
configuration
Tx and Rx 1.5 1.9 1.9 (4c) 2.3 2.3 (6c)

(3c) (4c) (5c)
CCDP with DP antenna
Diversity RX 1.4 1.8 1.8 (4c) 2.2 2.2 (6c)
(3c) (4c) (5c)
Tx and Rx NA NA NA NA NA
SP Non adjacent channels
Diversity RX
Tx and Rx 1.5 1.9 1.9 (4c) 2.3 2.3 (6c)

CCDP with DP antenna (3c) (4c) (5c)
Upgrade Ready Diversity RX 1.4 1.8 1.8 (4c) 2.2 2.2 (6c)
(3c) (4c) (5c)
Page 446 of 468

9.9 Ethernet Specifications

9.9.1 Ethernet Interface Specifications
Table 187: Ethernet Interface Specifications
Supported Ethernet Interfaces for Traffic Up to 8 x 10/100/1000Base-T (RJ-45) or 1000base-X (SFP)

Optional 10G 10GBase-X (SFP+)
Supported Ethernet Interfaces for Management 2 x 10/100 Base-T (RJ-45)
Supported SFP Types See Approved SFP Modules on page 448
9.9.2 Carrier Ethernet Functionality
Table 188: Carrier Ethernet Functionality
Switching capacity 10 Gbps

"Jumbo" Frame Support Up to 9600 Bytes
General Header De-Duplication
Integrated Carrier Ethernet Switch MAC address learning with 128K MAC addresses
802.1ad provider bridges (QinQ)
802.3ad link aggregation
QoS Advanced CoS classification and remarking
Per interface CoS based packet queuing/buffering (8 queues)
Per queue statistics
Tail-drop and WRED with CIR/EIR support
Flexible scheduling schemes (SP/WFQ/Hierarchical)
Per interface and per queue traffic shaping
Hierarchical-QoS (H-QoS) – 8K service level queues65
4Gbit packet buffer
Network resiliency MSTP
ERP (G.8032)
Service OAM FM (Y.1731)
PM (Y.1731)66
Performance Monitoring Per port Ethernet counters (RMON/RMON2)
Radio ACM statistics
Enhanced radio Ethernet statistics (Frame Error Rate,
Throughput, Capacity, Utilization)
65
66
PM is planned for future release.
Page 447 of 468

9.9.3 Approved SFP Modules
Table 189: Approved GbE SFP Modules
Part Number Marketing Model Marketing Description Item Description
AO-0058-0 SFP-GE-ZX SFP optical interface XCVR,SFP,1550nm,2.125G,SM,80km,W.DDM

1000Base-ZX
AO-0068-0 SFP-GE-ELC-RXLE SFP ELECT INT 1000Base-T XCVR,SFP,COOPER 1000BASE-T,RX_LOS ENABLED

RX_LOS enabled
AO-0193-0 SFP-BX-U-OPT SFP SM Fiber, 1310nm TX, XCVR,SFP,SINGLE FIBER,1310nm TX/1490nm

1490nm RX RX,1.25Gb,SM,10km,W.DDM,COMMERCIAL,SINGLE PACK KIT
AO-0194-0 SFP-BX-D-OPT SFP SM Fiber, 1310nm RX, XCVR,SFP,SINGLE FIBER,1490nm TX/1310nm

1490nm TX RX,1.25Gb,SM,10km,W.DDM,COMMERCIAL,SINGLE PACK KIT
AO-0226-0 SFP-GE-CWDM- SFP GE CWDM, 120Km, XCVR,SFP,1510nm,GE,SM,CWDM,120km,W.DDM,COMMERCIAL

120km-1510nm 1510nm TEMP
ER-8003-0 SFP-GE-ELC SFP electrical interface SFP 1000BASE-T 1.25 GBd Small FormPluggable Low Voltage
1000Base-T (3.3 V) ElectricalTransceiver over Category 5 Cable with package
ER-8000-0 SFP-GE-SX SFP optical interface XCVR,SFP,850nm,MM,1.0625 Gbit/s FC/ 1.25 GBE,PACKED
1000Base-SX
ER-1002-0 SFP-GE-LX SFP optical interface XCVR,SFP,1310nm,1.25Gb,SM,10km,W.DDM, SINGLE PACK KIT

1000Base-LX*ROHS
Table 190: Approved 2.5 GbE SFP Modules
AO-0165-0 SFP-3.7G-SX-EXT- SFP-3.7G-SX-EXT-TEMP XCVR,SFP,850nm,MM,3.7 Gbit/s, INDUSTRIAL GRADE

TEMP
AO-0265-0 SFP-3.7G-LX-EXT- SFP-3.7G-LX-EXT-TEMP XCVR,SFP,1310nm,SM,10km,3.7 Gbit/s, INDUSTRIAL GRADE

TEMP
Table 191: Approved 10 GbE SFP Modules
AO-0258-0 SFP+10GBASE-LR SFP+ 10G optical interface XCVR,SFP+,1310nm,SM,10 Gbit/s,2km,COMMERCIAL

10GBASE-LR GRADE
AO-0224-0 SFP+10GBASE-SR SFP+ 10G optical interface XCVR,SFP+,850nm,MM,10 Gbit/s, COMMERCIAL GRADE
10GBASE-SR
Note: Ceragon recommends the use of SFP and SFP+ modules certified
by Ceragon, as listed above.
Page 448 of 468

9.10 TDM Specifications
9.10.1 E1 Cross Connect
Table 192: E1 Cross Connect
E1 cross connect capacity 512 E1 trails (VCs)

E1 trails protection 1+1 / 1:1
9.10.2 E1 Interface Specifications
Interface Type E1
Number of Ports 16 x E1s per LIC
Connector Type MDR 69-pin
Framing Framed / Unframed
Coding HDB3
Line Impedance 120 ohm/100 ohm balanced. Optional 75 ohm unbalanced supported
using panel with integrated impedance adaption.
Compatible Standards ITU-T G.703, G.736, G.775, G.823, G.824, G.828, ITU-T I.432, ETSI ETS
300 147, ETS 300 417, Bellcore GR-253-core, TR-NWT-000499
9.10.3 Pseudowire Specifications
Table 193: Pseudowire Specifications
Circuit-Emulation Modes RFC 4553 – SAToP

RFC 5086 – CESoP67
Circuit-Emulation Ethernet (MEF-8)
Encapsulations IP/UDP68
MPLS (MFA-8)69
Frame payload size Configurable – 1 E1 frame (256 bytes) to 64 frames (8192 bytes)
De-Jitter buffer size Configurable – 1 ms to 32 ms
67
CESoP mode is planned for future release.
68
IP/MPLS encapsulation is planned for future release.
69
MFA-8 encapsulation is planned for future release.
Page 449 of 468

9.10.4 Electrical STM-1 SFP Interface Specifications
Table 194: Electrical STM-1 SFP Interface Specifications
Interface Type STM-1

Number of Ports 1 x STM-1 per LIC
Connector Type 1.0/2.3 on SFP
Framing Framed carrying up to 63 x VC12
Coding CMI
Line Impedance 75ohms
Compatible Standards ITU-T G.703, G.775, G.813, G.825, EN 300 386 V1.2.1, ES 201 468
V1.1.1 :2000-03, ES 201 468 V1.2.1 :2002-09, EN 61000 4-3
9.10.5 Optical STM-1 SFP Interface Specifications
Table 195: Optical STM-1 SFP Interface Specifications
Transceiver Name SH1310 LH1310 LH1550

Application Code S-1.1 L-1.1 L-1.2
Operating Wavelength (nm) 1261-1360 1263-1360 1480-580
Transmitter
Source Type MLM SLM SLM
Max RMS Width (nm) 7.7 - -
Min Side Mode Suppression Ratio - 30 30
(dB)
Min Mean Launched Power (dBm) -15 -5 -5
Max Mean Launched Power (dBm) -8 0 0
Min Extinction Ratio (dB) 8.2 10 10
Receiver
Min Sensitivity (BER of 1x10-42 EOL -28 -34 -34
(dBm)
Min Overload (dBm) -8 -10 -10
Max Receiver Reflectance (dB) - - -25
Page 450 of 468

Optical Path between S and R

Max Dispersion (ps/nm) 96 - -
Min Optical Return - - -20
Loss of Cable (dB)
Max Discreet - - 25
Reflectance (dB)
Max Optical Path 1 1 1
Penalty (dB)
9.10.6 Approved STM-1 SFP Modules
Table 196: Approved STM-1 SFP Modules
AO-0096-0 SFP-STM-1-Elec- SFP STM-1 Module XCVR,SFP,STM1E-SFP 155Mbps 1.0/2.3

1.0/2.3-75ohm Elec, 1.0/2.3, 75ohm
AO-0073-0 SFP-STM-1-L1.1 SFP STM-1 Module XCVR,SFP,1310nm,OC3,SM,40km,W.DDM
Long Haul 1310nm
AO-0074-0 SFP-STM-1-L1.2 SFP STM-1 Module XCVR,SFP,1550nm,OC3,SM,80km,W.DDM
Long Haul 1550nm
AO-0118-0 SFP-STM-1- SFP STM-1 Module XCVR,SFP,1310nm,OC3,MM,2km,W.DDM
MM_1310 Multi Mode 1310nm
AO-0072-0 SFP-STM-1-S1.1 SFP STM-1 Module XCVR,SFP,1310nm,OC3,SM,15km,W.DDM
Short Haul 1310nm
Note: Ceragon recommends the use of SFP modules certified by

Ceragon, as listed above.
Page 451 of 468

9.11 Mechanical Specifications

Table 197: IDU Chassis Mechanical Specifications
1RU Chassis Dimensions Height: 44.5 mm

Width: 444.3 mm
Depth: 245 mm
Weight: 3 kg (empty)
2RU Chassis Dimensions Height: 88 mm
Width: 444.3 mm
Depth: 245 mm
Weight: 6 kg (empty)
IDU-RFU Connection See IDU-RFU Cable Connection on page 462.
Table 198: IDU Card and Tray Weights
PDC 0.3 kg
RIC 0.5 kg
RMC 0.5 kg
LIC 0.5 kg
TCC 1.5
Fans Drawer (1RU) 0.3 kg
Fans Drawer (2RU) 0.6 kg
Table 199: RFU-C Mechanical Specifications
RFU-C Dimensions Height: 200 mm

Width: 200 mm
Depth: 85 mm
Weight: 4kg/9 lbs.
RFU-C Standard Mounting OD Pole 50 mm-120 mm/2”-4.5” (subject to vendor and
antenna size)
Page 452 of 468

Table 200: 1500HP/RFUHP Mechanical Specifications
1500HP/RFU-HP Dimensions Height: 490 mm

Width: 144 mm
Depth: 280 mm
Weight: 7 kg (excluding Branching)
1500HP/RFU-HP OCB Branching Height: 420 mm
(Split Mount and Compact All- Width: 110 mm
Indoor)
Depth: 380 mm
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
Table 201: RFU-D Mechanical Specifications (including diplexer unit)
RFU-D Dimensions Height: 230 mm

Width: 233 mm
Depth: 98 mm
Weight: 6.5 kg
Table 202: RFU-D-HP Mechanical Specifications (including diplexer or OCU unit)
RFU-D-HP Dimensions Height: 319 mm

Width: 286 mm
Depth: 107 mm
Weight: 12 kg
Table 203: RFU-E Mechanical Specifications
RFU-E Dimensions Height: 220 mm

Width: 198 mm
Depth: 75 mm
Weight: 3 kg
Table 204: RFU-S Mechanical Specifications
RFU-S Dimensions Height: 217 mm

Width: 210 mm
Depth: 85 mm
Weight: 4 kg
Page 453 of 468

9.12 Environmental Specifications
9.12.1 Environmental Specifications for IDU

• Temperature:
 -5C to 55 – Temperature range for continuous operating temperature with high
reliability.
 -25C to 65C – Temperature range for exceptional temperatures, tested
successfully, with limited margins.
Note: Cold startup requires at least -5C.
• Humidity: 5%RH to 95%RH
9.12.2 Environmental Specifications for RFU

• Temperature:
 -33C to +55C – Temperature range for continuous operating temperature with
high reliability:
 -45C to +60C – Temperature range for exceptional temperatures; tested
successfully, with limited margins:
• Humidity: 5%RH to 100%RH
Page 454 of 468

9.13 Supported Antenna Types

RFUs can be installed using Direct Mount antennas or Remote Mount antennas,
depending on the RFU type and the configuration used.
The following table shows the antenna types supported by the various Ceragon
RFUs.
Note: Support of Direct Mount or Remote Mount per RFU is band and
configuration dependent.
Table 205: Supported Antenna Types per RFU
RFU Integrated Antenna Direct Mount Support Remote Mount Support
RFU-D – All Supported Bands All Supported Bands
RFU-D-HP – All Supported Bands All Supported Bands
RFU-E E-Band E-Band –
RFU-S – All Supported Bands All Supported Bands
RFU-C – All Supported Bands All Supported Bands
1500HP/RFU-HP – – All Supported Bands
9.13.1.1 Direct Mount Antennas

The microwave RFUs can be mounted directly on the antenna using the following
antenna vendors:
• Ceragon
• RFS
• CommScope
• Xian Putian
• Radio Waves
9.13.1.2 Remote Mount Antennas

The microwave RFUs can be used with standard interface antennas using the
following antenna vendors:
• Ceragon
• RFS
• CommScope
• Xian Putian
• Radio Waves
For specific antenna requirements applicable to 1500HP/RFU-HP, see
1500HP/RFU-HP Antenna Interface Requirements on page 459
Page 455 of 468

9.13.2 RFU-E Antenna Connection

RFU-E uses two types of antennas:
• Integrated 43 dBi Class 2 antenna
• Direct Mount antenna.
9.13.2.1 RFU-E Integrated Antenna

The following table describes the electrical parameters of the RFU-E integrated
antenna.
Table 206: RFU-E Integrated Antenna – Electrical Parameters
Frequency coverage 71-76 GHz, 81-86 GHz

Gain 71-76 GHz: 43dBi
81-86 GHz: 44.5dBi
3dB beam width (azimuth and 1.0°
elevation)
XPOL 30 dB
Polarization Single Linear: V or H
Co/cross-polar ratio >35dB
Front to back ratio >60dB
Side lobe suppression ETSI EN 302 217-4 v2.1.1 (2017-05) CLASS 3
FCC 47CFR101.115
9.13.2.2 Direct Mount Antenna

The Direct Mount antenna interface is according to:
Waveguide Standard Antenna Flange
WR12 UG387/U
Page 456 of 468

9.14 Waveguide Specifications
9.14.1 RFU-D and RFU-S Waveguide Specifications
Table 207: RFU-D and RFU-S – Waveguide Flanges
Frequency (GHz) Waveguide Standard Waveguide Flange Antenna Flange
6 WR137 PDR70 UDR70

7/8 WR112 PBR84 UBR84
10/11 WR90 PBR100 UBR100
13 WR75 PBR120 UBR120
15 WR62 PBR140 UBR140
18-26 WR42 PBR220 UBR220
28-38 WR28 PBR320 UBR320
42 WR22 UG383/U UG383/U
60 WR15 UG385/U UG385/U
80 WR12 UG387/U UG387/U
9.14.2 RFU-D-HP Waveguide Specifications – Split Mount Configurations
Table 208: RFU-D-HP – Waveguide Flanges for Split Mount Configurations
Frequency Band Range (GHz) Rect. WG Flange Des. Radio Side (Remote) Flange Des.
4 GHz 3.6-4.2 WR229 UDR40

5 GHz 4.4-5.0 WR187 UDR48
6(L/U) GHz 5.8-7.1 WR137 UDR7070
7/8 GHz 7.1-8.5 WR112 UBR8470
10/11 GHz 10.0-11.7 WR90 UBR10070
70
There is no direct WG connection. An adaptor is required to connect the RFU to the WG.
Page 457 of 468

9.14.3 RFU-D-HP Waveguide Specifications – All Indoor Configurations
Table 209: RFU-D-HP – Waveguide Flanges for All-Indoor Configurations
Frequency Band Range (GHz) Rect. WG Flange Des. Radio Side (Remote) Flange Des.
4 GHz 3.6-4.2 WR229 UDR40

5 GHz 4.4-5.0 WR187 UDR48
6(L/U) GHz 5.8-7.1 WR137 UDR70
7/8 GHz 7.1-8.5 WR112 UDR84
10/11 GHz 10.0-11.7 WR90 UDR100
9.14.4 RFU-C Waveguide Specifications

For remote mount installations, the following flexible waveguide flanges should
be used (millimetric). The same antenna type (integrated) as indicated above can
be used (recommended).
Other antenna types using the flanges listed in the table below may be used.
Table 210: RFU-C – Waveguide Flanges
Frequency (GHz) Waveguide Standard Waveguide Flange Antenna Flange
6 WR137 PDR70 UDR70

7/8 WR112 PBR84 UBR84
10/11 WR90 PBR100 UBR100
13 WR75 PBR120 UBR120
15 WR62 PBR140 UBR140
18-26 WR42 PBR220 UBR220
28-38 WR28 PBR320 UBR320
42 WR22 UG383/U UG383/U
If a different antenna type (CPR flange) is used, a flange adaptor is required.
Page 458 of 468

9.14.5 1500HP/RFU-HP Waveguide Specifications

The radio output port (C – Carrier) is frequency dependent, and is terminated with
the following waveguide flanges:
Table 211: 1500HP/RFU-HP – Waveguide Flanges
Frequency Band (GHz) Waveguide Flanges
6L CPR137
6H CPR137
7 CPR112
8 CPR112
11 CPR90
9.14.6 1500HP/RFU-HP Antenna Interface Requirements

The following table summarizes the return loss requirements for the antennas.
The return loss figures listed below are measured at the antenna’s waveguide
interface (C, C’ Points) of the system.
Table 212: 1500HP/RFU-HP Antenna Interface Requirements
Installation Type No of Carriers
1 2 3 4 5 6 7 8 9 10
All Indoor (dB) 26 26 26 26 26 26 26 26 26 26

Split Mount dB) 17 17 17 17 17 17 17 17 17 17
Page 459 of 468

9.15 Power Input Specifications

Table 213: Power Input Specifications
IDU Standard Input -48 VDC

IDU DC Input range -40 to --60 VDC, with maximum current of up to
15A (1RU chassis) or 30A (2RU chassis).
RFU-C Operating Range -40.5 to -59 VDC
RFU-HP Operating Range -40.5 to -59 VDC
RFU-S Operating Range -40.5 to -59 VDC
RFU-D Operating Range -40.5 to -59 VDC
RFU-D-HP Operating Range -40.5 to -59 VDC
RFU-E Operating Range -40.5 to -59 VDC
Page 460 of 468

9.16 Power Consumption Specifications

The following table shows the maximum power consumption for each card in an
IP-20N chassis. The maximum power consumption for the entire system is the
sum of the modules in the chassis and the RFUs operating from the chassis.
Table 214: Power Consumption Specifications
Card Type/Configuration Power (W) Comments
TCC 25W
RIC-D 12W
RMC-A/RMC-B 17W
LIC-X-E4-Elec (4x GbE) 9W
LIC-X-E4-Opt (4x GbE) 9W
LIC-X-E10 (1x 10G) 12W
LIC-T16 (16x E1) 17W
LIC-T155 (1x ch-STM-1) 25W
LIC-STM1/OC3-RST (1 x STM-1) 9W
Fan – 2RU Chassis 30W max (6W typical at 25°C) Kinetic energy.
Fan – 1RU Chassis 6W max (4W typical at 25°C) Kinetic energy.
1500HP Max Bias: 85W
Min Bias: 72W RFU only
Mute: 29W
RFU-HP 6-8 GHz Max Bias: 73W
Mid Bias: 48W
Min Bias: 34W
Mute: 18W RFU only
11 GHz Max Bias: 74W
Min Bias: 64W
Mute: 21W
RFU-C 6-26 GHz 1+0: 22
RFU only.
1+1: 39
28-42 GHz 1+0: 26
RFU only.
1+1: 43
RFU-D (2+0) 75W RFU only
RFU-D-HP (2+0) 130W RFU only
RFU-E 43W RFU only
RFU-S 43W RFU only
Page 461 of 468

9.17 IDU-RFU Cable Connection

RFU-C and RFU-HP/1500HP RFUs are connected to the RMC by a coaxial cable RG-
223 (up to 100 m/300 ft), Belden 9914/RG-8 (up to 300 m/1000 ft) or equivalent,
with an N-type connector (male) on the RFU and a TNC connector on the RMC in
the IP-20N chassis.
An RFU-S, RFU-E, RFU-D, and RFU-D-HP can be connected to a RIC-D via a
standard CAT-5e or preferably CAT-6/6a cable, with RJ-45 connectors on the RFU
and an RJ-45 connector on the RIC-D. They can also be connected to the RIC-D
over optical fiber cables via the optical (SFP) RFU interface on the RIC-D.
For an RFU-D, RFU-E, or RFU-S connecting to an electrical RFU interface, the cable
can carry both the data and the DC power required for the RFU.
For an RFU-D, RFU-E, or RFU-S connecting to an optical RFU interface, and for an
RFU-D-HP connecting to either an electrical or an optical RFU interface, an
external DC power cable is required to supply power to the RFU.
Table 215: IDU-RFU Cable Connection
RFU Interface Cable Type Maximum Length

6-11 GHz 13-42 GHz
Optical Fiber 300m
CAT-5e (24 AWG) 65m 100m
Electrical
RFU-D CAT-6a (22 AWG) 110m 150m
DC (18 AWG) 100m
DC Power
DC (12 AWG) 101m-300m
Optical Fiber 300m
CAT-5e (24 AWG) 130m 150m
Electrical
RFU-S CAT-6a (22 AWG) 150m 150m
DC (18 AWG) 150m
DC Power
DC (14 AWG) 151m-300m
Optical Fiber 300m
CAT-5e (24 AWG) 150m
Electrical
RFU-D-HP CAT-6a (22 AWG) 150m
DC (14 AWG) 100m
DC Power
DC (10 AWG) 101m-300m
Optical Fiber 300m
CAT-5e (24 AWG) 130m
Electrical
RFU-E CAT-6a (22 AWG) 150m
DC (18 AWG) 150m
DC Power
DC (14 AWG) 151m-300m
Page 462 of 468

10. Annex 1: RFU-HP Transmit Power and RSL at Radio

Ports
The Transmit Power and Receive Threshold Levels shown in this Annex refer to
the Transmit Power and Receive Threshold Levels as they may be measured at the
Tx Port (Port A’) and Rx Port (Port A) of the RFU.
For Transmit Power values as measured at the Antenna Port of the OCB (Port C’-
C) in a 1+0 configuration, see Transmit Power with 1500HP/RFU-HP (dBm) on
page 389.
For RSL values as measured at the Antenna Port of the OCB (Port C’-C) in a 1+0
configuration, see Receiver Thresholds with RFU-HP on page 403 and Receiver
Thresholds with 1500HP on page 405.
10.1 Transmit Power Specifications (dBm)

The Transmit Power values shown in the tables below refers to the Transmit
Power levels at the Tx Port of the RFU (Port A’).
The Transmit Power values shown in the Web EMS or NMS refer to the Tx Power
as measured at the Antenna Port (Port C’) of the OCB at a 1+0 configuration and
may be up to 2 dB lower than then the values shown in the following tables.
The following table provides transmit power specifications for RFU-HP 1RX (dBm).
Table 216: Transmit Power Specifications for RFU-HP 1RX (dBm)
Modulation 6L&H GHz 7 GHz 8 GHz 11 GHz71
QPSK 34.5 34.5 34.5 30.5

8 PSK 34.5 34.5 34.5 30.5
16 QAM 34.5 34.5 34.5 30.5
32 QAM 34.5 34.5 34.5 30.5
64 QAM 33.5 33.5 33.5 30.5
128 QAM 32.5 32.5 32.5 29.5
256 QAM 31.5 31.5 31.5 28.5
512 QAM 29.5 29.5 29.5 26.5
1024 QAM 28.5 28.5 28.5 26.5
2048 QAM 26.5 26.5 26.5 24.5
71
1500HP only.
Page 463 of 468

The following table provides transmit power specifications for RFU-HP 2RX
(1500HP) (dBm).
Table 217: Transmit power specifications for RFU-HP 2RX (1500HP) (dBm)
Modulation 6L&H GHz 7 GHz 8 GHz 11 GHz
QPSK 34.5 34.5 34.5 30.5

8 PSK 34.5 34.5 34.5 30.5
16 QAM 34.5 34.5 34.5 30.5
32 QAM 34.5 34.5 34.5 30.5
64 QAM 34.5 34.5 34.5 30.5
128 QAM 33.5 33.5 33.5 29.5
256 QAM 32.5 32.5 32.5 28.5
512 QAM 30.5 30.5 30.5 26.5
1024 QAM 29.5 29.5 29.5 26.5
2048 QAM 27.5 27.5 27.5 24.572
• 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.
For System Gain calculations, use the Transmit Power
specifications as listed in Section 9.3.1 and the branching losses
as listed in 1500HP/RFU-HP Branching Network Losses on
page 442.
72
1500HP only.
Page 464 of 468

10.2 Receiver Threshold Specifications

The Receiver Threshold values shown in the tables below refers to the Receiver
Threshold levels at the Rx Port of the RFU (Port A).
Note: The values listed in this section are typical. Actual values may differ in
either direction by up to 1dB.
For System Gain calculations, please use the Transmit Power
specifications as listed in Section 9.5 and the branching losses as listed
in Mediation Device and Branching Network Losses on page 436.
10.2.1 Receiver Threshold – RFU-HP
Table 218: Receiver Threshold – RFU-HP
Profile Modulation Channel Frequency (GHz)

Spacing
6 7 8 11
0 QPSK 14 MHz -93 -92.5 -92.5 -92.5

1 8 PSK -87 -86.5 -86.5 -86.5
2 16 QAM -86 -85.5 -85.5 -85.5
3 32 QAM -83 -82.5 -82.5 -82.5
4 64 QAM -80 -79.5 -79.5 -79.5
5 128 QAM -76.5 -76 -76 -76
6 256 QAM -74 -73.5 -73.5 -73.5
7 512 QAM -71 -70.5 -70.5 -70.5
8 1024 QAM (strong FEC) -68 -67.5 -67.5 -67.5
9 1024 QAM (light FEC) -67.5 -67 -67 -67
0 QPSK 28 MHz -90 -89.5 -89.5 -89.5
1 8 PSK -85.5 -85 -85 -85
2 16 QAM -83.5 -83 -83 -83
3 32 QAM -80 -79.5 -79.5 -79.5
4 64 QAM -77 -76.5 -76.5 -76.5
5 128 QAM -74 -73.5 -73.5 -73.5
6 256 QAM -71 -70.5 -70.5 -70.5
7 512 QAM -68.5 -68 -68 -68
8 1024 QAM (strong FEC) -65.5 -65 -65 -65
9 1024 QAM (light FEC) -64.5 -64 -64 -64
Page 465 of 468


Spacing
6 7 8 11
10 2048 QAM -61 -60.5 -60.5 -60.5
0 QPSK 40 MHz -88.5 -88 -88 -88

1 8 PSK -83.5 -83 -83 -83
2 16 QAM -82 -81.5 -81.5 -81.5
3 32 QAM -78.5 -78 -78 -78
4 64 QAM -75.5 -75 -75 -75
5 128 QAM -72.5 -72 -72 -72
6 256 QAM -69.5 -69 -69 -69
7 512 QAM -66.5 -66 -66 -66
8 1024 QAM (strong FEC) -64 -63.5 -63.5 -63.5
9 1024 QAM (light FEC) -63 -62.5 -62.5 -62.5
10 2048 QAM -60.5 -60 -60 -60
0 QPSK 56 MHz -86.5 -86 -86 -

1 8 PSK -82.5 -82 -82 -
2 16 QAM -80 -79.5 -79.5 -
3 32 QAM -77 -76.5 -76.5 -
4 64 QAM -73.5 -73 -73 -
5 128 QAM -71 -70.5 -70.5 -
6 256 QAM -67.5 -67 -67 -
7 512 QAM -65.5 -65 -65 -
8 1024 QAM (strong FEC) -62 -61.5 -61.5 -
9 1024 QAM (light FEC) -61 -60.5 -60.5 -
10 2048 QAM -56.5 -56 -56 -
Page 466 of 468

10.2.2 Receiver Threshold – 1500HP
Table 219: Receiver Threshold – 1500HP

Spacing
6 7 8 11
0 QPSK 14 MHz -92.5 -92.5 -92.5 -92.5

1 8 PSK -86.5 -86.5 -86.5 -86.5
2 16 QAM -85.5 -85.5 -85.5 -85.5
3 32 QAM -82.5 -82.5 -82.5 -82.5
4 64 QAM -79.5 -79.5 -79.5 -79.5
5 128 QAM -76 -76 -76 -76
6 256 QAM -73.5 -73.5 -73.5 -73.5
7 512 QAM -70.5 -70.5 -70.5 -70.5
8 1024 QAM (strong FEC) -67.5 -67.5 -67.5 -67.5
9 1024 QAM (light FEC) -67 -67 -67 -67
0 QPSK 28 MHz -89.5 -89.5 -89.5 -89.5
1 8 PSK -85 -85 -85 -85
2 16 QAM -83 -83 -83 -83
3 32 QAM -79.5 -79.5 -79.5 -79.5
4 64 QAM -76.5 -76.5 -76.5 -76.5
5 128 QAM -73.5 -73.5 -73.5 -73.5
6 256 QAM -70.5 -70.5 -70.5 -70.5
7 512 QAM -68 -68 -68 -68
8 1024 QAM (strong FEC) -65 -65 -65 -65
9 1024 QAM (light FEC) -64 -64 -64 -64
10 2048 QAM -60.5 -60.5 -60.5 -60.5
Page 467 of 468


Spacing
6 7 8 11
0 QPSK 40 MHz -88 -88 -88 -88

1 8 PSK -83 -83 -83 -83
2 16 QAM -81.5 -81.5 -81.5 -81.5
3 32 QAM -78 -78 -78 -78
4 64 QAM -75 -75 -75 -75
5 128 QAM -72 -72 -72 -72
6 256 QAM -69 -69 -69 -69
7 512 QAM -66 -66 -66 -66
8 1024 QAM (strong FEC) -63.5 -63.5 -63.5 -63.5
9 1024 QAM (light FEC) -62.5 -62.5 -62.5 -62.5
10 2048 QAM -60 -60 -60 -60
Page 468 of 468

Ceragon FibeAir IP 20N Technical Description 10.9 Rev A.04

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ceragon FibeAir IP 20N Technical Description 10.9 Rev A.04

Uploaded by

Copyright:

Available Formats

Technical Description

August 2019 | Rev A.04

Open Source Statement

Ceragon Proprietary and Confidential

3. IDU Hardware Description ....................................................................................... 41

4. RFU Hardware Description and Branching Options ................................................... 81

Ceragon Proprietary and Confidential

4.3 RFU-D ......................................................................................................................................... 84

5. Activation Keys ..................................................................................................... 139

6. Feature Description............................................................................................... 147

Ceragon Proprietary and Confidential

6.1.1 Capacity Summary ...................................................................................................................149

7. FibeAir IP-20N Management ................................................................................. 317

Ceragon Proprietary and Confidential

7.4 Web-Based Element Management System (Web EMS) ..........................................................322

8. Standards and Certifications .................................................................................. 337

Ceragon Proprietary and Confidential

9.2.4 MRMC Scripts Supported with RMC-A.....................................................................................349

Ceragon Proprietary and Confidential

9.10.4 Electrical STM-1 SFP Interface Specifications ..........................................................................450

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Figure 35: LIC-T155 (1 x ch-STM-1) ........................................................................................................73

Ceragon Proprietary and Confidential

Figure 70: RFU-E Functional Block Diagram – 1+0 Configuration ........................................................113

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Figure 140: Management Service and its Service Points .....................................................................220

Ceragon Proprietary and Confidential

Figure 175: Transparent Clock – General Architecture ........................................................................293

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Table 35: RFU-D-HP All-Indoor Marketing Model Structure ----------------------------------------------------- 110

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Table 105: Radio Capacity for 112 MHz ------------------------------------------------------------------------------- 362

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

About This Guide

What You Should Know

Ceragon Proprietary and Confidential

1. Synonyms and Acronyms

Acronym Equivalent Term

ACM Adaptive Coding and Modulation

Ceragon Proprietary and Confidential

Acronym Equivalent Term

GMT Greenwich Mean Time

Ceragon Proprietary and Confidential

Acronym Equivalent Term

PN Provider Network (Port)

Ceragon Proprietary and Confidential

Acronym Equivalent Term

Web EMS Web-Based Element Management System

Ceragon Proprietary and Confidential

This chapter includes:

Ceragon Proprietary and Confidential

2.1 Product Overview

Ceragon Proprietary and Confidential

2.1.1 IP-20N Radio Options

Ceragon Proprietary and Confidential

2.1.2 IP-20N Hardware Options and Scalability