Ceragon Technical Description IP 20N IP 20A 1 259

Technical Description
IP-20N
IP-20A
Standard-Power Backhaul
Solutions
March 2022 | Rev A.02
CeraOS: 11.9.5
© Copyright 2022 by Ceragon Networks Ltd. All rights reserved.
Technical Description for IP-20N, and IP-20A, CeraOS 11.9.5
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 518
Ceragon Proprietary and Confidential

Table of Contents
1. Synonyms and Acronyms ........................................................................................ 23
2. Introduction............................................................................................................ 27
2.1 Product Overview ...................................................................................................................... 29
2.1.1 IP-20N Radio Options ................................................................................................................. 30
2.1.2 IP-20N IDU Hardware Options and Scalability ........................................................................... 31
2.1.3 Interoperability with other Ceragon Products ........................................................................... 34
2.1.4 Supported Radio Configurations ................................................................................................ 35
2.1.5 No-Single-Point-of-Failure Architecture .................................................................................... 51
2.2 IP-20 Assured Platform .............................................................................................................. 52
2.3 New Features in CeraOS 11.9.5 ................................................................................................. 53
3. IDU Hardware Description ....................................................................................... 54

3.1 Hardware Architecture .............................................................................................................. 56
3.2 Front Panel Description ............................................................................................................. 61
3.3 Chassis Slots and Card Population Guidelines ........................................................................... 63
3.3.1 Card Types Per Slot .................................................................................................................... 63
3.3.2 TCC GbE Interface Limitations.................................................................................................... 65
3.3.3 Adjacent Pair Guidelines ............................................................................................................ 66
3.3.4 Slot Sections and 2.5 Gbps Mode .............................................................................................. 67
3.3.5 Additional Slot Guidelines .......................................................................................................... 69
3.3.6 Sample Chassis Configurations .................................................................................................. 70
3.4 Traffic Control Cards (TCC) ......................................................................................................... 78
3.4.1 TCC-U Interfaces ........................................................................................................................ 80
3.4.2 TCC-B2/TCC-B2-XG-MC Interfaces ............................................................................................. 81
3.4.3 TCC-B/TCC-B-MC Interfaces ....................................................................................................... 82
3.4.4 Management Interfaces for TCC-U, TCC-B2-XG-MC, and TCC-B2 .............................................. 82
3.4.5 TCC LED ...................................................................................................................................... 83
3.4.6 TCC Summary ............................................................................................................................. 84
3.4.7 TCC Redundancy ........................................................................................................................ 85
3.5 Radio Interface Cards (RIC) ........................................................................................................ 87
3.6 Radio Modem Cards (RMC) ........................................................................................................ 89
3.7 Ethernet Line Cards (LIC-X) ........................................................................................................ 90
3.7.1 10G Interface Protection............................................................................................................ 92
3.8 TDM Line Cards (LIC-T) ............................................................................................................... 93
3.9 Power Distribution Cards (PDC) ................................................................................................. 95
3.10 Inventory Module (IVM) ............................................................................................................ 98
3.11 Fans Module .............................................................................................................................. 99
3.12 Filter Tray (Optional) ................................................................................................................100
Page 3 of 518

4. RFU Hardware Description and Branching Options ................................................. 101

4.1 RFU Overview...........................................................................................................................102
4.2 RFU Selection Guide .................................................................................................................103
4.3 RFU-D .......................................................................................................................................104
4.3.1 Main Features of RFU-D ...........................................................................................................105
4.3.2 RFU-D Functional Block Diagram .............................................................................................105
4.3.3 RFU-D Radio Interfaces ............................................................................................................106
4.3.4 RFU-D Marketing Models .........................................................................................................108
4.3.5 RFU-D MultiCore Mediation Devices (MCMD) .........................................................................111
4.4 RFU-E ........................................................................................................................................113
4.4.1 Main Features of RFU-E ...........................................................................................................113
4.4.2 RFU-E Functional Block Diagram ..............................................................................................113
4.4.3 RFU-E Radio Interfaces .............................................................................................................115
4.4.4 RFU-E Marketing Models .........................................................................................................116
4.5 RFU-S ........................................................................................................................................117
4.5.1 Main Features of RFU-S ...........................................................................................................117
4.5.2 RFU-S Functional Block Diagram ..............................................................................................117
4.5.3 RFU-S Interfaces .......................................................................................................................118
4.5.4 RFU-S Marketing Models .........................................................................................................119
4.5.5 RFU-S Mediation Devices .........................................................................................................123
4.6 RFU-C .......................................................................................................................................124
4.6.1 Main Features of RFU-C ...........................................................................................................124
4.6.2 RFU-C Functional Block Diagram ..............................................................................................125
5. Activation Keys ..................................................................................................... 126

5.1 Working with Activation Keys ..................................................................................................126
5.2 Demo Mode .............................................................................................................................126
5.3 Activation Key Reclaim .............................................................................................................127
5.4 Activation Key-Enabled Features .............................................................................................127
6. Feature Description............................................................................................... 134

6.1 Innovative Techniques to Boost Capacity and Reduce Latency ...............................................135
6.1.1 Capacity Summary ...................................................................................................................136
6.1.2 Unique MultiCore Architecture of RFU-D ................................................................................137
6.1.3 Header De-Duplication.............................................................................................................142
6.1.4 Latency .....................................................................................................................................144
6.1.5 Frame Cut-Through ..................................................................................................................145
6.2 Radio Features .........................................................................................................................147
6.2.1 Hybrid Multi-Carrier Adaptive Bandwidth Control (Hybrid MC-ABC) ......................................148
6.2.2 Space Diversity .........................................................................................................................157
6.2.3 HSB Protection .........................................................................................................................167
6.2.4 Adaptive Coding Modulation (ACM) ........................................................................................173
6.2.5 Cross Polarization Interference Canceller (XPIC) .....................................................................181
6.2.5.2 XPIC-Ready MultiCore 1+0 Links ..............................................................................................182
Page 4 of 518

6.2.6 Layer 1 Link Bonding ................................................................................................................186

6.2.7 Multiband.................................................................................................................................189
6.2.8 ATPC .........................................................................................................................................190
6.2.9 Radio Signal Quality PMs .........................................................................................................192
6.2.10 Radio Utilization PMs ...............................................................................................................192
6.3 Ethernet Features ....................................................................................................................193
6.3.1 Ethernet Services Overview .....................................................................................................194
6.3.2 Ethernet Capabilities ................................................................................................................210
6.3.3 Supported Standards ...............................................................................................................211
6.3.4 Ethernet Service Model ...........................................................................................................212
6.3.5 Ethernet Interfaces ..................................................................................................................230
6.3.6 Quality of Service (QoS) ...........................................................................................................242
6.3.7 Global Switch Configuration ....................................................................................................275
6.3.8 Automatic State Propagation and Link Loss Forwarding .........................................................275
6.3.9 Network Resiliency ..................................................................................................................277
6.3.10 OAM .........................................................................................................................................283
6.4 Synchronization .......................................................................................................................288
6.4.1 Synchronization Overview .......................................................................................................288
6.4.2 IP-20N or IP-20A Synchronization Solution ..............................................................................290
6.4.3 Native Sync Distribution Mode ................................................................................................291
6.4.4 SyncE PRC Pipe Regenerator Mode .........................................................................................299
6.4.5 IEEE-1588v2 PTP Optimized Transport ....................................................................................300
6.5 TDM Services............................................................................................................................308
6.5.1 Native TDM Trails .....................................................................................................................309
6.5.2 TDM Pseudowire ......................................................................................................................314
6.5.3 STM-1/OC-3 Interfaces ............................................................................................................319
6.5.4 TDM Card and Interface Protection .........................................................................................320
6.5.5 TDM Reference Solutions ........................................................................................................323
6.6 Radio Payload Encryption and FIPS ..........................................................................................325
6.6.1 AES-256 Payload Encryption ....................................................................................................325
6.6.2 FIPS 140-2 Compliance .............................................................................................................328
7. Unit Management ................................................................................................. 330

7.1 Management Overview ...........................................................................................................331
7.2 Automatic Network Topology Discovery with LLDP Protocol ..................................................333
7.3 Management Communication Channels and Protocols ..........................................................334
7.4 Web-Based Element Management System (Web EMS) ..........................................................336
7.5 SDN Support .............................................................................................................................339
7.6 Command Line Interface (CLI) ..................................................................................................340
7.7 Slot Management and Card Configuration ..............................................................................340
7.8 Configuration Management .....................................................................................................340
7.9 Software Management ............................................................................................................341
7.9.1 Backup Software Version .........................................................................................................342
Page 5 of 518

7.10 CeraPlan Service for Creating Pre-Defined Configuration Files ...............................................342

7.11 IPv6 Support .............................................................................................................................343
7.12 In-Band Management ..............................................................................................................343
7.13 Local Management ..................................................................................................................343
7.14 Alarms ......................................................................................................................................344
7.14.1 Configurable BER Threshold Alarms and Traps ........................................................................344
7.14.2 RSL Threshold Alarm ................................................................................................................344
7.14.3 Editing and Disabling Alarms and Events .................................................................................344
7.14.4 Timeout for Trap Generation ...................................................................................................344
7.15 External Alarms ........................................................................................................................345
7.16 NTP Support .............................................................................................................................345
7.17 UTC Support .............................................................................................................................346
7.18 Syslog Support .........................................................................................................................346
7.19 System Security Features .........................................................................................................346
7.19.1 Ceragon’s Layered Security Concept........................................................................................347
7.19.2 Defenses in Management Communication Channels ..............................................................347
7.19.3 Defenses in User and System Authentication Procedures .......................................................348
7.19.4 Secure Communication Channels ............................................................................................352
7.19.5 Security Log ..............................................................................................................................354
7.19.6 Anti-Theft .................................................................................................................................356
8. Standards and Certifications .................................................................................. 357

8.1 Supported Ethernet Standards ................................................................................................358
8.2 MEF Certifications for Ethernet Services .................................................................................359
8.3 Supported TDM Pseudowire Encapsulations ...........................................................................360
8.4 Standards Compliance .............................................................................................................360
8.5 Network Management, Diagnostics, Status, and Alarms.........................................................361
9. Specifications........................................................................................................ 362
9.1 General Radio Specifications ...................................................................................................363
9.1.1 General Radio Specifications for Microwave RFUs ..................................................................363
9.1.2 General Radio Specifications for E-Band ..................................................................................364
9.2 Radio Scripts ............................................................................................................................365
9.2.1 MRMC Scripts Supported with RIC-D, with RFU-D and RFU-S .................................................366
9.2.2 MRMC Scripts Supported with RIC-D and RFU-E .....................................................................368
9.2.3 MRMC Scripts Supported with RMC-B .....................................................................................369
9.2.4 MRMC Scripts Supported with RMC-A.....................................................................................370
9.3 Radio Capacity Specifications ..................................................................................................371
9.3.1 Radio Capacity Specifications – ETSI Channels ........................................................................371
9.3.2 Radio Capacity Specifications – ANSI Channels .......................................................................408
9.4 Transmit Power Specifications (dBm) ......................................................................................437
Page 6 of 518

9.4.1 Transmit Power with RFU-D .....................................................................................................437

9.4.2 Transmit Power with RFU-S .....................................................................................................438
9.4.3 Transmit Power with RFU-E .....................................................................................................439
9.4.4 Transmit Power with RFU-C (dBm) ..........................................................................................440
9.5 Receiver Threshold Specifications ...........................................................................................441
9.5.1 Receiver Thresholds with RFU-D and RFU-S ............................................................................441
9.5.2 Receiver Thresholds with RFU-E ..............................................................................................455
9.5.3 Receiver Thresholds with RMC-B and RFU-C ...........................................................................456
9.5.4 Receiver Thresholds with RMC-A and RFU-C ...........................................................................462
9.5.5 Overload Thresholds ................................................................................................................463
9.6 Frequency Bands ......................................................................................................................464
9.6.1 Frequency Bands – RFU-D, RFU-S, and RFU-C ..........................................................................464
9.6.2 Frequency Bands – RFU-E ........................................................................................................476
9.7 Ethernet Latency Specifications ...............................................................................................477
9.7.1 Ethernet Latency with RIC-D, and RFU-D and RFU-S................................................................477
9.7.2 Ethernet Latency with RIC-D and RFU-E ..................................................................................488
9.7.3 Ethernet Latency with RMC-B ..................................................................................................491
9.7.4 Ethernet Latency with RMC-A ..................................................................................................497
9.8 Mediation Device and Branching Network Losses ...................................................................500
9.8.1 RFU-D Mediation Device Losses...............................................................................................500
9.8.2 RFU-E Mediation Device Losses ...............................................................................................501
9.8.3 RFU-S and RFU-C Mediation Device Losses .............................................................................501
9.9 Ethernet Specifications ............................................................................................................502
9.9.1 Ethernet Interface Specifications .............................................................................................502
9.9.2 Carrier Ethernet Functionality .................................................................................................503
9.9.3 Approved SFP Modules ............................................................................................................504
9.10 TDM Specifications ..................................................................................................................505
9.10.1 E1/DS1 Cross Connect ..............................................................................................................505
9.10.2 E1/DS1 Interface Specifications ...............................................................................................505
9.10.3 Pseudowire Specifications .......................................................................................................505
9.10.4 Electrical STM-1 SFP Interface Specifications ..........................................................................506
9.10.5 Electrical OC-3 SFP Interface Specifications .............................................................................506
9.10.6 Optical STM-1 SFP Interface Specifications .............................................................................506
9.10.7 Optical OC-3 SFP Interface Specifications ................................................................................508
9.10.8 Approved STM-1/OC-3 SFP Modules .......................................................................................509
9.11 Mechanical Specifications ........................................................................................................510
9.12 Environmental Specifications ...................................................................................................512
9.12.1 Environmental Specifications for IDU ......................................................................................512
9.12.2 Environmental Specifications for RFU ......................................................................................512
9.13 Supported Antenna Types .......................................................................................................513
9.13.1 Direct Mount Antennas ...........................................................................................................513
9.13.2 Remote Mount Antennas.........................................................................................................513
9.13.3 RFU-E Antenna Connection ......................................................................................................513
9.14 Waveguide Specifications ........................................................................................................515
Page 7 of 518

9.14.1 RFU-D and RFU-S Waveguide Specifications ............................................................................515

9.14.2 RFU-C Waveguide Specifications .............................................................................................515
9.15 Power Input Specifications ......................................................................................................516
9.16 Power Consumption Specifications .........................................................................................517
9.17 IDU-RFU Cable Connection ......................................................................................................518
Page 8 of 518

List of Figures
Figure 1: 16+0 Link Bonding with Four RIC-D Cards ...............................................................................42
Figure 2: 8+0 Link Bonding with BBC Space Diversity (Internal) ............................................................43
Figure 2: 2 x 6+0 Link Bonding with BBC Space Diversity (Internal) .......................................................44
Figure 2: 12+0 Link Bonding with BBC Space Diversity (Internal) ..........................................................45
Figure 1: 2 x 1+0 with a Single RIC-D ......................................................................................................46
Figure 1: N x 2+0 with a Single RIC-D .....................................................................................................46
Figure 1: TCC-Based and RFU-Based Multi-Carrier ABC .........................................................................47
Figure 1: 2+0 Space Diversity with a Single RIC-D ..................................................................................48
Figure 1: Multiband with Both RIC-D RFU Interfaces .............................................................................49
Figure 7: Two 2+2 HSB Groups with Two RIC-Ds ....................................................................................50
Figure 1: 1RU Chassis .............................................................................................................................54
Figure 22RU Chassis ...............................................................................................................................54
Figure 3: Chassis Management ..............................................................................................................57
Figure 4: Traffic Connectivity in 2RU Chassis with TCC Redundancy .....................................................58
Figure 5: IDU Block Diagram – 1RU Chassis............................................................................................59
Figure 6: IDU Block Diagram – 2RU Chassis with TCC and PDC Redundancy .........................................60
Figure 7: IDU Front Panel and Interfaces – 1RU Chassis ........................................................................61
Figure 8: IDU Front Panel and Interfaces – 2RU Chassis ........................................................................62
Figure 9: 1RU Chassis Slot Numbering ...................................................................................................63
Figure 10: 2RU Chassis Slot Numbering .................................................................................................63
Figure 11: 1RU Chassis – Slot Sections ...................................................................................................67
Figure 12: 2RU Chassis – Slot Sections ...................................................................................................68
Figure 13: Sample Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (1 Gbps) ....................................70
Figure 14: Sample Chassis Configuration – 4 x 2+0 Multi-Carrier ABC (1 Gbps) ....................................71
Figure 15: Sample Chassis Configuration – 2 x 2+0 Multi-Carrier ABC with RST (1 or 2.5 Gbps) ...........72
Figure 16: Sample Chassis Configuration – 1 x 8+0 Multi-Carrier ABC (2.5 Gbps) – TCC-B-MC or TCC-
B2-XG-MC ...............................................................................................................................................73
Figure 17: Sample Chassis Configuration – 1 x 8+0 Multi-Carrier ABC (2.5 Gbps) – TCC-U ...................73
Figure 18: Sample Chassis Configuration – 1 x 6+0 Multi-Carrier ABC with RST (2.5 Gbps) – TCC-B-MC
or TCC-B2-XG-MC ...................................................................................................................................75
Figure 19: Sample Chassis Configuration – 1 x 6+0 Multi-Carrier ABC with RST (2.5 Gbps) – TCC-U .....75
Figure 20: Sample Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (2.5 Gbps) – TCC-B-MC or TCC-
B2-XG-MC ...............................................................................................................................................76
Figure 21: Sample Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (2.5 Gbps) – TCC-U ...................76
Figure 22: TCC-U .....................................................................................................................................78
Page 9 of 518

Figure 23: TCC-B .....................................................................................................................................78

Figure 24: TCC-U Interfaces ....................................................................................................................80
Figure 25: TCC-B2/TCC-B2-XG-MC Interfaces ........................................................................................81
Figure 26: TCC-B and TCC-B-MC Interfaces ............................................................................................82
Figure 27: TCC-B2/TCC-B2-XG-MC Management Interface Pin Connections .........................................82
Figure 28: RIC-D ......................................................................................................................................87
Figure 29: RIC-D Interfaces .....................................................................................................................88
Figure 30: RMC-A ...................................................................................................................................89
Figure 31: RMC-B....................................................................................................................................89
Figure 32: RMC-A and RMC-B Interfaces................................................................................................89
Figure 33: LIC-X-E4-Elec (4x GbE) ...........................................................................................................90
Figure 34: LIC-X-E4-Opt (4x GbE) ............................................................................................................90
Figure 35: LIC-X-E10 (1x 10G) .................................................................................................................91
Figure 36: LIC-X-E4-Elec (4x GbE) Interfaces ..........................................................................................91
Figure 37: LIC-X-E4-Opt (4x GbE) Interfaces ...........................................................................................91
Figure 38: LIC-X-E10 (1x 10G) Interface .................................................................................................92
Figure 39: LIC-T16 (16 x E1/DS1) ............................................................................................................93
Figure 40: LIC-T155 (1 x ch-STM-1/OC-3) ...............................................................................................93
Figure 41: LIC-STM1/OC3-RST (1 x STM-1/OC-3) ...................................................................................93
Figure 42: LIC-T16 (16x E1/DS1) Interfaces ............................................................................................94
Figure 43: LIC-T155 (1 x ch-STM-1/OC-3) Interfaces ..............................................................................94
Figure 44: LIC-STM1/OC3-RST (1 x STM-1/OC-3) Interfaces ..................................................................94
Figure 45: Single-Input PDC ....................................................................................................................95
Figure 46: Dual-Input PDC ......................................................................................................................95
Figure 47: PDC – Functional Diagram .....................................................................................................96
Figure 48: Standard PDC Interfaces .......................................................................................................96
Figure 49: Dual-Input PDC Interfaces .....................................................................................................96
Figure 50: Power Distribution with Redundant PDCs ............................................................................97
Figure 51: Fans Module – 1RU ...............................................................................................................99
Figure 52: Fans Module – 2RU ...............................................................................................................99
Figure 53: Fans Module Diagram ...........................................................................................................99
Figure 54: Filter Tray Sliding into Filter Slot (2RU Chassis) ...................................................................100
Figure 55: RFU-D Functional Block Diagram – 2+0 Configuration ........................................................106
Figure 56: RFU-D Radio Interfaces (6 to 15 GHz) .................................................................................107
Figure 57: RFU-D Rear View (Left) and Front View (Right) ...................................................................107
Page 10 of 518

Figure 58: RFU-D Interfaces (All Frequency Bands)..............................................................................107

Figure 59: Radio Unit and Diplexer Unit ...............................................................................................109
Figure 60: Splitter .................................................................................................................................112
Figure 61: OMT .....................................................................................................................................112
Figure 62: RFU-E Functional Block Diagram – 1+0 Configuration ........................................................114
Figure 63: RFU-E Antenna Interfaces ...................................................................................................115
Figure 64: RFU-D Front Side Interfaces ................................................................................................115
Figure 65: RFU-E Interfaces ..................................................................................................................116
Figure 66: RFU-S Functional Block Diagram – 1+0 Configuration ........................................................118
Figure 67: RFU-S Front Side Interfaces .................................................................................................118
Figure 68: RFU-S Data and Power Interfaces .......................................................................................119
Figure 69: RFU-S Radio Unit and Diplexers Unit (Separate) .................................................................121
Figure 70: RFU-S Radio Unit and Diplexers Unit (Attached) .................................................................121
Figure 71: RFU-S Coupler/Splitter ........................................................................................................123
Figure 72: RFU-S OMT ..........................................................................................................................123
Figure 73: RFU-C Functional Block Diagram – 1+0 Configuration ........................................................125
Figure 74: RFU-D MultiCore Modem and RFIC Chipsets ......................................................................137
Figure 75: Performance Characteristics of Generic, 1+0 Single-Carrier Radio .....................................138
Figure 76: Doubling RFU-D’s Capacity by Activating Second Core .......................................................139
Figure 77: Header De-Duplication ........................................................................................................142
Figure 78: Header De-Duplication Potential Throughput Savings per Layer ........................................143
Figure 79: Propagation Delay with and without Frame Cut-Through ..................................................145
Figure 80: Frame Cut-Through .............................................................................................................146
Figure 81: Frame Cut-Through Operation ............................................................................................146
Figure 82: TCC-Based Multi-Carrier ABC Traffic Flow ...........................................................................149
Figure 83: Multi-Carrier ABC Minimum Bandwidth Override ..............................................................155
Figure 84: Direct and Reflected Signals ................................................................................................157
Figure 85: 2+0 BBC Space Diversity (External) .....................................................................................160
Figure 86: Sample Chassis Configuration – 2+0 BBC Space Diversity ...................................................162
Figure 87: Sample Chassis Configuration – 4+0 BBC Space Diversity ...................................................162
Figure 88: Sample Chassis Configuration – 2 X 2+0 BBC Space Diversity .............................................163
Figure 89: Sample Chassis Configuration – 2 X 4+0 BBC Space Diversity – TCC-B2-XG-MC .................164
Figure 90: Sample Chassis Configuration – 2 X 4+0 BBC Space Diversity – TCC-U ...............................165
Figure 91: BBS Space Diversity .............................................................................................................166
Figure 92: Path Loss on Secondary Path of 1+1 HSB Protection Link ...................................................168
Page 11 of 518

Figure 93: Adaptive Coding and Modulation with 13 Working Points .................................................176
Figure 94: ACM with Adaptive Power Contrasted to Other ACM Implementations ............................180
Figure 95: Dual Polarization .................................................................................................................181
Figure 96: XPIC Implementation – RFU-C .............................................................................................182
Figure 97: XPIC Implementation – RIC-D with RFU-D ...........................................................................183
Figure 98: XPIC – Impact of Misalignments and Channel Degradation ................................................183
Figure 99: Basic Ethernet Service Model ..............................................................................................194
Figure 100: Ethernet Virtual Connection (EVC) ....................................................................................195
Figure 101: Point to Point EVC .............................................................................................................196
Figure 102: Multipoint to Multipoint EVC ............................................................................................196
Figure 103: Rooted Multipoint EVC ......................................................................................................196
Figure 104: MEF Ethernet Services Definition Framework ..................................................................198
Figure 105: E-Line Service Type Using Point-to-Point EVC ...................................................................199
Figure 106: EPL Application Example ...................................................................................................200
Figure 107: EVPL Application Example .................................................................................................201
Figure 108: E-LAN Service Type Using Multipoint-to-Multipoint EVC ..................................................201
Figure 109: Adding a Site Using an E-Line service ................................................................................202
Figure 110: Adding a Site Using an E-LAN service ................................................................................202
Figure 111: MEF Ethernet Private LAN Example ..................................................................................203
Figure 112: MEF Ethernet Virtual Private LAN Example.......................................................................204
Figure 113: E-Tree Service Type Using Rooted-Multipoint EVC ...........................................................204
Figure 114: E-Tree Service Type Using Multiple Roots .........................................................................205
Figure 115: MEF Ethernet Private Tree Example .................................................................................206
Figure 116: Ethernet Virtual Private Tree Example ..............................................................................207
Figure 117: Mobile Backhaul Reference Model ...................................................................................207
Figure 118: Packet Service Core Building Blocks ..................................................................................208
Figure 119: IP-20N and IP-20A Services Model ....................................................................................212
Figure 120: Services Core .....................................................................................................................214
Figure 121: Services Flow .....................................................................................................................215
Figure 122: Point-to-Point Service .......................................................................................................216
Figure 123: Multipoint Service .............................................................................................................216
Figure 124: Management Service ........................................................................................................219
Figure 125: Management Service and its Service Points .....................................................................221
Figure 126: SAPs and SNPs ...................................................................................................................222
Figure 127: Pipe Service Points ............................................................................................................222
Page 12 of 518

Figure 128: SAP, SNP and Pipe Service Points in a Microwave Network .............................................223
Figure 129: Service Path Relationship on Point-to-Point Service Path ................................................227
Figure 130: Physical and Logical Interfaces ..........................................................................................230
Figure 131: Grouped Interfaces as a Single Logical Interface on Ingress Side .....................................231
Figure 132: Grouped Interfaces as a Single Logical Interface on Egress Side ......................................231
Figure 133: Relationship of Logical Interfaces to the Switching Fabric ................................................235
Figure 134: QoS Block Diagram ............................................................................................................242
Figure 135: Standard QoS and H-QoS Comparison ..............................................................................244
Figure 136: Hierarchical Classification – TCC-U ....................................................................................245
Figure 137: Hierarchical Classification – TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-MC ...........................245
Figure 138: Classification Method Priorities – TCC-U ...........................................................................246
Figure 139: Classification Method Priorities – TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-MC .................250
Figure 140: Ingress Policing Model ......................................................................................................255
Figure 141: Queue Manager ................................................................................................................259
Figure 142: Synchronized Packet Loss ..................................................................................................260
Figure 143: Random Packet Loss with Increased Capacity Utilization Using WRED ............................261
Figure 144: WRED Profile Curve ...........................................................................................................262
Figure 145: Scheduling Mechanism for a Single Service Bundle ..........................................................268
Figure 146: G.8032 Ring in Idle (Normal) State ....................................................................................278
Figure 147: G.8032 Ring in Protecting State ........................................................................................279
Figure 148: Load Balancing Example in G.8032 Ring ............................................................................279
Figure 149: IP-20N or IP-20A End-to-End Service Management ..........................................................283
Figure 150: SOAM Maintenance Entities (Example) ............................................................................284
Figure 151: Ethernet Line Interface Loopback – Application Examples ...............................................285
Figure 152: Native Sync Distribution Mode .........................................................................................291
Figure 153: Synchronization Configuration ..........................................................................................294
Figure 154: Native Sync Distribution Mode Usage Example ................................................................296
Figure 155: Native Sync Distribution Mode – Tree Scenario ................................................................297
Figure 156: Native Sync Distribution Mode – Ring Scenario (Normal Operation) ...............................297
Figure 157: Native Sync Distribution Mode – Ring Scenario (Link Failure) ..........................................298
Figure 158: Synchronous Ethernet (SyncE) ..........................................................................................299
Figure 159: IEEE-1588v2 PTP Optimized Transport – General Architecture ........................................300
Figure 160: Calculating the Propagation Delay for PTP Packets ..........................................................301
Figure 161: Transparent Clock – General Architecture ........................................................................304
Figure 162: Transparent Clock Delay Compensation ...........................................................................305
Page 13 of 518

Figure 163: Boundary Clock – General Architecture ............................................................................306

Figure 164: Hybrid Ethernet and TDM Services ...................................................................................308
Figure 165: Hybrid Ethernet and TDM Services Carried Over Cascading Interfaces ............................309
Figure 166: Hybrid Ethernet and Native TDM Services ........................................................................310
Figure 167: 1:1 TDM Path Protection – Ring Topology ........................................................................311
Figure 168: 1+1TDM Path Protection – Dual Homing Topology ..........................................................312
Figure 169: All-Packet Ethernet and TDM Pseudowire Services ..........................................................314
Figure 170: 1+1 HSB Card Protection for LIC-T16 (E1/DS1) Cards........................................................320
Figure 171: 1+1 HSB Protection for LIC-T155 (STM-1/OC-3) and LIC-STM1/OC3-RST Cards ...............321
Figure 172: Uni-directional MSP for LIC-T155 (STM-1/OC-3) Cards .....................................................322
Figure 173: Native TDM Trail Interoperability with Optical SDH/SONET Equipment ..........................323
Figure 174: Native TDM Trail Interoperability with TDM Pseudowire-over-Packet Aggregation ........323
Figure 175: TDM Pseudowire Interoperability with Optical SDH/SONET Equipment ..........................323
Figure 176: TDM Pseudowire Interoperability with Third-Party Packet Aggregation Equipment .......324
Figure 177: AES-256 Encrypted Link .....................................................................................................325
Figure 178: Integrated Management Tools ..........................................................................................332
Figure 179: Security Solution Architecture Concept ............................................................................347
Figure 180: Designated ETSI System Class Explanation........................................................................365
Page 14 of 518

List of Tables
Table 1: IP-20N/IP-20A 1RU and 2RU Scalability with TCC-U ------------------------------------------------------ 32
Table 2: IP-20N/IP-20A 1RU and 2RU Scalability---------------------------------------------------------------------- 33
Table 3: Interoperability with Other Ceragon Products------------------------------------------------------------- 34
Table 4: Radio Configuration Options for RFU-C ---------------------------------------------------------------------- 36
Table 5: Radio Configuration Options for RFU-D, RFU-E, or RFU-S with RIC-D ------------------------------- 38
Table 6: New Features in CeraOS 11.9.5 -------------------------------------------------------------------------------- 53
Table 7: Card Types Allowed Per Slot – 1RU --------------------------------------------------------------------------- 63
Table 8: Card Types Allowed Per Slot – 2RU --------------------------------------------------------------------------- 64
Table 9: Slot Limitations When Used with TCC-B2 or TCC-B2-XG-MC ------------------------------------------ 65
Table 10: Card Type Usage Per Section Capacity --------------------------------------------------------------------- 67
Table 11: Additional Slot Limitations with Multi-Carrier ABC ----------------------------------------------------- 69
Table 12: 2 x FE Splitter Cable Marketing Model --------------------------------------------------------------------- 83
Table 13: TCC Comparison Table ------------------------------------------------------------------------------------------ 84
Table 14: Y-Cable for Electrical Splitter Mode FE Traffic Interface Protection -------------------------------- 85
Table 15: Standard-Power RFU Selection Guide -------------------------------------------------------------------- 103
Table 16: RFU-D Interfaces ----------------------------------------------------------------------------------------------- 107
Table 17: RFU-D Marketing Model Structure, 6 to 15 GHz (Radio Unit) -------------------------------------- 108
Table 18: RFU-D Marketing Model Structure, 6 to 15 GHz (Diplexer Unit) ---------------------------------- 108
Table 19: RFU-D Marketing Model Structure– Possible Values (Easy Set - Radio Unit Only) ----------- 109
Table 20: RFU-D Marketing Model Structure– Possible Values (Easy Set - Diplexer Unit Only)-------- 109
Table 21: RFU-D Diplexer Unit Marketing Model Examples ----------------------------------------------------- 110
Table 22: RFU-D Marketing Model Structure,18 to 42 GHz ------------------------------------------------------ 110
Table 23: RFU-D Marketing Model Structure– Possible Values ------------------------------------------------- 110
Table 24: RFU-D Marketing Model Examples (18-42 GHz) ------------------------------------------------------- 111
Table 25: RFU-D Mediation Devices ------------------------------------------------------------------------------------ 111
Table 26: RFU-E Interfaces ------------------------------------------------------------------------------------------------ 116
Table 27: RFU-E Marketing Models ------------------------------------------------------------------------------------ 116
Table 28: RFU-S Interfaces ------------------------------------------------------------------------------------------------ 119
Table 29: RFU-S Marketing Model Syntax, 6 to 15 GHz (Radio Unit) ------------------------------------------ 120
Table 30: RFU-S Marketing Model Syntax, 6 to 15 GHz (Diplexer Unit) -------------------------------------- 120
Table 31: RFU-S Marketing Model Structure– Possible Values (Easy Set - Radio Unit Only)------------ 121
Table 32: : RFU-S Marketing Model Structure– Possible Values (Easy Set - Diplexer Unit Only) ------ 121
Table 33: RFU-S Diplexer Unit Marketing Model Example ------------------------------------------------------- 122
Table 34: RFU-S Marketing Model Structure,18 to 42 GHz ------------------------------------------------------ 122
Page 15 of 518

Table 35: RFU-S Marketing Model Structure– Possible Values ------------------------------------------------- 122
Table 36: RFU-S Marketing Model Examples (18-42 GHz) ------------------------------------------------------- 123
Table 37: Activation Key Types ------------------------------------------------------------------------------------------ 128
Table 38: Capacity Activation Key Levels ----------------------------------------------------------------------------- 131
Table 39: CET Node Activation Key Levels ---------------------------------------------------------------------------- 133
Table 40: Edge CET Note Upgrade Activation Keys ---------------------------------------------------------------- 133
Table 41: TCO Comparison Between Single-Carrier and MultiCore Systems-------------------------------- 141
Table 42: RIC-D Multi-Carrier ABC – RFU-Based vs. TCC-Based ------------------------------------------------- 151
Table 43: Space Diversity Methods ------------------------------------------------------------------------------------- 158
Table 44: ACM Working Points (Profiles) – RIC-D with Microwave RFUs ------------------------------------ 174
Table 45: ACM Working Points (Profiles) – RIC-D with E-Band RFU (RFU-E) -------------------------------- 174
Table 46: ACM Working Points (Profiles) – RMC-A ----------------------------------------------------------------- 175
Table 47: ACM Working Points (Profiles) – RMC-B ----------------------------------------------------------------- 175
Table 48: External XPIC Configurations-------------------------------------------------------------------------------- 185
Table 49: MEF-Defined Ethernet Service Types --------------------------------------------------------------------- 198
Table 50: Ethernet Services Learning and Forwarding ------------------------------------------------------------ 217
Table 51: Service Point Types per Service Type --------------------------------------------------------------------- 224
Table 52: Service Point Types that can Co-Exist on the Same Interface -------------------------------------- 225
Table 53: Service Point Type-Attached Interface Type Combinations that can Co-Exist on the Same
Interface ----------------------------------------------------------------------------------------------------------------------- 226
Table 54: MPLS EXP Default Mapping to CoS and Color – TCC-U ---------------------------------------------- 247
Table 55: DSCP Default Mapping to CoS and Color – TCC-U ----------------------------------------------------- 247
Table 56: C-VLAN 802.1 UP and CFI Default Mapping to CoS and Color – TCC-U -------------------------- 248
Table 57: S-VLAN 802.1 UP and DEI Default Mapping to CoS and Color – TCC-U -------------------------- 248
Table 58: C-VLAN 802.1 UP and CFI Default Mapping to CoS and Color – TCC-B, TCC-B2, TCC-B-MC,
TCC-B2-XG-MC --------------------------------------------------------------------------------------------------------------- 250
Table 59: S-VLAN 802.1 UP and DEI Default Mapping to CoS and Color – TCC-B, TCC-B2, TCC-B-MC,
TCC-B2-XG-MC --------------------------------------------------------------------------------------------------------------- 251
Table 60: MPLS EXP Default Mapping to CoS and Color – TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-MC251
Table 61: DSCP Default Mapping to CoS and Color – TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-MC ----- 252
Table 62: QoS Priority Profile Example -------------------------------------------------------------------------------- 269
Table 63: WFQ Profile Example------------------------------------------------------------------------------------------ 270
Table 64: 802.1q UP Marking Table (C-VLAN) ----------------------------------------------------------------------- 272
Table 65: 802.1ad UP Marking Table (S-VLAN) ---------------------------------------------------------------------- 273
Table 66: Summary and Comparison of Standard QoS and H-QoS -------------------------------------------- 274
Table 67: Native Sync Interface Options – ETSI Systems --------------------------------------------------------- 292
Page 16 of 518

Table 68: Native Sync Interface Options – ANSI Systems--------------------------------------------------------- 293

Table 69: Boundary Clock Input Options ------------------------------------------------------------------------------ 306
Table 70: Boundary Clock Output Options --------------------------------------------------------------------------- 306
Table 71: Y-Cable for LIC-T16 Card Protection ---------------------------------------------------------------------- 321
Table 72: FIPS-Compliant Marketing Models ------------------------------------------------------------------------ 329
Table 73: Dedicated Management Ports ------------------------------------------------------------------------------ 334
Table 74: Supported Ethernet Standards ----------------------------------------------------------------------------- 358
Table 75: Supported MEF Specifications ------------------------------------------------------------------------------ 359
Table 76: MEF Certifications --------------------------------------------------------------------------------------------- 359
Table 77: Radio Frequencies --------------------------------------------------------------------------------------------- 363
Table 78: General Radio Specifications – Microwave RFUs ------------------------------------------------------ 363
Table 79: Radio Frequencies and General Radio Specifications – RFU-E ------------------------------------- 364
Table 80: Frequency Tuning Range for RFU-E ----------------------------------------------------------------------- 364
Table 81: MRMC Scripts Supported with RIC-D, and RFU-D and RFU-S (Split-Mount) ------------------- 366
Table 82: MRMC Scripts Supported with RIC-D and RFU-E ------------------------------------------------------ 368
Table 84: MRMC Scripts Supported with RMC-B ------------------------------------------------------------------- 369
Table 85: MRMC Scripts Supported with RMC-A ------------------------------------------------------------------- 370
Table 86: Radio Capacity for 7 MHz ------------------------------------------------------------------------------------ 371
Table 87: Radio Capacity for 14 MHz ---------------------------------------------------------------------------------- 372
Table 100: Radio Capacity for 70 MHz --------------------------------------------------------------------------------- 385
Table 102: Radio Capacity for 112 MHz ------------------------------------------------------------------------------- 388
Page 17 of 518


Table 106: Radio Capacity for 62.5 MHz ------------------------------------------------------------------------------ 391
Table 110: Radio Capacity for 3.5 MHz – Script ID 1023 ---------------------------------------------------------- 393
Table 111: Radio Capacity for 7 MHz – Script ID 1008 ------------------------------------------------------------ 393
Table 112: Radio Capacity for 14 MHz – Script ID 1009----------------------------------------------------------- 394
Table 124: Radio Capacity for 7 MHz – Script ID 33 ---------------------------------------------------------------- 405
Table 125: Radio Capacity for 14 MHz – Script ID 23 -------------------------------------------------------------- 405
Page 18 of 518


Table 143: Radio Capacity for 62.5 MHz ------------------------------------------------------------------------------ 423
Table 147: Transmit power specifications for RFU-D (dBm) ----------------------------------------------------- 437
Table 148: Pmin Power for RFU-D -------------------------------------------------------------------------------------- 437
Table 149: Transmit power specifications for RFU-S (dBm) ----------------------------------------------------- 438
Table 150: Pmin Power for RFU-S --------------------------------------------------------------------------------------- 438
Table 151: Transmit power specifications for RFU-E (dBm) ----------------------------------------------------- 439
Table 152: Transmit Power with RFU-C (dBm) ---------------------------------------------------------------------- 440
Table 153: Pmin Power with RFU-C ------------------------------------------------------------------------------------ 440
Table 154: Receiver Thresholds with RFU-D and RFU-S (6-18 GHz) ------------------------------------------- 441
Table 155: Receiver Thresholds with RFU-D and RFU-S (23-42 GHz) ------------------------------------------ 447
Table 156: Receiver Thresholds with RFU-E -------------------------------------------------------------------------- 455
Table 157: Receiver Thresholds with RMC-B and RFU-C---------------------------------------------------------- 456
Table 158: Receiver Thresholds with RMC-A and RFU-C --------------------------------------------------------- 462
Table 159: Frequency Bands – RFU-D, RFU-S, and RFU-C -------------------------------------------------------- 464
Table 160: Frequency Bands – RFU-E ---------------------------------------------------------------------------------- 476
Table 161: Ethernet Latency with RIC-D and RFU-D – 7 MHz Channel Bandwidth ------------------------ 477
Table 162: Ethernet Latency with RIC-D and RFU-D and RFU-S – 14 MHz Channel Bandwidth -------- 478
Table 163: Ethernet Latency with RIC-D, and RFU-D and RFU-S – 25 MHz Channel Bandwidth ------- 479
Table 170: Ethernet Latency with RIC-D and RFU-D – 70 MHz Channel Bandwidth ---------------------- 486
Table 171: Ethernet Latency with RIC-D, and RFU-D and RFU-S – 112 MHz Channel Bandwidth ----- 487
Page 19 of 518

Table 172: Ethernet Latency with RIC-D and RFU-E – 14 MHz Channel Bandwidth ----------------------- 488
Table 173: Ethernet Latency with RIC-D and RFU-E – 28 MHz Channel Bandwidth ----------------------- 488
Table 174: Ethernet Latency with RIC-D and RFU-E – 62.5 MHz Channel Bandwidth -------------------- 489
Table 175: Ethernet Latency with RIC-D and RFU-E – 125 MHz Channel Bandwidth --------------------- 489
Table 178: Ethernet Latency with RMC-B – 3.5 MHz Channel Bandwidth ----------------------------------- 491
Table 179: Ethernet Latency with RMC-B – 5 MHz Channel Bandwidth-------------------------------------- 491
Table 180: Ethernet Latency with RMC-B – 7 MHz Channel Bandwidth-------------------------------------- 492
Table 181: Ethernet Latency with RMC-B – 10 MHz Channel Bandwidth ------------------------------------ 492
Table 191: Ethernet Latency with RMC-A – 14 MHz Channel Bandwidth ------------------------------------ 497
Table 194: Ethernet Latency with RMC-A – 40MHz Channel Bandwidth ------------------------------------ 499
Table 195: Ethernet Latency with RMC-A – 56MHz Channel Bandwidth ------------------------------------ 499
Table 196: RFU-D Mediation Device Losses -------------------------------------------------------------------------- 500
Table 197: RFU-E Mediation Device Losses -------------------------------------------------------------------------- 501
Table 198: RFU-C and RFU-S Mediation Device Losses ----------------------------------------------------------- 501
Table 199: Ethernet Interface Specifications ------------------------------------------------------------------------ 502
Table 200: Carrier Ethernet Functionality ---------------------------------------------------------------------------- 503
Table 201: Approved GbE SFP Modules ------------------------------------------------------------------------------- 504
Table 202: Approved 2.5 GbE SFP Modules -------------------------------------------------------------------------- 504
Table 203: Approved 10 GbE SFP Modules --------------------------------------------------------------------------- 504
Table 204: E1/DS1 Cross Connect -------------------------------------------------------------------------------------- 505
Table 205: Pseudowire Specifications --------------------------------------------------------------------------------- 505
Table 206: Electrical STM-1 SFP Interface Specifications --------------------------------------------------------- 506
Page 20 of 518

Table 207: Optical STM-1 SFP Interface Specifications ----------------------------------------------------------- 506

Table 208: Approved STM-1/OC-3 SFP Modules -------------------------------------------------------------------- 509
Table 209: IDU Chassis Mechanical Specifications ----------------------------------------------------------------- 510
Table 210: IDU Card and Tray Weights -------------------------------------------------------------------------------- 510
Table 211: RFU-C Mechanical Specifications ------------------------------------------------------------------------ 510
Table 212: RFU-D Mechanical Specifications (including diplexer unit) --------------------------------------- 510
Table 213: RFU-E Mechanical Specifications ------------------------------------------------------------------------- 511
Table 214: RFU-S Mechanical Specifications ------------------------------------------------------------------------- 511
Table 215: Supported Antenna Types per RFU ---------------------------------------------------------------------- 513
Table 216: RFU-E Integrated Antenna – Electrical Parameters ------------------------------------------------- 514
Table 217: RFU-D and RFU-S – Waveguide Flanges ---------------------------------------------------------------- 515
Table 218: RFU-C – Waveguide Flanges ------------------------------------------------------------------------------- 515
Table 219: Power Input Specifications -------------------------------------------------------------------------------- 516
Table 220: Power Consumption Specifications --------------------------------------------------------------------- 517
Table 221: IDU-RFU Cable Connection -------------------------------------------------------------------------------- 518
Page 21 of 518

About This Guide

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

This document includes information and specifications for configurations using
IP-20N IDUs with standard-power RFUs (RFU-C, RFU-D, RFU-E, and RFU-S). For
information about configurations using high-power RFUs, refer to the Technical
Description for IP-20N and IP-20A – High-Power Backhaul Solutions.
This document describes both ETSI and ANSI (FCC) 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 IP-20N and IP-20A for use in system planning, and determining which
configuration is best suited for a specific network.
Related Documents
• Technical Description for IP-20N and IP-20A – High-Power Backhaul Solutions
• User Guide for IP-20N, IP-20A, and Evolution IP-20LH
• Installation Guide for IP-20N and IP-20A
• Installation Guide for Evolution IP-20H
• MIB Reference for IP-20 Products
Page 22 of 518

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

ACR Adaptive Clock Recovery
AES Advanced Encryption Standard
AIS Alarm Indication Signal
AT Anti-Theft
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
CSO Cold Switchover
DA Destination Address
DDM Digital Diagnostic Monitoring
DSCP Differentiated Service Code Point
EBS Excess Burst Size
EIR Excess Information Rate
EPL Ethernet Private Line
ETH-BN Ethernet Bandwidth Notification
EVPL Ethernet Virtual Private Line
Page 23 of 518

EVC Ethernet Virtual Connection

FEC Forward Error Correction
FTP (SFTP) File Transfer Protocol (Secured File Transfer Protocol)
GbE Gigabit Ethernet
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
Page 24 of 518

PDU Power Distribution Unit

PDV Packed Delay Variation
PIR Peak Information Rate
PM Performance Monitoring
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 Remote Network Monitoring
RSA Rivest–Shamir–Adleman public-key cryptosystem
RSL Received Signal Level
RSTP Rapid Spanning Tree Protocol
SAP Service Access Point
SD Space Diversity
SDN Software-Defined Networking
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
TACACS+ Terminal Access Controller Access-Control System Plus
TC Traffic Class
Page 25 of 518

TCC Traffic and Control Card

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
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 518

2. Introduction
This chapter provides an overview of the following products:
• 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-20A – Designed uniquely for the North American market, IP-20A enables
operators to deploy high capacity, long haul microwave systems in locations
where rack space and shelter real-estate are limited. IP-20A is based on the IP-
20N hardware and software package, customized to operate according to
ANSI (FCC) standards.
IP-20N and IP-20A enable operators to continuously increase operational
efficiency and provide better quality of experience to their customers. Highlights
include:
• 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).
• Ability to double wireless backhaul capacity via remote activation of another
radio carrier with no site visits required – the fastest transmission network
setup from planning to fulfillment.
• Reduction of tower or roof-top equipment footprint by 50% in dual carrier
configurations.
• Ability 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.
• Optimization of 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 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.
Note: For information and specifications for high-power and ultra-high-
power RFU options, refer to the Technical Description for IP-20N
and IP-20A – High-Power Backhaul Solutions.
Additionally, modular structure of the IP-20N IDU enables the gradual expansion of
network nodes through the addition of line and radio cards, utilizing a single 1RU or 2RU
chassis.
Page 27 of 518

In addition to these many benefits, a unit with the high-capacity TCC-U provides
these additional benefits, making it the ideal solution for high-capacity 5G
aggregation sites:
• Higher switching capacity per node – 80Gbps
• Ultra-high capacity links – up to 16 wireless links (members) in a single group
using Layer 1 Link Aggregation
• Higher number of ports per node – up to 8 10 GbE ports and/or 24 1 GbE ports
• Larger link configurations per interface card – RIC-D cards in slots 5-10 can
support a 4+0 RFU-D configuration by simply activating another port on the
RIC-D
• Optimal 5G synchronization technology with IEEE 1588 class C support
• Two additional onboard PoE interfaces with TCC-U
This chapter includes:

• Product Overview
• IP-20 Assured Platform
• New Features in CeraOS 11.9.5
Page 28 of 518

2.1 Product Overview

IP-20N and IP-20A are highly modular and flexible wireless backhaul products that
are optimized for multi-carrier and nodal deployment, with a small footprint, high
density, and a high degree of scalability and availability. An IP-20N or IP-20A
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.
IP-20N and IP-20A 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 or IP-20A 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 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 and IP-20A to support
advanced features such as Multi-Carrier ABC configurations of up to 8+0, as well
as 4x2+0 and 2x4+0.
With TCC-U, IP-20N and IP-20A provide virtually limitless switching capacity of 80
Gbps. This makes IP-20N/IP-20A with TCC-U the ideal solution for 5G aggregation
sites. IP-20N and IP-20A can support higher capacity in higher bands, enabling the
use of multiple E-band directions with RFU-E. With Layer 1 Link Bonding, the ultra-
high-capacity IP-20N/IP-20A with TCC-U can support configurations of up to 16+0,
as well as Multi-Carrier ABC configurations of up to 8+0 as well as 2x4+0.1 Link
Bonding groups can provide an aggregate capacity of up to 30 Gbps per unit.
IP-20N and IP-20A enable operators to increase their operational efficiency and
provide better quality of experience to their customers. They provide support for
emerging services, standards, and networking protocols (future proof). They also
enable 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 and IP-20A all provide 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 and IP-20A provide 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.
1
TCC-U requires CeraOS 11.5.5 or higher.
Page 29 of 518

IP-20N and IP-20A are optimized for multi-carrier and aggregation nodes by
means of their high modularity, scalability, and flexibility. The IP-20/IP-50
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).
Along with their other configuration options, IP-20N and IP-20A can be used in
Multiband configurations with IP-50E or IP-20E to provide robust links that
combine microwave with E-band transmissions, for capacity of up to 10 Gbps
(with IP-50E) or 2.5 Gbps (with IP-20E). In a Multiband configuration, the very high
availability of microwave effectively provides a backup for the high capacity E-
Band link, thus enabling operators to benefit simultaneously from the high
capacity of E-Band and the high reliability of microwave.
2.1.1 IP-20N Radio Options

An IP-20N or IP-20A 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 7-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.
Page 30 of 518

2.1.2 IP-20N IDU Hardware Options and Scalability

IP-20N and IP-20A are all based on the IP-20N IDU. IP-20N IDUs 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-U – Contains 6 x 1/10GE optical interfaces and 2 x RFU or 1/2.5 GbE electrical
PoE interfaces. Two of the optical interfaces (1 and 2) can be configured as
cascading interfaces. Supports both TCC-based and RFU-based Multi-Carrier ABC
and Layer 1 Link Bonding.2
 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. Supports both TCC-based and RFU-based 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-B-MC – Contains 2 x 1 GbE Ethernet combo interfaces (electrical or optical)
and supports both TCC-based and RFU-based Multi-Carrier ABC
 TCC-B – Contains 2 x 1 GbE Ethernet combo interfaces (electrical or optical)
• Radio Interface Cards (RIC)
 RIC-D – Used to connect IDU with RFU-D, 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
Radio Configurations on page 35.
• Radio Modem Cards (RMC)
 RMC-B – Can be used with RFU-C. Supports up to 2048 QAM (with ACM) and XPIC.
 RMC-A – Can be used with RFU-C. Based on the same modem technology used in
Ceragon’s 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. RMC-A is not supported with TCC-U.
2
TCC-U requires CeraOS 11.5.5 or higher. Support for the RFU electrical interfaces is planned for future
release.
Page 31 of 518

• 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/DS1)
 TDM – LIC-T155 (1x ch-STM-1/OC-3)
 TDM –LIC-STM1/OC3-RST (1 x STM-1/OC-3)
Radio carrier support depends on the chassis type and the TCC type.
IP-20N and IP-20A with TCC-U support the following:
• The 1RU chassis supports up to 10 carriers, with redundancy options for radio
and traffic, and a dual-feed power option for power redundancy.
• The 2RU chassis supports up to 16 carriers, with redundancy options for
management, radio, traffic, and power.
Table 1: IP-20N/IP-20A 1RU and 2RU Scalability with TCC-U3
Interface Type 1RU Chassis 2RU Chassis

Maximum Number Maximum Number Maximum Number Maximum Number
of RMCs/RICs/LICs3 of Radio/Line of of Radio/Line
Interfaces3 RMCs/RICs/LICs3 Interfaces3
Radio (RFU) 5 x RMC or 5 x RFU at RMC or 10 x RMC or 8 x RIC 10 x RFU at RMC

4x RIC 6 x RFU at BBI 14 x RFU at BBI
Ethernet (GbE/FE) 1 x LIC-X-E4-Elec/Opt 10 x GbE/FE 2 x LIC-X-E4- 10 x GbE/FE
(4x GbE)4 Elec/Opt (4x GbE)
Ethernet (10GbE) 6 x at TCC-U plus 1 x 7 x 10GbE 6 x at TCC U plus 2 8 x 10GbE
LIC-X-E10 x LIC-X-E10
TDM – E1/DS1s 8 x any combination of LIC-T16
4 x any combination of LIC-T16 (16x
(16x E1/DS1) and LIC-T155 (1x ch-STM-
TDM – ch-STM-1/OC-3 E1/DS1) and LIC-T155 (1x ch-STM-1/OC-3)
1/OC-3)
TDM – STM-1/OC-3 4 x LIC-STM1/OC3-RST 8 x LIC-STM1/OC3-RST
Note: In CeraOS 11.9.5, IP-20N and IP-20A with TCC-U support up to 8

carriers in a 2RU chassis and 5 carriers in a 1RU chassis with TCC-
based Multi-Carrier ABC.
3
Number of plug-in cards and interfaces are maximum considering sufficient number of free chassis
slots. A tradeoff between different plug-in cards occupying chassis slots needs to be considered.
Page 32 of 518

IP-20N and IP-20A with non-TCC-U TCCs support the following:

• 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 8 carriers, with redundancy options for
management, radio, traffic, and power.
Table 2: IP-20N/IP-20A 1RU and 2RU Scalability
Interface Type 1RU Chassis 2RU Chassis

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

Ethernet (GbE/FE) 1 x LIC-X-E4- 10 X GbE/FE5 2 x LIC-X-E4- 10 x GbE/FE6
Elec/Opt (4x GbE) Elec/Opt (4x GbE)
or LIC-X-E10 (10G) or LIC-X-E10 (10G)
TDM – E1/DS1s 4 x any combination of LIC-T16 (16x 8 x any combination of LIC-T16 (16x E1/DS1)
TDM – ch-STM-1/OC-3 E1/DS1) and LIC-T155 (1x ch-STM-1/OC-3) and LIC-T155 (1x ch-STM-1/OC-3)
TDM – STM-1/OC-3 4 x LIC-STM1/OC3-RST 8 x LIC-STM1/OC3-RST
5
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.
6
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 33 of 518

2.1.3 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
and IP-20A radio carriers using RMC-A and IP-10G R3/IP-10E R3 units.
Note: TCC-U does not support RMC-A. Therefore, IP-20N and IP-20A
with TCC-U are not interoperable with IP-10G or IP-10E.
Links using RMC-B or RIC-D are interoperable with other IP-20 and IP-50 IDUs and
RFUs as described in Table 3.
All TCC types are interoperable with IP-20N and IP-20A units using other TCC
types.
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 3: 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-20A
IP-20N RFU-C IP-20N, IP-20A, IP-20F RFU-S7 1+07
IP-20A
IP-20N RFU-S IP-20F RFU-S 1+0
IP-20A
IP-20N RFU-S IP-20N, IP-20A, IP- RFU-C7 1+07
IP-20A 20GX, IP-20G
IP-20N RFU-D IP-20F RFU-D 1+0, 2+0 MC-ABC
IP-20A
IP-20N RFU-D IP-20N, IP-20A, IP- RFU-C7 2+0 MC-ABC7
IP-20A 20GX, IP-20G
IP-20N RFU-D 2+0 MC-ABC7
IP-20C7
IP-20A
IP-20N RFU-E IP-20F RFU-E 1+0
IP-20A
IP-20N RFU-E 1+0 (up to 250 MHz)
IP-20E
IP-20A
7
Planned for future release.
Page 34 of 518

2.1.4 Supported Radio Configurations

There are two sets of configurations:
• Configurations implemented with RFU-C connected to the IDU via RMC-A or
RMC-B
• Configurations implemented with RFU-D, 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 67.
In addition to the configurations listed in this section, there are a number of Link
Bonding configurations that include IP-50 and IP-20 all-outdoor units. These
configurations are described in Layer 1 Link Bonding.
2.1.4.1 Configurations Implemented using RFU-C with RMC-A or RMC-B

For configurations using RFU-C with RMC-A or RMC-B, the following requirements
should be taken into account:
• Multi-Carrier ABC configurations require TCC-U, 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.
• With TCC-U, the following is supported:
 Up to two Multi-Carrier ABC groups with capacity of 2.5 Gbps per group.
 With TCC-U and Layer 1 Link Bonding, 1 x 16+0 group, 2 x 8+0 groups, or up to 4
groups with a total of 16 carriers and a total capacity of up to 30 Gbps for all the
Link Bonding groups configured on the unit.
Note: RMC-A is not supported with TCC-U.
• Multi-Carrier ABC configurations can be combined with non-Multi-Carrier ABC
configurations in the same unit. For example, a single IP-20N or IP-20A 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.
Page 35 of 518

The following radio configurations are available for RFU-C:

Table 4: Radio Configuration Options for RFU-C
Configuration Notes
1+0
1+0 IF Combining Requires RMC-B and 1500HP
2+0 (XPIC Optional) Requires Multi-Carrier ABC or LAG.
3+0 Requires Multi-Carrier ABC or LAG.
4+0 IF Combining (XPIC Optional) Requires Multi-Carrier ABC and 1500HP.
5+0 Single Polarization Requires Multi-Carrier ABC or LAG.
7+0 Single Polarization Requires Multi-Carrier ABC or LAG.
8+0 IF Combining and XPIC Requires Multi-Carrier ABC and 1500HP.
Up to 8+0 Link Bonding (XPIC Optional) Requires TCC-U, RMC-B, and Link Bonding. Maximum
aggregate capacity is 30 Gbps.
2 x 4+0 Link Bonding (XPIC Optional) Requires TCC-U, RMC-B, and Link Bonding. Maximum
3 x 2+0 Link Bonding (XPIC Optional) Requires TCC-U, RMC-B, and Link Bonding. Maximum
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-U or 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-U or TCC-B2-XG-MC, RMC-B, and Multi-Carrier
ABC
Page 36 of 518

Configuration Notes
4 X 1+1 HSB-SD Requires TCC-U or TCC-B2-XG-MC, RMC-B, and Multi-Carrier

ABC
2 X 2+2 HSB-SD Requires:
• TCC-B2-XG-MC, RMC-B, and Multi-Carrier ABC, OR
• TCC-U, RMC-B, and Link Bonding
Note: Not available with TCC-U in CeraOS 11.9.5, but
planned for release in future versions.
2 X 4+0 Multi-Carrier ABC Requires TCC-B2-XG-MC, RMC-B, and Multi-Carrier ABC
4+4 HSB-SD Requires TCC-U, RMC-B, and Link Bonding.
Note: Not available in CeraOS 11.9.5, but planned for
release in future versions.
2 X 4+4 HSB-SD Requires TCC-U, RMC-B, and Link Bonding.
Note: Not available in CeraOS 11.9.5, but planned for
Page 37 of 518

2.1.4.2 Configurations Implemented using RFU-D, 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-U, TCC-B-MC, or TCC-B2-XG-MC. Multiple groups in a single
unit and high capacity groups require TCC-U or 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-D. For example, an 8+0
Multi-Carrier ABC group must use four RIC-D cards, each connected to an
RFU-D.
• RFU-based Multi-Carrier ABC – Multi-Carrier ABC is implemented in the
RFU-D. 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. 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 149.
Note: For many configurations, both RFU interfaces can be used on a
single RIC-D, enabling operators to use up to four radio carriers
with a single slot and RIC-D card. For details, see Configurations
Using Second RIC-D RFU Interface (RFU2/2.5 GE2).
The following split-mount configurations are available for RIC-Ds:

Table 5: Radio Configuration Options for RFU-D, RFU-E, or RFU-S with RIC-D
Configuration Supported RFUs Notes
1+0 RFU-D, RFU-S, RFU-E

2+0 (XPIC Optional) RFU-D Requires Multi-Carrier ABC or LAG.8
4 X 1+09 RFU-E
8 X 1+010 RFU-S
8 X 1+0 RFU-E Requires TCC-U
8 X 2+0 (XPIC Optional) RFU-D Requires TCC-U and RFU-Based Multi-Carrier ABC
8
XPIC can be implemented between two carriers of the same RFU (Internal XPIC) or the first carrier in
each of two separate RFUs (External XPIC). External XPIC requires TCC-based Multi-Carrier ABC.
9
With 250 MHz channels, 3 x 1+0 configuration is supported in CeraOS 11.9.5. This limitation applies to
Multi-Carrier ABC, but not to configurations with Link Bonding (TCC-U only).
10
Page 38 of 518

4 X 2+0 (XPIC optional)11 RFU-D Requires TCC-based or RFU-based Multi-Carrier ABC8

4+0 (XPIC optional) RFU-D Requires TCC-based Multi-Carrier ABC8
2 X 4+0 (XPIC optional) RFU-D Requires TCC-based Multi-Carrier ABC8
16+0 (XPIC Optional) RFU-D Requires TCC-U and Link Bonding.
2 X 8+0 (XPIC optional) RFU-D Requires TCC-U and Link Bonding.
4 X 4+0 (XPIC optional) RFU-D Requires TCC-U and Link Bonding.
2+0 BBC Space Diversity RFU-D
4+0 BBC Space Diversity RFU-D Requires TCC-U or TCC-B2-XG-MC and TCC-based Multi-
Carrier ABC
2 X 2+0 BBC Space Diversity RFU-D
2 X 4+0 BBC Space Diversity RFU-D Requires TCC-U or TCC-B2-XG-MC and TCC-based Multi-
Carrier ABC
1+1 HSB RFU-D
1+1 HSB BBS Space Diversity RFU-D Requires TCC-based Multi-Carrier ABC
1+1 HSB BBC Space Diversity RFU-D Requires TCC-based Multi-Carrier ABC
2+2 HSB (XPIC Optional) RFU-D Requires RFU-based Multi-Carrier ABC
2+2 HSB BBS Space Diversity RFU-D Requires TCC-based Multi-Carrier ABC
(XPIC Optional) RIC-Ds must be placed in the following slots:
• TCC-B-MC or TCC-B2-XG-MC: Slots 3, 4, 5, and/or 6
• TCC-U: Slots 2, 3, 4, and/or 12
4+4 HSB BBS Space Diversity RFU-D Requires TCC-U and Link Bonding.
(XPIC Optional) Note: Not available in CeraOS 11.9.5, but planned for
2 X 2+2 HSB (XPIC Optional) RFU-D Requires RFU-based Multi-Carrier ABC
11
Page 39 of 518

2 X 2+2 HSB BBS Space RFU-D Requires TCC-based Multi-Carrier ABC

Diversity (XPIC Optional) RIC-Ds must be placed in the following slots:
• TCC-B-MC or TCC-B2-XG-MC: Slots 3, 4, 5, and/or 6
• TCC-U: Slots 2, 3, 4, and/or 12
2 X 4+4 HSB BBS Space RFU-D Requires TCC-U and Link Bonding.
Diversity (XPIC Optional) Note: Not available in CeraOS 11.9.5, but planned for
Page 40 of 518

2.1.4.3 Configurations Using Second RIC-D RFU Interface (RFU2/2.5 GE2)

The second RFU interface on a RIC-D (RFU2/2.5 GE2) can be used for certain
configurations. Using both RIC-D interfaces enables operators to densify slot
usage, freeing other slots for other types of cards such as LIC-STM1/OC3-RST. It
can also provide significant TCO savings through the use of fewer RIC-D cards to
support the same number of RFUs.
In order to use the second RFU interface on a RIC-D, the unit must be using TCC-U.
RFU2/2.5GE2 can only be used for RIC-D cards in slots 5-10. In a 1RU chassis, the
RIC-D must be placed in slots 5-6.
Slots 7 and 8 are subject to the following limitations:
• If the first onboard RJ-45 interface on the TCC-U (RFU1/Eth7) is being used,
the second RFU port (RFU2/2.5GE2) cannot be used on a RIC-D in slot 7.
• If the second onboard RJ-45 interface on the TCC-U (RFU2/Eth8) is being used,
the second RFU port (RFU2/2.5GE2) cannot be used on a RIC-D in slot 8.
• The use of RFU2/2.5GE2 in slots 7 and 8 requires TCC-U P/N 24-T014-2 or
later, once it is available. For details about availability, contact your Ceragon
representative.
The two RIC-D RFU interfaces can be used with mixed media types (RJ-45 for one,
SFP for the other). When used as RJ-45 interfaces, both interfaces support PoE,
subject to certain limitations on cable length and total number of PoE interfaces in
use per unit. For details, see IDU-RFU Cable Connection on page 518.
The following configurations are supported with the use of the second RFU
interface on the RIC-D:
• 16+0 Link Bonding with Four RIC-D Cards
• 8+0 Link Bonding with BBC Space Diversity (Internal)
• 2 x 6+0 Link Bonding with BBC Space Diversity (Internal)
• 12+0 Link Bonding with BBC Space Diversity (Internal)
• 2 x 1+0 with a Single RIC-D
• Up to 4 x 2+0 with a Two RIC-Ds
• TCC-Based and RFU-Based Multi-Carrier ABC
• 2+0 Space Diversity with a Single RIC-D
• Multiband with Both RIC-D RFU Interfaces
• 2+2 HSB
• 2 x 2+2 HSB
Each one of these configurations is illustrated and explained in the following
sections.
Page 41 of 518

16+0 Link Bonding with Four RIC-D Cards

A 16+0 Link Bonding group can be configured using only four slots and four RIC-D
cards. The cards must be placed in slots 5, 6, 9, and 10. Each RIC-D is connected to
two RFUs, and each RFU is configured with RFU-based Multi-Carrier ABC so that
each RFU provides two carriers. The Link Bonding group includes all eight Multi-
Carrier ABC groups, for a total of 16 carriers in the group.
Link Bonding Group
RFU-D
RFU1/2.5GE1 2+0 RFU-Based
Slot 5 Multi-Carrier ABC RFU-D
RIC-D RFU2/2.5GE2
2+0 RFU-Based
Multi-Carrier ABC
RFU-D
IDU Slot 6
RFU2/2.5GE2 Multi-Carrier ABC RFU-D
RIC-D 2+0 RFU-Based
Multi-Carrier ABC
RFU-D
RIC-D RFU2/2.5GE2
2+0 RFU-Based
Multi-Carrier ABC
RFU-D
RIC-D RFU2/2.5GE2
2+0 RFU-Based
Multi-Carrier ABC
Figure 1: 16+0 Link Bonding with Four RIC-D Cards
Page 42 of 518

8+0 Link Bonding with BBC Space Diversity (Internal)

A Link Bonding group can be configured that contains eight BBC Space Diversity
groups (internal), using only four slots and four RIC-D cards. The cards must be
placed in slots 5, 6, 9, and 10. Each RIC-D is connected to two RFUs, and each RFU
is configured as a 1+0 internal Space Diversity group, for a total of eight Space
Diversity groups.
Link Bonding Group
RFU-D
RFU1/2.5GE1 1+0 BBC Space
Slot 5 Diversity RFU-D
RIC-D RFU2/2.5GE2
1+0 BBC Space
Diversity
RFU-D
IDU Slot 6
RFU2/2.5GE2 Diversity RFU-D
RIC-D 1+0 BBC Space
Diversity
RFU-D
RIC-D RFU2/2.5GE2
1+0 BBC Space
Diversity
RFU-D
RIC-D RFU2/2.5GE2
1+0 BBC Space
Diversity
Figure 2: 8+0 Link Bonding with BBC Space Diversity (Internal)
Page 43 of 518

2 x 6+0 Link Bonding with BBC Space Diversity (Internal)

Two independent Link Bonding groups can be configured in two independent
directions, each containing six BBC Space Diversity groups (internal). Although this
configuration requires 12 RFUs, it can be implemented by using both RFU ports on
the RIC-D cards in slots 5, 6, 9, and 10, along with RFU1/2.5GE1 on any four of the
RIC-D cards in slots 2, 3, 4, 7, 8, and 12.
6+0 Link Bonding Group 1
RFU-D
Slot 2 RFU1/2.5GE1 1+0 BBC Space
RIC-D Diversity
RFU-D
RIC-D Diversity
RFU-D
RIC-D Diversity
RFU-D
RIC-D RFU2/2.5GE2
1+0 BBC Space
Diversity
RFU-D
1+0 BBC Space
IDU RFU1/2.5GE1 Diversity
Slot 6
RIC-D RFU2/2.5GE2
RFU-D
1+0 BBC Space
Diversity
RFU-D
RIC-D RFU2/2.5GE2
1+0 BBC Space
Diversity
RFU-D
RIC-D RFU2/2.5GE2
1+0 BBC Space
Diversity
RFU-D
RIC-D Diversity
6+0 Link Bonding Group 2
Figure 3: 2 x 6+0 Link Bonding with BBC Space Diversity (Internal)
Page 44 of 518

12+0 Link Bonding with BBC Space Diversity (Internal)

A single Link Bonding group can be configured, consisting of 12 BBC Space
Diversity groups (internal). This configuration requires 12 RFUs and is
implemented by using both RFU ports on the RIC-D cards in slots 5, 6, 9, and 10,
along with RFU1/2.5GE1 on the RIC-D cards in slots 2, 3, 4, and 12.
12+0 Link Bonding Group
RFU-D
RIC-D Diversity
RFU-D
RIC-D Diversity
RFU-D
RIC-D Diversity
RFU-D
RIC-D RFU2/2.5GE2
1+0 BBC Space
Diversity
RFU1/2.5GE1 RFU-D
IDU Slot 6 1+0 BBC Space
Diversity
RIC-D RFU2/2.5GE2 RFU-D
1+0 BBC Space
Diversity
RFU-D
RIC-D RFU2/2.5GE2
1+0 BBC Space
Diversity
RFU-D
RIC-D RFU2/2.5GE2
1+0 BBC Space
Diversity
RFU-D
RIC-D Diversity
Figure 4: 12+0 Link Bonding with BBC Space Diversity (Internal)
Page 45 of 518

2 x 1+0 with a Single RIC-D

A single RIC-D card can support two independent 1+0 links. Each link is connected
to an RFU-D with only a single core active. This can be used as a future-ready 2 x
2+0 configuration by simply activating the second cores when growth in traffic
requires expanded capacity, with no additional hardware configuration necessary.
RFU1/2.5GE1 RFU-D
(1+0)
IDU
RFU2/2.5GE2 RFU-D
(1+0)
Figure 5: 2 x 1+0 with a Single RIC-D
Up to 4 x 2+0 with Two RIC-Ds

A single RIC-D card can support two independent 2+0 links, and two RIC-D cards
can support up to four independent 2+0 links. Each link is connected to an RFU-D
or RFU-D-HP operating with both of its radio carriers active. In each RFU, the
carriers are configured as an RFU-Based Multi-Carrier ABC group.
RFU-D
RIC-D RFU2/2.5GE2
2+0 RFU-Based
Multi-Carrier ABC
IDU
RFU-D
RIC-D RFU2/2.5GE2
2+0 RFU-Based
Multi-Carrier ABC
Figure 6: N x 2+0 with a Single RIC-D
Page 46 of 518

TCC-Based and RFU-Based Multi-Carrier ABC

The RFU connected to RFU1/2.5GE1can be part of a TCC-Based Multi-Carrier ABC
group, in single-core operation, while the RFU connected to RFU2/2.5GE2 can
operate independently, in a different direction, either with a single core or in
MultiCore operation as an RFU-Based Multi-Carrier ABC group.
TCC-Based Multi-
Carrier ABC Group
RFU-D
RFU-D
RFU1/2.5GE1
RFU-D
IDU
RFU-D
RFU2/2.5GE2 (2+0 RFU-Based
Multi-Carrier
ABC)
Figure 7: TCC-Based and RFU-Based Multi-Carrier ABC
Page 47 of 518

2+0 Space Diversity with a Single RIC-D

Each RIC-D interface is connected to an RFU-D. The first RFU is the Master RFU
operating in 2+0 mode. The second RFU is the Slave RFU, and operates as a 2+0
configuration in RX mode, providing Space Diversity.
RFU1/2.5GE1 Main
RFU-D
(Master – 2+0)
Main
IDU
RFU2/2.5GE2 RFU-D Diversity

(Slave – 2+0)
Diversity
Figure 8: 2+0 Space Diversity with a Single RIC-D
Page 48 of 518

Multiband with Both RIC-D RFU Interfaces

Each RIC-D interface can be connected to an RFU-D that provides the Microwave
link in a Multiband configuration with an IP-50E. This enables operators to
configure two independent Multiband configurations with a single RIC-D
supporting both Microwave components of the Multiband links.
Note: This does not apply to Multiband configurations that use Link
Bonding. Support for RFU2/2.5GE2 with Link Bonding
configurations is planned for future release.
10/40G Ingress
IP-50E
RFU-D
RFU1/2.5GE1 RFU-Based Multi-
Carrier ABC
XPIC Optional
IDU
RFU-D
RFU2/2.5GE2 RFU-Based Multi-
Carrier ABC
XPIC Optional
IP-50E
10/40G Ingress
Figure 9: Multiband with Both RIC-D RFU Interfaces
Page 49 of 518

2+2 HSB and 2 x 2+2 HSB

RFU2/2.5GE2 can be used for an RFU-D in an HSB configuration, as either the
active or the standby member. The RFU can be configured in single-core mode for
1+1 HSB or MultiCore mode for 2+2 HSB. This configuration can be implemented
using a single RIC-D connected to two RFUs. However, it is recommended to use
two separate RIC-D cards in order to ensure RIC-D card protection as well as RFU
protection. The ability to use RFU2/2.5GE2 for the active member, the standby
member, or both, leaves RFU1/2.5GE1 free to support other RFUs with other
configurations.
Protection
Group 1
Active
RFU1/2.5GE1 RFU-D Protection
2+0 Multi-Carrier Group 2
RIC-D
ABC
Active
RFU2/2.5GE2 RFU-D
2+0 Multi-Carrier
IDU ABC
Standby
RFU1/2.5GE1 RFU-D
2+0 Multi-Carrier
X
RIC-D
ABC Mute
Standby
RFU2/2.5GE2 RFU-D
2+0 Multi-Carrier
X
ABC Mute
Figure 10: Two 2+2 HSB Groups with Two RIC-Ds
Page 50 of 518

2.1.5 No-Single-Point-of-Failure Architecture

IP-20N and IP-20A are built according to a no-single-point-of-failure architecture,
with full support for the hot-swapping of cards.
The 2RU IDU 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/DS1) – Redundancy is available using 1:1 or 1+1 Path
Protection, or 1+1 HSB Card Protection.
• LIC-T155 (1x ch-STM-1/OC-3) – 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.
The IP-20N IDU 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.
The IP-20N IDU includes a set of redundant fans that can continue sustained
operation in the event of a single fan failure.
Page 51 of 518

2.2 IP-20 Assured Platform

Ceragon’s 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 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 IP-20 Assured platform also provides:
• Secured communication and protocols for management interface.
• Centralized user authentication management via RADIUS or TACACS+.
• Advanced identity management and password policy enforcement.
• Security events log.
• Secure product architecture and development.
The following products are included in the IP-20 Assured platform:
• IP-20N Assured
• IP-20A Assured
• IP-20LH Assured
• IP-20G Assured
• IP-20GX Assured
• IP-20C Assured
• IP-20C-HP Assured
• IP-20S Assured
Notes: CeraOS 11.9.5 cannot be used in IP-20 Assured platforms. For IP-
20 Assured, use CeraOS 10.9.6 or CeraOS 8.3.
Page 52 of 518

2.3 New Features in CeraOS 11.9.5

The following table lists the features that have been added in CeraOS version
11.9.5, 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 6: New Features in CeraOS 11.9.5
Feature Further Information Configuration Instructions in the User’s Guide
Second RFU Interface on RIC-D Configurations Using Second Section 2.16, Enabling the Interfaces
RIC-D RFU Interface (RFU2/2.5 (Interface Manager)
GE2) on page 41.
Page 53 of 518

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 11: 1RU Chassis Figure 122RU 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/DS1)
 TDM – LIC-T155 (1x ch-STM-1/OC-3)
 TDM – LIC-STM1/OC3-RST (1 x STM-1/OC-3)
Page 54 of 518


• 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 55 of 518

3.1 Hardware Architecture

The IP-20N IDU 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 IDU
and the RFU:
• Radio Modem Card (RMC) – Provides the modem interface with the RFU-C.
• Radio Interface Card (RIC) – Interfaces with the RFU-D, RFU-E, and RFU-S.
A 1RU IDU can contain up to five RMCs and/or RICs. A 2RU IDU 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.
The IDU 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 56 of 518

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 13: Chassis Management
Page 57 of 518

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
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 14: Traffic Connectivity in 2RU Chassis with TCC Redundancy
Page 58 of 518

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 15: IDU Block Diagram – 1RU Chassis
Page 59 of 518

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 16: IDU Block Diagram – 2RU Chassis with TCC and PDC Redundancy
Page 60 of 518

3.2 Front Panel Description

This section describes the IP-20N IDU’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 17: IDU Front Panel and Interfaces – 1RU Chassis
Page 61 of 518

Figure 18: IDU Front Panel and Interfaces – 2RU Chassis
Page 62 of 518

3.3 Chassis Slots and Card Population Guidelines

The figures below show the 1RU and 2RU chassis slot numbers.
Figure 19: 1RU Chassis Slot Numbering
Figure 20: 2RU Chassis Slot Numbering
3.3.1 Card Types Per Slot

The following tables list the card types that can be placed in each slot:
Table 7: 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 Multi-Carrier ABC Group 1 must include
• Ethernet LIC the card in Slot 3, or Slot 3 must be left
unpopulated if a Multi-Carrier ABC group
• TDM LIC with the group number 1 is configured on
the unit.
For Ethernet LICs in these slots, see below
for limitations.
Page 63 of 518

Table 8: 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 Multi-Carrier ABC Group 1 must include the
• Ethernet LIC card in Slot 3, or Slot 3 must be left
unpopulated if a Multi-Carrier ABC group
• TDM LIC with the group number 1 is configured on
the unit.
For Ethernet LICs in these slots, see below
for limitations.
11 • TCC Only valid when TCC Redundancy is enabled.
When an Ethernet LIC is used in Slots 3-10, the following restrictions apply:
• Only LIC-X-E4 cards can be used, not LIC-X-E10.
• Only Port 1 of the LIC-X-E4 can be used. Ports 2-4 of the LIC-X-E4 cannot be
used.
• LIC-X-E4 cards in slots 3-10 cannot be used with the following features:
 Ethernet Bandwidth Notification (Eth-BN)
 Radio Bandwidth Notification (RBN)
 Link Aggregation (LAG)
 1588 Transparent Clock
 1588 Boundary Clock
 TCC Redundancy (CSO and HSO)
 Port Mirroring
Page 64 of 518

3.3.2 TCC GbE Interface Limitations
3.3.2.1 TCC GbE Interface Limitations with TCC-U

In some configurations with TCC-U, the second RFU interface (RFU2) can be used
on RIC-D cards that are placed in certain slots. However, this is subject to the
following limitations:
the second RFU port (RFU2) cannot be used on a RIC-D in slot 7.
representative.
Note: For details, see Configurations Using Second RIC-D RFU Interface
(RFU2/2.5 GE2).
3.3.2.2 TCC GbE Interface Limitations with TCC-B2 and TCC-B2-XG-MC

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 9: 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 65 of 518

3.3.2.3 TCC GbE Interface Limitations with TCC-B and TCC-B-MC

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.
3.3.3 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)
Note: This limitation does not apply to RIC-D.
If you are configuring 2+2 HSB with XPIC using RMCs, 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
Page 66 of 518

3.3.4 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.
Note: When TCC-U is used, slot sections do not exist and none of the
restrictions listed in this section are applicable. With TCC-U, 2.5
Gbps capacity is available in all slots.
Table 10: 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.
Slot sections A, C, and D – see Card Types
Per Slot on page 63.
LIC-X-E4-Opt Cannot be used Slot sections B, E, and F– no restrictions
Slot sections A, C, and D – see Card Types
Per Slot on page 63.
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 21: 1RU Chassis – Slot Sections
Page 67 of 518

Figure 22: 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
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 TCC-Based Multi-Carrier ABC groups with nominal capacity
greater than 1 Gbps, you must configure Slot Section A (1RU chassis) or C (2RU
chassis) to 2.5 Gbps mode. In this configuration, the high-capacity 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 68 of 518

3.3.5 Additional Slot Guidelines

Note: For TCC-U, only the ABC Group 1 limitation is applicable.
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 11. 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 11: 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 69 of 518

3.3.6 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 161.
3.3.6.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 23: Sample Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (1 Gbps)
This configuration uses four RIC-D cards with four RFU-Ds to provide 2 x 4+0
Multi-Carrier ABC groups, each with a capacity of 1 Gbps. The configuration
requires TCC-B-MC or TCC-B2-XG-MC.
Note: A similar configuration is also available for TCC-U. See Sample
Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (2.5 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 70 of 518

3.3.6.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 24: Sample Chassis Configuration – 4 x 2+0 Multi-Carrier ABC (1 Gbps)
Note: This configuration is not available with TCC-U.

Multi-Carrier ABC groups, each with a capacity of 1 Gbps.
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 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 71 of 518

3.3.6.3 Sample Chassis Configuration – 2 x 2+0 Multi-Carrier ABC with RST (1 Gbps/2.5
Gbps)
11 – TCC-B2-XG-MC or 12 -Traffic PDC2

TCC-U (Optional)
7 – RST 8 - RST 9 - Traffic 10 -Traffic
Filter
Fans
1 – TCC-B2-XG-MC or 2 - Traffic PDC1
TCC-U
Figure 25: 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, 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.5 Gbps mode.
Note: Not relevant with TCC-U.
• 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 72 of 518

3.3.6.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 26: Sample Chassis Configuration – 1 x 8+0 Multi-Carrier ABC (2.5 Gbps) –
TCC-B-MC or TCC-B2-XG-MC
11 – TCC-U (Optional) 12 -RIC-D PDC2
7 – Empty 8 – Empty 9 - Traffic 10 -Traffic

Filter
Fans
3 -RIC-D 4 -RIC-D 5 - Traffic 6 -Traffic
1 – TCC-U 2 -RIC-D PDC1
TCC-U
This configuration uses four RIC-D cards with four RFU-Ds to 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.
• The RIC-D cards are placed in the following slots:
 TCC-B-MC or TCC-B2-XG-MC: Slots 3, 4, 5, and 6
 TCC-U: Slots 2, 3, 4, and 12
• ABC Group 1 includes all 8 carriers connected to Slots 3, 4, 5, and 6 (TCC-B-MC
or TCC-B2-XG-MC) or 2, 3, 4, and 12 (TCC-U).
Page 73 of 518

• With TCC-B-MC or TCC-B2-XG-MC, Slots 2, 9, 10, and 12 can be populated with

Ethernet and/or TDM traffic cards. No additional radio cards can be used.
• With TCC-U, Slots 5, 6, 9, and 10 can be populated with TDM traffic cards or
additional radio cards that are not part of a Multi-Carrier ABC group.
Note: Although with TCC-U, no Ethernet traffic cards can be used with
this configuration, the TCC-U itself provides six optical Ethernet
ports and two additional electrical ports that can be configured
for use as Ethernet ports.
• Slots 7 and 8 cannot be populated.
Page 74 of 518

3.3.6.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 28: Sample Chassis Configuration – 1 x 6+0 Multi-Carrier ABC with RST (2.5 Gbps)
– TCC-B-MC or TCC-B2-XG-MC
11 – TCC-U (Optional) 12 -Traffic PDC2
7 – RST 8 - RST 9 -Traffic 10 -Traffic

Filter
Fans
3 -RIC-D 4 -RIC-D 5 -Traffic 6 -Traffic
Figure 29: Sample Chassis Configuration – 1 x 6+0 Multi-Carrier ABC with RST (2.5 Gbps)
– TCC-U
This configuration uses three RIC-D cards with three RFU-Ds, 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.
 TCC-B-MC or TCC-B2-XG-MC: Slots 3, 4, and 5
 TCC-U: Slots 2, 3, and 4
• The LIC-STM1/OC3-RST cards used in the Multi-Carrier ABC group are placed
in Slots 7 and 8.
Page 75 of 518

• ABC Group 1 includes all 6 carriers connected to Slots 3, 4, and 5 (TCC-B-MC or

TCC-B2-XG-MC) or Slots 2, 3, and 4 (TCC-U) 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 used for the
6+0 Multi-Carrier ABC configuration.
3.3.6.6 Sample Chassis Configuration – 2 x 4+0 Multi-Carrier ABC (2.5 Gbps)

(Optional)
Filter
Fans
TCC-B-MC or TCC-B2-XG-MC
11 – TCC-U (Optional) 12 -RIC-D PDC2

Filter
3 -RIC-D 4 -RIC-D 5 - Traffic 6 - Traffic Fans
TCC-U
Multi-Carrier ABC groups, each with a capacity of 2.5 Gbps.
Page 76 of 518


 TCC-B-MC or TCC-B2-XG-MC: Slots 3, 4, and 5
 TCC-U: Slots 2, 3, 4, and 12
• ABC Group 2 includes all four radio carriers connected to Slots 5 and 6 (TCC-B-
MC or TCC-B2-XG-MC) or 2 and 12 (TCC-U).
Note: For units with TCC-B-MC or TCC-B2-XG-MC, you must use Group
IDs 1 and 3.
• With TCC-B-MC or TCC-B2-XG-MC, Slots 2, 9, 10, and 12 can be populated with
Ethernet and/or TDM traffic cards. No additional radio cards can be used.
• With TCC-U, Slots 5, 6, 9, and 10 can be populated with TDM traffic cards. No
additional radio cards can be used.
Note: Although with TCC-U, no Ethernet traffic cards can be used with
this configuration, the TCC-U itself provides six optical Ethernet
ports and two additional electrical ports that can be configured
for use as Ethernet ports.
Slots 7 and 8 cannot be populated.
Page 77 of 518

3.4 Traffic Control Cards (TCC)

The Traffic Control Card (TCC) provides the control functionality for the IP-20N or
IP-20A unit. It also provides Ethernet management and traffic interfaces.
Figure 32: TCC-U
Figure 33: TCC-B
Page 78 of 518

IP-20N and IP-20A offer the following types of TCC:

• TCC-U – Provides 6 x 1/10GE optical interfaces and 2 x RFU or 1/2.5 GbE
electrical PoE interfaces. Two of the optical interfaces (1 and 2) can be
configured as cascading interfaces. Supports up to two Multi-Carrier ABC
groups, with capacity of 2.5 Gbps (non-configurable). Supports multiple high-
capacity configurations with Link Bonding.12
• TCC-B2-XG-MC – Supports up to two Multi-Carrier ABC groups with capacity of
2.5 Gbps13 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.
• 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-B –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.
The TCC is responsible for the following functionality:
• Provides the main CPU for the IDU
• Responsible for chassis management
• Responsible for switch aggregation
• Responsible for synchronization in the IDU
12
TCC-U requires CeraOS 11.5.5 or higher. Support for the RFU electrical interfaces is planned for future
release. TCC-U does not support RMC-A.
13
Only RIC-D cards and LIC-STM1/OC3-RST cards are supported in multiple 2.5 Gbps groups.
Page 79 of 518

3.4.1 TCC-U Interfaces
Figure 34: TCC-U Interfaces
TCC-U contains six optical 1/10 GbE interfaces, labelled SFP+ 1 through 6.
SFP+ 1 and SFP+ 2 can be configured as normal Ethernet 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 and IP-50 units in a node for multi-directional applications based on
hybrid Ethernet and Native or pseudowire TDM services.
Note: Support for electrical SFP modules with TCC-U is planned for
future release.
TCC-U also contains two RJ-45 interfaces, each with a capacity of 2.5 Gbps, that
can be used either as RFU interfaces or as additional Ethernet interfaces. These
interfaces are labelled RFU1/Eth7 and RFU2/Eth8.
• When used as RFU interfaces, they can be connected to RFU-D, RFU-E, or
RFU-S. They support PoE and capacity of 2.5 Gbps. They do not support TCC-
based Multi-Carrier ABC or radio HSB.
Notes: Use of these ports as RFU interfaces is planned for future
release.
• When used as Ethernet interfaces, capacity of each interface can be
configured to 1 Gbps or 2.5 Gbps.
In some configurations with TCC-U, the second RFU interface (RFU2/2.5GE2) can
be used on RIC-D cards that are placed in slots 5-10. However, this is subject to
the following limitations:
representative.
Note: For details, see Configurations Using Second RIC-D RFU Interface
(RFU2/2.5 GE2).
Page 80 of 518

The TCC-U also contains the following interfaces:

• One RJ-45 synchronization interface for clock input and clock output
• One RJ-45 interface for terminal connection (console) and external alarms,
supporting one input and one output alarm14
For a description of the management interfaces on TCC-U, see Management
Interfaces for TCC-U, TCC-B2-XG-MC, and TCC-B2.
Note: TCC-U also includes a USB port, which is planned for future use.
3.4.2 TCC-B2/TCC-B2-XG-MC Interfaces
Figure 35: 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-20N and IP-20A units in a node for multi-directional applications based on
hybrid Ethernet and Native or pseudowire TDM services.
TCC-B2 and TCC-B2-XG-MC also contain the following interfaces:
• One RJ-45 terminal interface (RS-232)
• One DB-9 interface for external alarms, supporting five input alarms and one
alarm output
For a description of the management interfaces on TCC-B2 and TCC-B2-XG-MC,
see Management Interfaces for TCC-U, TCC-B2-XG-MC, and TCC-B2.
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.
14
Support for external alarms with TCC-U is planned for future release.
Page 81 of 518

3.4.3 TCC-B/TCC-B-MC Interfaces
Figure 36: 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.
TCC-B and TCC-B-MC also contain the following interfaces:
• One RJ-45 terminal interface (RS-232)
• One DB-9 interface for external alarms, supporting five input alarms and one
alarm output
The FE management interfaces are labeled MGMT1 and MGMT2. These interfaces
are 100BaseT with auto negotiation and auto crossover.
3.4.4 Management Interfaces for TCC-U, TCC-B2-XG-MC, and TCC-B2

TCC-U, 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 37: TCC-B2/TCC-B2-XG-MC Management Interface Pin Connections
Page 82 of 518

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 12: 2 x FE Splitter Cable Marketing Model
Marketing Model Marketing Description Part Number
SPL-ETH-CBL Ethernet split cable rohs WA-0245-0
3.4.5 TCC LED

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).
Page 83 of 518

3.4.6 TCC Summary

All TCC models can be used in both 1RU and 2RU IDUs.
The following table summarizes the functionality supported by the various TCC
models.
Table 13: TCC Comparison Table
TCC Type Ethernet Traffic Interfaces Multi-Carrier ABC Support Link Bonding Support
TCC-U 4 x 1/10GE SFP+/ SFP • 1 x up to 8+0 Multi-Carrier ABC • 1 x up to 16+0

interfaces • 12 x 2+0 RFU-based Multi-Carrier ABC • 2 x 8+0
2 x dual mode 1/10GE SFP+ or
• 2 x up to 4+0 Multi-Carrier ABC • 4 x 4+0
cascading interfaces
• 4 x 1+1 HSB Protection with BBS Space
2 x Gb electrical interfaces,
Diversity
configurable as RFU or 2.5GE
interfaces • 2 x 2+2 HSB
• 2 x 2+2 HSB-SD
• 2.5 Gbps (non-configurable)
TCC-B2-XG-MC 2 x Gb electrical interfaces • 1 x up to 8+0 Multi-Carrier ABC16 None
2 x Gb optical interfaces • 4 x 2+0 Multi-Carrier ABC
2 x dual mode electrical or • 4 x 1+1 HSB Protection with Space
cascading interfaces Diversity
• 2 x 4+0 Multi-Carrier ABC
• 1 or 2.5 Gbps (user-configurable)15
• 2 x 2+2 HSB
• 2 x 2+2 HSB-SD
TCC-B-MC 2 x Gb combo (optical or • 1 x up to 8+0 Multi-Carrier ABC16 None
electrical) interfaces • 1 Gbps
TCC-B2 2 x Gb electrical interfaces Only with RIC-D and RFU-D None
2 x Gb optical interfaces
2 x dual mode electrical or
cascading interfaces
TCC-B 2 x Gb combo (optical or Only with RIC-D and RFU-D None
electrical) interfaces
15
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.
16
With RMC-B and RIC-D, a Multi-Carrier ABC group can include up to eight radio and STM1/OC3-RST
members in total.
Page 84 of 518

3.4.7 TCC Redundancy

The 2RU IDU can have two TCCs for TCC Redundancy. 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.
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 14: 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
• Loss of Carrier (LOC) in any of the optical Ethernet interfaces on the TCC
Page 85 of 518

Note: Hot-swap of the active TCC module does not trigger switchover.
If it becomes necessary to remove the active TCC, the user must
first perform a Manual Switch or Forced Switch before extracting
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 86 of 518

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-E
• RFU-S
The 1RU IDU can accommodate up to five RICs. The 2RU IDU can accommodate
eight RICs.
IP-20N and IP-20A offer the RIC-D. The RIC-D includes two combo interfaces to the
RFU (optical or electrical), each with a capacity of 2.5 Gbps.
The second RFU interface can be used for many configurations, enabling
operators to use up to four radio carriers with a single slot and RIC-D card. It is
also subject to certain limitations. For details, see Configurations Using Second
RIC-D RFU Interface (RFU2/2.5 GE2).
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. This
restriction is not relevant with TCC-U. For details, see Slot
Sections and 2.5 Gbps Mode on page 67.
In CeraOS 11.9.5, the following RFU configurations are supported per RIC-D:
• 1 x RFU-D
• 1x RFU-E
• 1 x RFU-S
Figure 38: RIC-D
Page 87 of 518

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

3.6 Radio Modem Cards (RMC)

The Radio Modem Card (RMC) provides the modem interface between the IDU
and RFU-C.
The 1RU IDU can accommodate up to five RMCs. The 2RU IDU can accommodate
up to ten RMCs.
IP-20N and IP-20A offer two types of RMC:
• RMC-A – RMC-A is based on the modem used in 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.
Note: RMC-A is not supported with TCC-U.
Figure 40: RMC-A Figure 41: RMC-B
Figure 42: 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 89 of 518

3.7 Ethernet Line Cards (LIC-X)

IP-20N and IP-20A offer 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/IP-50
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-U or TCC-B2-XG-MC.
Figure 43: LIC-X-E4-Elec (4x GbE) Figure 44: LIC-X-E4-Opt (4x GbE)
Page 90 of 518

Figure 45: LIC-X-E10 (1x 10G)
Figure 46: LIC-X-E4-Elec (4x GbE) Interfaces
Figure 47: LIC-X-E4-Opt (4x GbE) Interfaces
Page 91 of 518

Figure 48: 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 92 of 518

3.8 TDM Line Cards (LIC-T)

IP-20N and IP-20A offer the following types of TDM Line Cards (TDM LICs):
• LIC-T16 (16 x E1/DS1)
• LIC-T155 (1 x ch-STM-1/OC-3)
• LIC-STM1/OC3-RST (1 x STM-1/OC-3)
Figure 49: LIC-T16 (16 x E1/DS1) Figure 50: LIC-T155 (1 x ch-STM-1/OC-3)
Figure 51: LIC-STM1/OC3-RST (1 x STM-1/OC-3)
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 93 of 518

Figure 52: LIC-T16 (16x E1/DS1) Interfaces
Figure 53: LIC-T155 (1 x ch-STM-1/OC-3) Interfaces
Figure 54: LIC-STM1/OC3-RST (1 x STM-1/OC-3) 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 94 of 518

3.9 Power Distribution Cards (PDC)

The IDU 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 518.
Figure 55: Single-Input PDC Figure 56: 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 and IP-20A provide 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 95 of 518

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 57: 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 58: Standard PDC Interfaces Figure 59: Dual-Input PDC Interfaces
A 2RU IDU 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 96 of 518

-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 60: Power Distribution with Redundant PDCs
Page 97 of 518

3.10 Inventory Module (IVM)

Each IP-20N IDU 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 IDU software accesses the IVM to validate the
chassis type and hardware revision, and to verify the activation key for enabled
features and capacities.
Page 98 of 518

3.11 Fans Module

The IDU includes 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 61: Fans Module – 1RU Figure 62: 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 63: Fans Module Diagram
Page 99 of 518

3.12 Filter Tray (Optional)

IP-20N and IP-20A offer a filter as optional equipment. If a filter tray is not
ordered, the IDU is delivered with a blank filter slot cover.
Figure 64: Filter Tray Sliding into Filter Slot (2RU Chassis)
Page 100 of 518

4. RFU Hardware Description and Branching Options

The radio carrier functionality for IP-20N and IP-20A nodes is provided by Radio
Frequency Units (RFUs). With TCC-U, IP-20N and IP-20A can support up to 16 (2RU
chassis) or 7 (1RU chassis) RFUs. With other TCC models, IP-20N and IP-20A can
support up to ten (2RU chassis) or five (1RU chassis) RFUs.
IP-20N and IP-20A all work with the following RFUs:
Standard Power
• RFU-D
• RFU-E
• RFU-S
• RFU-C
High Power
• RFU-D-HP
• 1500HP
• RFU-HP
In addition, IP-20A operating in ANSI mode works with the following high-power
RFU designed uniquely for the North American market:
• RFU-A
Note: This Technical Description for Standard-Power Backhaul
Solutions describes the standard-power RFUs. For a description
of the high-power RFUs, refer to the Technical Description for IP-
20N and IP-20A – High-Power Backhaul Solutions.

• RFU Overview
• RFU Selection Guide
• RFU-D
• RFU-E
• RFU-S
• RFU-C
Page 101 of 518

4.1 RFU Overview

Ceragon 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, except RFU-A, can be
used with an IP-20N or an IP-20A. RFU-A is specifically designed for the North
American market, and can be used with IP-20A.
The Ceragon standard-power RFU portfolio includes RFUs that operate in the
microwave bands (6-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 standard-power 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)
• The following RFUs use RMC-A or RMC-B to interface with the IDU:
 RFU-C (6 – 42 GHz)
All standard-power RFUs can be installed in split-mount configurations.
For information about the IDU-RFU connection, see IDU-RFU Cable Connection on
page 518.
Page 102 of 518

4.2 RFU Selection Guide

The following table can be used to help you select the RFU that is appropriate to
your location.
Table 15: Standard-Power RFU Selection Guide
Character RFU-D RFU-E RFU-S RFU-C
Installation Type Direct Mount √ √ √ √
Remote Mount √ √ √ √
All-Indoor − − − −
Configuration 1+0 √ √ √ √
2+0 √ − − √
1+1 √ − √
2+2 √ − − √
N+0 ( N>2) √ − − −
SD support √ (BBC) − − √ (BBS)
Available Filter Diplexers √ √ √ √

Types
Channel Filters − − − −
Lowest Modulation BPSK BPSK BPSK QPSK
Highest Modulation 4096 QAM 1024 QAM 4096 QAM 2048 QAM
Frequency Range (GHz) 6 – 42 71 – 76, 6 – 42 6 – 42

81 – 86
Carriers per RFU 2 1 1 1
Supported Radio Cards RIC-D RIC-D RIC-D RMC-A,

RMC-B
Page 103 of 518

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 on page 137.
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 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 7-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 104 of 518

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:
 ETSI: 14 MHz – 112 MHz
 ANSI: 20 MHz – 80 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
 1+1 HSB
 1+1 HSB BBS or BBC Space Diversity
 MultiCore 2+2 SP/DP HSB
 MultiCore 2+2 SP/DP HSB with BBS 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.
Page 105 of 518

The following block diagram illustrates the functional modules of an RFU-D in a

2+0 configuration.
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
DAC TX Converter Driver
PA
2.5Gbps
H-Pole
+ POE
Mod-De
RX
ADC Rx Converter
CPU Radio
Figure 65: 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.
Page 106 of 518

Figure 66: RFU-D Radio Interfaces (6 to 15 GHz)
Figure 67: RFU-D Rear View (Left) and Front View (Right)
Figure 68: RFU-D Interfaces (All Frequency Bands)
Table 16: RFU-D Interfaces
Interface Description
P1 PoE / RFU Interface (RJ-45)

P2 RFU Interface (SFP)
P4 Data Sharing
Page 107 of 518

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 17 provides the marketing model structure for the RFU-D Easy Set radio
unit.
Table 18 provides the marketing model structure for the RFU-D Easy Set diplexer
unit.
Table 17: 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 18: 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 108 of 518

Figure 69: Radio Unit and Diplexer Unit
Table 19: 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 20: 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 109 of 518


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)
When using different diplexer types. ccWdd indicates the
diplexer associated with Antenna Port 1 and eeWgg
indicates the diplexer associated with Antenna Port 2.
t TX low / TX high indication L – TX Low
H – TX high
Table 21 provides examples of specific RFU-D diplexer unit marketing models based on the syntax described
above.
Table 21: 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 22: 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 23: RFU-D Marketing Model Structure– Possible Values

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


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)
When using different diplexer types. ccWdd indicates the
diplexer associated with Antenna Port 1 and eeWgg
indicates the diplexer associated with Antenna Port 2.
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 24: 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 25: 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 111 of 518

Figure 70: Splitter
Figure 71: OMT
Page 112 of 518

4.4 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.4.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
 ETSI: 14 MHz to 500 MHz
 FCC: 62.5 MHz to 500 MHz
costs
antenna types
4.4.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 113 of 518

RSL Source Sharing

Grounding Connector (PINs) (TNC)

DC
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 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 72: RFU-E Functional Block Diagram – 1+0 Configuration
Page 114 of 518

4.4.3 RFU-E Radio Interfaces

The following figures show the RFU-E TX and RX interfaces.
Figure 73: RFU-E Antenna Interfaces
Figure 74: RFU-D Front Side Interfaces
Page 115 of 518

Figure 75: RFU-E Interfaces
Table 26: RFU-E Interfaces

P3 Reserved for future use
4.4.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 27: 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 116 of 518

4.5 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
bandwidths from 14-112 MHz can be selected together with a range of
modulations. RFU-S provides a range of modulations from BPSK to 4096 QAM.
4.5.1 Main Features of RFU-S

• More power in a smaller package - Up to 28 dBm, ideal for long-range
applications
• Configurable Modulation – BPSK – 4096 QAM
 ETSI: 14 MHz – 112 MHz
costs
antenna types

• Specifications
4.5.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 117 of 518

RSL Source Sharing

Grounding Connector (PINs) (TNC)

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 76: RFU-S Functional Block Diagram – 1+0 Configuration
4.5.3 RFU-S Interfaces

The following figures show the RFU-S interfaces.
Figure 77: RFU-S Front Side Interfaces
Page 118 of 518

Figure 78: RFU-S Data and Power Interfaces
Table 28: RFU-S Interfaces

4.5.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.
Note: Not all fields are always necessary to define a valid marketing
model. If a specific field is not applicable, it should be omitted.
Page 119 of 518

4.5.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 29 provides the marketing model syntax for the RFU-S Easy Set radio unit.
Table 30 provides the marketing model syntax for the RFU-S Easy Set diplexer
unit.
Table 29: 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 30: 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 120 of 518

Figure 79: RFU-S Radio Unit and Diplexers Unit (Separate) Figure 80: RFU-S Radio Unit and Diplexers Unit (Attached)
Table 31: 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 32: : 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 121 of 518


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

LOW/HIGH or blank
H – TX high
Table 33 provides examples of specific RFU-S diplexer unit marketing models based on the syntax described
above.
Table 33: 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.5.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 34: 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 35: 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 122 of 518

The following are some examples of specific RFU-S 18 to 42 GHz marketing models based on the syntax
specified above.
Table 36: 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.5.5 RFU-S Mediation Devices

RFU-S requires a Coupler/Splitter for 1+1 configurations and an OMT for 2+2
configurations.
Figure 81: RFU-S Coupler/Splitter Figure 82: RFU-S OMT
Page 123 of 518

4.6 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-60 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.6.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
 ETSI: 3.5 MHz – 56 MHz
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 124 of 518

4.6.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 83: RFU-C Functional Block Diagram – 1+0 Configuration

• Specifications
Page 125 of 518

5. Activation Keys
This chapter describes the IP-20 and IP-50 activation key model. The IP-20 and IP-
50 families offer 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 IDU is considered a distinct device, regardless of which cards
are included in the IDU. 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
unit. 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 126 of 518

5.3 Activation Key Reclaim

If a customer needs to deactivate an IP-20 or IP-50 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 and IP-50
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 127 of 518

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

can be purchased for the features described in the following table.
Table 37: 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 131. 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 MultiCore Unique MultiCore
RFU-D. Architecture of RFU-D
SL-Radio-2nd-Rx-Port-Act Per RFU Enables use of second carrier on a MultiCore BBC Space Diversity
RFU-D for RX-only operation. The primary
application for this activation key is for slave
carriers in BBC Space Diversity
configurations.
SL-IDU-Radio-Port-Act. Per RIC-D Enables use of the second RFU port on a RIC- Radio Interface Cards (RIC)
D.
SL-NETCONF/YANG Per Device Enables use of NETCONF/YANG protocols, SDN Support
enabling customers to manage, configure,
and monitor network elements within the
paradigm of SDN network architecture using
Ceragon’s SDN Master controller.
L1 Link Bonding Per Device Enables use of Layer 1 Link Bonding. One Layer 1 Link Bonding
activation key per chassis enables the
configuration of up to four groups on the
unit.
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)
Page 128 of 518

SL-MC-ABC Per Carrier18 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.
SL-XPIC Per Carrier Enables the use of Cross Polarization Cross Polarization
Interference Canceller (XPIC). Each carrier in Interference Canceller (XPIC)
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. 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.
18
Note that STM-1-RST interfaces are not considered carriers and do not require an SL-MC-ABC
activation key.
Page 129 of 518

SL-GE-Port Per Port Enables the use of a TCC/LIC Ethernet traffic Traffic Control Cards (TCC)
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.
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 133. 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.
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-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
Page 130 of 518


activation key is also required to use
Synchronous Ethernet (SyncE).
SL-IEEE-1588-TC Per Device Enables IEEE-1588 Transparent Clock. This IEEE-1588v2 PTP Optimized
activation key is used for units with TCCs Transport
other than TCC-U.
SL-IEEE-1588-TC-BRCM Per Device Enables IEEE-1588 Transparent Clock. This IEEE-1588v2 PTP Optimized
activation key is used units with TCC-U. Transport
SL-IEEE-1588-BC Per Device Enables IEEE-1588 Boundary Clock. This IEEE-1588v2 PTP Optimized
activation key is used for units with TCCs Transport
other than TCC-U.
SL-IEEE-1588-BC-BRCM Per Device Enables IEEE-1588 Boundary Clock. This IEEE-1588v2 PTP Optimized
activation key is used units with TCC-U. 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 (SSH, Secure Communication
HTTPS, SFTP, SNMPv3, TACACS+, and Channels
RADIUS).
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).19
SL-LACP Per Device Enables Link Aggregation Control Protocol Link Aggregation Groups
(LACP). (LAG) and LACP
SL-NE-Anti-theft Per Device Enables Anti-Theft protection. Anti-Theft
Table 38: Capacity Activation Key Levels
Marketing Model Description Notes
SL-Capacity-50M SL - Capacity 50M, per carrier

19
PM support is planned for future release.
Page 131 of 518

Marketing Model Description Notes

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

Table 39: 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 Services20 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 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 use a CET upgrade activation key. The following table lists the
CET upgrade activation keys:
Table 40: Edge CET Note Upgrade Activation Keys
Marketing Model Upgrade From Upgrade To
SL-Upg Smart-Pipe/Edge-CET node NG Smart Pipe Activation Key (SL-0311-0) SL-Edge-CET-Node (SL-0312-0)
SL-Upg Edge/Agg-Lvl-1-CET node IP-20-SL-Edge-CET-Node (SL-0312-0) IP-20-SL-Agg-Lvl-1-CET-Node (SL-0313-0)
SL-Upg Agg-Lvl-1/Lvl-2-CET node IP-20-SL-Agg-Lvl-1-CET-Node (SL-0313-0) IP-20-SL-Agg-Lvl-2-CET-Node (SL-0314-0)
20
Including Point-to-Point, Multipoint, and TDM Pseudowire services. An SL-TDM-PW activation key is
also required to enable TDM Pseudowire services.
Page 133 of 518

6. Feature Description
This chapter describes the main IP-20N and IP-20A 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 134 of 518

6.1 Innovative Techniques to Boost Capacity and Reduce Latency

IP-20N and IP-20A utilize Ceragon’s innovative technology to provide a high
capacity low-latency solution. Header De-Duplication is one of the innovative
techniques that enables IP-20N and IP-20A to boost capacity and provide
operators with efficient spectrum utilization, with no disruption of traffic and no
addition of latency.
IP-20N and IP-20A also utilize 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
• Header De-Duplication
• Latency
• Frame Cut-Through
Page 135 of 518

6.1.1 Capacity Summary

Each carrier provides the following capacity:
• Supported Microwave Channels (ETSI) – 3.5/7/14/28/40/56/80/112 MHz
channels.
• Supported Microwave Channels (ANSI) – 5/10/20/25/30/40/50/60/80 MHz
channels.
• Supported E-Band Channels (ETSI) – 14/28/62.5/125/250/500 MHz channels.
• Supported E-Band Channels (ANSI) – 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 136 of 518

6.1.2 Unique MultiCore Architecture of RFU-D

RFU-D is a 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’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 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 an advantageous choice for deployment in numerous
heterogeneous network scenarios, such as small cells and fronthaul.
Figure 84: RFU-D MultiCore Modem and RFIC Chipsets
RFU-D’s parallel radio processing engine is what differentiates RFU-D from other
multiple-core solutions, which are really nothing more than multiple radio
systems compacted into a single box. RFU-D’s MultiCore architecture enables
RFU-D 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 137 of 518

6.1.2.1 Radio Script Configuration for Multiple Cores

When operating with two cores in a single RFU-D, 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’s MultiCore architecture is inherently versatile and suitable for many
different network deployment scenarios. A node using RFU-D 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’s MultiCore architecture, consider a
generic, 1+0 single-carrier radio with high performance in terms of capacity, link
distance, and antenna size.
Figure 85: Performance Characteristics of Generic, 1+0 Single-Carrier Radio
RFU-D 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,
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‘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 also maintains the same small form-factor.
Effectively, activating the second core provides a pure doubling of capacity
without any tradeoffs.
Page 138 of 518

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

The increased performance that RFU-D’s MultiCore architecture provides can be
leveraged to increase link distance. A node with an RFU-D 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 in a 1+0 configuration with only one core
activated, transmitting 280 Mbps over a 28/30 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/30 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’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’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’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’s MultiCore architecture. Relatively long-span links, which
previously required operation in lower, more congested, and more expensive
frequencies such as 6, 7, and 8 GHz, can be shifted to higher, less congested, and
Page 139 of 518

less expensive frequency bands such as 11 GHz with the help of RFU-D’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’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 or IP-20A using RFU-D, network operators can initially install the
MultiCore RFU-D 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 and IP-20A 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 140 of 518

The following table summarizes the cost benefits of RFU-D’s MultiCore technology
in terms of TCO.
Table 41: 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 141 of 518

6.1.3 Header De-Duplication

Header De-Duplication enables 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 and IP-20A still remove
the IFG and Preamble fields. This mechanism operates
automatically, even if Header De-Duplication is not selected by
the user.
Figure 87: 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 142 of 518

• 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.
IDU
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 88: 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 143 of 518

6.1.3.1 Header De-Duplication Counters

In order to help operators optimize Header De-Duplication, special counters are
provided 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 and IP-20A provide best-in-class latency (RFC-2544) for all channels,
making it the obvious choice for LTE (Long-Term Evolution) networks.
The ability of IP-20N and IP-20A 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 144 of 518

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 89: Propagation Delay with and without Frame Cut-Through
Page 145 of 518

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 90: 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 91: Frame Cut-Through Operation
Page 146 of 518

6.2 Radio Features

This chapter describes the main IP-20N and IP-20A 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 and IP-20A utilize Ceragon’s advanced ACM technology, and extends it to the
range of BPSK to 4096 QAM when using RFU-D or RFU-S, and BPSK to 1024 QAM
when using RFU-E.
IP-20N and IP-20A also support 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 supports multiple-carrier features such as Multi-Carrier ABC
and XPIC, utilizing its 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)
• Layer 1 Link Bonding
• Multiband
• ATPC
• Radio Signal Quality PMs
• Radio Utilization PMs
Page 147 of 518

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 148 of 518

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. It is
supported from CeraOS 10.0, and can be used with any TCC.
TCC-based Multi-Carrier ABC requires TCC-U, TCC-B-MC, or TCC-B2-XG-MC.
Multiple groups in a single unit and high capacity groups require TCC-U or TCC-B2-
XG-MC. For RIC-D cards, TCC-based Multi-Carrier ABC requires CeraOS 10.5 or
higher and TCC-U or 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/DS1/CH-STM1/OC3
Engine E1
LIC
Srv
TDM Crossconnect
E1 Services
PW
TDM E1/DS1/CH-STM1/OC3
E1
Srv
LIC
STM1/OC3 STM1/OC3 RST
RST LIC
RMC-B or
IF STM1/OC3 STM1/OC3 RST
RIC-D
RST LIC
STM1/OC3 STM1/OC3 RST
RST LIC
Figure 92: TCC-Based Multi-Carrier ABC Traffic Flow
Page 149 of 518

6.2.1.2 Multi-Carrier ABC with RIC-D

The following restrictions apply to TCC-based Multi-Carrier ABC with RIC-D cards:
• With TCC-B-MC or TCC-B2-XG-MC, the RIC-D cards must be placed in Slots 3,
4, 5, and/or 6. This is true for both 1RU and 2RU chassis. This limitation only
applies to MultiCore configurations, i.e., configurations using both carriers of
an RFU-D.
• With TCC-U, the RIC-D cards must be placed in Slots 2, 3, 4, and/or 12 (2RU
chassis) or 2, 3, and/or 4 (1RU chassis). This limitation only applies to
MultiCore configurations, i.e., configurations using both carriers of an RFU-D.
• 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.
• 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.
TCC-based Multi-Carrier ABC cannot be used with the RFU ports on the front
panel of a TCC-U (RFU1 and RFU2).
If you want to use one or more 2+0 Multi-Carrier ABC groups with RFU-D, 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 67.
For a full comparison between the advantages and requirements of TCC-based
and RFU-based Multi-Carrier ABC, see Table 42: 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.
Page 150 of 518

Table 42: RIC-D Multi-Carrier ABC – RFU-Based vs. TCC-Based
RFU-Based Multi-Carrier ABC TCC-Based Multi-Carrier ABC
Supported Configurations Up to 12 X 2+021 Up to 4 X 2+022, Up to 2 X 4+0, Up to 8+0

Supported RFUs RFU-D RFU-D
Minimum CeraOS Version 10.0 10.5
TCC Requirement Any TCC TCC-U, TCC-B-MC, or TCC-B2-XG-MC (multiple
or high capacity groups require TCC-U or TCC-
B2-XG-MC)
XPIC Support Yes Yes
Permitted Slots Any slot that supports RIC-D TCC-B-MC, or TCC-B2-XG-MC: 3, 4, 5, 6
TCC-U: 2, 3, 4, 12
Note: This limitation only applies to
MultiCore configurations, i.e., configurations
using both carriers of an RFU-D.
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. For units with TCC-U, all groups
have 2.5 Gbps.
21
Requires TCC-U. Otherwise, the maximum is 4 x 2+0.
22
Not available with TCC-U.
Page 151 of 518

6.2.1.3 Multi-Carrier Configurations

In Hybrid MC-ABC mode, IP-20N and IP-20A support the following configurations.
For a detailed list of configurations supported by each RFU, see Supported Radio
Configurations on page 35.
• Supported with both TCC-U, 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-U and TCC-B2-XG-MC:
 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+0 BBC Space Diversity
 2 X 2+0 BBC Space Diversity
 4+0 BBC Space Diversity
 2 X 4+0 BBC Space Diversity
• Supported with TCC-B2-XG-MC only:
• Supported with RIC-D and all TCCs, using two carriers in a single MultiCore
RFU-D:
 4 X 2+0 (XPIC)
 4 X 1+1 HSB/SD23
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.
23
4 X 1+1 HSB/SD is planned for future release.
Page 152 of 518

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 Multi-Carrier ABC Robustness

Multi-Carrier ABC Robustness is a feature that gives operators the ability to
automatically remove a radio member from the Multi-Carrier ABC group
temporarily when the member is experiencing unstable conditions, such as an
open or shorted cable, a power failure, or an RFU communication failure. In such
scenarios, removing the member stabilizes the group’s performance so that the
problem can be resolved while the group continues to function normally.
Multi-Carrier ABC Robustness is configured per group. When enabled, the
mechanism removes a radio member when the member experiences a user-
defined number of hardware failures (3-10) within a pre-defined period (1-24
hours). The member is automatically restored to the group if and when a pre-
defined period (from one hour to one week) passes without such events.
Alternatively, the feature can be defined so that the member is permanently
disabled within the group.
To restore a member that has been permanently disabled within the group, or to
reset the Robustness mechanism, the user can do one of the following:
• Disable, then re-enable the Robustness feature.
• Disable, then re-enable the interface.
• Reset the unit.
The Robustness mechanism does not remove the last remaining member of a
Multi-Carrier ABC group even in the event of repeated hardware failures. This is to
ensure that in-band management is not lost due to operation of the Robustness
mechanism.
When the Robustness mechanism removes a member from a Multi-Carrier ABC
group, an alarm is raised (MC-ABC member has been disabled due to robustness
reason – Alarm Number 2213).
Page 153 of 518

The following events are considered hardware failures that can trigger removal of
an interface:
• Radio card extraction
• Radio card reset
• Disconnected IDU-RFU cable
Notes: For RIC-D, these events raise a Radio Unit communication failure
alarm (Alarm ID 1730).
For RMC-B, these events raise an RFU communication failure

alarm (Alarm ID 1703).
Radio failures, such as LOF or BER, are not considered hardware

failures.
Multi-Carrier ABC Robustness does not operate with HSB radio protection. It is
only available for TCC-based groups, not RFU-based groups.
6.2.1.6 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.7 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 239) in cases where the operator wants traffic from an upstream
switch connected to another IP-20 or IP-50 unit to be re-routed whenever the link
is providing less than a certain capacity.
Page 154 of 518

External
Switch LAG
Ethernet Link Ethernet Link Multi-Carrier ABC Link
Upstream IP-20 Unit IP-20N
Alternate Link
Figure 93: Multi-Carrier ABC Minimum Bandwidth Override
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
Redundancy, but not with HSB radio protection.
6.2.1.8 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.9 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.10 TDM Traffic Handling

Three types of TDM services are supported by the system:
• STM-1/OC-3-RST Services
• Native E1/DS1 Trails
• E1/DS1 Pseudowire Services
Page 155 of 518

STM-1/OC-3 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/OC-3 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/OC-3 RST traffic.
Any cross connect of the SDH/SONET traffic should be done externally.
Native E1/DS1 Trails

E1/DS1 services are implemented by the LIC-T16 or LIC-T155. The E1/DS1 services
enable use of the internal Cross Connect functionality of the system. E1/DS1
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/DS1 service trails
are forwarded to the Hybrid MC-ABC with specific VC marking.
E1/DS1 Pseudowire Services

Pseudowire E1/DS1 services using LIC-T16 or LIC-T155 LICs are handled by the
Hybrid MC-ABC as Ethernet frames.
6.2.1.11 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 156 of 518

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 94: 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.
IP-20N and IP-20A support several methods for implementing Space Diversity:
• Baseband Combining (BBC) – External – 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.
• Baseband Combining (BBC) – Internal – The received signals of the two
carriers in a single RFU are shared and combined to produce an optimized
received signal. Supported with RFU-D-HP.24
24
For further information, refer to the Technical Description for IP-20N and IP-20A – High-Power
Backhaul Solutions. 1+1 HSB with BBC Space Diversity is also supported with RFU-D.
Page 157 of 518

• Baseband Switching (BBS) – The IDU chooses, at any given moment, the best
received signal from between two radio carriers. Supported with RFU-C.
Table 43: Space Diversity Methods
Baseband Switching Baseband Switching (BBS) Baseband Combining Baseband Combining

(BBS) with RMC-B with RIC-D (BBC) - External (BBC) - Internal
Supported 1+1, 2+2 1+1, 2+2 2+0, 2x(2+0), 4+0, 1+1

Configurations 2x(4+0) (XPIC only)
Supported RFUs RFU-C RFU-D RFU-D RFU-D
Minimum CeraOS All 10.7 10.7 11.3
Version
Radio Card RMC-B RIC-D RIC-D RIC-D
Requirements
TCC Requirement TCC-U, TCC-B-MC, TCC-U, TCC-B-MC, TCC B2- TCC-U, TCC-B2-XG- TCC-B2-XG-MC
TCC B2-XG-MC XG-MC MC
XPIC Option Yes Yes Yes (only XPIC) No
Permitted Slots All slots that 1+1: All slots that support All slots that All slots that support
support radio cards radio cards support radio radio cards.
2+2: cards.
• TCC-B-MC, TCC B2-XG-
MC : Slots 3,4, 5,
and/or 6.
• TCC-U: Slots 2, 3, 4,
and/or 12
LIC-STM1/OC3-RST Yes Yes Yes Yes
Page 158 of 518

6.2.2.1 BBC Space Diversity

Note: BBC Space Diversity requires RIC-D, with RFU-D. Most types of
BBC Space Diversity require TCC-U or TCC-B2-XG-MC. However,
1+0 Space Diversity (Internal) can be implemented with any TCC.
Internal Space Diversity requires RFU-D-HP.
RFU-D can perform Space Diversity via Baseband Combining (BBC). The BBC
mechanism provides up to 3 dB in system gain.
IP-20N and IP-20A with standard-power RFUs support External BBC Space
Diversity. External Space Diversity utilizes
• External BBC Space Diversity – Consists of two or four RFU-D units, where
each unit is either a Master RFU or a Slave RFU. The following External SD
configurations are available:
 2+0 SD
 2 X 2+0 SD
 4+0 SD
 2 X 4+0 SD
• Internal BBC Space Diversity – Consists of two RFU-D units. For each RFU, one
radio carrier is the Master and the other is the Slave. The following Internal SD
configurations are available:
◦ 1+1 HSB-SD25
External BBC Space Diversity

The basic building block of each of these External Space Diversity configurations is
a 2+0 SD configuration that consists of two RFU-D 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 IDU 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.
25
For more information about 1+1 HSB-SD, and about Space Diversity options with HSB for RFU-D in
general, see HSB with RFU-D on page 181.
Page 159 of 518

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.
In 2+0 SD and 2 x 2+0 configurations, the Multi-Carrier ABC group can be TCC-
based or RFU-based Multi-Carrier ABC.
In 4+0 SD and 2 x 4+0 configurations, the Multi-Carrier ABC group must be TCC-
based Multi-Carrier ABC.
When using RFU-based Multi-Carrier ABC:
• Any type of TCC can be used.
• The maximum profile limitations for Scripts 4905 (80 MHz) and 4911 (112
MHz) are removed, so that these scripts can be configured to their maximum
allowed profiles. See BBC Space Diversity MRMC Scripts on page 161.
When using TCC-based Multi-Carrier ABC, the 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.
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.
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
H
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 95: 2+0 BBC Space Diversity (External)
Page 160 of 518

BBC Space Diversity MRMC Scripts

The following MRMC scripts can be used for BBC Space Diversity with RFU-D:
• MRMC Script 4901 – 28/30 MHz
• MRMC Script 4902 – 40 MHz
• MRMC Script 4903 – 56/60 MHz
• MRMC Script 4905 – 80 MHz
• MRMC Script 4911 – 112 MHz (ETSI only)
Note: If you are using TCC-based Multi-Carrier ABC:
For Script 4905, do not set the maximum profile higher than 8.
For script 4911, do not set the maximum profile higher than 5.
These limitations apply for both ACM and Fixed modes. These
limitations only apply when the script is applied to a carrier that
belongs to a TCC-based Multi-Carrier ABC group. They do not
apply to other carriers in the chassis, and they do not apply to
RFU-based Multi-Carrier ABC groups.
Using these scripts, XPIC runs in the background.
For details, see MRMC Scripts Supported with RIC-D, with RFU-D and RFU-S on
page 366.
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:
• With TCC-B2-XG-MC:
 Master RFU: Slots 3, 4, 5, 6
 Slave RFU: Slots 7, 8, 9, 10
• With TCC-U:
 Master RFU: Slots 2, 3, 4, 12
 Slave RFU: Slots 7, 8, 9, 10
Page 161 of 518

Figure 96 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.

TCC-U (Optional)
7 – RIC-D 8 - Traffic 9 - Traffic 10 -Traffic
(Slave)
Filter
Fans
3 -RIC-D 4 -RST 5 -Traffic 6 -Traffic
(Master)
TCC-U
Figure 96: Sample Chassis Configuration – 2+0 BBC Space Diversity
Figure 97 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.

TCC-U (Optional)
7 – RIC-D 8 – RIC-D 9 - Traffic 10 -Traffic
(Slave) (Slave)
Filter
Fans
3 -RIC-D 4 -RIC-D
(Master) (Master) 5 -Traffic 6 -Traffic
TCC-U
Figure 97: Sample Chassis Configuration – 4+0 BBC Space Diversity
Page 162 of 518

Figure 98 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.

TCC-U (Optional)
7 – RIC-D 8 – RIC-D 9 - Traffic 10 -Traffic
(Slave) (Slave)
Filter
Fans
(Master) (Master)
TCC-U
Figure 98: Sample Chassis Configuration – 2 X 2+0 BBC Space Diversity
Page 163 of 518

Figure 99 illustrates a recommended slot placement use case for 2X 2+0 BBC
Space Diversity. In this example:
• The RIC-D in Slot 5 (TCC-B2-XG-MC) or Slot 2 (TCC-U) is connected to a Master
RFU.
• The RIC-D in Slot 6 (TCC-B2-XG-MC) or Slot 12 (TCC-U) is connected to a
Master RFU.
• 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 (TCC-B2-XG-MC) or Slots 2 and 12 (TCC-U).

(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 99: Sample Chassis Configuration – 2 X 4+0 BBC Space Diversity – TCC-B2-XG-MC
Page 164 of 518

11 – TCC-U (Optional) 12 – RIC-D PDC2

(Master)
7 – RIC-D 8 – RIC-D 9 – RIC-D 10 – RIC-D
Filter (Slave) (Slave) (Slave) (Slave)
Fans
(Master) (Master)
1 – TCC-U 2 – RIC-D PDC1
(Master)
Figure 100: Sample Chassis Configuration – 2 X 4+0 BBC Space Diversity – TCC-U
Page 165 of 518

6.2.2.2 BBS Space Diversity

Note: BBS Space Diversity requires TCC-U, TCC-B-MC, or TCC-B2-XG-
MC. BBS Space Diversity configurations using RIC-D and HSB
radio protection are described separately. See HSB with RFU-D
on page 169.
BBS Space Diversity requires two antennas and RFUs. The antennas must be
separated by approximately 15 to 20 meters. Any supported RFU type 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 101: BBS Space Diversity
2+2 BBS with Multi-Carrier ABC is also supported with optional XPIC.
6.2.2.3 IF Combining
Note: IF Combining 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 166 of 518

6.2.3 HSB Protection

IP-20N and IP-20A offer 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.
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/RIC or RFU, the standby RMC/RIC and RFU switches
to active mode.
Each RMC or RIC 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 or RICs must have the same configuration.
• The RFUs must be the same type and must have the same configuration.
IP-20N and IP-20A include a mismatch mechanism that detects if there is a
mismatch between the radio configurations of the local and mate RMC/RICs 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 RMC/RICs. Once the mismatch mechanism
detects a configuration mismatch, it raises a Mate Configuration Mismatch alarm.
When the configuration of the active and standby RMC/RICs is changed to be
identical, the mechanism clears the Mate Configuration Mismatch alarm.
In order to align the configuration between the active and standby RMC/RICs, the
user must first complete the required configuration of the active RMC or RIC, and
then perform a copy-to-mate command. This command copies the entire
configuration of the active RMC or RIC to the standby RMC or RIC to achieve full
configuration alignment between the active and standby RMC/RICs. The
command also initiates a reset of the standby RMC or RIC. As soon as the standby
RMC or RIC is up and running, its configuration is aligned to the configuration of
the active RMC or RIC . This operation has no effect on the active RMC or RIC.
When a pair of RMC/RICs and RFUs are defined as a 1+1 HSB pair, any
configuration performed on the active RMC or RIC will be automatically copied to
the standby RMC or RIC, in order to maintain the RMC/RIC configuration
alignment. This makes it unnecessary to perform a copy-to-mate command when
a configuration change is made.
Page 167 of 518

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 102: Path Loss on Secondary Path of 1+1 HSB Protection Link
IP-20N and IP-20A support revertive HSB protection for both 1+1 and 2+2 HSB
configurations. In revertive HSB protection mode, the 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 168 of 518

6.2.3.3 HSB with RFU-D

RFU-D, because of its MultiCore design, can be used in a variety of HSB
configurations that combine HSB radio and equipment protection with BBS and
BBC Space Diversity, as well as XPIC.
The following HSB configurations can be used with RFU-D:
• 1+1 HSB
• 1+1 HSB-SD (BBS Space Diversity)
• 1+1 HSB-SD (BBC Space Diversity)
• 2+2 HSB (Single Polarization)
• 2 x 2+2 HSB (Single Polarization)
• 2+2 HSB with XPIC (Dual Polarization)
• 2 x 2+2 HSB with XPIC (Dual Polarization)
• 2+2 HSB-SD (BBS Space Diversity – Single Polarization)
• 2 x 2+2 HSB-SD (BBS Space Diversity – Single Polarization)
• 2+2 HSB-SD with XPIC (BBS Space Diversity – Dual Polarization)
• 2 x 2+2 HSB-SD with XPIC (BBS Space Diversity – Dual Polarization)
1+1 HSB (Single Polarization)

1+1 HSB (single polarization) uses two RFU-D units connected to a single antenna
to provide radio protection. The active RFU operates in single-core (1+0) mode. In
case of radio or equipment failure, the standby RFU becomes the active RFU, and
the 1+0 link is preserved. Both RFUs use only radio carrier 1 in this configuration.
This configuration requires the user to configure a 1+1-HSB Radio Protection
group that consists of radio carrier 1 in each RFU.
STM1/OC3-RST interfaces cannot be used with this configuration.
1+1 HSB-SD (BBS Space Diversity)

1+1 HSB-SD with BBS Space Diversity uses two RFU-D units, each connected to a
single main and a single diversity antenna. Only radio carrier 1 is used in each RFU.
In normal operation, the active carrier transmits and receives via the main path
and the standby carrier receives only via the diversity path. The diversity switching
is performed in the IDU backplane.
In the event of switchover, Space Diversity is lost until recovery, but the link
continues to function as an ordinary 1+0 link without Space Diversity.
This configuration requires the user to configure the following groups:
• Radio Protection: A 1+1-HSB-SD group, consisting of radio carrier 1 on each
RFU.
• Multi-Carrier ABC: A TCC-based Multi-Carrier ABC group that includes the
Radio Protection group.
STM1/OC3-RST interfaces can be used with this configuration.
Page 169 of 518

1+1 HSB-SD (BBC Space Diversity)

1+1 HSB-SD with BBC Space Diversity uses two RFU-D units, each connected to a
single main and a single diversity antenna. Each RFU functions as a 1+0 Internal
Space Diversity configuration, one active and one standby.
In each RFU, radio carrier 1 transmits and receives via the main path and radio
carrier 2 is muted and receives via the diversity path. The diversity combining is
performed within the RFU itself.
This configuration requires the user to configure the following groups:
• Space Diversity: A separate AMCC group for the two carriers of each RFU.
These are internal Space Diversity groups.
• Radio Protection: A 1+1-HSB-SD group, consisting of radio carrier 1 (Master)
on each RFU.
2+2 HSB (Single Polarization)

2+2 HSB (single polarization) configuration uses two RFU-D units connected to a
single antenna to provide radio protection. Each RFU is configured as a 2+0
configuration that includes both of that RFU’s radio carriers. In case of radio or
equipment failure, the standby RFU becomes the active RFU, and the 2+0 link is
preserved.
This configuration requires the user to configure a the following groups:
• Multi-Carrier ABC: A separate RFU-based Multi-Carrier ABC group for the two
carriers of each RFU. These groups must be created before creating the Radio
Protection group.
• Radio Protection: A 2+2-HSB group consisting of each RFU (radio-unit).
2+2 HSB with XPIC

2+2 HSB-XPIC (dual polarization) uses two RFU-D units connected to a single
antenna to provide XPIC, along with radio protection. Each RFU is configured as a
2+0 XPIC configuration that includes both of that RFU’s radio carriers. In case of
radio failure, the standby RFU becomes the active RFU, and the 2+0 XPIC link is
preserved.
• Multi-Carrier ABC: A separate RFU-based Multi-Carrier ABC group for the two
carriers of each RFU. These groups must be created before creating the Radio
Protection group.
• XPIC: A separate XPIC group on each RFU consisting of both carriers on the RFU.
• Radio Protection: A 2+2-HSB group that includes each RFU (radio unit).
Page 170 of 518

2+2 HSB-SD (BBS Space Diversity – Single Polarization)

2+2 HSB-SD with BBS Space Diversity (single polarization) uses two RFU-D units.
One unit is connected to the main antenna, the other to the diversity antenna.
Each RFU functions as a 2+0 single polarization configuration. Both carriers on the
active RFU transmit and receives via the main path. Both carriers on the standby
RFU are muted and receive via the diversity path. The diversity switching is
performed in the IDU backplane.
continues to function as an ordinary 2+0 link without Space Diversity.
Note: In this configuration, the RIC-D cards must be placed in Slots 3, 4,
5, and/or 6 (TCC-B-MC or TCC-B2-XG-MC) or Slots 2, 3, 4, and/or
12 (TCC-U).
• Radio Protection: A 2+2-HSB-SD group consisting of each RFU (radio-unit).
2+2 HSB-SD XPIC (BBS Space Diversity – Dual Polarization)

2+2 HSB-SD XPIC with BBS Space Diversity uses two RFU-D units. One unit is
connected to the main antenna, the other to diversity antenna. Each RFU
functions as a 2+0 XPIC configuration. Both carriers on the active RFU transmit
and receive via the main path. Both carriers on the standby RFU receive via the
diversity path, and do not transmit. The diversity switching is performed in the
IDU backplane.
continues to function as an ordinary 2+0 XPIC link without Space Diversity.
Note: In this configuration, the RIC-D cards must be placed in Slots 3, 4,
5, and/or 6 (TCC-B-MC or TCC-B2-XG-MC) or Slots 2, 3, 4, and/or
12 (TCC-U).
• Radio Protection: A 2+2-HSB-SD group consisting of each RFU (radio-unit).
• XPIC: A separate XPIC group on each RFU consisting of both carriers on the
RFU.
Page 171 of 518

Configuring HSB with RFU-D

The options described above can all be configured via a Quick Configuration
wizard in the Web EMS, and it is recommended to do so.
For further information about configuring these options, refer to Configuring HSB
Radio Protection with RIC-D and RFU-D or RFU-D-HP in the User Guide for IP-20N
and IP-20A.
Page 172 of 518

6.2.4 Adaptive Coding Modulation (ACM)
This feature requires:

• ACM script
Related topics:
• Quality of Service (QoS)
IP-20N and IP-20A employ full-range dynamic ACM. The ACM mechanism copes
with 90 dB per second fading in order to ensure high transmission quality. The
ACM mechanism is designed to work with the 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 Ceragon’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 173 of 518

6.2.4.1 Up to 13 Working Points

IP-20N and IP-20A implement ACM with up to 13 available working points. The
number of working points depends on the type of RFU or RMC used.
Table 44: ACM Working Points (Profiles) – RIC-D with Microwave RFUs
Working Point (Profile) Modulation
Profile 0 BPSK
Profile 1 QPSK
Profile 2 8 QAM
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 45: ACM Working Points (Profiles) – RIC-D with E-Band RFU (RFU-E)
Profile 0 BPSK
Profile 1 QPSK
Profile 2 8 QAM
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 174 of 518

Table 46: ACM Working Points (Profiles) – RMC-A
Profile 0 QPSK
Profile 1 8 QAM
Profile 2 16 QAM
Profile 3 32 QAM
Profile 4 64 QAM
Profile 5 128 QAM
Table 47: ACM Working Points (Profiles) – RMC-B
Profile 0 QPSK
Profile 1 8 QAM
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 175 of 518

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 103: 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/30 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 176 of 518

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 Hysteresis Value

When stepping down to a lower profile, the switch is initiated when the RSL is
approximately 3.5 dB higher than the threshold for the current profile. When
stepping up to a higher profile, the switch is initiated when the RSL is
approximately 5 dB higher than the threshold for the higher profile.
6.2.4.5 ACM PMs

Users can configure two thresholds, per radio carrier, for the ACM profile. These
thresholds enable users to monitor ACM profile fluctuations by displaying the
number of seconds, per 15-minute or 24-hour interval, that the ACM profile drops
beneath each profile threshold.
In addition, these thresholds trigger the following alarms:
• Threshold 1 – When the ACM profile goes beneath this threshold, Alarm ID
1313 (Major) is raised. The alarm is cleared when the ACM profile is at or
above this threshold.
• Threshold 2 – When the ACM profile goes beneath this threshold, Alarm ID
1314 (Critical) is raised. The alarm is cleared when the ACM profile is at or
above this threshold.
6.2.4.6 ACM Benefits

The advantages of 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
Page 177 of 518

6.2.4.7 ACM and Built-In QoS

The ACM mechanism is designed to work with the 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 the unit 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.8 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).
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 178 of 518

6.2.4.9 ACM with Adaptive Transmit Power

• ACM script
• When working with RFU-C, requires RFU software version 2.17 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 and IP-20A are
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 the 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 179 of 518

Figure 104: ACM with Adaptive Power Contrasted to Other ACM Implementations
Page 180 of 518

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 105: 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. The XPIC algorithm enables detection of both streams even
under the worst levels of XPD such as 10 dB. This is accomplished 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, XPIC is implemented using two different RMCs and RFUs. For slot
placement guidelines, see Adjacent Pair Guidelines on page 66.
For RIC-D, XPIC is supported with MultiCore RFU-D, using the two carriers in a
single RFU as the XPIC pair.
6.2.5.1 XPIC Benefits

The advantages of XPIC include BER of 10e-6 at a co-channel sensitivity of 5 dB.
Page 181 of 518

6.2.5.2 XPIC-Ready MultiCore 1+0 Links

MultiCore RFU-D can be installed initially in single-core mode, hardware ready for
2+0 Dual Polarization (XPIC). Later, when the operator is ready to expand network
capacity, the link can be converted to a 2+0 XPIC link remotely by uploading and
installing the activation keys for XPIC and for the second core and activating the
second core and XPIC.
When installing a MultiCore 1+0 link which is hardware ready for 2+0 XPIC, the
operator must plan and install the link as if it is immediately being configured as
an XPIC link. This includes both link budget calculation and hardware installation.
The OMTs must be carefully aligned according to the XPIC alignment procedure.
Activation key Demo Mode can be used to activate the second radio interface for
purposes of alignment. After completing alignment, the regular activation key
should be installed and the link configured for 1+0 operation.
Failure to follow these steps may limit the ability to remotely upgrade a 1+0 link
to a 2+0 XPIC link at a later date.
6.2.5.3 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-20 IP-20
Figure 106: XPIC Implementation – RFU-C
Page 182 of 518

V V+h V
Modem Modem
h
v
Modem Modem
H H+v H
RFU-D RFU-D
Figure 107: XPIC Implementation – RIC-D with RFU-D
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.
Figure 108: XPIC – Impact of Misalignments and Channel Degradation
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.4 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.
Page 183 of 518

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.
6.2.5.5 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.
6.2.5.6 XPIC with RIC-D

XPIC with RIC-D requires RFU-D, and can be configured in the following ways:
• Internal XPIC – XPIC is configured between the two carriers of a single RFU.
• External XPIC – XPIC is configured between two RFU-Ds connected to two RIC-
Ds. This configuration is called “External” XPIC, since the second polarization is
provided by a second RFU rather than the second radio carrier of the same
RFU. Thus, the second member of the XPIC group is “external” to the first
member.
External XPIC with RFU-D can only be configured without Internal BBC Space
Diversity. Each RFU uses only its first radio carrier. If a in a 2+0 External XPIC
configuration one of the RFUs stops functioning, the link continues to function as
a 1+0 link until the problem is resolved and the link resumes operating as a 2+0
XPIC link.
In each External XPIC pair, the two RFUs must be connected with the following
cables:
• A source sharing cable between the EXT REF ports of the two RFUs.
• A data sharing cable between the P4 ports of the two RFU-Ds.
Page 184 of 518

For details about these cables, refer to the Installation Guide for RFU-D.
The software automatically considers the RFU connected to the lower slot to be
the vertical RFU. For example, in a configuration using slots 3 and 4, slot 3 must be
the vertical RFU. In a configuration using slots 5 and 6, slot 5 must be connected
to the vertical RFU. This cannot be modified via the software. Therefore, it is
vitally important to connect the RFU connected to the lower slot during
installation as the vertical RFU and the RFU connected to the upper slot as the
horizontal RFU.
Note: For purposes of synchronization, the vertical RFU is automatically
assigned the Master role.
Up to four External 2+0 XPIC pairs can be configured in a single IDU. These pairs
can be joined in a single 8+0 Multi-Carrier ABC group. Table 48 shows the number
of groups supported per IDU.
Table 48: External XPIC Configurations
Configuration Number of Number of Number of XPIC Number of Multi-Carrier

RIC-Ds RFUs groups ABC Groups
2+0 XPIC 2 2 1 1
4+0 XPIC 4 4 2 1
6+0 XPIC26 6 6 3 1
8+0 XPIC26 8 8 4 1
2 x 2+0 XPIC 4 4 2 2
2 x 4+0 XPIC26 8 8 4 2
4 x 2+0 XPIC26 8 8 4 4
External XPIC is supported with all TCCs that support Multi-Carrier ABC
configurations (TCC-U, TCC-B-MC, and TCC-B2-XG-MC).
Note: In External XPIC configurations, the capacity of each carrier is
limited to 600 Mbps per member.
Only certain scripts can be used with External XPIC. For details, refer to the User
Guide for the CeraOS version you are using.
26
Requires 2RU IDU.
Page 185 of 518

6.2.6 Layer 1 Link Bonding

Layer 1 Link Bonding aggregates up to 16 radio carriers into a single link. The Link
Bonding mechanism performs traffic distribution by segmenting and re-
assembling the data stream and dividing it among the radio channels in the Link
Bonding group. Each segment is a valid Ethernet packet with a proprietary header
added.
Traffic is distributed symmetrically until a member of the Link Bonding group
reaches its individual capacity. Remaining traffic is distributed symmetrically
among the remaining group members. If a member of a Link Bonding group goes
down, traffic is automatically redistributed to the other members with no traffic
loss.
Layer 1 Link Bonding requires TCC-U, which implements Link Bonding-based traffic
distribution. Link Bonding is supported with both RIC-D and RMC-B, and a single
Link Bonding group can include both RIC-D and RMC-B members together.
With RIC-D, the following Link Bonding configurations are supported:
• Up to 16+0
• 2 x 8+0
• 4 x 4+0
With RMC-B, the following Link Bonding configurations are supported:
• Up to 10+0
• 2 x 5+0
• 4 x 2+0
In addition to these configurations, an IP-20N or IP-20A can be used with certain
IP-50 and IP-20 all-outdoor units to provide the following Link Bonding
configurations:
• IP-50E (1+0) and RMC-B (2+0 XPIC) – Combines a 1+0 E-band unit (IP-50E) and
a 2+0 Microwave XPIC configuration that utilizes two RFU-Cs connected to
two RMC-Bs. The result is a Multiband link that consists of three carriers on
each side of the link.
• IP-50E (2+0 XPIC) and RIC-D (up to 6+0) – Combines a high-capacity E-band
2+0 XPIC configuration with up to 6 Microwave carriers. The Microwave
configuration is implemented by using up to three Multicore RFU-D or RFU-D-
HP RFUs. Each RFU is configured as an RFU-based Multi-Carrier ABC group.
The result is a Multiband link that consists of two E-band and up to six
Microwave carriers on each side of the link.
• IP-50E (1+0) and IP-50C (4+0) – Combines a 1+0 E-band unit (IP-50E) and two
MultiCore IP-50C units, for a total of one E-band carrier and 4 Microwave
carriers. Each IP-50C is configured as a 2+0 Multi-Carrier ABC group. The result
is a Multiband link that consists of one E-band and four Microwave carriers on
• IP-50C (4+0) and RIC-D (4+0) – Combines two MultiCore IP-50C units with two
MultiCore RFU-D or RFU-D-HP units to form a link that consists of eight
Microwave carriers on each side of the link.
Page 186 of 518

• IP-50C (2+0) and IP-20C (4+0) – Combines one MultiCore IP-50C unit with two
MultiCore IP-20C units to form a Microwave link that consists of six carriers on
• IP-50C (2+0) and IP-20C or IP-20C-HP (2+0) and RIC-D (2+0) – Combines one
MultiCore IP-50C, one MultiCore IP-20C or IP-20C-HP, and one MultiCore RFU-
D or RFU-D-HP to form a Microwave link that consists of six carriers on each
side of the link.
Note: For IP-20C, ESS and ESX hardware versions are both supported
with these Link Bonding configurations.
Like all IP-20N/IP-20A Link Bonding configurations, these configurations require
TCC-U, which implements Link Bonding-based traffic distribution. Up to four IP-
50/IP-20 all-outdoor units can be used with a single IP-20N/IP-20A unit.
An IP-20N or IP-20A with TCC-U can support up to four Link Bonding groups with a
maximum aggregated capacity of 30 Gbps for all the Link Bonding groups
configured on the unit.
A Link Bonding group can include up to eight RIC-D or up to 10 RMC-B radio cards
(RIC-D or RMC-B). A 16+0 link can be achieved by using eight RIC-Ds, each
connected to an RFU-D with RFU-based Multi-Carrier ABC configured between the
two carriers of each RFU.
There is no restriction on configuring Link Bonding groups and Multi-Carrier ABC
groups on the same unit. However, only RFU-based Multi-Carrier ABC groups can
be members of a Link Bonding group. TCC-based Multi-Carrier ABC groups cannot
be members of a Link Bonding group, but can be used in the same IDU as a Link
Bonding group.
Each MultiCore RFU and all-outdoor unit in the Link Bonding group can be
configured in either a single-polarization or an XPIC configuration. Additionally,
different RFUs can use different frequencies, providing operators with more
flexibility to utilize the available frequency spectrum in whatever way is most
efficient.
Layer 1 Link Bonding can provide an upgrade path for existing IP-20N or IP-20A
nodes, enabling operators to significantly increase the link’s capacity while
retaining the same hardware configuration and cabling. For units with older TCC
models, TCC-U can be easily installed in order to utilize the increased capacity of
TCC-U and Link Bonding, thereby facilitating conversion to 5G without the need
for extensive hardware upgrade or replacement.
Page 187 of 518

6.2.6.1 Cable Requirements for Link Bonding Configurations with All-Outdoor Units
When an all-outdoor IP-50 or IP-20 unit is used in a Layer 1 Link Bonding
configuration with an IP-20N/IP-20A, the following optical cables must be
connected between the IP-20N/IP-20A and the all-outdoor unit:
• Traffic Cable – Carries traffic between the IP-20N/IP-20A and the all-outdoor
unit.
• Protocols Cable - Carries L2 protocol data between the IP-20N/IP-20A and the
all-outdoor unit.
For details about the ports and port speeds that must be used for these
connections, refer to the User Guide for IP-20N and IP-20A.
6.2.6.2 PoE Support for All-Outdoor Units

All-outdoor units in a configuration with an IP-20N/IP-20A can receive PoE power
from the IP-20N/IP-20A. The following IP-20N/IP-20A ports can be used to supply
PoE power to an IP-50 or IP-20 all-outdoor unit:
• TCC-U: RFU1/ETH7 (Slot 1, Port 7)
• TCC-U: RFU2/ETH8 (Slot 1, Port 8)
Note: PoE is not available for IP-20C-HP.
6.2.6.3 Layer 1 Link Bonding Limitations

The following limitations exist for Layer 1 Link Bonding:
• Layer 1 Link Bonding cannot be used with LIC-STM1/OC3-RST cards. If TDM
services are required, a TCC-based Multi-Carrier ABC group should be used.
See Hybrid Multi-Carrier Adaptive Bandwidth Control (Hybrid MC-ABC).
• IEEE-1588v2 PTP Optimized Transport cannot be used with Layer 1 Link
Bonding groups unless the group includes one or more IP-50 and/or IP-20 all-
outdoor units. IEEE-1588v2 PTP support for Link Bonding groups that include
only RIC-Ds and/or RMC-Bs is planned for future release.
• Resiliency protocols (MSTP, G.8032) cannot be configured on members of a
Link Bonding group, but can be configured on the group.
• Service OAM (Y.1731) cannot be configured on members of a Link Bonding
group, but can be configured on the group.
• RMC-A cannot be used with Layer 1 Link Bonding groups.
• The maximum supported traffic ratio between members of a Link Bonding
group is 1:200. Exceeding this ratio (which is very rare) may lead to
degradation of the link.
Page 188 of 518

6.2.7 Multiband

• RFU-D or RFU-C
IP-20N and IP-20A can be used in Multiband configurations with IP-50E and IP-
20E.
Multiband bundles E-Band and microwave radios in a single group that is shared
with an Ethernet interface. This provides an Ethernet link over the radio with
capacity of up to 10 Gbps (with IP-50E) or 2.5 Gbps (with IP-20E). A Multiband link
is highly resilient because the microwave link acts, in effect, as a backup for the E-
Band link.
In the event of radio failure in one device, the other device continues to operate
to the extent of its available capacity. Thus, operators benefit from both the high
capacity of E-Band and the high reliability of microwave.
Multiband can be configured with an IP-50E or IP-20E and either of the following:
• RIC-D with an RFU-D
• RMC-B with an RFU-C
When using an RFU-D, the carriers can be configured as an RFU-based Multi-
Carrier ABC group.
Traffic is sent to the IDU from the E-band unit via an optical cable from the E-band
unit to any 1 Gbps optical SFP port on the IDU.
If it is necessary to provide management and/or synchronization to the IDU via
the E-band unit, an additional optical cable must be connected between the E-
band unit and any 1 Gbps optical SFP port on the IDU.
The following must be configured on the IDU:
• A service must be configured between the Ethernet port connected to the
E-band unit and the radio or Multi-Carrier ABC group being used for the
Multiband link. Any service type can be used. However, this service must be
given higher priority than any other service attached to the interfaces used for
Multiband.
• Automatic State Propagation, with ASP trigger by remote fault enabled.
• Radio BNM.
Note: The latency differential between the E-band unit and the
microwave unit cannot be more than 1.6 ms. That means that
under all foreseeable conditions, such as a high ACM profile on
one unit and a low ACM profile on the other unit, there should
be no more than a 1.6 ms difference between the latency of the
two radio carriers in the Multiband link.
Some of the details of Multiband operation differ depending on whether the IP-
20N or IP-20A is being used in a node with an IP-50E or an IP-20E. For details,
refer to the Technical Description for the IP-50E or IP-20E.
Page 189 of 518

6.2.8 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.8.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 and IP-20A provide 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.
Page 190 of 518

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 191 of 518

6.2.9 Radio Signal Quality PMs

IP-20N and IP-20A support 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 344. Users can also configure an alarm that is raised if the RSL falls beneath a
user-defined threshold. See RSL Threshold Alarm on page 344.
6.2.10 Radio Utilization PMs

IP-20N and IP-20A support 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). Up to three utilization thresholds can be
defined by users (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 192 of 518

6.3 Ethernet Features

IP-20N and IP-20A feature 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.
The service-oriented Ethernet paradigm enables operators to configure VLANs,
CoS, security, and network resiliency on a service, service-point, and interface
level.
IP-20N and IP-20A provide 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
• 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 193 of 518

6.3.1 Ethernet Services Overview

The IP-20/IP-50 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 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 Ethernet services
implementation.
The following figure illustrates the basic MEF Ethernet services model.
Figure 109: 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/SONET, 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 194 of 518

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 110: 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 195 of 518

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 111: 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 112: 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 113: Rooted Multipoint EVC
Page 196 of 518

In the IP-20N and IP-20A, 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 and IP-20A, bandwidth profiles are constructed using a full
standardized TrTCM policer mechanism.
Page 197 of 518

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
types of Ethernet services. IP-20N and IP-20A support 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 114: 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 49: 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)
Page 198 of 518

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.
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 115: E-Line Service Type Using Point-to-Point EVC
Page 199 of 518

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 116: 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 200 of 518

Figure 117: 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 118: 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 201 of 518

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 119: 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 120: 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 202 of 518

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 121: 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 203 of 518

The following figure provides an example of an EVP-LAN service.
Figure 122: 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 123: 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 204 of 518

can also be provided, effectively allowing for enhanced service reliability and
flexibility.
Figure 124: 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 205 of 518

The following figure provides an example of an EP-Tree service.
Figure 125: 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 206 of 518

Figure 126: Ethernet Virtual Private Tree Example
IP-20N and IP-20A enable 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 127: Mobile Backhaul Reference Model
The 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 207 of 518

(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 Universal Packet Backhaul Services Core

IP-20N and IP-20A address 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
services core, which is structured around the building blocks shown in the figure
below. IP-20N and IP-20A provide rich and secure packet backhaul services over
any transport type with unified, simple, and error-free operation.
Figure 128: Packet Service Core Building Blocks
Any Service
• Ethernet services (EVCs)
 E-Line (Point-to-Point)
 E-LAN (Multipoint)
 E-Tree (Point-to-Multipoint)27
• Port based (Smart Pipe) services
Any Transport
• Native Ethernet Transport (802.1q or Q-in-Q)
• Any topology and any mix of radio and fiber interfaces
27
E-Tree services are planned for future release.
Page 208 of 518

• 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, preservation,
and translation)
• Improved security/isolation without limiting C-VLAN reuse by different
customers
• Per-service MAC learning with 64K (TCC-U) or 128K (TCC-B, TCC-B2, TCC-B-MC,
TCC-B2-XG-MC) MAC addresses support
Fully Programmable and Future-Proof

• Personalized QoS (H-QoS) (TCC-U only)
• 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

• Superb service OAM (CFM, PM)
• Carrier-grade service resiliency (G.8032, MSTP)
Page 209 of 518

6.3.2 Ethernet Capabilities

IP-20N and IP-20A are 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. The 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 and IP-20A’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
• MAC learning table, with separate learning per service (including limiters), up
to 64K (TCC-U) or 128K (TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-MC) MAC
Addresses
• 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 64 queues per interface, 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 (L4 hashing requires TCC-B, TCC-B2, TCC-B-
MC, or TCC-B2-XG-MC)
• Enhanced <50msec network level resiliency (G.8032) for ring/mesh support
28
E-Tree service support is planned for future release.
Page 210 of 518

6.3.3 Supported Standards

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

6.3.4 Ethernet Service Model

IP-20N and IP-20A’s service-oriented Ethernet paradigm is based on Carrier-
Ethernet Transport (CET), and provides a highly flexible and granular switching
fabric for Ethernet services.
The 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
UNI
P2P
NNI
Service
SAP SAP
Multipoint Multipoint
SN
SA SNP Service Service
PP
SAP SAP
Multipoint Multipoint
Service Service
SAP
P2P
Service
Multipoint
Service
SAP
Figure 129: IP-20N and IP-20A Services Model
Page 212 of 518

The services core provides for fully flexible C-VLAN and S-VLAN encapsulation,
with a full range of classification, preservation, and translation options available.29
Service security and isolation is provided without limiting the C-VLAN reuse
capabilities of different customers.
Users can define up to 1,024 services on a single IDU. 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, the IDU 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 services model, with traffic entering and
leaving the network element. The IP-20N and IP-20A 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.
29
VLAN translation requires TCC-U and is planned for future release.
Page 213 of 518

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 130: 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 IDU.
• 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 65,536 (TCC-U
or 131,072 (TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-MC) entries, with a global aging
timer and a maximum learning limiter that are configurable per-service.
Page 214 of 518

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 131: Services Flow
6.3.4.2 Service Types

IP-20N and IP-20A support 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 215 of 518

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 132: 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.
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 133: Multipoint Service
Page 216 of 518

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 and IP-20A can learn up to 65,536 (TCC-U) or 131,072 (TCC-B, TCC-B2, TCC-
B-MC, TCC-B2-XG-MC) Ethernet source MAC addresses. The IDU 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.
The following table illustrates the operation of the learning and forwarding
mechanism.
Table 50: 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.
Page 217 of 518

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
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.
Page 218 of 518

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 134: 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 and IP-20A 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.
• 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.
Page 219 of 518

• 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 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 the hierarchical
classification mechanism, refer to Classification on page 244.
• 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 and IP-20A support 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 220 of 518

MNG
MNG MNG
MNG
MNG
MNG MNG
MNG MNG
MNG MNG
MNG
Figure 135: 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 221 of 518

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 136: 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 137: Pipe Service Points
Page 222 of 518

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 138: SAP, SNP and Pipe Service Points in a Microwave Network
Page 223 of 518

The following table summarizes the service point types available per service type.
Table 51: 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 224 of 518

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 52: 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 225 of 518

Table 53: 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 226 of 518

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 139: 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 227 of 518

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 228 of 518

• 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 263.
Page 229 of 518

6.3.5 Ethernet Interfaces

The 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 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 140: 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 230 of 518

When physical interfaces are grouped into a logical interface, IP-20N and IP-20A
also show 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
ce
l In terfa
LAG Lo gica
Physical Interface 2
SP SP Logical Interface Physical Interface 4

Service
Figure 141: 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 142: 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 231 of 518

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.30
• 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.
30
This functionality is planned for future release.
Page 232 of 518

• 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
IP-20N and IP-20A store and display 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 transmitted31
• Pause control frame transmitted
• FCS error frames31
• Frame length error31
• Oversized frames – frames with length > 1518 bytes (1522 bytes for VLAN-
tagged frames) without errors
• Undersized frames (good only)31
• Fragments frames (undersized bad)31
• Jabber frames – frames with length > 1518 bytes (1522 for VLAN-tagged
frames) with errors31
• 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.
• Frames with length 1519-1522 bytes, good or bad31
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.
31
Not supported with TCC-U.
Page 233 of 518

• Received frames (good or bad)

• Multicast frames (good only)
• Broadcast frames (good only)
• Control frames received31
• Pause control frame received
• FCS error frames
• Frame length error31
• 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 bad31
• Frames with length > MAX_LEN without errors31
• Frames with length > MAX_LEN with errors31
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 234 of 518

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 143: 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. The hierarchy
differs between units using TCC-U and units using TCC-B, TCC-B2, TCC-B-MC, and
TCC-B2-XG-MC.
Classification is performed according to the following hierarchy for units with
TCC-U:
• 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.
• DSCP Trust Mode –When this attribute is set to Trust mode and the arriving
packet has DSCP priority bits, the interface performs QoS and Color
classification according to a user-configurable DSCP bit to CoS and Color
classification table. If MPLS EXP priority bits are present, DSCP is not
considered regardless of the Trust mode setting and regardless of whether an
MPLS match was found.
• 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 and DSCP classification have priority over 802.1p Trust Mode, so that if
a match is found on the MPLS or DSCP level, 802.1p bits are not considered.
• 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.
Page 235 of 518

Classification is performed according to the following hierarchy for units with TCC-
B, TCC-B2, TCC-B-MC, and TCC-B2-XG-MC:
• 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.
• 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 245.
Ingress Path Rate Meters at Logical Interface Level

Note: Unknown unicast and unknown multicast rate meters are only
available for units with TCC-U.
• Multicast or Unknown-Unicast Traffic Rate Meter Admin – Enables or
disables the unicast rate meter (policer) on the logical interface.
• Multicast or Unknown-Unicast Traffic Rate Meter Profile – Associates the
rate meter (policer) with a specific rate meter (policer) profile.
• Multicast or Unknown-Multicast Traffic Rate Meter Admin – Enables or
disables the multicast rate meter (policer) on the logical interface.
• Multicast or Unknown-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
meter (policer) on the logical interface.
• 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
specific rate meter (policer) profile.
• 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).
Page 236 of 518


• 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.
Egress Path Shapers at Logical Interface Level

Note: Only available for units with TCC-B, TCC-B2, TCC-B-MC, and
TCC-B2-XG-MC.
• 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.32
• 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

TCC-B2-XG-MC.
• 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.
32
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 237 of 518

Logical Interface Statistics
RMON Statistics at Logical Interface Level

As discussed in Ethernet Statistics on page 233, if the logical interface represents a
group, such as a LAG or a 1+1 HSB pair, the IDU stores and displays RMON and
RMON2 statistics for the logical interface.
Ingress Frame and Byte per Color Statistics at Logical Interface Level
Note: Only available for units with TCC-U.
Users can display the number of frames and bytes ingressing the logical interface
per color, in granularity of 64 bits:
• Green Frames
• Green Bytes
• Yellow Frames
• Yellow Bytes
• Red Frames
• Red Bytes
Rate Meter (Policer) Statistics at Logical Interface Level

TCC-B2-XG-MC.
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.
Page 238 of 518

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. The load balancing function differs depending on the TCC
model. For units with TCC-B, TCC-B2, TCC-B-MC, and TCC-B2-XG-MC, an enhanced
LAG distribution function exists enabling users to select the distribution scheme
that best suits the link and network. This option is not available for units with
TCC-U.
LAG Load Balancing for Units with TCC-U

For units with TCC-U, the LAG distribution function uses the following parameters:
• Ethernet
 MAC – DA and SA
• MPLS
 For multiple MPLS labels, only the first is considered
• IPv4
 DA and SA, if up to three MPLS labels are defined
• IPv6
 DA Bytes 5-16 and SA Bytes 9-16 if there is no MPLS label
 DA Bytes 9-16 and SA Bytes 9-16 if up to three MLPS labels are defined
LAG Load Balancing for Units with TCC-B, TCC-B2, TCC-B-MC, and TCC-B2-XG-MC
Units with TCC-B, TCC-B2, TCC-B-MC, and TCC-B2-XG-MC use 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
The LAG distribution function is implemented as follows:
• The hashing is done over the packets header, up to L4
• The 4 LSBs of hashing provide 16 possibilities for streams to hit
• Per each result one port out of 16 LAG members is assigned
• The default assignment is cyclic. For example, for 3-port LAG the ports are
assigned as 1-2-3-1-2-3-1-2-3-1-2-3-1-2-3-1
Page 239 of 518

The user must analyze the Tx traffic load over the link members of the LAG and
decide whether the load balancing is appropriate. If it is not, the user should
select a different distribution function from the list of predefined functions and
check the result again.
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 Configuration (All TCC Models)

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).
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
or with a 10GE interface on the TCC-U, 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.
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.
Page 240 of 518

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, not logical interfaces, can belong to a LAG group.
• It is recommended not to include radio interfaces in 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 and IP-20A enable 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 241 of 518

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 and IP-20A’s personalized QoS enables operators to handle a wide and
diverse range of scenarios. This 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 the 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 144: 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 242 of 518

• 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 bundle33, and per port).
• Marker – This mechanism provides the ability to modify priority bits in frames
based on the calculated CoS and Color.
For units with TCC-U, 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). In H-QoS mode, the IDU performs QoS in a hierarchical manner in
which the egress path is managed on three levels: logical interfaces, service
bundles, and specific queues. This enables users to fully distinguish between
streams, therefore providing a true SLA to customers.
For units with other TCC models, only Standard QoS is available.
Note: H-QoS is planned for future release. It will only be supported
with TCC-U.
33
Service bundles are only relevant for units with TCC-U.
Page 243 of 518

The following figure illustrates the difference between how standard QoS and H-
QoS handle traffic:
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 145: Standard QoS and H-QoS Comparison
6.3.6.1 QoS on the Ingress Path
Classification
IP-20N and IP-20A support 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 244 of 518

The classification hierarchy differs depending on whether the unit has a TCC-U or
a TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-MC.
The following figures illustrate both hierarchical classification models. In these
figures, 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
Port Logical Interface
SAP SNP
SAP
Service level
Logical interface level • Default CoS
• MPLS EXP-based CoS • Preserve Service Point Decision
• DSCP-based CoS
• 802.1p-based CoS
• Default CoS
SAP SNP
SAP
Service
Figure 146: Hierarchical Classification – TCC-U
Service point level

• Preserve previous decision
• Default CoS
• Destination MAC Address (MAC DA)
Port Logical Interface
SAP SNP
SAP
Logical interface level Service level
• VLAN ID • Default CoS
• 802.1p-based CoS • Preserve Service Point Decision
• MPLS EXP-based CoS
• DSCP-based CoS
• Default CoS
SAP SNP
SAP
Service
Figure 147: Hierarchical Classification – TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-MC
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 classification hierarchy differs between units using TCC-U and units
using TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-MC.
Page 245 of 518

Logical Interface-Level Classification – TCC-U

For units with TCC-U, 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
 MPLS EXP field.
 DSCP bits (only considered if MPLS is not present, regardless of trust setting)
 802.1p bits
 Default CoS
The IDU 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.
Users can disable some of these classification methods by configuring them as un-
trusted. For example, if MPLS classification is configured as un-trusted for a
specific interface, the classification mechanism does not perform classification
according to the MPLS EXP bits. This is useful, for example, if the required
classification is based on 802.1p bits.
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 MPLS EXP DSCP 802.1p Default CoS
Lowest
Priority
Figure 148: Classification Method Priorities – TCC-U
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 235.
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.
Page 246 of 518

Table 54: MPLS EXP Default Mapping to CoS and Color – TCC-U
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
Table 55: DSCP Default Mapping to CoS and Color – TCC-U
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
Page 247 of 518

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.
Table 56: C-VLAN 802.1 UP and CFI Default Mapping to CoS and Color – TCC-U
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
6 1 6 Yellow
7 0 7 Green
7 1 7 Yellow
Table 57: S-VLAN 802.1 UP and DEI Default Mapping to CoS and Color – TCC-U
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
Page 248 of 518

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
Logical Interface-Level Classification – TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-MC

For units with TCC-B, TCC-B2, TCC-B-MC, and TCC-B2-XG-MC, 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 (If MPLS is set to un-trusted, DSCP bits are not considered)
 Default CoS
The IDU 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.
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.
Page 249 of 518

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 MPLS EXP DSCP Default CoS
Lowest
Priority
Figure 149: Classification Method Priorities – TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-

MC
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 235.
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 58: C-VLAN 802.1 UP and CFI Default Mapping to CoS and Color – TCC-B, TCC-B2, TCC-
B-MC, TCC-B2-XG-MC
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
Page 250 of 518

7 0 7 Green
7 1 7 Yellow
Table 59: S-VLAN 802.1 UP and DEI Default Mapping to CoS and Color – TCC-B, TCC-B2, TCC-
B-MC, TCC-B2-XG-MC
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 60: MPLS EXP Default Mapping to CoS and Color – TCC-B, TCC-B2, TCC-B-MC, TCC-B2-
XG-MC
0 0 Yellow
1 1 Green
2 2 Yellow
3 3 Green
4 4 Yellow
5 5 Green
6 6 Green
Page 251 of 518

7 7 Green
Table 61: DSCP Default Mapping to CoS and Color – TCC-B, TCC-B2, TCC-B-MC, TCC-B2-XG-
MC
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.
For the DSCP mapping table, users can modify not only the CoS and Color per
entry, but also the Description. In addition, users can delete and add entries to
the table, up to a maximum of 32 entries.
Page 252 of 518

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)
 Default service point CoS
 MAC DA
Note: MAC DA Classification is not available for units with TCC-U.
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 provides 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
Page 253 of 518

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.
Rate Meter (Policing)

IP-20N and IP-20A’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 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 meter34
• Service point CoS-level rate meter35
MEF 10.2 is the de-facto standard for SLA definitions, and the QoS
implementation in IP-20N and IP-20A 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 and IP-20A provide 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.
34
Service point-level rate metering is planned for future release.
35
Service point and CoS-level rate metering is planned for future release.
Page 254 of 518

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
Note: For units with TCC-U, ingress rate meters can be configure per
service point or per service point CoS, but not on both.
CoS 1
Service Frame
CoS 2 Ethertype
Point Type
CoS 3
Figure 150: Ingress Policing Model
For units with TCC-U, users can attach and activate a rate meter profile at the
logical interface level, and on a service point or service point + CoS level.
For units with TCC-B, TCC-B2, TCC-B-MC, and TCC-B2-XG-MC, users can attach and
activate a rate meter profile at each level (logical interface, service point, and
service point + CoS).
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 10 Gbps for units with
TCC-U and 0 to 1 Gbps for units with TCC-B, TCC-B2, TCC-B-MC, and TCC-B2-
XG-MC, with a minimum granularity of 32Kbps.
Page 255 of 518

• 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 1 to 4096 Kbytes for units with TCC-
U and 0 to 8192 Kbytes for units with TCC-B, TCC-B2, TCC-B-MC, and TCC-B2-
XG-MC, 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 10 Gbps for units with TCC-U and 0 to 1 Gbps for units with
TCC-B, TCC-B2, TCC-B-MC, and TCC-B2-XG-MC, 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 1 to 4096 Kbytes for units with TCC-U and 0 to 8192 Kbytes for
units with TCC-B, TCC-B2, TCC-B-MC, and TCC-B2-XG-MC, with a minimum
granularity of 2 Kbytes.
Note: For units with TCC-U, EIR and EBS are only relevant for rate
meters assigned to logical interfaces. For Known and Unknown
Unicast, Known and Unknown Multicast, and Broadcast, the
policer profile must be configured to EIR=0, Color Mode=Color
Blind, and Coupling Flag=Disabled.
• 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 234.
Page 256 of 518

• 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 and Unknown-Unicast rate meter
• Multicast and Unknown-Multicast rate meter
Note: Unknown-Unicast and Unknown-Multicast rate meters are only
available for units with TCC-U.
• Broadcast rate mete
• User defined Ethertype 1 rate meter
For each rate meter, the following statistics are available:36
• Green Frames (64 bits)
• Green Bytes (64 bits)
• Yellow Frames (64 bits)
• Yellow Bytes (64 bits)
• Red Frames (64 bits)
• Red Bytes (64 bits)
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:36
36
Rate meter statistics are not available for units with TCC-U. Instead, general ingress statistics are
available. See Ingress Statistics on page 282.
Page 257 of 518


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: 36
Ingress Statistics
Note: Only available for units with TCC-U.
Users can display the following statistics counters for ingress frames and bytes per
interface and per service point:
Service point statistics can be displayed for the service point in general or for
specific CoS queues on the service point.
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 and IP-20A support up to 64 transmission queues per interface
(with H-QoS), 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.
Page 258 of 518

• 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.
The 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 151: 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.
Page 259 of 518

Ceragon Technical Description IP 20N IP 20A 1 259

Uploaded by

Copyright:

Available Formats

Ceragon Technical Description IP 20N IP 20A 1 259

Uploaded by

Document Information

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 Technical Description IP 20N IP 20A 1 259

Uploaded by

Copyright:

Available Formats

Technical Description

Open Source Statement

Ceragon Proprietary and Confidential

3. IDU Hardware Description ....................................................................................... 54

Ceragon Proprietary and Confidential

4. RFU Hardware Description and Branching Options ................................................. 101

5. Activation Keys ..................................................................................................... 126

6. Feature Description............................................................................................... 134

Ceragon Proprietary and Confidential

6.2.6 Layer 1 Link Bonding ................................................................................................................186

7. Unit Management ................................................................................................. 330

Ceragon Proprietary and Confidential

7.10 CeraPlan Service for Creating Pre-Defined Configuration Files ...............................................342

8. Standards and Certifications .................................................................................. 357

Ceragon Proprietary and Confidential

9.4.1 Transmit Power with RFU-D .....................................................................................................437

Ceragon Proprietary and Confidential

9.14.1 RFU-D and RFU-S Waveguide Specifications ............................................................................515

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Figure 23: TCC-B .....................................................................................................................................78

Ceragon Proprietary and Confidential

Figure 58: RFU-D Interfaces (All Frequency Bands)..............................................................................107

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Figure 163: Boundary Clock – General Architecture ............................................................................306

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Table 68: Native Sync Interface Options – ANSI Systems--------------------------------------------------------- 293

Ceragon Proprietary and Confidential

Table 103: Radio Capacity for 112 MHz ------------------------------------------------------------------------------- 389

Ceragon Proprietary and Confidential

Table 138: Radio Capacity for 50 MHz --------------------------------------------------------------------------------- 417

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

Table 207: Optical STM-1 SFP Interface Specifications ----------------------------------------------------------- 506

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

EVC Ethernet Virtual Connection

Ceragon Proprietary and Confidential

Acronym Equivalent Term

PDU Power Distribution Unit

Ceragon Proprietary and Confidential

Acronym Equivalent Term

TCC Traffic and Control Card

Ceragon Proprietary and Confidential

Ceragon Proprietary and Confidential

This chapter includes:

Ceragon Proprietary and Confidential

2.1 Product Overview

Ceragon Proprietary and Confidential